Sure, you can do this by setting a version number to 'RELEASE' to get the
latest non-snapshot, but IMHO it's a bad practice in general. In any dev
You can also do similar things with version ranges eg [1,2) means
version greater than 1 but less than 2.
If you are making serious (breaking)
Dave Newton wrote:
In other words, use the maven-release-plugin to publish
formal releases of code, and make sure that project A
never depends on a snapshot of project B if you can
possibly avoid it. Use proper version numbers.
Would it be reasonable to say that *released* versions of A
Rick wrote:
Here's what I'm confused at though. Project A builds a jar. It needs
to be used in Project B. Ideally of course Project A should be tested
in Project B locally, but in reality (unfortunately) the dev
environment often becomes a more 'real' test. Typically the developers
of Project A
Graham Leggett wrote:
But by doing this, project B is saying we accept that project A may
break at any time, and we accept this.
...
There is no right answer as to when this should happen, this is up to
the development team. But it is down to a binary choice: be on the
snapshot
You might want to either have a look at the versions-maven-plugin or
consider version ranges.
With the versions-maven-plugin you can update a property that locks down the
version you use automatically, which can be helpful in controlling when you
get an update in your dependency.
If you just
This isn't in reply to Stephen directly since so many people have made
good points.. so thanks.
I guess I'm still wonder what most people practice (or maybe not most
but what's considered 'good'), in regard to the following situation...
Project B will be putting out a new release based on
is an error shown during the build? perhaps the JDK you are using doesn't
have the certificate or that of its issuer in the JDK certificate store.
- Brett
2008/9/11 Simone Tripodi [EMAIL PROTECTED]
Hi folks,
here in the company we're using subversion with certificate-based
authentication,
It seems the dependency report is not honouring the mirror settings - you
might need to check if the newer version (which is planned to be released
soon) corrects this issue, or if there is another issue in JIRA for it. If
not, it should definitely be recorded.
I'm not sure if it will be possible
