We are building an Eclipse RCP plugin that is based on an Eclipse target platform (also developed internally in our company, by a different department). We would like to compile the plugin using MAVEN2 (we also use NEXUS for repository management).
The target platform consists of about 130 JARs (most of them org.eclipse.*). One way to perform the build would be to add 130 references into the tag of the POM file. Not only is this a lot of effort, but the target platform occasionally changes, so a new target platform would mean a lot of modifications.
Is there a better way to deal with a lot of dependencies in MAVEN?
Take a look at All Client jBoss artifact. They have solved the same problem using POM artifact.
Related
In Tycho there are two ways to define the target platform: a target file and the <repositories> tag of the pom.xml. According to the manual, both can be used; they just have different drawbacks.
The target file is easy and straightforward, especially if you worked with Eclipse PDE before switching to Tycho.
What I don't get is how do you develop against a target definition defined in the pom.xml.
Dependencies are not added to a "Maven Dependencies" folder in the Java project, like they are for plain Maven projects. So Eclipse can't resolve them and your code doesn't even compile. And even if it does for some miracle reason... you cannot start a product or run tests.
All of this, because Eclipse needs a target platform to run. And the standard one (the plug-ins folder of Eclipse) is usually not the correct one for the project.
So how do you tell Eclipse that your target platform is defined in the pom.xml? How do you develop using only the <repositories> tag?
We are using Maven to build our projects and Nexus as repository manager.
Is there a way to know where an artifact is a dependency of another artifact?
For example, we want to know which of the artifacts in our Release repository have a dependency on commons-io 1.2, or version x.y of our framework2, or ...
mvn dependency:tree should help you get this info.
Have you looked at the Maven Site plugin in conjunction with the dependencies and dependencies-convergence report from the Maven Project Info Reports plugin?
This will generate an html report that shows all the artifacts that the project uses and what other artifacts that are dependent on that artifact.
The Maven client will only tell you the dependencies of a single project. I'd recommend using Sonar as part of your build process. It's primarily used for source code analysis, but it will also report usage of a particular library by other projects in the same Sonar database.
I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.
I am working on a fairly large project (with a number of modules, a bunch of external libraries etc.) and we are now considering switching from Ant to Maven. I understand the differences between the two, but I am not convinced that it is really worth spending time converting the project layout, setting up all the dependencies, teaching developers and configuration managers doing things "the new way" etc.
There are a lot of resources on the web describing how to migrate from Ant to Maven, but I haven't found that many that say why :-)
Before changing your build system, ask yourself (and the group) why you're changing? If you're changing just because Maven is the "new thing", don't. If you actually see a technical reason to migrate, do it.
In general, unless there's a major compelling reason to do so (new capabilities or much simpler management), I'd say stay with what you have for the current project, but consider Maven for future projects.
Have you read chapter 1 of "Maven, the definitive guide"? In particular, 1.7 Comparing Maven with Ant has an interesting discussion.
I agree with the other answers that advise caution. Maven has strong points, but nothing that can't be done by an Ant build process:
dependency management: Ant has the Ivy subproject, which can interact with Maven repositories.
convention over configuration: you can also do that with Ant, it's just a matter of establishing the rules and enforcing them.
build lifecycle: same as above, you can enforce a convention over the tasks exposed by each build.
build logic reuse (Maven plugins): you can also achieve that in Ant with macrodefs and task libraries.
The thing is, with Maven you get these features out-of-the-box, while with Ant you need a rock-solid build, a very strict set of rules and a way to enforce them (for instance, make sure that everyone follows the conventions when they create a new subproject, that they reuse the existing blocks instead of doing everything from scratch, etc.).
Personally, I would see how well the existing process addresses the issues above: how are dependencies managed, is there a central repository? Are the project structures uniform (when I checkout a project I don't know, how long does it take to figure out how to build it)? Is there some form of build logic reuse, or does each project reinvent the wheel? Which of these features are needed?
Then I would try to balance the cost of adding the missing features to the existing Ant script, against the cost of migrating to Maven (if you don't know Maven, that also includes the cost of learning it).
In any case, I suggest you build a small Maven prototype (5 to 10 projects) illustrating the common cases in your build. You can test a lot of Maven's features with dummy projects containing little java logic (use the archetype plugin to generate them).
Before Maven we were checking dependency libraries (typically third-party, open source variety) into source control - so that we could insure our components compiled and got packaged with the precise versions intended.
Now with Maven in place, we're relying on artifact repositories to hold those versions and we let our pom.xml dependency declarations be the official means of defining version dependencies. This has proven to be a simplifying approach that makes project organization in version control repositories (and their Hudson build projects) much easier to devise. Our local artifact repository is under backup policy along with our source control repositories. It's nice to use the Maven tools to go and search and specify a needed library version. We also use parent pom files to specify dependencies that other project poms inherit by default. So if you want all projects to use the same log4j version, then that is specified in one place in the parent pom file. (But any project can at anytime override and specify a specific version instead of just accepting the default from the parent pom.)
Here is the secret to a successful adoption of Maven:
Use Maven project build approach for
your new greenfield projects
Modify existing legacy projects that
use ant build.xml files to incorporate Maven task
for managing depenedencies (a hybrid
approach)
The benefit is that you can then get all of your projects under Maven dependency management, which is of course it's greatest benefit.
The nice thing about the Maven task for ant, where you specify all dependencies in a pom.xml file, is that it involves just modest modification of the existing ant build.xml file to incorporate Maven for this. From the ant file's perspective, Maven is just a means for defining classpath definitions, which are subsequently used by the various ant build task.
The Maven scope classifier of dependencies can be utilized when defining classpaths such that a suitable classpath can be set for compiling, running unit test, packaging, et al. Other definitions in the pom can also be accessed as ant property definitions.
A lot of existing ant build files are rather complex. It can be a formidable undertaking to convert such projects to a full Maven build process. This hybrid approach of having Maven manage all the dependencies and leave the bulk of the ant build.xml file as is, is most pragmatic.
First, like I'm sure a lot of people will mention, Ant and Maven are not exactly intended to solve the same goals. Since you said you understand what each provides, I won't get into the details of that, so suffice it to say that Ant lets you define the details of how to build individual components, while Maven manages the dependencies between components plus Maven lets you define a complete project build cycle from compile through test and deploy in a programmatic way.
I've used Maven on a couple projects in the past, and I just started using it on another one recently. There are plenty of articles on the net that compare Ant and Maven, so you can look at those, but from my experience, its always worthwhile to consider how you can improve a project. Dependency management and build lifecycle are two important aspects of any large project, and Maven helps in both those areas. If you already have a good build system in place using ant, and your dependencies are kept in a easy to access central location, and you don't plan on extending your build process to include any more advanced build management, then maybe you should stay with what you have.
On the other hand, if you want to use a continuous integration server like hudson or an artifact repository like nexus, then moving your project to maven can really help with build efficiency and automation. You probably would like maven in those situations because the full cycle from dependency to build to artifact can be achieved using those types of tools and you'll be able to better control your builds and releases. On my current project we have many modules and dependencies, like you mention. Migrating to maven so we could use hudson and nexus really helped because we could drop all those 3rd party jars into a nexus repository and stop having to check them into version control or email them around. Also, builds were out of hand because the CM people had a build plan as a document that they would sometimes follow, but making that part of your project (i.e., the pom.xml) defines how you are supposed to build and lets you enforce it. Maven is the glue that holds all of those things together.
In the end, its a matter of how long you expect the project to last, how good your process is now, whether you want to clean up your dependencies, whether you want to enforce your build plan, and whether you want to have the option to use continuous integration and artifact management. If you any of those things, Maven is a strong candidate.