maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Garcia" <>
Subject RE: new maven goal
Date Sat, 20 Dec 2003 02:04:31 GMT
I have a related question to SNAPSHOTs, now that we have a thread on this.

I notice that SNAPSHOT jar file names substitute the version for the word
SNAPSHOT.  How does this behavior work for projects that have multiple

Our Platform project at work has many branches to it, there is a v1.0
branch, a v1.1 branch, and a v2.0 branch.  The 1.0 branch is stable, no new
changes are going in it (unless they are bug fixes).  The 1.1 and 2.0
branches are not stable yet.  So in our Maven repository we would ideally

platform-1.0.jar          (stable)
platform-1.1-SNAPSHOT.jar (not stable)
platform-2.0-SNAPSHOT.jar (not stable)

but in reality the SNAPSHOT versions lose the version number so I end up
with something like

platform-1.0.jar      (stable)
platform-SNAPSHOT.jar (for 1.1)
platform-SNAPSHOT.jar (for 2.0)

The relevant portions of the project.xml files for the projects are

When I jar:install-snapshot goal, I get the platform-<timestamp>.jar, and a
platform-SNAPSHOT.jar (which are the same).  I've just lost the version 
though!  I should have platform-2.0-SNAPSHOT.jar.

I can change the project.xml to look like


but that seems to go against Maven policies.  

Any suggestions here?

-----Original Message-----
From: Sonnek, Ryan
To: 'Maven Developers List'
Sent: 12/19/2003 4:12 PM
Subject: RE: new maven goal

I see your point.  My original impression was that people were wanting
have every snapshot from the projects' inception on the remote repo.  I
could see a maven continuous integration server running and providing
snapshot artifacts for a month or so.  Maybe I could modify this plugin
keep archives of snapshots by date or a certain number. 

Now I have 2 scenerio questions to ask you.  
1.  How would your developer know which snapshot worked and which
didn't?  It's still going to be a hassle and problematic to guess which
snapshot to rollback too.  
2.  If you're depending on SpicyJMX-SNAPSHOT, that suggests to me that
are integrating with current features and will use a stable release when
is finished.  That means that your developers will NEED to use the
new snapshot and fix the incompatibilities as your dependency changes


-----Original Message-----
From: Ryan Hoegg [] 
Sent: Friday, December 19, 2003 5:57 PM
To: Maven Developers List
Subject: Re: new maven goal

(all projects mentioned below are fictitious.. blah blah)

I am working on jFnord, an open source project with at least three other

active developers.  I am the primary developer of FnordJMX, which 
depends on the SNAPSHOT version of SpicyJMX.  I go on a three week 
holiday for Christmas.  SpicyJMX developers release a few new 
SNAPSHOTs.  The other jFnord developers try to work on the CVS version, 
and it fails to build.

In this case, I think resolving snapshots is the best course of action.

Ryan Hoegg
ISIS Networks

Sonnek, Ryan wrote:

>Understood.  I think that this plugin is strictly for developers use on
>their local respository, and any files on the remote repository must be
>handled with great care.  
>Although, I personally question the usefulness of having multiple
>snapshots on the remote repository.  If you are developing an
>with a SNAPSHOT dependency, you are essentially on the bleeding edge
>and putting yourself at risk of suffering changes from the other
>(versus waiting for a stable release).  I honestly don't see when you
>want to use the "resolve-snapshots" goal to change from a SNAPSHOT
>to a TIMESTAMPED release.  IMO, you should be using the snapshot OR an
>official release.  

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message