From my point of view you can't have SNAPSHOTs of things not built
with Maven. Just give them a release version, anything without
SNAPSHOT and go with it. I would typically use the svn rev if i
grabbed code, or some other id like a date.
On Wed, Sep 16, 2009 at 11:01 AM, Paul Gier
I don't think that's really practical if you are tightly integrated with a
project that has a non-maven build. We have some projects with Ant builds that
regularly need to be integrated and tested with Maven built projects. So it
might mean deploying a release version once a day in some
Another case where this comes up is when deploying snapshot versions of
non-maven built jars. For example I deploy projectA-1-SNAPSHOT using
deploy:deploy-file, and now I want to deploy the associated -sources jar. It
will give a new timestamp for the source jar and won't be able to find the
I don't think changing the POM or metadata formats in 3.0 is a good
idea. 3.0 needs to be release and we watch how it's working and make
any and all corrections to move 2.x users forward in a drop-in
replacement fashion. In the planning for 3.1 we should start talking
about additions to
On 08/09/2009, at 5:44 PM, Jason van Zyl wrote:
I don't think changing the POM or metadata formats in 3.0 is a good
idea. 3.0 needs to be release and we watch how it's working and make
any and all corrections to move 2.x users forward in a drop-in
replacement fashion. In the planning for
I think that extending the repo metadata with full coordinates is
still the best general solution.
These builds are de facto different builds, I see no value producing
them with _same_ timestamp. They will all be resolvable using standard
metadata resolution and version 1.0-SNAPSHOT to their
I don't think this is very hard and for 2.x we could just leave the
old format. 3.x can read both and we'll phase out the old format.
On 2009-09-07, at 10:15 AM, Tamás Cservenák wrote:
I think that extending the repo metadata with full coordinates is
still the best general solution.
These
On 07/09/2009, at 11:55 PM, Jason van Zyl wrote:
I don't think this is very hard and for 2.x we could just leave the
old format. 3.x can read both and we'll phase out the old format.
This has to include the POM too:
http://markmail.org/message/a42w3dqkmogbj4rq
I think there's pretty good
I agree, but I got the feeling Brian would like the same version on these
parallel builds which will need extra to make sure they are in sync.
I'm just exploring the concepts and options. I think most cases could
be solved by being able to resolve the latest snapshot of a particular
On 05/09/2009, at 12:58 AM, Brian Fox wrote:
Since the source in this case is identical, having separate modules
for this seems out of the way. Classifier really is the right way to
distinguish between different flavors normally, but obviously this
doesn't work well when you have to produce
On 2009-09-05, at 4:51 PM, Brett Porter wrote:
On 05/09/2009, at 12:58 AM, Brian Fox wrote:
Since the source in this case is identical, having separate modules
for this seems out of the way. Classifier really is the right way to
distinguish between different flavors normally, but obviously
On 06/09/2009, at 4:57 AM, Jason van Zyl wrote:
On 2009-09-05, at 4:51 PM, Brett Porter wrote:
On 05/09/2009, at 12:58 AM, Brian Fox wrote:
Since the source in this case is identical, having separate modules
for this seems out of the way. Classifier really is the right way to
distinguish
In fact we rarely deploy -SNAPSHOTs at all... the only time we have deployed
-SNAPSHOT builds is when SV have a complex test scenario and we need to
check the fix before we roll a big suite release
2009/9/4 Stephen Connolly stephen.alan.conno...@gmail.com
I find that we have given up on unique
True - I missed that part. We used -SNAPSHOT only for volatile
versions, but if we wanted to lock in on a specific snapshot, we'd
roll a milestone or nightly build. In fact, one client just rolled a
nightly release and stamped it 1.2.3-NIGHTLY-20070325 (or so). But
this is a real
On Fri, Sep 4, 2009 at 11:12 AM, Stephen
Connollystephen.alan.conno...@gmail.com wrote:
In fact we rarely deploy -SNAPSHOTs at all... the only time we have deployed
-SNAPSHOT builds is when SV have a complex test scenario and we need to
check the fix before we roll a big suite release
The
I ran to the same thing and ended up to turn off timestamp snapshot
-D
On Fri, Sep 4, 2009 at 8:04 AM, Christian Edward
Gruberchristianedwardgru...@gmail.com wrote:
I've used classifiers before, though I think it's a bit of a hack. There's
also the native plugin which makes .nar archives -
I've used classifiers before, though I think it's a bit of a hack.
There's also the native plugin which makes .nar archives - you should
look and see what it does, since it is geared for native c/c++ builds
(I believe)
Christian.
On Sep 4, 2009, at 10:58 AM, Brian Fox wrote:
I was
I was recently working with a customer to move them off of using
non-unique snapshots for various reasons. In the process we discovered
a problem with snapshots, classifiers and multi-platform builds.
In this scenario, we have a project that is built on multiple
platforms, say windows, solaris
I find that we have given up on unique snapshots
we just use non-unique all the time.
if you need a unique snapshot, just roll a release, e.g. 1.0-milestone-1
-Stephen
2009/9/4 Brian Fox bri...@infinity.nu
I was recently working with a customer to move them off of using
non-unique
Why not just incorporate the full coordinate in the metadata. This is
also a problem for finding attached artifacts like javadocs and
sources. There is no record of them in the metadata. If we had a
complete catalog of the the artifacts deployed and not just for the
primary this would not
On Fri, Sep 4, 2009 at 4:36 PM, Jason van Zyljvan...@sonatype.com wrote:
Why not just incorporate the full coordinate in the metadata. This is also a
problem for finding attached artifacts like javadocs and sources. There is
no record of them in the metadata. If we had a complete catalog of the
Hi
I had the same problem in with the NAR plugin at the time. No way to
make those SNAPSHOTS
work if you deploy multi-platform artifacts with classifiers. I hope
this can be fixed in 3.0 as
there did not seem a way out in 2.x for NAR to handle it correctly.
Regards
Mark Donszelmann
On Sep
22 matches
Mail list logo
