Am 23.01.2012 09:34, schrieb Ansgar Konermann:
Am 23.01.2012 08:36 schrieb "Thomas Scheffler"<thomas.scheff...@uni-jena.de
:
Am 20.01.2012 16:27, schrieb Ron Wheeler:
Of all of the developers that have built thousands of applications using
Maven, you are the only one who wants to do this.
Does that not raise any red flags?
There must be a "best practice" for what you are trying to achieve.
This is clearly not it.
Hi Ron,
did you faced that problem already? What is your solution or what would
be a general solution of keeping track unique version numbers?
Through Hudson I run tests in a core library, the SNAPSHOT library, that
got releases from time to time. Between those releases a SNAPSHOT is
deployed to a snapshot repository from where another Hudson project gets
this library and run integration test.
Snapshots change over time. If you want to depend on your library and have
reliable dependency tracking, why not just *release* the library?
Hi, I thought of that but that would mean several minor releases every
day and changing application pom very often. I think that is the reason
why maven as SNAPSHOT versions. But sadly there is no easy way to track
them. So for some reason there are unique versioned SNAPSHOTS - that's
the default case by the way - but when requesting a SNAPSHOT version you
can not get it's unique version of it.
The best way so far is to use the versions plugin prior testing:
With "versions:lock-snapshots" you can modify the current pom and get
the unique versions written inside the pom.
After tests successfully finish you can grab the information from the
pom.xml or you run "versions:unlock-snapshots" to put back "SNAPSHOT" to
the versions.
That is so far the best solution I got. It would be better to get this
information after tests.
So anymore ideas?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
