On 3/8/07, Al Maw <[EMAIL PROTECTED]> wrote:
Martijn Dashorst wrote: The alternative is to write a little script which goes and updates <version> elements in the POMs, tags everything in SVN, then does a fresh checkout and then a "mvn -DperformRelease=true deploy" in each of the jdk-1.* directories. This would actually be pretty simple. If it's the preferred approach, I'll have a go at that. It'd be nice to be able to do it with just Maven, though.
I think just doing a svn cp branches/wicket-1.x tags/wicket-1.3.0 svn cp tags/wicket-1.x releases/wicket-1.3.0 svn switch releases/wicket-1.3.0 find . -name "pom.xml" | xargs sed -e "s/version>1.x-incubating-SNAPSHOT/version>1.3.0-incubating-beta1/g" mvn4 -DperformRelease=true install site assembly:assembly mvn -DperformRelease=true install site assembly:assembly svn commit -m "Release 1.3" scp `find . -name "*.zip"` people.apache.org:~/public_html/release-1.3-incubating-beta1 scp `find . -name "*.gz"` people.apache.org:~/public_html/release-1.3-incubating-beta1 scp `find . -name "*.md5"` people.apache.org:~/public_html/release-1.3-incubating-beta1 scp `find . -name "*.sig"` people.apache.org:~/public_html/release-1.3-incubating-beta1 We also need to sign the release using gpg, as I understand there is a maven plugin for that as well.
> I've used the release plugin in the maven 1 days and it was nothing > but a big pain in the rectum. The Maven 2 version is a ground-up rewrite, so I don't think that's relevant.
Not everything that is a complete rewrite is good ;)
> Why is the root pom version 1-SNAPSHOT and the jdk* poms > 1-3-incubating-SNAPSHOT? Can't we just put the version in the root > pom and be done with that? Depends. If we need to use two different JDKs, we need to release the jdk-1.4 and jdk-1.5 trees separately. At this point, you'll need to have released the parent already. The thinking was that this is easily done by just having a static version number, so effectively you can release the parent independent of the rest of it. It's not going to change much, after all (especially if we remove the contributor list).
I like and prefer the one version fits all approach, then you don't have to match the versions. And the structure will be copied in full between branches, not without the parent pom imo. This makes that we could have different 1.0 versions in different branches. I'd rather make it one stream: 1.3.0 for all poms in all wicket 1.3.0 modules in the 1.3.0 branch
> Another thing I want to remove from the pom's are the contributor, > developer list. These are rather dynamic and don't add much. The poms > don't need to change and be released when these things are modified. Fine. This is in the root pom only in the new branch, so would be an easy fix. I thought we originally put stuff in there to keep the Apache folk happy. If not, let's ditch it. It gets out of sync and bloats things annoyingly. You can probably auto-generate something similar from JIRA, anyway.
Contributors and developers can better go onto the website than in the pom, and I don't know if it is a policy or convention or something the maven folks like. Given the allergic reaction to the @author tags, I would assume putting this information also into the pom would result in a slight rash. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.5 will keep your server alive. Download Wicket now! http://wicketframework.org
