maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Garcia" <SGar...@qrs.com>
Subject RE: new maven goal
Date Sat, 20 Dec 2003 01:28:38 GMT
Ryan I think that a great point.  When you state one has a dependency on a
branch of a project, as opposed to a stable release of a project, then you
might encounter times that building your code against a snapshot from that
branch might break your build.  That is the reason why following a branch
means you must sync often, and try to follow HEAD as closely as possible.

We are addressing this exact problem at my work.  We have many projects that
are dependent on a branch my group is responsible for.  That code is
fluctuating because it isn't stable yet.  In the past people would grab our
jar file in an ad hoc manner, meaning they would grab some release point of
our branch that does not match with HEAD.  As a result many people saw bad
things happen.  And it was all derived from not taking a build jar from HEAD
but at some prior point in the branches time.

As a result, I'm not sure why one would need to keep track of all the
different timestamp version of a snapshot branch, when it is constantly
changing.  We probably post a new SNAPSHOT 10 times a day, consequently we
are going to be having artifact bloat.  

-----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
to
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
to
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
snapshot
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
you
are integrating with current features and will use a stable release when
one
is finished.  That means that your developers will NEED to use the
"broken"
new snapshot and fix the incompatibilities as your dependency changes
them.


Ryan

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

Scenario:
(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
http://www.isisnetworks.net

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
archived
>snapshots on the remote repository.  If you are developing an
application
>with a SNAPSHOT dependency, you are essentially on the bleeding edge
anyways
>and putting yourself at risk of suffering changes from the other
project
>(versus waiting for a stable release).  I honestly don't see when you
would
>want to use the "resolve-snapshots" goal to change from a SNAPSHOT
release
>to a TIMESTAMPED release.  IMO, you should be using the snapshot OR an
>official release.  
>
>Ryan  
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message