almaw's new build-test branch

[Igor Vaynberg <ig...@gmail.com>]

<AlMaw> svn checkout
https://svn.apache.org/repos/asf/incubator/wicket/branches/al-test-wicket-1.3.x
<AlMaw> cd al-test-wicket-1.3.x
<AlMaw> mvn install
<AlMaw> Done.
<AlMaw> In theory, we should be able to go:
<AlMaw> cd jdk-1.4
<AlMaw> mvn release:prepare
<AlMaw> ...
<AlMaw> mvn release:perform
<AlMaw> cd ../jdk-1.5
<AlMaw> mvn release:prepare
<AlMaw> ...
<AlMaw> mvn release:perform
<AlMaw> And we'll be done.
<AlMaw> It'll need a little tweaking.
<AlMaw> And you'll probably want to run the jdk-1.4 stuff using a 1.4 JDK.
<AlMaw> But check out how much neater the poms all are.

Re: almaw's new build-test branch

[Frank Bille <fr...@gmail.com>]

On 3/8/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> On 3/8/07, Frank Bille <fr...@gmail.com> wrote:
> > Ok, so
> >
> http://www.nabble.com/Maven-2-project-structure-with-wicket-parent-tf3175043.html#a8812638is
> > still a problem?
>
> Yep still a problem. But the biggest problem with getting all stuff
> built in one go (*not* the release, but locally) could be resolved by
> adding an 'all' profile that lists all modules. If you don't mind
> building against 1.5, then that would solve the 90% usecase.
>
> The release build, and our bamboo should always explicitly use JDK 1.4
> for wicket, extensions datetime and spring. The eclipse project
> settings should also explicitly set a 1.4 profile to remove the
> possibility to use 1.5 stuff.


Good, as long as the release is linked correctly thats fine.

Frank

Re: almaw's new build-test branch

[Al Maw <wi...@almaw.com>]

Martijn Dashorst wrote:
> On 3/8/07, Frank Bille <fr...@gmail.com> wrote:
>> Ok, so
>> http://www.nabble.com/Maven-2-project-structure-with-wicket-parent-tf3175043.html#a8812638is 
>>
>> still a problem?
> 
> Yep still a problem. But the biggest problem with getting all stuff
> built in one go (*not* the release, but locally) could be resolved by
> adding an 'all' profile that lists all modules. If you don't mind
> building against 1.5, then that would solve the 90% usecase.

The new structure no longer requires profiles:
To just build JDK 1.4 stuff, execute mvn in the jdk-1.4 folder.
To just build JDK 1.5 stuff, execute mvn in the jdk-1.5 folder.
To build both, execute mvn in the root folder.

Getting it all into Eclipse:
mvn eclipse:eclipse in the root.
File | Import > Choose the root folder.
Check the ones you want and click OK.

> The release build, and our bamboo should always explicitly use JDK 1.4
> for wicket, extensions datetime and spring. The eclipse project
> settings should also explicitly set a 1.4 profile to remove the
> possibility to use 1.5 stuff.

Yeah. See previous threads on how mvn eclipse:eclipse will set you up 
for 1.4 compliant code (no generics, etc.) but still use the default 
(probably JDK 5) JRE libraries to build against. Hence the utility of 
bamboo.

Al

Re: almaw's new build-test branch

[Martijn Dashorst <ma...@gmail.com>]

On 3/8/07, Frank Bille <fr...@gmail.com> wrote:
> Ok, so
> http://www.nabble.com/Maven-2-project-structure-with-wicket-parent-tf3175043.html#a8812638is
> still a problem?

Yep still a problem. But the biggest problem with getting all stuff
built in one go (*not* the release, but locally) could be resolved by
adding an 'all' profile that lists all modules. If you don't mind
building against 1.5, then that would solve the 90% usecase.

The release build, and our bamboo should always explicitly use JDK 1.4
for wicket, extensions datetime and spring. The eclipse project
settings should also explicitly set a 1.4 profile to remove the
possibility to use 1.5 stuff.

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

Re: almaw's new build-test branch

[Frank Bille <fr...@gmail.com>]

On 3/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> <AlMaw> And you'll probably want to run the jdk-1.4 stuff using a 1.4 JDK.
>

Ok, so
http://www.nabble.com/Maven-2-project-structure-with-wicket-parent-tf3175043.html#a8812638is
still a problem?

But are you proposing that we structure our 1.x projects like that?
Frank

Re: almaw's new build-test branch

[Igor Vaynberg <ig...@gmail.com>]

when i do mvn install from that branch root i get:

http://papernapkin.org/pastebin/view/4946

-igor



