I've been working on this all day and can't seem to find a solution to fit my requirements.
Addition to compile life cycle that generates code. (I thought a MOJO would work here)
MOJO depends on compiled code to generate 'new' parts.
MOJO is only ever going to be required for this maven project.
I cannot alter the definitions of the existing maven project which
is a fully compliant maven infrastructure and packaging of jar. (So
I cannot create the MOJO as a module of this)
Is there any way I can create this step as part of the maven lifecycle?
I've tried a dozen different routes and they either cause issues as I try to declare the dependency as it self and goes into an infinite loop, or if I make the MOJO as a child of the project (part of the src), I have no way to automatically compile the MOJO's project during the compilation of the main maven project.
Related
How to properly set up maven-shade plugin in a multi-module maven project setup?
storyline
A (https://github.com/DataSystemsLab/GeoSpark) has a dependency on B (https://github.com/jiayuasu/JTSplus) is a fork of C (com.vividsolutions.jts)
Now for some tasks in my project I need to use D (http://www.geotools.org) which depends on another Version of com.vividsolutions.jts.
How can I use both jars in a single project? A simple dependency replacement unfortunately does not work here. Shading should be the solution.
first attempt - shading the parent pom
When I try to apply the maven-shadeplugin to the root pom of https://github.com/DataSystemsLab/GeoSpark/blob/master/pom.xml as outlined Using Maven shade plugin in a multi module project - NullPointerException a null pointer exception occurs
multi project setup
When following How to configure Maven shade plugin in a multi-module project? to set it up for a multi module build the maven build compiles at least. However, the generated jar is lacking the actual code of the geospark module. I can't see where this would be filtered.
My changes are available https://github.com/geoHeil/GeoSpark/commit/23d212aeeeacad8b7199da69366d583fc48edcf0
With the main changes being:
introducing a third module FinalModule
shading only enabled there replacing com.vividsolutions.jts with com.vividsolutions.jtsgeospark
Indeed, disabling magnification is the solution. Otherwise probably explicitly including desired artifacts would work as well.
Is there a way for a maven project to contain local maven plugin (maven mojo classes) that can be used within the project directly, from the local classpath, without a need to do a maven install first?
With Maven the "build related code" (though declarative, not imperative) lies in your project's POM (Project Object Model, pom.xml). The runtime environment for these declarations is the installed Maven.
Once you become familiar with POMs and its ideas and concepts it's even simpler than coding build related things – at least from my, and many many others, POV.
If you really want or even must code something use GMavenPlus to use Groovy code inside your POM or create your own plugin(s) and use Maven as runtime environment for them.
I have a small (4 module) maven project with the root pom in pom packaging. Right now, I have a impl module that contains the main methods and setup. This does lead to some issues, eg building a single jar for the entire project, (possible) huge dependency list containing all modules, and confusion trying to trace back to the main method for future developers.
So I'm thinking: Is it best practice to put this kind of stuff in the root project, or should it stay in its own module? Would there be any disadvantages of putting it in root (eg plugin issues)?
This does lead to some issues, eg building a single jar for the entire project
There are solutions for this (e.g. using a dedicated module and the Maven Assembly Plugin or the Maven Shade Plugin).
(possible) huge dependency list containing all modules,
I didn't understand what you're referring to here.
and confusion trying to trace back to the main method for future developers.
Just document things if nobody can transmit the information.
So I'm thinking: Is it best practice to put this kind of stuff in the root project, or should it stay in its own module? Would there be any disadvantages of putting it in root (eg plugin issues)?
Stephen is correct, aggregating and/or parent POMs must have a packaging of type pom and you can't put any code in them.
AFAIK, the parent module of a multi-module project has to have type "pom" and that would preclude putting any code or other resources into it.
Certainly, I wouldn't try this.
If you want to have all of your classes, etc assembled into a single JAR, there are other ways of doing this. For example, take a look at the Maven Shade Plugin.
I downloaded Java source code of some project that works with Maven. After checking out
the code to Eclipse, and then building it from the command line, I followed the instructions
and imported it from Eclipse as: File > Import > Maven Projects. Now I have the core source code and many additional sub projects that seem to have the same thing like the core, just separated.
Could anyone please explain me what are these sub projects? why I need them? and on which code I need to work now if I want to make changes, the core or the new imported Maven ones?
I don't know nothing about Maven besides the fact that it's a tool for building code and managing releases.
Thanks!
In Maven land, these are called modules. There a nice way to further divide a project into very distinct pieces.
People handle Maven differently. I've seen projects where there was the actual project module, then 10 or so implementation modules. Most people use them for the above mentioned separation.
Most likely, your going to need all of the modules in order to work correctly.
To modify the project, your going to need Maven. I don't know if Eclipse has an embedded maven, but at least NetBeans does. With this you can modify anything that you want, then build it with Maven, which should be just a simple click.
In addition to what #Quackstar said:
Eclipse has embedded Maven support provided by the m2eclipse plugin. When you import a Maven project consisting of multiple modules, the default behavior is to map each Maven module as a separate Eclipse project. This allows the Eclipse build paths to be constructed in a way that matches the declared Maven module dependencies.
There is also a way to map a multi-module Maven project into a single Eclipse project that entails enabling m2eclipse's "Nested Module" support. This results in an Eclipse project with a build path that is an amalgam of all of the Maven module dependencies ... and not exactly correct. This approach is not recommended by the m2eclipse developers, and I've heard they are intending to remove the nested module feature entirely in a future release.
Our software is written in Java and comprise many (7) projects.
These projects are Netbeans ant projects.
I'm considering to converting them to maven2.
Where can I find some hints for doing such thing?
Don't read that book. It will only make you confused. Read this book instead: "Maven - The definitive guide" http://www.sonatype.com/books/maven-book/reference/ .
Also, the maven site has a lot of information, but the structure is terrible so you'll need to use google to navigate in it.
Here is my suggestion:
Do this by hand, not with "automagic" "help" from the IDE. Maven integration doesn't work that good yet, not in any IDE.
Make sure you program project is divided into modules under a common umbrella module, so that each module produces a single binary artifact (jar, war,...) possibly accompanied by the javadoc of the source code behind that artifact, a zip with the source code etc. The basic principle is that each module produces a single artifact, containing all the non-test-code under that module. You can do this while the project is still built by ant.
Each module should conform to the standard maven directory layout. The build destination is under [module]/target/[output-type, e.g. "classes"]. The source code is under [module]/src/main/[src-type e.g. "java"] and [module]/test/[src-type]. The artifact consists of all the code under src/main, and none of the code under src/test, as it built to the target directories. You can do this while the is still built by ant.
Start by transforming the sub-module that has no dependencies on other modules in the project.
Now you can create the parent maven module pom.xml with artifact type "pom", consisting of one of the modules below. Make a child module for the first submodule (the one with only external dependencies), using the umbrella module as "parent". Remember that you need to specify version for the parent. Remember to add the child module as a "module" in the parent too. Always use ${project.version} as version in the child modules when you create multi-module projects like this. All modules under a parent must be released simultaneously in a single operation, and if you use this setting maven will make sure the version fields stay the same across all modules and gets updated everywhere during the release. This may make it difficult to re-use the existing numbering scheme, but that doesn't matter. You are never going to run out of version numbers anyway.
Add the necessary dependencies, and make sure you can build the parent and the child module together using the command "mvn clean install" from the parent module.
Proceed with the rest of the modules the same way. Dependencies to other modules under the same parent project should also use ${project.version} as the "version" they are depending on, meaning "the same version as this". NOTE THAT in order to build, the module you are depending on must be built using "mvn install", so that it gets deployed to you local (computer) repository. Otherwise the depending module will not be able to find the classes. There are NO source-code dependencies between modules in maven, only dependencies to built and packed versions installed in local and remote repositories. This can be very confusing if you come from ant-projects. Build from the root module until you get comfortable with this. It takes two days.
Don't use maven integration in IDEs. It is a bad idea. Use "mvn idea:idea" or "mvn eclipse:eclipse" to set up your workspace as a non-maven ordinary IDE project. The inter-module dependencies mechanisms in maven and the IDE aren't identical and will never be. Also, if you have several mavenized projects with dependencies in between, you want to have several of these in your workspace with dependencies set up between. You can do this with mvn idea:idea / eclipse:eclipse if you create a separate maven project file called "workspace.xml" (or whatever) in the same directory as parent module, set up as a multi-module project containing modules "." and "../otherproject" (only one-way reference here, no parent ref back). If you run "mvn idea:idea / eclipse:eclipse -f workspace.xml" you get a workspace with all these modules linked together. No IDE integration lets you do that. This sound like a lot of extra work, but the workspace.xml-file is really small. It doesn't have to contain all that dependency stuff and all that, only the reference to the modules you want to bind together in your IDE.
I did a succeful migration of NetBeans Ant project to Maven project using the instruccions by Joseph Mocker here: http://forums.netbeans.org/ptopic55953.html
I cite the important part:
close the project
rename the build.xml, nbproject files/folders to something so NB won't recognize them.
close and restart NB (so any memory cache knowledge of the project is gone)
copy in an empty pom from some other project.
open the project back up in NB (NB should now identify it as a maven project)
rearrange the files to follow the maven way (™)
This won't be an easy task since Maven2 expects the files to be organized in a specific way. Anyway Better Builds with Maven is a free book that should get you started. It will help you understand Maven and it also has a chapter on migration.
I discovered that the migration is not necessary. The real requirements that I need was automatic download of dependencies (libraries).
This is also achieved by Ivy which nonetheless uses maven repositories.
I solved converting project from ant to ant+ivy with IvyBeans.
I have built a script to migrate Ant builds to Maven. You can find more information here:
https://github.com/ewhauser/ant2maven
It won't help you with fixing your directory structure and or any additional Ant tasks, but it removes a lot of the tedious steps to get started.