What's the best way to download remote maven artifact from within a maven plugin while also supporting maven 2.2.x1), 3.0.x, 3.1.x and newer?
Aether seems a good candidate but it changed package namespace between 3.0.5 and 3.1 breaking compatibility.
There's pieces of information around,
some pointing towards maven-dependency-tree (as suggested in this SO post) (how?)
yet another to jcbi,
Another SO post which I think uses Aether underneath and presumably suffers from the same version incompatibility problem
Try to manually force your version of Ather based on the ResolveArtifact example
Try to port the really complex solution reflection solution from Apache Karaf
Some other util from maven-shared ?
So what's the correct, or at least working, way to go on about this?
1) Where Maven 2.2.x is a nice to have as pointed out by #khmarbaise is EoL
If you're in a plugin and want to have another plugin invoked, the best solution - by far - is to use Mojo Executor. This way, you won't rewrite the maven-dependency-plugin ...
Considering the maven version issues, well, I guess you should indeed give up on maven 2.* support.
Related
All versions of struts1 have multiple vulnerabilities
CVE-2016-1182
CVE-2015-0899
CVE-2016-1181
CVE-2014-0114
CVE-2012-1007
I need to use a patched version but apache did not release patches for struts1 since it's well beyond its EOL, and as far as I know, only Redhat provided fixes for these vulnerabilities.
I need to use this version in my Maven project but I am not sure how to include an RPM dependency in the project? and how to even test it since I am using windows?
I looked at RPM maven plugin but all the usage scenarios on the official website seem to be centered around using it to produce an RPM from a Maven project, not the other way around, using an RPM in a Maven project.
Edit:
I also considered installing the package using yum and then use system scope and specify the location using systemPath but I am not sure if this is the best approach.
I have a Maven project that needs to be versioned. I have chosen to use the versions-maven-plugin as my versioning plugin but am unsure if that's the best option.
I have read the documentation that such plugin actually modifies the POM and I don't really like that approach. I have worked on projects where they had separate build.properties file that got modified manually.
What I want to achieve is to have my CI generating the artifact for me ready to be deployed and update the version number automatically.
So, any suggestions? How have you done before?
Thank you
I'd get the version number from the one source that matters: that's the source code management system (Subverson, Mercurial, or Git), not Maven.
I'd say that Maven might be out of synch unless your Maven plug-in is getting it from SCM.
Use the Release Plugin. You want to perform automatic deployment and batch release. The Versions Plugin is designed for something else.
We have found MAVEN-RELEASE-PLUGIN super useful and can not imagine releasing and managing version with it.
I'm using Ivy to manage my dependencies, and It's causing me issues with easymock
my ivy.xml file has the following:
<dependency org="easymock" name="easymock" rev="2.5.+" conf="compile,test -> default" />
and then I follow with other library dependencies, hoping that in case some other library uses another version of easymock then at least my library gets the correct one.
but then after I resolve, in eclipse i can see that there are 2 versions of easymock (1.2 and 2.5) and then the 1.2 is listed first.
and when I run my unit test, I'm getting a java.lang.NoSuchMethodError on the contstructor of org.easymock.internal.RecordState which takes org.easymock.internal.IMocksBehavior.
which suggest I'm hitting the old version of EasyMock.
Any ideas how can I get around this issue?
Generate an ivy dependency report to see exactly what versions ivy is using, for each configuration:
<ivy:resolve/>
<ivy:report todir='${ivy.reports}' graph='false' xml='false'/>
Normally when ivy encounters two versions of the same library it will "evict" the older version.
To fix problems with incorrect conflict resolution I'd suggest reading the doco
Update
Ivy's conflict algorithms have always worked well for me in the past, but I must admit I never fully understood some of the complexities of transitive analysis. The following Maven article is worth reading:
http://guntherpopp.blogspot.com/2011/02/understanding-maven-dependency.html
The latest easymock I can see in the ibiblio mirrors is rev 2.0. That would mean, that 2.5 is not found and an older Version is used. Check your resolver settings and revisions.
It also helps to clean the cache once in a while (ivy:cleancache) so ivy is forced to search the repos for revisions.
I am developing a web-app and use maven for dependency management (duh). Some of the needed jars are already available in the server lib folder, but do not match the "maven naming scheme", ie missing the version suffix.
I would like to use them for development and deployment, but..
1. i cant point maven to them because maven seem to need a version suffix. I cant omit it in the pom.
2. If i define the dependency outside maven then maven is obviously unable to build.
3. Renaming the files inside the server distribution sounds like a kludge.
What would Brian Boitano do? I mean, there sure is an elegant solution that im not aware of, or at least a good argument for one of the three solutions above.
Thank you
PS. i am using jboss 5.1 and maven 2.2.1 atm, but its subject to change
You can provide those jars as a dependency with a system scope if you want explicitly to identify where they live. For more info have a look here
IF those are not proprietary libs you are using, I'd recommend you use official versions of those from maven repository.
If they are proprietary you can manually install jar to your local repository using maven(you can use your version, suffixes, group names, artifactid etc) and then use them in your pom.
Warning: I have just picked up Maven, so things mentioned might be wrong or not best practice.
I have a medium size open source project that I am migrating to Maven from the basic
NetBeans project management. This is not a developer team sharing the same room, this is 1-5 people over the internet sharing a SVN repo. Reading over the how-tos on dependencies, it seems that the only way to get dependencies is to get them from an online repo or install them locally.
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons including portability (anybody can pass by, check out the repo, build, and use; all that simply without manual adding to local repo's and whatnot), getting newer versions (discussed below), and manual versioning.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
So
How can I force all dependencies to come from /lib for example
On a related note, can mvn build from library's SVN repo directly? Just curious
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
FYI, this is a Java project with 3 modules, project global dependencies and module specific dependencies.
Bonus points if it can work with the bundled version of Maven that comes with NetBeans.
Not a duplicate of
Maven: add a dependency to a jar by relative path - Not wanting to install to local repository
maven compile fails because i have a non-maven jar - Don't think a System dependency is the right answer
maven look for new versions of dependencies - Still uses(?) repository, just the latest (old) version
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons (...)
I will come back on this but the solution I described in Maven: add a dependency to a jar by relative path (using a file-based repository) allows to implement such a solution.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
It looks like mvnbrowser indices are totally out of date (making it useless as repository search engine) because the maven central repository does have logback-core-0.9.24.jar (the logback project is doing what has to be done to make this happen) but only has an old pircbot-1.4.2.jar. Why? Ask the pircbot team. Anyway, you're right, the central repository might not always have ultimate versions.
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
Yeah, this happens too.
How can I force all dependencies to come from /lib for example
As previously hinted, you should re-read carefully the solution suggested in Maven: add a dependency to a jar by relative path. This solution is not about installing libraries to the local repository but is about using a file-based repository (that could thus be stored in SVN). You might have missed the point, this matches your use case. And also check Brett's answer for a variation.
On a related note, can mvn build from library's SVN repo directly? Just curious
Didn't get that one. Can you clarify?
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Maven supports version ranges and you could use a syntax allowing to use "any version greater than X". But I do NOT recommend using version ranges at all, for the sake of build reproducibility. You don't want the build to suddenly fail because of some automatic update that happened on your back. Only upgrade if you need bug fixes or new features, but do it explicitly (if it ain't broke, don't fix it).
You might also find mentions of the LATEST and RELEASE version markers. I don't recommend them neither for the same reasons as above and even less since they're removed from Maven 3.x.
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
Can't say for Ivy. But in the Maven land, if you can't host up a "corporate" repository for your project (Nexus, Archiva, Artifactory), then the file-based repository is IMO the best approach.
Setup your own Maven repository.
http://archiva.apache.org/