> Don't you have some scripts to help you release it? You said something about > a script for doing the mvn clean site assembly:assembly thing in all > projects. Can't you add a line or two to unpack the release and run mvn test > in it? Is there something I/we can help you with in setting up a good > release environment/scripts so it will be easier for you?
I have some scripts to help me, but building the actual stuff is not what takes the most time. Wicket 1.x is special in that it requires 2 different JVM's (otherwise you have the possibility of using 1.5 rt.jar in your 1.4 project): JDK 1.4: * wicket, wicket-extensions, wicket-examples, wicket-spring, wicket-spring-examples JDK 1.5: * the rest of the projects So I have two maven start up scripts: mvn4 and mvn. mvn4 uses the JDK1.4 (doesn't know that 1.5 even exists). Steps I do: - check out the wicket-1.2.x branch - try to build all projects - fix compilation issues - fix unit tests - try to build all projects - fix dependencies - try to build all projects - generate the sites - fix the site documentation - generate the sites - try to build all projects - commit to svn - svn copy wicket-1.2.x to tags/wicket-1.2.5 - svn copy tags/wicket-1.2.5 to releases/wicket-1.2.5 - switch to releases/wicket-1.2.5 - update all project files to use version 1.2.5 - edit index.xml in site of Wicket project to add release notes - generate site for wicket project - curse the maven site plugin for being very buggy - edit index.xml in site of Wicket project to add release notes - generate site for wicket project - repeat last 3 steps until the site is workable - commit to svn - generate assemblies using script - look at contents of distributions to see if anything is really wrong - try to build jar with mvn, sometimes even with ant - rebuild assemblies - commit to svn - upload assemblies to sf.net - create releases for each project in release filesystem - assign each zip and tgz to a project and release - update release descriptors for each zip and tgz to "platform independent" and "zip", "tgz" respectivily - deploy site to sf.net - check if site still works - create release notes for email to user, dev, announce list - create release notes for javalobby.org, blog So the biggest problems are in the manual stuff: failing unittests, maven plugins that don't work, sites that don't generate, and mostly: waiting for the compiler, jar/javadoc/unittests to do their work. The last stage is also mind numbing: releasing to sf.net, as each file released requires about 15 mouse clicks to complete (each click is a page request). The best way of helping is ensuring that all the unittests run when a release vote is held. Martijn ------------------------------------------------------------------------- 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 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
