The Apache Maven team is pleased to announce the release of the
Apache Maven Invoker Plugin Version 2.0.0
Sorry the link to the plugin was wrong. The link correctly looks like
this:
http://maven.apache.org/plugins/maven-invoker-plugin/
Enjoy,
-The Apache Maven team
Hi,
So the release of submodule because of this reason is nothing significant
from the point of view of the whole platform and all the internal
dependencies should continue with the highest snapshot versions with as
small effort as possible. I hope this does makes sense.
If I understand this
OK all, so I've taken the not so clean but should solve my problem faster
road... I publish the 2 zips separatly on Archiva.
But now, my main build that declare dependencies on them both (as 'runtime')
seems to randomly fail, looking for one or the other. If I publish one of
the 2, the main build
OK, so Maven only sees the most recent one uploaded because on Archiva, the
maven-metadata.xml file is updated each time with the timestamp of the
most recent one (either *-linux or *-win). But the 2 qualified artifacts do
not share the same timestamp so one of those is not found leading to build
Well that is if version ranges worked by magic...
How does [2,3) know that it is supposed to prefer the version from your
reactor?
If you are following some semver-like [1] versioning scheme, then you
should be building against 2 and running tests against any random *release*
(or all releases...
Hi Michael,
Sorry, I've been too busy to follow up on this in detail.
My strong intuition is that you don't need to hack the Amazon S3 source
code or POMs at all. Rather, you can create another project downstream
whose whole purpose is to shade the contents of
com.amazonaws:aws-java-sdk-s3 as
I do not like any uncertainty about what is going into a build.
If you are a developer and suddenly your code changes behaviour after
you have made a change, your natural assumption is that you broke it.
SNAPSHOTS are hard enough to deal with and you need manual policies
about snapshot
