geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From siss...@insession.com
Subject Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
Date Fri, 01 Apr 2005 05:10:58 GMT
Jeremy Boynes <jboynes@apache.org> wrote on 01/04/2005 02:17:48 PM:

> Geir Magnusson Jr wrote:
> > 
> > No, but I worry about just bundling random whatever from outside the 
> > project with our releases.  It would help to use the svn revision on 
the 
> > jar, but we should really make it clear that it's something the 
geronimo 
> > project created for it's use, rather than confuse people that it might 

> > be an artifact from ActiveMQ.  The word 'SNAPSHOT' would help.
> > 
> 
> SNAPSHOT has a specific meaning to Maven - it will cause it to check the 

> remote repo for a newer version (by timestamp) even if a copy exists in 
> the local repo.
> 
> This is good for daily builds, a nightmare for anything where 
> consistency is required.
> 
> So when we decide to do a milestone (or release) we need to ensure there 

> are no dependencies on versions with SNAPSHOT in them and instead use 
> ones that contain a SVN revision number or a CVS timestamp:
> 
> bad:    foo-bar-1.3-SNAPSHOT.jar
> ok:     foo-bar-1.3-20050401.jar
> better: foo-bar-1.3-158653.jar

+1 for foo-bar-1.3-158653.jar

I often wonder whether we would have a more stable daily build environment 
if we also use dependencies with versions in them.  Currently there is no 
easy way to guarantee that an online build will work, as an unversioned 
SNAPSHOT that is updated could break the build.

It would be nice to be able to say that today's daily build (where all 
tests passed) used the following dependencies: foo-bar-1.3-158653.jar, 
etc...  Therefore if we used versioned dependencies there would be a 
higher chance that if you wanted to build Geronimo at a particular 
revision (e.g. 14 days ago) that it would build successfully (assuming 
those versioned dependencies are still around).

To be able to do this effectively, we would need a tool that tells us when 
there is a newer version available in a remote repository.  When a newer 
version is available, a developer (or a continuous integration tool) can 
change their local copy of the code to use the newer version and test 
compatibility with that version and if all is ok, commit the change. 

Currently, all developers are exposed to updates to SNAPSHOTS and 
sometimes the build can be broken for days.  If you don't have a backup of 
your previously building code (and repository?), one is in trouble if they 
want rebuild (e.g. an offline build) a working version.

I haven't thought this through too much, but have never felt comfortable 
with SNAPSHOTs.  Could versioned dependencies help us here?

John

> 
> --
> Jeremy

This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.


Mime
View raw message