We use maven-release-plugin to release our maven components to repository(ies). However, some of these components use ranges on some of our dependencies. We want this because some of the dependencies are released often (Snapshots are not an option)
When we use release plugin the ranges are checked into scm and deployed to our maven repo. This doesn't make any sense since unresolved pom files in the maven repository could (and will) ensure that other build change for one build to another.
We tried using release:prepare-with-pom, but the just makes a new pom file that is committed to scm (release-pom.xml). The original pom with ranges is still deployed to the repo.
As another snag we would like to keep the ranges for the next development release. So our head/trunk should not b resolved.
I have this feeling that we are going about this the wrong way.
Can anyone please help us to solve our problem? If there are other ways to do this we would appreciate your suggestions.
I have stumbled upon two known maven release plugin bugs. Please see the following bug reports:
MRELEASE-618
MRELEASE-727
These are scheduled to be release in version 2.2.3 or 2.3 of maven-release-plugin
Edit as response to posted comments:
I agree that it is not obvious why these bugs solves my problem. I'll try to elaborate.
To get the release plugin to use the resolved pom file and deploy it you need to first use release:prepare-with-pom and then release:perform. If you want perform to deploy the resolved pom file you need to set the pomFileName in config to release-pom.xml. If not it deployes the unresolved pom.xml. Deployed pom files with ranges is not a good idea. This is why the 618 is needed.
The 727 is needed because the release-pom.xml is only checked in on the tag. When doing a release:perform your tag is checked out in the target directory. Because og the bug the plugin is looking for the release-pom.xml in the module root directory and comes up empty. This could also possibly go wrong without the pomFileName config, but less likely.
Ranges is generally a bad idea in Maven because it is buggy and because Maven does not by default deploy the resolved pom files. If Maven always deployed resolved pom files ranges would be a good idea.
Related
I'm working on a project in Intellij IDEA which is divided into several Maven modules. Moreover I configured these modules as WAR artifacts, so they can be deployed to a Tomcat 8 independently. During development I recognized a behavior I couldn't solve so far: If I add/remove a dependency in a module's pom.xml these changes are not considered in the lib-directory of my final artifact, leading to ClassNotFoundExceptions on server startup and so on. The only solution that came up to me is to fix these changes in my artifact settings manually, which works but seems not very handy to me. Is there any way to configure IntelliJ to synchronize an atrifact's lib folder with Maven dependencies automatically?
Sorry in case of duplication. I already found questions related to this one, but these solutions as well as the JetBrains docs have not been successful so far.
Thank for helping me!
Finally got it. The problem arises if you create WAR artifacts 'manually'. Because IntelliJ uses pom.xml to configure artifacts automatically, including war makes IDEA creating all necessary artifacts for you. These are always up to date with your Maven dependencies.
I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?
These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".
I am very new to the industry, so apologies in advance for the very likely stupidity of the question.
In the team, we work with Intellij IDEA 13 as IDE, and use Maven 3 for our projects. We provide a few online services and portals, and I'm just starting to work on one: the project has several dependencies that are shared by other older projects, some are JAR archives, some are WARs...
To my questions re: how to edit those dependencies locally (e.g. editing a resources.properties was the case I had in mind) my tutor suggested turning the dependencies into snapshots and work with those.
What I managed to do was create a copy of the appropriate folders in my local repository and change wherever the version of the dependency was in the name or in the files, then modify my pom.xml files.
Now, this works perfectly if I open the JAR/WAR and edit some file, but I'd like to be able to do it from my IDE, also cause not being able to suggests I'm probably doing this in a wrong way. Do I need to somehow unpack the dependency to be able to do so? Is my entire approach wrong?
P.S.: I would ask someone in my office, but oddly enough none of those who could help are at work today anymore!
If none of your colleagues was able to help you, I am afraid there might be something else hidden.
However, let's try it!
I am guessing, here, that your resources.properties is a part of his own project. Project handled by Maven and expressed as a dependency in one of your main project.
I am also guessing that your main projects are WARs (Webapps mostly, services, portals) and the JARs are libraries, configurations, etc...)
Therefore, I am guessing that your webapps are referencing some libraries as Maven dependencies, to a specific version.
That said, IntelliJ (and other IDE) can easily handle modification of either JARs and WARs related to each other via Maven as long as the visioning is meaningful.
Note: Having -SNAPSHOT at the end of the version number tell to Maven NOT to cache the package. On the opposite, a definitive version number is considered as released and is only fetched from the cache. This is important because with a SNAPSHOT, you can publish an illimited number of time and it is guaranteed to have the latest version.
Note: Doing mvn clean install publish a package into your local Maven repository (generally located in ~/.m2) and is only available to you.
The general good practice is to have, in all the development branches of your DVCS, all your owned, often modified projects (Don't be too greedy, it depend on the situation) as SNAPSHOT. And during a release (Maven has a specific plugin for that) change all the versions to a final one, attributed in this precise moment (You never know if you will need a minimal version or a major).
Your code, then, has always the SNAPSHOT number of your expected next release.
Finally, I think that in your case, if you choose to change the pom.xml of one of your library for a SNAPSHOT, you should change the pom.xml of the root project to correspond.
If this dependency version is the same, then, you can add your library as a module within IntelliJ and the IDE will do the math to figure that the Maven dep and the Java module are the same entity.
I don't even know if that's help you (I'm not even sure if it's clear), but I hope it will make you ask more questions about what you need. Your co-workers will probably be able to help you more.
I need to confirm what I suspect as I cannot find any documentation on it, so this would appear a silly question, and since I am a learner at eclipse PDE.
Initially,
I had a parent project pom of an eclipse plugin project with
<version>1.1.0-SNAPSHOT</version>
with two child projects, with both their poms referring to the parent pom as version 1.1.0-SNAPSHOT.
I was able to build the projects successfully and had a site which I use to install the plugin into eclipse.
Then, I wanted my personal temp version called 1.1.1-mine. So I modified the three poms to
1.1.1-mine
I also updated the META-INF/MANIFEST.MF and feature.xml from
0.13.0.qualifier
to
0.13.1.qualifier
However, the build encountered the following error.
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.15.0:validate-version (default-validate-version) on project org.sonatype.m2e.subclipse: OSGi version 1.1.1.qualifier in META-INF/MANIFEST.MF does not match Maven version 1.1.1-mine in pom.xml
Does qualifier have to be a maven version keyword? Because, the build proceeded without error after I changed mine to SNAPSHOT in the poms.
If not, what did I do wrong?
What can I do to allow me to have version 1.1.1-mine?
In a nutshell, OSGi .qualifier means the same thing as -SNAPSHOT.
Since OSGi doesn't allow for more than 3 numbers in a version (+ qualifier), creating a -mine version is a bit tricky.
According to the FAQ, you can tell Tycho a string that it should be use to replace qualifier with:
mvn -DforceContextQualifier=mine
Note that this disables all the goodness you get from SNAPSHOT versions (namely that you can deploy the bundle several times).
Last month I asked this question because I couldn't get the EhCache jar to pull down into my local Maven cache using the M2E Eclipse plugin.
Now, I am trying to convert several EhCache/Terracotta POM files into Ivy XML files (using the IvyConvertPom task (which works perfectly fine for every other POM in my local repository - and there are hundreds) and it is choking, stating:
impossible convert given pom file to ivy file: java.io.IOException: Impossible to load parent for file:/C:/Users/myUser/jars/net/sf/ehcache/ehcache-terracotta-root/2.5.0/ehcache-terracotta-root-2.5.0.pom. Parent=org.terracotta.forge#forge-parent;2.3 from=C:/Users/myUser/jars\net\sf\ehcache\ehcache-terracotta-root\2.5.0\ehcache-terracotta-root-2.5.0.pom to=C:/Users/myUser/jars\net\sf\ehcache\ehcache-terracotta-root\2.5.0\ivy.xml
Could not find artifact for C:/Users/myUser\jars\net\sf\ehcache\ehcache-terracotta-root\2.5.0\ehcache-terracotta-root-2.5.0.pom
This is happening for all of the following EhCache/Terracotta artifacts:
net\sf\ehcache\ehcache-terracotta\2.4.7\ehcache-terracotta-2.4.7.pom
net\sf\ehcache\ehcache-terracotta\2.5.0\ehcache-terracotta-2.5.0.pom
net\sf\ehcache\ehcache-terracotta-root\2.4.7\ehcache-terracotta-root-2.4.7.pom
net\sf\ehcache\ehcache-terracotta-root\2.5.0\ehcache-terracotta-root-2.5.0.pom
I'm not sure if this issue is related to the issue I had last month, or if the developers over at EhCache just have a non-standard way of writing their POMs, but this is twice now where Maven (IvyConvertPom uses Maven XSLT under the hood) has choked on doing something with their jars.
Does anything jump out at anybody as being obvious? Otherwise I have to debug Ivy code, which sounds like a painful way to wrap up a Wednesday. I'll do it if I have to, but thought I'd ask here first in case I was missing something glaring.
Thanks in advance!
I think the problem is that ivy can't resolve org.terracotta.forge#forge-parent;2.3
I'm not expert in ivy or IvyConvertPom, but I think you might need to somehow compel ivy into using the terracotta maven repository:
http://repo.terracotta.org/maven2/
I think I reproduced this problem locally and ran ant with "-d" and I could see it try all the standard maven repos out there, but not all terracotta artifacts are on maven central.
I have no idea how to inform ivy about other repos though, hopefully you know that bit of the puzzle
The ehcache versions prior to 2.9.0 have declared terracotta artifacts as a managed dependency supplied by the specific maven repository.
A fix for this bug has made it to ehcache project on Feb 6, 2015 where it became a jar dependency instead.