I'm starting working with Eclipse + Maven (2.2.1) and I have some question about it:
1- I have an internal framework MyFramework that is dependency in another project, something like that:
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>MyFramework</artifactId>
<version>[7.0.0,),[LATEST]</version>
</dependency>
The version is a range because I want to work with my workspace framework version, or with the latest (in case I don't have the project in workspace).
My project is building fine, but when I try to make a relase (maven-release-plugin 2.3.2) I got:
NullPointerException: version of MyFramework is null
Is that a bug or am I doing something wrong?
2- Suppose that I have a version 7.0.4-SNAPSHOT and I want to roll the second version number instead of third like that:
7.0.4-SNAPSHOT -> 7.1.0-SNAPSHOT or 7.1.4-SNAPSHOT (whatever)
Can I do it with maven-release-plugin?
3- I'm starting with Maven, so I don't need to care about migrations, should I start with Maven 3 instead of Maven 2?
Please, I need help with it.
Thanks in advanced.
Answers:
This appears to be a known issue: http://jira.codehaus.org/browse/MRELEASE-318
Yes, every time you perform a release you can override the default version number. If you release using the command line, you will be prompted to select the next version number (with a sensible default displayed).
Use Maven 3. Read this blog post for a list of reasons why it is superior.
Related
All our projects are built using maven.
we have centralized some of our main configuration within a super pom.
In order to always have an update version of this super pom (without having to modify the version), we have used the following syntax :
<parent>
<groupId>my.organization</groupId>
<artifactId>superPom</artifactId>
<version>RELEASE</version>
</parent>
The problem is that Maven Eclipse plugin (m2e) doesn't understand this syntax (the RELEASE constant is not resolved).
So, our Eclipse users can't use built-in compilation.
What do you suggest to overcome this problem ?
By the way, we have tried several options from a maven point of view (especially those described here), but the version.RELEASE is the easiest for everybody (except those who are using Eclipse).
EDIT:
Our projects sources are split within multiple SVN repositories.
This super pom is an independent project. It is retrieved through our Nexus server.
You are trying to go into the wrong direction. A release in maven is a particular version like 1.0.0 and it indicates that you have a defined state of that artifact. In your case you super pom has a particular state. If you are trying to define the version to "RELEASE" you are saying my release is always the same but in reallity it's not true.
Usually such a super pom will change over the time lets say today you have defined some particular dependency versions in it (dependencyManagemet). And tomorrow you change those definition. Now the 1.000.000$ questions which state of the super pom is used in a build which has been done today? Ok in that simple scenario you can answer the question but if you have changed the super pom sometime yesterday you can't answer the question accurately.
Furthermore if you try to recreate an artifact of let's say last week you can't say which exact state of super pom has been used at that particular time cause you have no indicator which gives you the chance to see it.
And that's the reason why you need real versions like 1.0.0 or 1.1.0 etc.
I can strongly recomment to use real versions like 1.0.0 etc. but NOT things like "RELEASE" that will creep in the Maven system with its corrdinate group, artifact and version.
Version ranges and expansion indeed do not work for parent artifacts.
Someone advised to invoke the version plugin instead :
mvn versions:update-parent
which does not cover exactly your need, but I am afraid there is no better workaround. Other ideas : using a SNAPSHOT parent pom (not very satisfactory I admit). See also Maven2 cannot find parent from relative path.
Update
The reason I couldn't update properly was I didn't have game's jar file properly installed. That was fixed by first running this on the command line:
mvn install:install-file -DgroupId=com.mygame -DartifactId=mygame-core -Dversion=0.9-beta -Dpackaging=jar -Dfile=/home/klenwell/projects/mygame/playn/mygame/java/target/mygame-java-0.9-beta.jar
Then, in Eclipse, I right-clicked java folder > Maven > Test. This updated all my dependencies including lwjgl.
Otherwise, see thomasbroad's answer.
Original Question
I've consulted the following authorities on this topic and applied their various recommendations:
http://lwjgl.org/installation.php
http://www.lwjgl.org/wiki/index.php?title=Setting_Up_LWJGL_with_Maven
http://www.lwjgl.org/wiki/index.php?title=Setting_Up_LWJGL_with_Eclipse
https://stackoverflow.com/a/11065814/1093087
https://groups.google.com/forum/?fromgroups#!topic/playn/E2t7gNh4ab0
https://groups.google.com/d/msg/playn/3D4JZ1Dbm-E/HmPHofS2fqgJ
Part of the problem is I'm not sure whether I should be following the Maven instructions or the Eclipse instructions. I've tried both and everything in between.
I'm working in Ubuntu 12.04 64-bit on Eclipse using Maven. Everything was working fine until I changed the PlayN version in my POM file from 1.2 to 1.3.1 and introduced the lwjgl dependency.
What I would have expected to have worked:
1) Download lwjgl (latest version 2.8.4) and test per lwjgl.org instructions (this was successful)
2) Update the appropriate POM files
2A) Add lwjgl.version as a property to mygame/pom.xml
<properties>
<playn.version>1.3.1</playn.version>
<lwjgl.version>2.8.4</lwjgl.version>
</properties>
2B) Add lwjgl as a dependency to mygame/mygame-java/pom.xml
<dependency>
<groupId>org.lwjgl.lwjgl</groupId>
<artifactId>lwjgl</artifactId>
<version>${lwjgl.version}</version>
</dependency>
3) Right-click mygame-java project in Eclipse > Run As > Run Configurations > Arguments and add either -Djava.library.path=target/natives or -Djava.library.path=/absolute/path/to/my/lwjgl/lib to VM arguments. (I've tried both variations.)
I can see the dependencies listed under my java project folder in Eclipse. And when I follow the lwjgl.org guide for Eclipse, I can see the jar listed under the java project folder. But I still get the error.
After two hours of hair-wrenching frustration, I hope somebody can either point out my fatal oversight or provide explicit instructions that will help me get back to work. Thanks.
I upgraded my project from 1.2 to 1.3 a while ago. I only updated my pom.xml files to refer to the new version of PlayN . I did not manually install lwjgl and neither did I add the lwjgl dependency as that one is implicitly pulled in by PlayN
Manually apply the diffs found here to your project, to your poms.
The key part being the piece in the java pom that tells Maven to unpack native dependencies. This part was actually added in the previous diff, so you may want to look there as well.
Now your IDE will most likely tell you that your project is not up-to-date with your poms, update your project, this should pull in the lwjgl dependency and set it up correctly.
I believe you should add the -Djava.library.path arguments to the VM Arguments, not to the Program Arguments in your runtime configuration.
The other -using maven- option is described on the Getting Started page, it worth noting, that the default embedded Maven is buggy for development, you should download and use at least Maven 3.0.3 as it is mentioned on the page (but I guess you already do this).
I just started a new project fresh with PlayN 1.4 and encountered this issue again in Eclipse. Resolved it as follows:
Right click mygame-java > Run As > Run Configurations...
Then added the following to VM Arguments under Arguments tab:
-Djava.library.path=target/natives
Then successfully ran as application.
At one point, I also ran the mvn install:install-file... command mentioned in question but I'm not sure whether that was necessary or not.
Before the question I'd like to describe the methodology I use.
I have a lot of projects under version control folder, some of them multi maven projects, some of them standalone bundles, some of them maven plugins or archetypes. All jars are snapshot (currently we can not use release artifacts). So for example application A1 depended on bundle B, which depended on utility C, another application A2 directly depended on utility C. When I change code in C I need to update it's version and then update B and A2, then A1. It is really annoying to update all those poms once at week. So I'm looking for some automatic solution that can handle it for me (like if C has new version all depended modules have to be updated).
Does any body have idea?
Thanks in advance
P.S. I thought to make a MOJO which can handle this, but I faced with some difficulty since not all projects has common parent project ...
Sounds like something the versions plugin can handle... http://mojohaus.org/versions-maven-plugin/
This is considered a bad practice, but if you deploy your projects using -DupdateReleaseInfo=true (or with the release plugin), then you can set the dependency version to RELEASE
<dependency>
<groupId>some.groupid</groupId>
<artifactId>some.artifactid</artifactId>
<version>RELEASE</version>
</dependency>
and you will always get the latest release version
If you're using SNAPSHOT-s only, you could always go for parent based projects. Define the versions in a parent and make the children extend it. You can also choose to use versions such as RELEASE or LATEST.
Consider using a Continuous integration engine to watch all projects and build them when changed.
If you use Jenkins you can set it up to provide the built maven artifacts as a Maven repository, which you can then use in your own Maven configuration.
This should be enough - the snapshot mechanism handles the rest.
I have a serious probleam with my Eclipse Plugin..
My plugin depends on another two plugins. All of theese plugins (including my plugin) use Mozilla Rhino engine - two of them use js.jar (version 1.4). But my plugin uses new version, which is not released yet and is packed in MyRhino.jar.
While developing, everything goes fine - code completion offers me classes and methods from my special version of rhino, no errors etc.
But when I run my plugin, a different version of Rhino is used and I get runtime exceptions like ClassNotFoundException and so on.
How am I supposed to tell eclipse to use the same jar in runtime as in development time?
When I was developing plugins on NetBeans, the solution was simple - wrapping the jar in a separate module, set which packages to export and declare dependency on this new module..
I found simmilar solution in Eclipse, however it did not work for me - although I declared a dependency on the wrapper plugin, the packages and classes were not available even in development time.
I've spent hours with this probleam and not solved it, so and help is appreciated. Thanks everyone.
Make sure your dependencies are correct. If your code depends on new version of library, then you need to indicate that in your MANIFEST.MF. E.g. if you require bundle org.mozilla.rhino, specify minimum version you need:
Require-Bundle: org.mozilla.rhino;bundle-version="1.5.0"
Your MyRhino.jar will need to specify correct version (e.g. 1.5.0), even though it is not released yet:
Bundle-Version: 1.5.0.qualifier
(If MyRhino.jar isn't converted to plugin yet, you need to do that manually: you can simply craete new plugin project using existing JAR in Eclipse)
Alternativaly, you can wrap MyRhino.jar into your plugin, and remove dependencies on other plugins. To do this, use Bundle-ClassPath (see http://www.aqute.biz/Blog/2007-02-19 for details). If you put your MyRhino.jar directly into your plugin, then Bundle-ClassPath should be:
Bundle-ClassPath: .,MyRhino.jar
Finally I've solved it..
It's simple to create the wrapper plugin form existing jar by the new project wizard in eclipse.. But the catch is that the wizard does not include the jar in bundle classpath (as I expected). Prety confusing (at least for me) that the wizard does only half of the job for you :/
After inserting the jar in the wrapper plugin bundle classpath, everytning works.
Thanks Peter for your answear anyway :)
Scenario: The system has number of components, each with its own POM. There are some long dependency chains (A depends on B depends on C, etc.). I want each "non-developer-desktop" build to be a potential release candidate -- if it passes QA, we will deploy it without rebuilding. In other words, I never want to build SNAPSHOT versions as part of my regularly scheduled builds, only versions like 1.3.0.5, 1.3.0.6, etc. I also want to enable the developers to work on multiple components at once.
To forestall some expected suggestions: the Maven Release Plugin doesn't help me ... unless there's some magic way I can have my dependency versions not be SNAPSHOTs in the POMs but still let the developers work on more than one component at once?
How should we manage the project and dependency versions in all of our our POMs? Right now it's just SNAPSHOTs everywhere, which makes things simple for the developers (they started with SNAPSHOTs and never concerned themselves with anything else). But it's worrying at deployment time (builds with SNAPSHOT dependencies are not well-defined, and not reproducible).
I'd like to avoid excessive juggling at build time, but right now I don't see any way around it.
Let's say I have components util, libj, libk, APP, and UI, with dependencies as follows:
libj -> util (libj depends on util)
libk -> util
APP -> libj
UI -> libj, libk
I have development teams working on APP and UI, and they will sometimes need to make changes/additions to some of the dependencies (even util) in order to enable their current work. How should the checked-in POM and dependency versions for each component look?
Edit: I updated the title to refer to Maven 2 instead of 2.0, since it became apparent that I would need to work with 2.1 or better in order to best resolve this.
Try to layout your builds such that modules that need to be developed together are released together. This will let the maven release plugin do most of the work for you.
For dependencies that really should have a separate lifecyle...because they change infrequently or are shared by multiple projects, you want to handle those differently. They way I do it is to keep the dependencies at the last release version until a change actually requires an upgrade to the next snapshot. In this way when you go to release the product, you will find all the things that may also be released simply by following the snapshot trails.
I find it also helpful to keep the external dependency versions specified as properties in the top pom of my project. This makes it easy to see at a glance what needs to be released. Look for an example of the Nexus pom.
This is something I find very difficult with maven and internal projects; you have two version control systems (maven's, which, quite frankly, isn't very good) and your source code control's (which, assuming it's CVS or better, supports real workflow).
Here's how we do it:
report --depends on--> core
web --depends on--> core
We use the maven release plug:
report's pom, during development, would have a SNAPSHOT version matching what's in core's pom. I do a mvn clean install in core, then I can see those changes in report in my local environment.
When I do a release of report, I must first release core via the maven release plug. When I I use it on core, it asks me to set the version of core to release (i.e. remove the -SNAPSHOT), to which I say yes, and the resulting released artifact doesn't depend on a SNAPSHOT release. When the release plugin is done, the report pom now depends on the next SNAPSHOT release of core (though you can override this during mvn release:prepare if you want).
The devs on web then get an email that a new version of core is available and they can choose to use it if they wish. Our policy is that they should update before releasing.
This is really the same problem as someone needing to branch code they are working on. You need some form of identifier to be able to get at the specific version until you merge back to the mainline development of that component.
The dependency classifier may be something worth looking into. You'll still need to have developers that will properly identify their modified code.
we work with a "Super Parent".pom-project, in it the versions are defined as properties and in every child.project, the versions are set with those properties
in addition the real projects have no version set, instead they inherit it from their parent pom-project (incl. groupId etc.)
with this set up the versions are only defined in some parent pom-projects, thus the needed setup is minimized
e.g. this structure
super parent pom-project (all 3rd party versions as properties defined, e.g. 2.5.6 spring-framework)
---- persistence-parent pom-project, inherits all from super parent
------ persistence-foobar jar project, inherits all from persistence-parent
---- util-parent
etc.
only versions you see are the ones inside the parent relations
example:
<modelVersion>4.0.0</modelVersion>
<artifactId>foo-bar-foo</artifactId>
<packaging>jar</packaging>
<name>whatever</name>
<description>...</description>
<parent>
<groupId>org.foo.bar</groupId>
<artifactId>persistence-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>foo-bar</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>foo-bar</artifactId>
<version>${project.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.jdbc</artifactId>
<version>${parent.spring.version}</version>
</dependency>
it works this way, because inside the pom you can use already defined values like version, even if the version is set via inheritance
we combine this with module setups inside the parent projects to make the builds easier