Martin,

If you want to redeploy a clean 2.3.0 it looks like you could do the
same thing Andrea did.

--adrian

On Tue, 2006-12-12 at 09:43 +0100, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
> > 
> > Andrea Aime wrote:
> >> Martin Desruisseaux ha scritto:
> >>> Andrea Aime a écrit :
> >>>> * to fix this, is it simply ok to checkout the 2.2.2 tag,
> >>>>    build and do a mvn deploy?
> >>> I think that it work. It should overwrite the 2.2.2 JARs files.
> >>>
> >>>> * since the tag gets checked out during release:perform,
> >>>>    I guess the release instructions do miss something about
> >>>>    checking out the tag set-up by release:prepare and fix the
> >>>>    poms?
> >>> Maybe. For myself, I never used "mvn release"; I never trusted Maven
> >>> for that part. I always did the tag creation and pom.xml edition by
> >>> hand, and then used "mvn deploy".
> >> In fact we do something similar for geoserver, avoiding mvn release
> >> altogheter. mvn release makes us do a ridicolous number of full builds
> >> during the process as well, so I really guess we should change
> >> the release istructions accordingly.
> >>
> >> The only catch is, how do we build the source and bin stuff this way?
> >> In geoserver we call assembly:assembly, but as far as I know it has
> >> to be configured properly, or not? Justin, you're the Geoserver release
> >> process master, want to add anything?
> >>
> > Yeah, in GeoServer we use the assembly plugin directly, however it
> > leaves something to be desired as well. Its not really multi project
> > oriented so for some things you have to specify all modules manually,
> > not very nice.
> > 
> > Its been a while since i looked at the docs though, perhaps it has
> > gotten better.
> 
> I did redeploy stuff on the maven repo, seems to be fine now (confirmed
> by the users who reported the problem).
> 
> Also yesterday, just for the kicks of it, I did run mvn 
> assembly:assembly against 2.2.2 sources, with no configuration changes 
> in the pom, and surprise, it did generate a bin and src zips in target.
> The bin is exactly equal to the one I've deployed on sf (just a slightly 
> different level of compression apparently), and the src does not show
> significant differences (I've spotted changes in files that
> should not be there such as .classpath or surefire.properties).
> 
> I've opened a jira issue about trying to provide a streamlined release
> process that is not such a mess as our current one:
> http://jira.codehaus.org/browse/GEOT-1064
> 
> Cheers
> Andrea
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to