On 3/8/07, Alastair Maw <me...@almaw.com> wrote:
>
> Martijn Dashorst wrote:
> > On 3/8/07, Al Maw <wi...@almaw.com> wrote:
> >> We can automate the scp stuff as part of the -DperformRelease=true.
> >>
> >> We should surely also be copying doing a proper deploy, not an install,
> >> so that we copy the JARs for the projects to apache's Maven repo, so
> >> they can be synced up with repo1.maven.org?
> >
> > Incubator jars are barred from being released to the central repo. And
> > the release should be voted on before we put it into the wild. Maven
> > does have something like a staging thing, not sure how that works.
>
> Hmmm. We still need the Maven 2 poms and things in a repo somewhere so
> people can actually use them. If we're not allowed to publish things to
> repo1.maven.org while incubating that's pretty serious and seems rather
> misguided. :-(
>
> >> I'm still in favour of using the release plug-in if we can, as it scps
> >> the site to the right place, doesn't let you tag if there are test
> >> failures, and all the rest of it.
> >
> > We will not deploy the site as it currently is: no more examples and
> > just the default maven reports. But having the javadoc and the
> > dependencies up on the site is something worthwile. The WICKETxSITE
> > will function as our site portal, wicket-1.3.0 will have the release
> > details.
>
> Well, I was going to tweak the output of site:site somewhat to make it
> more useful as part of this process.
>
> >> > We also need to sign the release using gpg, as I understand there is
> a
> >> > maven plugin for that as well.
> >>
> >> OK, I'll see if I can look into this at some point.
> >
> > I just got gpg installed on my mac, so I'll be able to generate a key
> > and sign the releases.
>
> Hokay.
>
> What I'm interested in at this point is whether people would be happy to
> move the 1.3 modules/build structure to something that resembles this
> branch. I'm reluctant to do much more work on this proof-of-concept
> branch as there seems little point doing it all twice. I'll call a vote
> on this shortly on dev@ if no one objects.
>
> I'd also like to rename the "wicket-1.x" branch to "wicket-1.3.x" while
> I'm about it.
>
> Al
>

Re: almaw's new build-test branch

[Alastair Maw <me...@almaw.com>]

Martijn Dashorst wrote:
> On 3/8/07, Al Maw <wi...@almaw.com> wrote:
>> We can automate the scp stuff as part of the -DperformRelease=true.
>>
>> We should surely also be copying doing a proper deploy, not an install,
>> so that we copy the JARs for the projects to apache's Maven repo, so
>> they can be synced up with repo1.maven.org?
> 
> Incubator jars are barred from being released to the central repo. And
> the release should be voted on before we put it into the wild. Maven
> does have something like a staging thing, not sure how that works.

Hmmm. We still need the Maven 2 poms and things in a repo somewhere so
people can actually use them. If we're not allowed to publish things to
repo1.maven.org while incubating that's pretty serious and seems rather
misguided. :-(

>> I'm still in favour of using the release plug-in if we can, as it scps
>> the site to the right place, doesn't let you tag if there are test
>> failures, and all the rest of it.
> 
> We will not deploy the site as it currently is: no more examples and
> just the default maven reports. But having the javadoc and the
> dependencies up on the site is something worthwile. The WICKETxSITE
> will function as our site portal, wicket-1.3.0 will have the release
> details.

Well, I was going to tweak the output of site:site somewhat to make it
more useful as part of this process.

>> > We also need to sign the release using gpg, as I understand there is a
>> > maven plugin for that as well.
>>
>> OK, I'll see if I can look into this at some point.
> 
> I just got gpg installed on my mac, so I'll be able to generate a key
> and sign the releases.

Hokay.

What I'm interested in at this point is whether people would be happy to
move the 1.3 modules/build structure to something that resembles this
branch. I'm reluctant to do much more work on this proof-of-concept
branch as there seems little point doing it all twice. I'll call a vote
on this shortly on dev@ if no one objects.

I'd also like to rename the "wicket-1.x" branch to "wicket-1.3.x" while
I'm about it.

Al

Re: almaw's new build-test branch

[Martijn Dashorst <ma...@gmail.com>]

On 3/8/07, Al Maw <wi...@almaw.com> wrote:
> We can automate the scp stuff as part of the -DperformRelease=true.
>
> We should surely also be copying doing a proper deploy, not an install,
> so that we copy the JARs for the projects to apache's Maven repo, so
> they can be synced up with repo1.maven.org?

Incubator jars are barred from being released to the central repo. And
the release should be voted on before we put it into the wild. Maven
does have something like a staging thing, not sure how that works.

> I'm still in favour of using the release plug-in if we can, as it scps
> the site to the right place, doesn't let you tag if there are test
> failures, and all the rest of it.

We will not deploy the site as it currently is: no more examples and
just the default maven reports. But having the javadoc and the
dependencies up on the site is something worthwile. The WICKETxSITE
will function as our site portal, wicket-1.3.0 will have the release
details.

> > We also need to sign the release using gpg, as I understand there is a
> > maven plugin for that as well.
>
> OK, I'll see if I can look into this at some point.

I just got gpg installed on my mac, so I'll be able to generate a key
and sign the releases.

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

Re: almaw's new build-test branch

[Al Maw <wi...@almaw.com>]

Martijn Dashorst wrote:
> On 3/8/07, Al Maw <wi...@almaw.com> 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 can automate the scp stuff as part of the -DperformRelease=true.

We should surely also be copying doing a proper deploy, not an install, 
so that we copy the JARs for the projects to apache's Maven repo, so 
they can be synced up with repo1.maven.org?

I'm still in favour of using the release plug-in if we can, as it scps 
the site to the right place, doesn't let you tag if there are test 
failures, and all the rest of it.

> We also need to sign the release using gpg, as I understand there is a
> maven plugin for that as well.

OK, I'll see if I can look into this at some point.

Al

Re: almaw's new build-test branch

[Jean-Baptiste Quenot <jb...@apache.org>]

* Martijn Dashorst:

> find . -name "pom.xml" | xargs sed -e "s/version>1.x-incubating-SNAPSHOT/version>1.3.0-incubating-beta1/g"

You mean "sed -i", not just "sed", otherwise changes go to stdout.
-- 
     Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

Re: almaw's new build-test branch

[Martijn Dashorst <ma...@gmail.com>]

On 3/8/07, Al Maw <wi...@almaw.com> 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

Re: almaw's new build-test branch

[Al Maw <wi...@almaw.com>]

Martijn Dashorst wrote:
> How does the nested projects work with Eclipse? afaiu eclipse's
> workspace needs to be a flat structure...

You just run mvn eclipse:eclipse at the top level and import only the 
bottom-level projects (use File | Import and uncheck three boxes, I 
guess). This isn't a big deal.

You don't need to have the <packaging>pom</packaging> projects imported 
into Eclipse as Maven 2 builds. If you want the top-level project in 
there for convenience of editing the site stuff, add the src folder from 
it instead of the root.

> afair the release plugin tags/branches each project separately. This 
> is not good imo. We don't release each project separate, but the
> whole branch in one go. I've used the release plugin in the maven 1
> days and it was nothing but a big pain in the rectum.

So, I've just tried to fake out a release in this branch. If it weren't 
for the failing unit tests I'd have some tags to show you, but the long 
and the short of it is that we will end up with two tags - one for the 
JDK 1.4 directory and one for the JDK 1.5 directory.

This is the result of having to run two releases because you want to use 
two different JDKs, and there's not much we can do about it.

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'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.

> Last thing for the moment: inherit the top parent from 
> org.apache/apache/4.0, this way you get the organization and some 
> other things for free.

Last time I tried this it bought almost nothing because the various 
plug-ins it pulled in were alpha versions that didn't even work. :)
But yes, we should probably do that.

> 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).

> 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.

Al

Re: almaw's new build-test branch

[Martijn Dashorst <ma...@gmail.com>]

afair the release plugin tags/branches each project separately. This
is not good imo. We don't release each project separate, but the whole
branch in one go. I've used the release plugin in the maven 1 days and
it was nothing but a big pain in the rectum.

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?

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.

Last thing for the moment: inherit the top parent from
org.apache/apache/4.0, this way you get the organization and some
other things for free.

Martijn

On 3/8/07, Martijn Dashorst <ma...@gmail.com> wrote:
> How does the nested projects work with Eclipse? afaiu eclipse's
> workspace needs to be a flat structure...
>
> Martijn
>
> On 3/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > <AlMaw> svn checkout
> > https://svn.apache.org/repos/asf/incubator/wicket/branches/al-test-wicket-1.3.x
> > <AlMaw> cd al-test-wicket-1.3.x
> > <AlMaw> mvn install
> > <AlMaw> Done.
> > <AlMaw> In theory, we should be able to go:
> > <AlMaw> cd jdk-1.4
> > <AlMaw> mvn release:prepare
> > <AlMaw> ...
> > <AlMaw> mvn release:perform
> > <AlMaw> cd ../jdk-1.5
> > <AlMaw> mvn release:prepare
> > <AlMaw> ...
> > <AlMaw> mvn release:perform
> > <AlMaw> And we'll be done.
> > <AlMaw> It'll need a little tweaking.
> > <AlMaw> And you'll probably want to run the jdk-1.4 stuff using a 1.4 JDK.
> > <AlMaw> But check out how much neater the poms all are.
> >
>
>
> --
> 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
>


-- 
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

Re: almaw's new build-test branch

[Martijn Dashorst <ma...@gmail.com>]

How does the nested projects work with Eclipse? afaiu eclipse's
workspace needs to be a flat structure...

Martijn

On 3/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> <AlMaw> svn checkout
> https://svn.apache.org/repos/asf/incubator/wicket/branches/al-test-wicket-1.3.x
> <AlMaw> cd al-test-wicket-1.3.x
> <AlMaw> mvn install
> <AlMaw> Done.
> <AlMaw> In theory, we should be able to go:
> <AlMaw> cd jdk-1.4
> <AlMaw> mvn release:prepare
> <AlMaw> ...
> <AlMaw> mvn release:perform
> <AlMaw> cd ../jdk-1.5
> <AlMaw> mvn release:prepare
> <AlMaw> ...
> <AlMaw> mvn release:perform
> <AlMaw> And we'll be done.
> <AlMaw> It'll need a little tweaking.
> <AlMaw> And you'll probably want to run the jdk-1.4 stuff using a 1.4 JDK.
> <AlMaw> But check out how much neater the poms all are.
>


-- 
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