> Java (ant->maven->gradle)
Maven is declarative.
I'd say aggressively so. It has its escape hatches (antrun, groovy-maven-plugin), but a well written pom.xml should be 100% declarative. Maven is disliked because it is annoying to extend (it's primarily extensible in Java, which makes for a poor scripting language) and because the configuration uses a bloated form of XML (everything is a tag; it could have made a lot of things attributes and life would have been much nicer).
But in many regards Maven is a great example of a declarative build system. I'd say more build tools should copy its core concepts (good repo format, convention over configuration, extensibility through clearly defined interfaces used by plugins) and just avoid its main issues.
As a regular creator and user of Archetypes, I would have to disagree about the difficulty in using/discovering them. I use archetypes all of the time and know that a lot of our JUG members use them as well. As for the ability to customize them, you can use the archetype descriptor file to specify required values from the user and use those values as velocity template values in your archetype resources to replace anything in your resource files. I think that the problem here is more about not understanding the tooling available.. I will freely admit that the Maven docs for archetypes could be a lot more user friendly.
EDIT: Spelling are hard!
Congratulations, you're about to learn what maven is! This is the gold standard of Java project configuration and dependency management. If you are wise and ambitious you will learn all you can about it.
As for sharing there's google code, github, sourceforge, and so on.
Maven has a steep learning curve but the investment pays off in magnitudes. Persist.
Of course! You just package your application into a jar.
There is a neat assembly plugin that put every third party libs and dependencies into the final jar, that can be then easily distributed.
Maven is a dependency management system and build tool for Java applications.
If the app you're working on is using maven, there should be a pom.xml file in the project root directory.
Maven and other build tools.
Learn servlets, server pages, server faces, etc. just to understand Then learn a Java web app framework like spring or struts. Make sure you grok MVC and how modern web applications are organized.
Effective Java is like the Bible where I work. Honestly, if you work your way through that and understand every bit of it, then you're pretty well ahead of the curve.
Ant is a way to script your builds. You create (or use) tasks to compile, test and assemble your source to get some kind of artifact. Since it is mainly used for Java projects, you'll mainly end up having jar-files as the artifacts it produces.
You don't have to use it but most IDEs (silently) create ant tasks for you so that when you hit "clean and build" (or similar) it actually just runs the ant-script. If you want to do things not directly supported through the IDE, you will want to edit the ant manually.
There are mainly one "competitor" to ant in Maven, also created and maintained by the Apache Software Foundation.
I'm not sure how blueJ handles build configuration so I can't say how it differs from ant (maybe it uses ant behind the curtains). However, most IDEs will create ant scripts behind the scenes (or maven if you tell them).
I'm not an ant user myself so as I said, you don't have to use it. But you should probably learn at least one of the two main build "systems" (maven or ant).
The benefits of ant depends on what you compare it to. Compared to manually building by calling javac from a command line it has obvious benefits in that you can write the "commands" once and then just run the script instead of having to first call javac, setting the classpath and then jar the result, and run tests on the produced classes.
TL;DR It's a way to manage your build.
The classpath is where the Java runtime looks for referenced classes.
If you're using Maven you really should just let it handle running the tests.
I don't know Groovy, yet I've been using Gradle quite successfully for a few years now. All I need to know is how to merge collections (+), the string interpolation syntax, and maybe an if
statement here and there.
OTOH, to use Maven you have to learn the Maven API, because sooner or later you'll need to write your own plugin.
Let me put it this way: with Maven I had to resort to custom plugins sooner than I had to learn Groovy -- beyond those expressions I mentioned -- when using Gradle.
I agree: the Maven philosophy is better. Unfortunately, it just doesn't work in practice. Build processes require scripting. Here's a list of some Maven plugins you'll need to learn, and those are only the ones directly supported by the Maven team. True, Gradle has plugins, too, but you often don't need them.
>People continue to show interest in a Maven repo, just tell me what I need to do to help set it up.
It's already here: http://civcraft.org:8080/plugin/repository/everything/
To use it, you would add this repo to your local maven settings as described here: http://maven.apache.org/settings.html#Repositories
yes, the latest Apache Maven Release is 3.2.1 (3.0.5 was a sec fix)
http://maven.apache.org/docs/3.2.1/release-notes.html
and Maven 2.2 is in EOL http://maven.40175.n5.nabble.com/End-of-Life-Apache-Maven-2-x-td5785222.html
> No, AFAIK, Maven can't have multiple versions of the same library being used at the same time. Someone correct me if I'm wrong there.
Since the request was made; you're wrong. :)
It can have different transient dependencies if you allow it, and it can tell you when it might be a problem: http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
Oh I should probably have given a link. Turns out the maven documentation gives a pretty good description on what profiles are and how to them: http://maven.apache.org/guides/introduction/introduction-to-profiles.html
Spring is a huge beast which has been around about 10 years. There are tons of books. I would serious look at spring boot. find some online tutorials.
WRT maven. maven serves as NuGet and MSBuild. It's very pluggable and flexible so you can find tons of other stuff as well.
https://spring.io/guides/gs/spring-boot/
before you follow that get a recent JDK (8 please ? ) and maven (http://maven.apache.org ).
The MDK one has a pretty good readme.
The sysml one I'm not sure of, since I've never used it before. Typically, you install maven and then include the artifacts you want in your own pom, then maven includes them for you.
From what little I can tell, you're going to have a bit of knowledge of sysml and java to get up to speed... maybe you need to find a mentor who knows both?
Also, I found: https://github.com/Open-MBEE/ProjectWiki which seems to have more info in general.
SourceForge is more or less dead. Service Unavailable simply means the server isn't responding.
You could use the maven command line version instead: http://maven.apache.org/plugins/maven-checkstyle-plugin/download.cgi
Edit: Oh, I seem to have found the DL link via google cache. You'll have to install it manually though: http://downloads.sourceforge.net/project/eclipse-cs/Eclipse%20Checkstyle%20Plug-in/6.5.0/net.sf.eclipsecs-updatesite_6.5.0.201504121610-bin.zip
I haven't used that plugin, but the only way I know of to manipulate properties in this way is with the Groovy Maven plugin.
Here's an example that generates a snapshotless version string:
<plugin> <groupId>org.codehaus.groovy.maven</groupId> <artifactId>gmaven-plugin</artifactId> <executions> <execution> <phase>generate-sources</phase> <goals> <goal>execute</goal> </goals> <configuration> <source> System.setProperty("baseVersion", "${version}".replace('-SNAPSHOT', '')) </source> </configuration> </execution> </executions> </plugin>
That said, this example appears to only use the <directory>
tag. Maybe it's of some help.
> Oh, it turns out, you can't do that anymore. You could previously, but you can't now.
I'm not sure what you mean by that, I do that all the time when developing. If I want to install a library locally I just do lein install
from the library folder and it's in my local repo. I can just use it like any other dependency. You can also trivially install any jar you want locally using Maven.
There isn't really a single convention that all projects use. Even amongst a single language, you're going to find a lot of variance.
However, it's very common to have a README
file in the base directory that details information about the project, an AUTHORS
or COPYING
file that details licensing information and/or credits, and a src
folder that contains all source files (possibly in further sub directories). Binaries (which aren't usually in version control) are typically placed in a bin
folder.
I'm rather fond of the Apache Standard Directory Layout. It's meant for use with Maven (a Java build tool), but is language independent. I've seen projects in various languages that use this directory layout (or close to it). It also works very well for projects with multiple languages.
>Is there any particular reason it isn't "steam-api/src/" for code, "steam-api/test/" for test and "steam-api/resources/" for resources or somesuch flatter convention?
Then you would have source code both in /src and /test and both resources and test resources in /resources. The reason there is a project/src level is because the output of the project goes into project/target. Also see Introduction to the Standard Directory Layout.
This is what build tools like Ant,Maven and Gradle are for. I would recommend using Ant if you are a beginner since it is a bit easier to write build script with. You then essentially layout a directory structure that is <projectname>/src and <projectname>/libs and you put the .jar files from third-parties (in this case, robocode) in to there and then write a build.xml (for ant, pom.xml for maven) that goes in <projectname> and then you just write a task that compiles your code in the /src folder using the jars in the /libs folder. Then you can just run 'ant jar' from the command line. Most IDEs will also let you add a reference to a 3rd party library/jar file too if you would rather do that.
So what's your actual goal? If you want to make modifications to the bitcoinj project, you should import that through eclipse using the default import feature. It will allow you to import a maven project. Then you can look at the actual bitcoinj code and play with it as you want. You can then use mvn test, install, etc. either through the plugin or command line.
If instead you want to create your own separate project that utilizes the bitcoinj library then there is no requirement to use maven. You just need to include the bitcoinj .jar file in your classpath so you can access the classes. If you want to use maven to do this for you, you certainly can, but it's not required. If you want to use maven you will need to create a new maven project from scratch (the plugin should also be able to do this) and then add the bitcoinj dependency to the pom.xml for your project.
I would recommend Maven's 5-minute guide if you haven't seen it already.
Of course it is possible, but it may be complex.
First, what kind of application are you talking about? A runnable jar? A standalone java application with a prepackaged VM? An android .apk? A J2ME Midlet? An eclipse app? Java runs in so many environments now that your question cannot be answered easily without further information.
In any event, assuming you already know what to change and how to change it, this is only the first step to change the application. See, Java is a compiled language, so you need to build the application. Ideally, the source code you have contains some kind of build script (look for build.xml which can be used with Ant, pom.xml for Maven, a .gradle script (see Gradle) or even a Makefile that you can execute - assuming you have the requisite build system.
This build process will hopefully result in your application .jar, .exe, .war, .apk or other package. Depending on the type of applications, there may be other steps required (e.g. signing an application) before your package is fully usable.
This is all ignoring the question wether it's legal to create a custom build of the application, which depends on the license under which you got the application including the source code. If you only want to extend the application for yourself, this probably won't be a problem, though I am not a lawyer and in case of uncertainty would advise anyone to consult with one before proceeding. ;-)
I actually don't mind putting compiler output in a repository. However, I think it should be a separate repository. That helps with speed, and it allows you to change your mind if you feel like it.
Basically, there's nothing wrong with preserving build artifacts; I just don't want them cluttering up the repository I use for source code.
On a side note, there are a few repositories out there meant specifically for build artifacts. For example, Ivy is a system for going out and grabbing binaries that have already been built, and Maven is a system for doing that and a ton of other things related to building.
Since I know my post isn't very informative, you may want to repost this on a different forum.
I've never used Maven, but I have used Apache Ant. They're both build tools. I loaded Eclipse for a couple seconds and found that you can Right click on the project folder, go to Configure, and Convert to Maven Project. This then "creates a new pom.xml" for you. Sorry if this isn't enough, but I don't know anything about Maven.
Here's some stuff I found: * http://static.springsource.com/projects/documentation/index.html * http://www.theserverside.com/news/1364572/Maven-Magic * http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Simple_Project
Well, since no one else answered, I'll give it a shot, though I am far from an expert*.
Apache Maven is an open source build system, inspired by make and sort of the successor to Apache Ant. I say sort of, because maven can integrate Ant build scripts into the Maven build process.
*I am currently working my way through the book Maven:The Definitive Guide, which has an Ant Eater on the cover. The book was developed by sonatype.com, and much of the same material in the book seems to be available here I found this post when I was searching reddit to see if there was a Maven sub reddit.
New project probably just refers to the notion of an eclipse project. I.e. the location of the .project file.
I would recommend maven as a standard project structure to use instead of the old src/lib layout that eclipse generates (if i remember correctly).
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Try Mockito it will allow you to mock any classes you need. So you can mock the response coming from the server.
Also the package structure is not what I'd usually expect to see. Have a look at Maven's default package structure. It's a very popular tool but you don't have to use it to follow the structure.
Surefire does have a [failIfNoTests](http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#failIfNoTests] option.
But she if there is a way to ensure a count above a certain threshold. You might need to examine the rest report by at that point you are better off measuring coverage rather than number of tests.
I'm using the maven shade plugin to create a fatjar. In the configuration section I remove all the module-info classes from the final file:
<filters> <filter> <artifact>:</artifact> <excludes> <exclude>module-info.class</exclude> </excludes> </filter> </filters>
Will try this, thanks! I assumed this doesn't work based on the Maven documentation here.
You need to change this :
"version = "1.0" group = "com.yourname.modid" // http://maven.apache.org/guides/mini/guide-naming-conventions.html archivesBaseName = "modid""
Change "group" to the package of your mod, for example "fr.leonard.anmod" And change "modid" to your mod id. For example "ic2". You can change "version" everytime you export your mod to a new version.
When you have modified the build.gradle, do grade build in the terminal. You can find your mod in an folder (I don't remember).
This all depends on how you create the projects. If it's Java i suggest ypu use Maven for all projects (even simple Hello World projects). Initialize them anywhere outside of IntelliJ, like in the terminal with commands taken from this site http://maven.apache.org/guides/getting-started/index.html#How_do_I_make_my_first_Maven_project then in IntelliJ at the right hand side under the "Maven" tab press the plus sign/icon and choose your project. Do this as many times as you like and all will be in the same "workspace". When you want to remove something, just right click in the same Maven tab and remove the module.
Maven assembly plugin
> The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive.
Maven: you need library A for your code. You could download a .`jar` with that library and put it you project folder. But if that library depends on some other library B you would get an error and would be forced to download B `.jar`. Rinse and repeat. Or you could use maven - all you would need is to write (for instance, for JSON library):
<dependency> <groupId>org.json</groupId> <artifactId>json</artifactId> <version>20180813</version> </dependency>
If there are some B, C, D, E libraries library A directly or indirectly depends on, maven would get them for you.
Also, there is a <build></build>
tag in Maven. In that tag you could specify some stuff you want to do when your project is built.
What means project is built? First Maven downloads dependencies, compiles your source code, does some other stuff you may have specified in the build tag and packages your project into a `.jar`, `.war` or maybe something else, depending on what you write in tag <packaging>
.
In your Maven's pom.xml
file (basically a guidebook for Maven on what you want it to do) you can also specify a place where Maven would put your compiled sources: <outputDirectory>
which is also located inside build tag. You could also ask Maven to move some files/folders around during the build process, for instance ask it to copy folder with downloaded .jar
s into some other place inside your project.
There's an official tutorial where you can see some examples and other useful tags/things Maven could do if you ask it to.
​
This question is nothing IntelliJ specific. Everything you needs to know is in the maven documentation: http://maven.apache.org/guides/mini/guide-creating-archetypes.html
Probably, but don't be intimidated by that. Even a moderately sized project can span thousands of classes across a multitude of third-party frameworks and libraries. The actual business logic might be contained in a couple hundred classes if not less.
Are you worried that such a thing would be difficult to compile? If you use a build tool like Maven or Gradle then building a project or that size becomes actually doable.
If you want to compile a jar from the command line you can use the apache-maven. Once you get the maven download extracted you should have an executable called "mvn". Navigate to the root of the BesterArmor plugin directory and run "~/whatever/path/to/mvn package". This will attempt to compile the java files and pack everything up into a jar. Occasionally you will run into dependencies in the pom.xml file that no longer exist in the provided repository URLs; I've yet to figure out how to effectively deal with that, other than hoping I can find the dependency on another repository. Of the three or four plugins I attempted to compile from CivCraft's github I was only able to successfully compile FactoryMod after tweaking around the pom.xml dependency names. I did a test compile of the BesterArmor github repo and it seems to build fine. I didn't load it into the server to see if it crashed/error'd though.
Most projects I've seen will follow standard maven directory layout, for starters:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
It makes it easier for others (who are familiar with maven) to see your code, and to run it (maven builds expect by default source files and whatnot to be in this directory). So, your source code will for the most part be placed in src/main/java/<package>.
In addition, convention generally follows that packages be named like so:
So, for example, my project for school last year, was an implementation of a board game. I don't have my own website (because I'm a noob ^_>), so I used the school's. My package was then:
ca.myschool.boardgame.<further packages>
If you looked through a directory, my project was then laid out as:
BoardGame/src/main/java/ca/myschool/boardgame/
After that, it gets a bit more personal. Try to organize the code into logical sections, such as model classes, business logic (the work of the program), the display, etc. For my project, I organized the into a couple packages, such as "entity" (entity classes, such as the player's character, ai characters, etc.), "gui" (for the window, panes, etc.), "item" (items in the game, weapons and armor), "network" (networking), etc.
As for your specific problem, are you using package statements correctly? If your file is under:
src/main/java/cookies/YourClass.java
then at the top of the file, there should be:
package cookies;
Importing the file into another becomes:
import cookies.YourClass;
> preferred in some cases
depends on if you're doing it right or want to produce some throwaway project. Either your dependencies are in your source as a dependant module, or you have them someplace accessable ~/.m2 if you're a lone wolf, or trivial nexus/artifactory repo. Another [hacky] option is to give everybody instructions on using something like http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
Why not use vim keybindings for Eclipse?
On the more serious side, start with the oracle java trails and if you're more intermediate and are using libraries and such, use maven.
Eclipse has an option to export project as a runnable jar. If you are using maven you can use the shade plug in
http://m.wikihow.com/Create-an-Executable-File-from-Eclipse
http://maven.apache.org/plugins/maven-shade-plugin/examples/executable-jar.html
Dependencies can also be compiled against, but not packaged with a jar. This usually occurs when you're relying on the dependencies to be provided for you.
For example, I compile my Spark jobs against the Scala library and the Spark libraries. But as they will be provided at runtime by the Spark executor, I can omit them from my JAR, greatly reducing the size of it when compiled - this makes the difference between a 75MB JAR and a 440KB JAR.
In a Maven build you specify scopes for a dependency - the default is 'compile' which will also package it. 'provided' is the one I'm using to compile against, but omit from packaging.
I am downloading manually during library setup, but referencing them locally without installing to a repo is messy and strongly discouraged.
I had to resort to this mess to compile, just what I was trying to avoid: http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
Arh cool! I will check that out. Any suggestion on the placement of the Maven binaries? As fare as I understand it's used by the IDE, so I wont be running it myself.
The install notes just says to leave wherever I prefér ...
> Installing Maven > ---------------- > > 1) Unpack the archive where you would like to store the binaries, eg: > > Unix-based Operating Systems (Linux, Solaris and Mac OS X) > tar zxvf apache-maven-3.x.y.tar.gz > Windows 2000/XP > unzip apache-maven-3.x.y.zip > > 2) A directory called "apache-maven-3.x.y" will be created. > > 3) Add the bin directory to your PATH, eg: > > Unix-based Operating Systems (Linux, Solaris and Mac OS X) > export PATH=/usr/local/apache-maven-3.x.y/bin:$PATH > Windows 2000/XP > set PATH="c:\program files\apache-maven-3.x.y\bin";%PATH% > > 4) Make sure JAVA_HOME is set to the location of your JDK > > 5) Run "mvn --version" to verify that it is correctly installed. > > For complete documentation, see http://maven.apache.org/download.html#Installation
> That sounds like you havent worked on a very complicated project with custom steps for xsd achema generation or setting up and tearing down for integrarion tests or running ant acripts. Theres more to it than just the directory structure
All those things happen in modules that the final module is dependent on.
Also, there are plugins for all the things you talked about:
xsd schema generation - http://mojo.codehaus.org/jaxb2-maven-plugin/usage_schemagen.html
integration tests - http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
including running ant scripts - http://maven.apache.org/plugins/maven-antrun-plugin/
Sounds like you need to better modularize your build process and learn the capabilities of tools that you're using (or being forced to use by the sound of it, hence the resistence)
At my last job I did a lot of work with Maven. I found the way to integrate with Eclipse was through the maven-eclipse-plugin. If you have your project setup right you should be able to run 'mvn eclipse:clean eclipse:eclipse' which will generate the eclipse files. After that in Eclipse you should be able to use 'import as existing project'. This avoids using something like m2eclipse which I personally don't like.
ahem GOOGLE!
What is it: Maven is a build automation tool for java.
In simple terms: Source code and config file listing dependencies goes in, magic, then compiled code comes out.
Other fancy stuff is available like: * running unit tests to ensure bugs don't reappear in your code. * processing files before compiliation * bundling libraries into the final jar.
http://en.wikipedia.org/wiki/Apache_maven
It works with pretty much every OS that supports java.
Tutorials and instructions, see links above, google and youtube.
Thanks. I've made a little progress. I checked out the Maven in 5 Minutes page here: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html, created a new project, edited the pom.xml file, and finally ran 'mvn dependency:copy-dependencies'. Then, I added the jars to my Eclipse build path, and now my test compiles.
On a more general note, you could look into either maven or ant with ivy to handle build life cycle and dependency management. Both of these solutions are fairly heavy-weight, but work nicely once everything is configured properly. They have the concept of declaring the project dependencies and publishing libraries to a well defined and versioned location. They'll take care of the actual publishing to the repository and downloading dependencies once setup with a simple command.
Using ant? http://code.google.com/p/jarjar/ Using maven? http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies
Both should give you a single executable jar file that includes all needed libs. And .. NO .. zipping a dir isn't complicated.
Maven can help automate 'things' or tasks for compiling, development, and/or deployment. Learn from the source itself. If that's enough, then convince your boss to buy you a couple of books on Maven.
android-maven allows you to use maven easily with android development. I submitted it
I use maven. Take a look to assembly plugin, or with dependency:copy-dependencies you can create later a zip file with everyhting you need (or deb file).
I use maven. Take a look to assembly plugin, or with dependency:copy-dependencies you can create later a zip file with everyhting you need (or deb file).