excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans ...@domek.be>
Subject Re: releasing excalibur, partially this time
Date Sun, 20 Aug 2006 14:54:58 GMT

On 20 Aug 2006, at 15:50, Leo Simons wrote:

> Do all artifact ids stay the same?

IIRC i created the m2 poms largely off the m1 project.xml's so there  
shouldn't be any big differences.

>> Is everyone happy
>> with the current module structure ?
> *shrug*. Never really was :)
> Honestly, I haven't reviewed the m2 bits in a looong time. I know it
> looked good when initially committed. Were there big changes from the
> maven 1 structure?

Nope, no structural changes really. If you do an mvn - 
Dmaven.test.skip=true install and then check your local repo you get  
an idea of what the artifacts and their groupids will look like (note  
i'm in the process of simplifying the groupIds a bit - again nothing  
structural though).

>> Lazy consensus applies, so scream if you have problems, comments or
>> suggestions.
> Of course, lazy consensus doesn't apply to releases. They need a  
> PMC vote.

<insert witty comment here about me forgetting about this "minor"  

> If you create some candidate releases and put them up somewhere  
> I'll be happy
> to review and vote, but we're all busy so count on some time :)

If some time means a week or two then that's fine, anything longer  
and you'ld be testing (so in fact scratching) my itch to get this  
release out of the way :)

> My main beef with maven 2 (corporate stuff) is its so hard to have
> "repeatable" builds, eg making sure I can take some source code a year
> from now and result in a build with exactly the same binaries, so I'd
> love to see you be very precise in keeping logs, perhaps even going so
> far as cleaning out ~/.m2, creating the builds, then zipping ~/.m2 and
> pushing it in SVN somewhere close to the release tag, then doing later
> release candidates with -offline. Or something; haven't fully  
> figured it
> out yet. Does cocoon have a process?

The release plugin will refuse to work if it detects any *-SNAPSHOT  
dependencies in you pom. It's not an absolute guarantee to have a  
repeatable build enviroment but it goes a long way already. If  
required i can tar up ~/.m2 ofcourse, no biggy - that should give you  
the 100% reproduceability then. At cocoon we don't have a process in  
place for this.


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

View raw message