This is why I ([collections]) use ant for builds and maven only for website building.
Basically, IMHO, a src-zip should contain not only the source java, but the source for building a local copy of the website.
I agree (that the xdoc should be included in the src distro). This could be done using a maven preGoal:
<preGoal name="dist:build-src">
<ant:copy todir="${maven.dist.src.assembly.dir}/xdocs">
<ant:fileset dir="xdocs"/>
</ant:copy>
</preGoal>I don't see this as a big maintenance issue, but could be I am missing Hen's point below.
Phil
Stephen
----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]>
Pretty sure Maven doesn't put xdocs in the src zip. If we have to do this, then I think we shouldn't branch for a release, it's going to be too painful to keep the two sites synced.
Starting to see negatives to the tying of site to code that Maven does :)
Hen
On Sun, 13 Feb 2005 01:51:52 -0000, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Er, no. The xdocs should be shipped in the src zip file. They are used by people outside Apache building a website.
Stephen
----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>
> Cool. I'll remove the xdocs from the branch.
>
> Hen
>
> On Sat, 12 Feb 2005 21:39:33 -0000, Stephen Colebourne
> <[EMAIL PROTECTED]> wrote:
>> It needs to be like [collections], but probably not as automated
>>
>> Website is built from trunk.
>> Javadoc of 2.1 release is built from 2.1 branch and copied to server >> in
>> apidocs-2.1 directory
>> Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk
>>
>> Stephen
>>
>> ----- Original Message -----
>> From: "Henri Yandell" <[EMAIL PROTECTED]>
>> > Though now I'm a bit confused about whether the website should exist
>> > on the 2.1 branch or not :)
>> >
>> > Odd as it sounds, I think we should we be releasing code from 2.1
>> > branch, and building the site from trunk.
>> >
>> > Otherwise it'll be a bit odd I think. Sound insane?
>> >
>> > Hen
>> >
>> >
>> > On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell >> > <[EMAIL PROTECTED]>
>> > wrote:
>> >> Only question is whether to specify a 0 for the 0th maintenance. >> >> Not
>> >> a big deal though, I've setup the following release branch:
>> >>
>> >> https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH
>> >>
>> >> the naming matches the syntax we used for 1.0 when making 1.0.1. I
>> >> know it could be a lot better (especially as SVN doesn't barf on . >> >> as
>> >> CVS does), but I'm going with consistency for the moment.
>> >>
>> >> I'll start tweaking that towards a release. Trunk is 2.2-dev now.
>> >>
>> >> Hen
>> >>
>> >> On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory
>> >> <[EMAIL PROTECTED]> wrote:
>> >> > Personally, I've always liked the following numbering scheme:
>> >> >
>> >> > Major.Minor.Maintenance.
>> >> >
>> >> > Gary
>> >> >
>> >> > -----Original Message-----
>> >> > From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
>> >> > Sent: Monday, February 07, 2005 2:08 PM
>> >> > To: Jakarta Commons Developers List
>> >> > Subject: Re: [lang] release strategy
>> >> >
>> >> > Personally I find the three digit release numbers just confusing. >> >> > I
>> >> > much
>> >> >
>> >> > prefer to reserve the third digit for essential patches.
>> >> >
>> >> > So, I'm happy to have a 2.1-branch, but I want the release to be
>> >> > 2.1,
>> >> > not
>> >> > 2.1.0 or 2.1.1.
>> >> >
>> >> > Stephen
>> >> >
>> >> > ----- Original Message -----
>> >> > From: "Henri Yandell" <[EMAIL PROTECTED]>
>> >> > > I'm very tempted to try the branch then release strategy, and
>> >> > > wondered
>> >> > > what people thought about the idea. It might suggest a slight
>> >> > > change
>> >> > > to the version number style:
>> >> > >
>> >> > > Create 2.1 branch.
>> >> > > Make changes to 2.1 branch until we're ready for release.
>> >> > > Tag 2.1 branch with 2.1.0 tag.
>> >> > > ... later
>> >> > > Change 2.1 branch until we're ready for release
>> >> > > Tag 2.1 branch with 2.1.1tag.
>> >> > > ... later in parallel
>> >> > > Change trunk until we're near a release
>> >> > > Create 2.2 branch (or 3.0)
>> >> > > Change 2.2 until ready
>> >> > > Tag 2.2 with 2.2.0
>> >> > >
>> >> > > etc.
>> >> > >
>> >> > > If we called it 2.1-head or something, it wouldn't need the
>> >> > > version
>> >> > > change, it just feels more logical to go with a 2.1.0 release >> >> > > than
>> >> > > a
>> >> > > 2.1 one if we use this style of development.
>> >> > >
>> >> > > Anyway, it seems to me that this fits us more nowadays. We end >> >> > > up
>> >> > > with
>> >> > > the text package slowing down because it's not planned for the
>> >> > > next
>> >> > > release, and having to avoid various other bugzilla requests as
>> >> > > they're not wanting to be fixed until later.
>> >> > >
>> >> > > Any thoughts?
>> >> > >
>> >> > > Hen
>> >> > >
>> >> > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
