I'm converting an existing project structure to Maven where there's EJBs and JARs contained in EARs that are deployed. My issue is with making EARs. It seems obvious to use the Maven EAR plugin, which either takes an existing application.xml or generates one on basis of configuration.modules. I feel I'm not entirely leveraging Maven if I would not use the modules configuration (although it would allow developers to reuse the existing application.xml editor), but I'm thinking about many of our developers who love to click around in RAD/Eclipse to get things configured. So I took a look at RAD/Eclipse in full expectation to see some m2e support that would allow me to point-and-pick my EAR modules, and then see the modules in the POM file being populated accordingly. But I'm not able to find such thing. I believe I installed m2e (1.3.0) and m2e-wtp (0.17.0) although it seems to bring me very little in terms of WTP/EAR support. Also I spent most of tonight googling around, to no avail. Should I forget about it and have devs just manually edit the POM file, or am I overlooking some nifty UI for this purpose? Thanks for your pointers!
Seeing a comment and an answer that drive me to elaborate. I do appreciate that when using Maven, Maven is leading. No argument there. And I know that I can take control over the application.xml back using generateApplicationXml, but that's not even what I'm after, again Maven can be leading. But as I can use the "Maven POM Editor" to edit the basic structure of the POM, would there be any UI available to edit the configuration.modules? Our devs are very acustomed to IDE-centric development, and them having to start editing POM file XML in order to manage modules is something that scares me slightly...
If you want to configure your application.xml manually you can include the file to your source folder and set the generateApplicationXml property to false so maven will not overwrite it.
See for details: http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html#generateApplicationXml
Related
Should I put .classpath, .project files and .settings files on SCM when working with Maven project with m2eclipse plugin? Theoretically every developer can grab the sources and import maven projects.
Due to your experience is it better to do this that way or to put Eclipse files to SCM too? Some developers are using InteliJ so I don't want the projects to be Eclipse specific. It seems that the .project file may change according to the set of installed plugins, e.g. change buildCommand from org.eclipse.jdt.core.javabuilder to org.eclipse.wst.common.project.facet.core.builder etc.
Please share your knowledge and experience.
In my experience, you should not include .classpath, .project or .settings. All the information needed to re-import the project is in the pom file, so long as you use "import existing maven projects".
If you put all those local ones, you are likely to end up having SCM changes for irrelevant things, such as different order of entries, local modifications someone made to their project preferences, etc...
As per my experience , it is safe to check-in .project file as it defines the nature and other properties which is useful for developers who will be creating new workspace. Many times, custom facets needs to be added via Eclipse and you may want to share it with other members of your team provided all others use the same IDE for example RAD.
They won't have to go through the pain of again setting and changing project nature, so it might help. Even we had to share our .settings folder in most cases because ppl were facing issues with workspace setup. So all depends on the need and it might help.
One situation in which it is very convenient to have Eclipse project files under version control is when you have Java code automatically generated by plugins. Eclipse removes missing source directories from its configuration before code generators run.
UPDATE
With recent Eclipse releases (I'd say since Juno, certainly since Mars) this is no longer the case.
Over the years the m2e plugin was greatly improved and nowadays there is really no need to store project settings in your SCM, as these settings are properly recreated from the project POM. This has the added benefit of allowing the use of different Eclipse releases with the same project.
I have inherited a big project with several subprojects.
all of them use several jar files, all of them located under each project's lib directory. I want to take all the projects and migrate them to maven, but dependencies are a problem (too many of them), some of them are commonly used libraries (apache projects, xerces, jms, etc) and others are not.
is there a way to autogenerate maven dependencies for those jars that can be found on public maven repositories. for example, see that my project use the spice-jndikit-1.2.jar file and automatically get the appropiate depedency with group, artifact and (if possible) version?
thank you
I wrote a groovy script to generate a starting set of Apache ivy files.
https://github.com/myspotontheweb/ant2ivy
In my case, I wanted to "Maven-ize" my ANT builds without switching completely away from ANT.
It is feasible to extend this code to generate a Maven POM, if people were interested in this feature.
You can convert a project to Maven using the m2e plugin, but this erases your jar references, and should not be used.
I doubt that such a thing exists since typical jars (unless themselves built with Maven) don't have the necessary information to correlate the groupId, artifactId and version back to a repository to get the proper path.
You might be able to write something that parses the file name for the name and version, but you still have the package-based path to figure out.
If you're building using Ant, you might also consider using Apache Ivy, and its file-system based resolution (very fast and easy to configure), to get you started, and slowly role over to the Maven repos for the artifacts, this way you're not spending a lot of time up-front finding Maven dependencies.
I used Maven before in quite a few projects but they we already configured by someone else. I quickly understood the main concepts (groups, artifacts and versions for jars, local and remote repositories) so I assumed that if I'm asked I'll be able to set up a new project from scratch easily.
That turned out not to be the case when I deal with multiple modules which depend on one another. I poked around maven docs but they are either way too concise or way too technical (sometimes I get a feeling that Maven people wrote it for themselves and not for Maven users). So I'm asking for community help.
Here's a typical scenario:
Three repositories:
My local repo at <User>/.m2
My company repo at http://maven.mycompany.com/repository
Maven Central at http://repo1.maven.org/maven2/
I'm building a normal Java EE project consisting of one EJB jar with a corresponding client jar, a web module and a JPA module (I like keeping my entities and all db-connectivity separated from business logic). That gives me 5 project in my IDE:
myapp-ear
myapp-ejb
myapp-ejb-client
myapp-jpa
myapp-web
myapp-jpa is used by myapp-ejb and myapp-web. myapp-ejb-client contains business interfaces for my EJBs.
How should I set all that up? I suspect that I need some kind of parent project but I'm not sure how should I organize inter-project dependency resolution. For example: currently when I specify
<dependency>
<groupId>com.mycompany.myapp</groupId>
<artifactId>myapp-jpa</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
in myapp-ejb's pom.xml maven tries to search for it in my repository and tells me that the .jar can't be found. Even if I build and install all app components into my local repository one by one Maven always fails to build the ear file itself :(
I'd love to get it working under Eclipse or NetBeans.
I think you're on the right path. You need a parent project to pull it all together. In the parent project (and here is the important part) you need your dependencies laid out NOT in the dependency section of your parent pom, rather, you need them in your dependencyManagement section. Then, in your child pom's you can declare dependencies that are in the parent.
The only other gotcha (that I can think of) is that when you check the project using a version control system in Eclipse you need to remember to check the parent project out "as Maven project" otherwise the m2Eclipse plugin tends to freak out and not resolve things properly.
I hope this helps.
With the maven-eclipse-plugin, using mvn eclipse:eclipse, you can specifiy eclipse project natures and builders that will automatically be added to the eclipse project.
Earlier versions of m2eclipse used the configuration block of the maven-eclipse-plugin and also let you activate natures and builders using the same mechanisms. This seems to no longer be the case because a) I can't find any reference to maven-eclipse-plugin in the m2eclipse sources and b) it just doesn't work :-)
So this is my question: is there any way to configure the eclipse project generated by m2eclipse from the pom.xml? Specifically: project builders and natures, but I'd be interested in other options as well.
The following thread summarizes almost everything. First, it explains that m2eclipse doesn't and won't support anything from the Maven Eclipse Plugin anymore because:
Sonatype doesn't maintain it.
It causes them too much troubles.
Second, it states that the m2eclipse way to handle additional project natures and builders is to write project configurators:
(...) we encourage writing configurators to add the natures and builders you want based on what it available in the POM.
See this link for a guide and this project for some existing configurators for checkstyle, findbugs, pmd.
I have now implemented this as a maven plugin I call maven-eclipseconf-plugin.
Unfortunately it's proprietary work for a client, so I can't share it. But let me describe what I do:
Tied to the lifecycle verify, I check for the existence of an eclipse .project file. If it's there, I check it for the presence of the builders and natures I want to automatically add (and you can deactivate this behavior by using a maven property or a stop file with a configurable name). You can also define configuration files that will be written (like .pmd, which is related to this other question of mine). The contents of the Configuration files can be specified inline, it can come from an external file, or from a URL. I also tried to introduce variable substitution in the config files where a special placeholder would be replaced with a multi-moduke-project's root folder, but I had to give up on that approach.
Anyway, the plugin gives me pretty much all the functionality of the maven-eclipse-plugin I ever used (of course there is a lot more though) and I'm happy with that. Perhaps I will build something similar once more in open source when this contract is finished.
Project configurators are the proposed approach. But the latest version of m2e-extensions is from early 2010 and developed against m2eclipse 0.10.x. There is a successor project called m2e-code-quality which is more recent and active and developed against m2eclipse 0.12.x.
But neither m2e-extensions nor m2e-code-quality do support FindBugs at the moment. And there are some other limitations with header files, exclusions and modified JARs.
I have successfully used a universal approach with AntRun, Ant and XMLTask to automatically add project natures, builders and configuration files for Eclipse plugins from pom.xml.
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.
The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
Why not use access rules to keep your code clean?
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.