You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2010/03/12 02:25:38 UTC
[all] Replace Commons Site m1 build with m2 version
I have created a m2 site for Commons[1][2] as (hopefully) a
replacement for the m1 site[3] that we currently have - you can see it
here:
http://people.apache.org/~niallp/commons/
IMO its a PITA to have to switch to m1 to build the commons site and
its time to move to m2.
* The new releases page[4] points to the download pages on the
components' sites (removing the need for the current XSLT ant task to
generate the downloads)
* I've put PMC members in the pom - so we have a page showing them[5]
Feel free to jump in and correct/improve anything.
Opinions/feedback on switching from the old m1 site to this m2 site
would be welcome. If anyone objects please shout or I'll assume people
are OK with this.
Niall
[1] http://svn.apache.org/viewvc?view=revision&revision=922094
[2] http://svn.apache.org/viewvc/commons/proper/commons-site/
[3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
[4] http://people.apache.org/~niallp/commons/downloads/index.html
[5] http://people.apache.org/~niallp/commons/team-list.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>> I have created a m2 site for Commons[1][2] as (hopefully) a
>>> replacement for the m1 site[3] that we currently have - you can see it
>>> here:
>>> http://people.apache.org/~niallp/commons/
>>>
>>> IMO its a PITA to have to switch to m1 to build the commons site and
>>> its time to move to m2.
>> +1, thanks for doing this.
>>
>>> * The new releases page[4] points to the download pages on the
>>> components' sites (removing the need for the current XSLT ant task to
>>> generate the downloads)
>>> * I've put PMC members in the pom - so we have a page showing them[5]
>>>
>>> Feel free to jump in and correct/improve anything.
>>>
>>> Opinions/feedback on switching from the old m1 site to this m2 site
>>> would be welcome. If anyone objects please shout or I'll assume people
>>> are OK with this.
>> There seem to be rather too many links marked as "external". I don't
>> know if this is a side effect of creating a demo build or whether this
>> would be seen in a live deployment - if so, then this needs to be
>> fixed.
>
> OK fixed alot of them - some of these links are now broken on my
> *demo* site - but would be fine once deployed to the normal location:
First, thanks for doing this. I vaguely recall that when we created
the old m1 site, we got rid of the silly little external arrow
thingies in a stylesheet fix. It was easier to test (as you can see
in your demo site) when the nav included full URL links. Doesn't
make a difference to me personally.
Thanks again for doing this.
Phil
>
> http://people.apache.org/~niallp/commons/
> http://svn.apache.org/viewvc?view=revision&revision=922120
>
>>> Niall
>>>
>>> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 17:22, sebb wrote:
> On 13/03/2010, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-13 16:53, sebb wrote:
>> > On 13/03/2010, Dennis Lundberg <de...@apache.org> wrote:
>> >> On 2010-03-12 11:34, Niall Pemberton wrote:
>> >> > On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>> >> >> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >> >>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>> >> >>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >> >>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>> >> >>> >> replacement for the m1 site[3] that we currently have - you can see it
>> >> >>> >> here:
>> >> >>> >> http://people.apache.org/~niallp/commons/
>> >> >>> >>
>> >> >>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>> >> >>> >> its time to move to m2.
>> >> >>> >
>> >> >>> > +1, thanks for doing this.
>> >> >>> >
>> >> >>> >> * The new releases page[4] points to the download pages on the
>> >> >>> >> components' sites (removing the need for the current XSLT ant task to
>> >> >>> >> generate the downloads)
>> >> >>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>> >> >>> >>
>> >> >>> >> Feel free to jump in and correct/improve anything.
>> >> >>> >>
>> >> >>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>> >> >>> >> would be welcome. If anyone objects please shout or I'll assume people
>> >> >>> >> are OK with this.
>> >> >>> >
>> >> >>> > There seem to be rather too many links marked as "external". I don't
>> >> >>> > know if this is a side effect of creating a demo build or whether this
>> >> >>> > would be seen in a live deployment - if so, then this needs to be
>> >> >>> > fixed.
>> >> >>>
>> >> >>>
>> >> >>> OK fixed alot of them - some of these links are now broken on my
>> >> >>> *demo* site - but would be fine once deployed to the normal location:
>> >> >>>
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>> >> >> links for Commits and Issues. Just noticed that Announce is missing
>> >> >> from the list ;-)
>> >> >>
>> >> >> The Surefire report is not relevant - and is confusing - but I could
>> >> >> not work out how to get rid of it.
>> >> >
>> >> > I've changed the pom's parent from commons-parent to apache - this
>> >> > means we don't inherit the reports specified (such as surefure) and
>> >> > also the site.xml. Not inheriting site.xml from commons-parent gives
>> >> > us more control over the main sites navigation.
>> >>
>> >>
>> >> We could move all the reposting stuff in commons parent to a "reporting"
>> >> profile. This is a common way to achieve two things:
>> >>
>> >> - Make the build faster if you don't want the reports
>> >> - Prevent some children (like commons-site) from inheriting stuff unless
>> >> you explicitly activate the profile
>> >>
>> >> The only drawback is that you need to supply the -Preporting parameter
>> >> when you deploy the site, but this can easily be documented in our
>> >> release instructions.
>> >
>> > Is it possible to add a section to the commons-site pom that generates
>> > a warning message if the -Preporting param is not used?
>>
>>
>> Sorry, what I wrote wasn't clear.
>>
>> The -Preporting parameter is only needed when the site of a *component*
>> is deployed - not when *commons-site* is deployed.
>
> OK, but the question is still relevant - is it possible to print a
> warning on the console if the param is omitted?
>
> This could also be useful in other contexts.
I'm not sure if/how you could do that.
>> >
>> >> I can help with this if you think it's a good idea.
>> >>
>> >>
>> >> >
>> >> > Niall
>> >> >
>> >> >>> http://people.apache.org/~niallp/commons/
>> >> >>>
>> >> >>> http://svn.apache.org/viewvc?view=revision&revision=922120
>> >> >>>
>> >> >>>
>> >> >>> >> Niall
>> >> >>> >>
>> >> >>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> >> >>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> >> >>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> >> >>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>> >> >>
>> >> >> Still shows external links for me.
>> >> >>
>> >> >>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>> >> >>> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Dennis Lundberg
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by sebb <se...@gmail.com>.
On 13/03/2010, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-13 16:53, sebb wrote:
> > On 13/03/2010, Dennis Lundberg <de...@apache.org> wrote:
> >> On 2010-03-12 11:34, Niall Pemberton wrote:
> >> > On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
> >> >> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >> >>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
> >> >>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >> >>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
> >> >>> >> replacement for the m1 site[3] that we currently have - you can see it
> >> >>> >> here:
> >> >>> >> http://people.apache.org/~niallp/commons/
> >> >>> >>
> >> >>> >> IMO its a PITA to have to switch to m1 to build the commons site and
> >> >>> >> its time to move to m2.
> >> >>> >
> >> >>> > +1, thanks for doing this.
> >> >>> >
> >> >>> >> * The new releases page[4] points to the download pages on the
> >> >>> >> components' sites (removing the need for the current XSLT ant task to
> >> >>> >> generate the downloads)
> >> >>> >> * I've put PMC members in the pom - so we have a page showing them[5]
> >> >>> >>
> >> >>> >> Feel free to jump in and correct/improve anything.
> >> >>> >>
> >> >>> >> Opinions/feedback on switching from the old m1 site to this m2 site
> >> >>> >> would be welcome. If anyone objects please shout or I'll assume people
> >> >>> >> are OK with this.
> >> >>> >
> >> >>> > There seem to be rather too many links marked as "external". I don't
> >> >>> > know if this is a side effect of creating a demo build or whether this
> >> >>> > would be seen in a live deployment - if so, then this needs to be
> >> >>> > fixed.
> >> >>>
> >> >>>
> >> >>> OK fixed alot of them - some of these links are now broken on my
> >> >>> *demo* site - but would be fine once deployed to the normal location:
> >> >>>
> >> >>
> >> >> Thanks!
> >> >>
> >> >> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
> >> >> links for Commits and Issues. Just noticed that Announce is missing
> >> >> from the list ;-)
> >> >>
> >> >> The Surefire report is not relevant - and is confusing - but I could
> >> >> not work out how to get rid of it.
> >> >
> >> > I've changed the pom's parent from commons-parent to apache - this
> >> > means we don't inherit the reports specified (such as surefure) and
> >> > also the site.xml. Not inheriting site.xml from commons-parent gives
> >> > us more control over the main sites navigation.
> >>
> >>
> >> We could move all the reposting stuff in commons parent to a "reporting"
> >> profile. This is a common way to achieve two things:
> >>
> >> - Make the build faster if you don't want the reports
> >> - Prevent some children (like commons-site) from inheriting stuff unless
> >> you explicitly activate the profile
> >>
> >> The only drawback is that you need to supply the -Preporting parameter
> >> when you deploy the site, but this can easily be documented in our
> >> release instructions.
> >
> > Is it possible to add a section to the commons-site pom that generates
> > a warning message if the -Preporting param is not used?
>
>
> Sorry, what I wrote wasn't clear.
>
> The -Preporting parameter is only needed when the site of a *component*
> is deployed - not when *commons-site* is deployed.
OK, but the question is still relevant - is it possible to print a
warning on the console if the param is omitted?
This could also be useful in other contexts.
> >
> >> I can help with this if you think it's a good idea.
> >>
> >>
> >> >
> >> > Niall
> >> >
> >> >>> http://people.apache.org/~niallp/commons/
> >> >>>
> >> >>> http://svn.apache.org/viewvc?view=revision&revision=922120
> >> >>>
> >> >>>
> >> >>> >> Niall
> >> >>> >>
> >> >>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
> >> >>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
> >> >>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
> >> >>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
> >> >>
> >> >> Still shows external links for me.
> >> >>
> >> >>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
> >> >>> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Dennis Lundberg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 16:53, sebb wrote:
> On 13/03/2010, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-12 11:34, Niall Pemberton wrote:
>> > On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>> >> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>> >>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>> >>> >> replacement for the m1 site[3] that we currently have - you can see it
>> >>> >> here:
>> >>> >> http://people.apache.org/~niallp/commons/
>> >>> >>
>> >>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>> >>> >> its time to move to m2.
>> >>> >
>> >>> > +1, thanks for doing this.
>> >>> >
>> >>> >> * The new releases page[4] points to the download pages on the
>> >>> >> components' sites (removing the need for the current XSLT ant task to
>> >>> >> generate the downloads)
>> >>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>> >>> >>
>> >>> >> Feel free to jump in and correct/improve anything.
>> >>> >>
>> >>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>> >>> >> would be welcome. If anyone objects please shout or I'll assume people
>> >>> >> are OK with this.
>> >>> >
>> >>> > There seem to be rather too many links marked as "external". I don't
>> >>> > know if this is a side effect of creating a demo build or whether this
>> >>> > would be seen in a live deployment - if so, then this needs to be
>> >>> > fixed.
>> >>>
>> >>>
>> >>> OK fixed alot of them - some of these links are now broken on my
>> >>> *demo* site - but would be fine once deployed to the normal location:
>> >>>
>> >>
>> >> Thanks!
>> >>
>> >> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>> >> links for Commits and Issues. Just noticed that Announce is missing
>> >> from the list ;-)
>> >>
>> >> The Surefire report is not relevant - and is confusing - but I could
>> >> not work out how to get rid of it.
>> >
>> > I've changed the pom's parent from commons-parent to apache - this
>> > means we don't inherit the reports specified (such as surefure) and
>> > also the site.xml. Not inheriting site.xml from commons-parent gives
>> > us more control over the main sites navigation.
>>
>>
>> We could move all the reposting stuff in commons parent to a "reporting"
>> profile. This is a common way to achieve two things:
>>
>> - Make the build faster if you don't want the reports
>> - Prevent some children (like commons-site) from inheriting stuff unless
>> you explicitly activate the profile
>>
>> The only drawback is that you need to supply the -Preporting parameter
>> when you deploy the site, but this can easily be documented in our
>> release instructions.
>
> Is it possible to add a section to the commons-site pom that generates
> a warning message if the -Preporting param is not used?
Sorry, what I wrote wasn't clear.
The -Preporting parameter is only needed when the site of a *component*
is deployed - not when *commons-site* is deployed.
>
>> I can help with this if you think it's a good idea.
>>
>>
>> >
>> > Niall
>> >
>> >>> http://people.apache.org/~niallp/commons/
>> >>>
>> >>> http://svn.apache.org/viewvc?view=revision&revision=922120
>> >>>
>> >>>
>> >>> >> Niall
>> >>> >>
>> >>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> >>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> >>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> >>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>> >>
>> >> Still shows external links for me.
>> >>
>> >>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>> >>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>>
>> --
>>
>> Dennis Lundberg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by sebb <se...@gmail.com>.
On 13/03/2010, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-12 11:34, Niall Pemberton wrote:
> > On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
> >> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
> >>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
> >>> >> replacement for the m1 site[3] that we currently have - you can see it
> >>> >> here:
> >>> >> http://people.apache.org/~niallp/commons/
> >>> >>
> >>> >> IMO its a PITA to have to switch to m1 to build the commons site and
> >>> >> its time to move to m2.
> >>> >
> >>> > +1, thanks for doing this.
> >>> >
> >>> >> * The new releases page[4] points to the download pages on the
> >>> >> components' sites (removing the need for the current XSLT ant task to
> >>> >> generate the downloads)
> >>> >> * I've put PMC members in the pom - so we have a page showing them[5]
> >>> >>
> >>> >> Feel free to jump in and correct/improve anything.
> >>> >>
> >>> >> Opinions/feedback on switching from the old m1 site to this m2 site
> >>> >> would be welcome. If anyone objects please shout or I'll assume people
> >>> >> are OK with this.
> >>> >
> >>> > There seem to be rather too many links marked as "external". I don't
> >>> > know if this is a side effect of creating a demo build or whether this
> >>> > would be seen in a live deployment - if so, then this needs to be
> >>> > fixed.
> >>>
> >>>
> >>> OK fixed alot of them - some of these links are now broken on my
> >>> *demo* site - but would be fine once deployed to the normal location:
> >>>
> >>
> >> Thanks!
> >>
> >> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
> >> links for Commits and Issues. Just noticed that Announce is missing
> >> from the list ;-)
> >>
> >> The Surefire report is not relevant - and is confusing - but I could
> >> not work out how to get rid of it.
> >
> > I've changed the pom's parent from commons-parent to apache - this
> > means we don't inherit the reports specified (such as surefure) and
> > also the site.xml. Not inheriting site.xml from commons-parent gives
> > us more control over the main sites navigation.
>
>
> We could move all the reposting stuff in commons parent to a "reporting"
> profile. This is a common way to achieve two things:
>
> - Make the build faster if you don't want the reports
> - Prevent some children (like commons-site) from inheriting stuff unless
> you explicitly activate the profile
>
> The only drawback is that you need to supply the -Preporting parameter
> when you deploy the site, but this can easily be documented in our
> release instructions.
Is it possible to add a section to the commons-site pom that generates
a warning message if the -Preporting param is not used?
> I can help with this if you think it's a good idea.
>
>
> >
> > Niall
> >
> >>> http://people.apache.org/~niallp/commons/
> >>>
> >>> http://svn.apache.org/viewvc?view=revision&revision=922120
> >>>
> >>>
> >>> >> Niall
> >>> >>
> >>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
> >>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
> >>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
> >>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
> >>
> >> Still shows external links for me.
> >>
> >>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
> >>> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
> --
>
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 9:35 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-13 20:50, Niall Pemberton wrote:
>> On Sat, Mar 13, 2010 at 6:59 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2010-03-13 18:35, Niall Pemberton wrote:
>>>> On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> On 2010-03-13 17:58, Niall Pemberton wrote:
>>>>>> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>>>>>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>>>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>>>>>>>> >> here:
>>>>>>>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>>>>>>>> >> its time to move to m2.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > +1, thanks for doing this.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>>>>>>>> >> generate the downloads)
>>>>>>>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>>>>>>>> >> are OK with this.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>>>>>>>> > fixed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>>>>>>>> from the list ;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>>>>>>>> not work out how to get rid of it.
>>>>>>>>>>>>
>>>>>>>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>>>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>>>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>>>>>>>> us more control over the main sites navigation.
>>>>>>>>>>>
>>>>>>>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>>>>>>>> profile. This is a common way to achieve two things:
>>>>>>>>>>>
>>>>>>>>>>> - Make the build faster if you don't want the reports
>>>>>>>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>>>>>>>> you explicitly activate the profile
>>>>>>>>>>>
>>>>>>>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>>>>>>>> when you deploy the site, but this can easily be documented in our
>>>>>>>>>>> release instructions.
>>>>>>>>>>>
>>>>>>>>>>> I can help with this if you think it's a good idea.
>>>>>>>>>>
>>>>>>>>>> I think the small amount of duplication (mailing list information) is
>>>>>>>>>> probably better. It also didn't work out that well inheriting the
>>>>>>>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>>>>>>>> components/sandbox/dormant. We don't want to put that in the
>>>>>>>>>> commons-parent site.xml as it would mean we needed to release
>>>>>>>>>> commons-parent every time we wanted to do a menu change for a new
>>>>>>>>>> module - or moved module. Also there is less control over the main
>>>>>>>>>> site menu - because it needs to be geared towards being inherited by
>>>>>>>>>> components - this way we are freed up to have a slightly different
>>>>>>>>>> menu - no constrained by what modules require.
>>>>>>>>>
>>>>>>>>> I understand. We could create another POM project to handle this. Move
>>>>>>>>> the stuff that is only interesting for components to a
>>>>>>>>> commons-component-parent and let all our components inherit from that
>>>>>>>>> POM. What is left in commons-parent should work well for commons-site
>>>>>>>>> and other non-components that might occur.
>>>>>>>>>
>>>>>>>>> commons-parent (minus reporting and component-specific navigation)
>>>>>>>>> |
>>>>>>>>> +-- commons-site
>>>>>>>>> |
>>>>>>>>> +-- commons-component (reporting and component-specific navigation)
>>>>>>>>> |
>>>>>>>>> +-- commons-bar
>>>>>>>>> |
>>>>>>>>> +-- commons-foo
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>
>>>>>>>> The disadvantage of this is that we now would have two parent poms
>>>>>>>> that we need to release but besides that I don't see how this is any
>>>>>>>> better than just having commons-site inherit directly from Apache
>>>>>>>> parent.
>>>>>>>
>>>>>>> With reporting and component-specific navigation removed from
>>>>>>> commons-parent, I see that POM having fewer releases going forward.
>>>>>>
>>>>>> It would still mean an additional pom to release though.
>>>>>
>>>>> Yes it would.
>>>>>
>>>>>>> The benefit of this setup is that you get a clear separation between
>>>>>>> what is needed for Commons components and other Commons projects.
>>>>>>
>>>>>> What other commons projects - besides the main site?
>>>>>
>>>>> commons-build
>>>>
>>>> This is an m1 project, so doesn't apply.
>>>>
>>>>> commons-build-plugin
>>>>
>>>> This is like a component so will always inherit from the same pom as components.
>>>>
>>>>> commons-skin
>>>>
>>>> Skin is just a set of resources - I can't see how this would benefit
>>>> at all from inheriting from some *reporting* pom?
>>>
>>> Right, that's why commons-skin would inherit from the POM that has no
>>> reporting in it, namely the new commons-parent.
>>
>> OK but how does that benefit commons-skin?
>
> If we at some point would decide to give commons-skin its own site, then
> that site wouldn't have a pointless Surefire report and the navigation
> wouldn't have the usual component links in it.
I can't why we would ever want to do that and at the moment then,
theres zero benefit.
Niall
>> Niall
>>
>>>>
>>>> Niall
>>>>
>>>>>>>> In fact since we never release commons-site - then not having
>>>>>>>> to depend on anything else we release seems like a big advantage to
>>>>>>>> me.
>>>>>>>
>>>>>>> Since commons-site is constantly evolving and deployed you don't
>>>>>>> necessarily need for it to have a non-SNAPSHOT parent when you deploy
>>>>>>> it. So the number of ancestors in the POM hierarchy should not matter.
>>>>>>
>>>>>> True, but for commons-site it is very simple.
>>>>>>
>>>>>>>> Also as I said before the duplication is very minimal and what is
>>>>>>>> there now in commons-site is very straight forward. So I don't see any
>>>>>>>> advantage in over-complicating this and the rest of our parent pom
>>>>>>>> structure.
>>>>>>>
>>>>>>> I don't see this as complicating things, on the contrary, it is meant to
>>>>>>> make things less complicated and more clear. Compare this to how you
>>>>>>> would use inheritance in Java.
>>>>>>
>>>>>> Its an extra pom just to remove the duplication of mailing list info.
>>>>>> One less layer in our pom hierarchy for components is a good thing
>>>>>> IMO. Having two commons pom ancestors for components is going in the
>>>>>> wrong direction IMO and for virtually no benefit.
>>>>>>
>>>>>> Niall
>>>>>>
>>>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Niall
>>>>>>>>>>
>>>>>>>>>>>> Niall
>>>>>>>>>>>>
>>>>>>>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> >> Niall
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> Still shows external links for me.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>>>>>>>> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 20:50, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 6:59 PM, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-13 18:35, Niall Pemberton wrote:
>>> On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>> On 2010-03-13 17:58, Niall Pemberton wrote:
>>>>> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>>>>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>>>>>>> >> here:
>>>>>>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>>>>>>> >> its time to move to m2.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > +1, thanks for doing this.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>>>>>>> >> generate the downloads)
>>>>>>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>>>>>>> >> are OK with this.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>>>>>>> > fixed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>>>>>>> from the list ;-)
>>>>>>>>>>>>
>>>>>>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>>>>>>> not work out how to get rid of it.
>>>>>>>>>>>
>>>>>>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>>>>>>> us more control over the main sites navigation.
>>>>>>>>>>
>>>>>>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>>>>>>> profile. This is a common way to achieve two things:
>>>>>>>>>>
>>>>>>>>>> - Make the build faster if you don't want the reports
>>>>>>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>>>>>>> you explicitly activate the profile
>>>>>>>>>>
>>>>>>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>>>>>>> when you deploy the site, but this can easily be documented in our
>>>>>>>>>> release instructions.
>>>>>>>>>>
>>>>>>>>>> I can help with this if you think it's a good idea.
>>>>>>>>>
>>>>>>>>> I think the small amount of duplication (mailing list information) is
>>>>>>>>> probably better. It also didn't work out that well inheriting the
>>>>>>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>>>>>>> components/sandbox/dormant. We don't want to put that in the
>>>>>>>>> commons-parent site.xml as it would mean we needed to release
>>>>>>>>> commons-parent every time we wanted to do a menu change for a new
>>>>>>>>> module - or moved module. Also there is less control over the main
>>>>>>>>> site menu - because it needs to be geared towards being inherited by
>>>>>>>>> components - this way we are freed up to have a slightly different
>>>>>>>>> menu - no constrained by what modules require.
>>>>>>>>
>>>>>>>> I understand. We could create another POM project to handle this. Move
>>>>>>>> the stuff that is only interesting for components to a
>>>>>>>> commons-component-parent and let all our components inherit from that
>>>>>>>> POM. What is left in commons-parent should work well for commons-site
>>>>>>>> and other non-components that might occur.
>>>>>>>>
>>>>>>>> commons-parent (minus reporting and component-specific navigation)
>>>>>>>> |
>>>>>>>> +-- commons-site
>>>>>>>> |
>>>>>>>> +-- commons-component (reporting and component-specific navigation)
>>>>>>>> |
>>>>>>>> +-- commons-bar
>>>>>>>> |
>>>>>>>> +-- commons-foo
>>>>>>>> ...
>>>>>>>>
>>>>>>>
>>>>>>> The disadvantage of this is that we now would have two parent poms
>>>>>>> that we need to release but besides that I don't see how this is any
>>>>>>> better than just having commons-site inherit directly from Apache
>>>>>>> parent.
>>>>>>
>>>>>> With reporting and component-specific navigation removed from
>>>>>> commons-parent, I see that POM having fewer releases going forward.
>>>>>
>>>>> It would still mean an additional pom to release though.
>>>>
>>>> Yes it would.
>>>>
>>>>>> The benefit of this setup is that you get a clear separation between
>>>>>> what is needed for Commons components and other Commons projects.
>>>>>
>>>>> What other commons projects - besides the main site?
>>>>
>>>> commons-build
>>>
>>> This is an m1 project, so doesn't apply.
>>>
>>>> commons-build-plugin
>>>
>>> This is like a component so will always inherit from the same pom as components.
>>>
>>>> commons-skin
>>>
>>> Skin is just a set of resources - I can't see how this would benefit
>>> at all from inheriting from some *reporting* pom?
>>
>> Right, that's why commons-skin would inherit from the POM that has no
>> reporting in it, namely the new commons-parent.
>
> OK but how does that benefit commons-skin?
If we at some point would decide to give commons-skin its own site, then
that site wouldn't have a pointless Surefire report and the navigation
wouldn't have the usual component links in it.
>
> Niall
>
>>>
>>> Niall
>>>
>>>>>>> In fact since we never release commons-site - then not having
>>>>>>> to depend on anything else we release seems like a big advantage to
>>>>>>> me.
>>>>>>
>>>>>> Since commons-site is constantly evolving and deployed you don't
>>>>>> necessarily need for it to have a non-SNAPSHOT parent when you deploy
>>>>>> it. So the number of ancestors in the POM hierarchy should not matter.
>>>>>
>>>>> True, but for commons-site it is very simple.
>>>>>
>>>>>>> Also as I said before the duplication is very minimal and what is
>>>>>>> there now in commons-site is very straight forward. So I don't see any
>>>>>>> advantage in over-complicating this and the rest of our parent pom
>>>>>>> structure.
>>>>>>
>>>>>> I don't see this as complicating things, on the contrary, it is meant to
>>>>>> make things less complicated and more clear. Compare this to how you
>>>>>> would use inheritance in Java.
>>>>>
>>>>> Its an extra pom just to remove the duplication of mailing list info.
>>>>> One less layer in our pom hierarchy for components is a good thing
>>>>> IMO. Having two commons pom ancestors for components is going in the
>>>>> wrong direction IMO and for virtually no benefit.
>>>>>
>>>>> Niall
>>>>>
>>>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>>>>>
>>>>>>>>> Niall
>>>>>>>>>
>>>>>>>>>>> Niall
>>>>>>>>>>>
>>>>>>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> >> Niall
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>>>>>>
>>>>>>>>>>>> Still shows external links for me.
>>>>>>>>>>>>
>>>>>>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>>>>>>> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 6:59 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-13 18:35, Niall Pemberton wrote:
>> On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2010-03-13 17:58, Niall Pemberton wrote:
>>>> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>>>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>>>>>> >> here:
>>>>>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>>>>>> >> its time to move to m2.
>>>>>>>>>>>> >
>>>>>>>>>>>> > +1, thanks for doing this.
>>>>>>>>>>>> >
>>>>>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>>>>>> >> generate the downloads)
>>>>>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>>>>>> >> are OK with this.
>>>>>>>>>>>> >
>>>>>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>>>>>> > fixed.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>>>>>> from the list ;-)
>>>>>>>>>>>
>>>>>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>>>>>> not work out how to get rid of it.
>>>>>>>>>>
>>>>>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>>>>>> us more control over the main sites navigation.
>>>>>>>>>
>>>>>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>>>>>> profile. This is a common way to achieve two things:
>>>>>>>>>
>>>>>>>>> - Make the build faster if you don't want the reports
>>>>>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>>>>>> you explicitly activate the profile
>>>>>>>>>
>>>>>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>>>>>> when you deploy the site, but this can easily be documented in our
>>>>>>>>> release instructions.
>>>>>>>>>
>>>>>>>>> I can help with this if you think it's a good idea.
>>>>>>>>
>>>>>>>> I think the small amount of duplication (mailing list information) is
>>>>>>>> probably better. It also didn't work out that well inheriting the
>>>>>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>>>>>> components/sandbox/dormant. We don't want to put that in the
>>>>>>>> commons-parent site.xml as it would mean we needed to release
>>>>>>>> commons-parent every time we wanted to do a menu change for a new
>>>>>>>> module - or moved module. Also there is less control over the main
>>>>>>>> site menu - because it needs to be geared towards being inherited by
>>>>>>>> components - this way we are freed up to have a slightly different
>>>>>>>> menu - no constrained by what modules require.
>>>>>>>
>>>>>>> I understand. We could create another POM project to handle this. Move
>>>>>>> the stuff that is only interesting for components to a
>>>>>>> commons-component-parent and let all our components inherit from that
>>>>>>> POM. What is left in commons-parent should work well for commons-site
>>>>>>> and other non-components that might occur.
>>>>>>>
>>>>>>> commons-parent (minus reporting and component-specific navigation)
>>>>>>> |
>>>>>>> +-- commons-site
>>>>>>> |
>>>>>>> +-- commons-component (reporting and component-specific navigation)
>>>>>>> |
>>>>>>> +-- commons-bar
>>>>>>> |
>>>>>>> +-- commons-foo
>>>>>>> ...
>>>>>>>
>>>>>>
>>>>>> The disadvantage of this is that we now would have two parent poms
>>>>>> that we need to release but besides that I don't see how this is any
>>>>>> better than just having commons-site inherit directly from Apache
>>>>>> parent.
>>>>>
>>>>> With reporting and component-specific navigation removed from
>>>>> commons-parent, I see that POM having fewer releases going forward.
>>>>
>>>> It would still mean an additional pom to release though.
>>>
>>> Yes it would.
>>>
>>>>> The benefit of this setup is that you get a clear separation between
>>>>> what is needed for Commons components and other Commons projects.
>>>>
>>>> What other commons projects - besides the main site?
>>>
>>> commons-build
>>
>> This is an m1 project, so doesn't apply.
>>
>>> commons-build-plugin
>>
>> This is like a component so will always inherit from the same pom as components.
>>
>>> commons-skin
>>
>> Skin is just a set of resources - I can't see how this would benefit
>> at all from inheriting from some *reporting* pom?
>
> Right, that's why commons-skin would inherit from the POM that has no
> reporting in it, namely the new commons-parent.
OK but how does that benefit commons-skin?
Niall
>>
>> Niall
>>
>>>>>> In fact since we never release commons-site - then not having
>>>>>> to depend on anything else we release seems like a big advantage to
>>>>>> me.
>>>>>
>>>>> Since commons-site is constantly evolving and deployed you don't
>>>>> necessarily need for it to have a non-SNAPSHOT parent when you deploy
>>>>> it. So the number of ancestors in the POM hierarchy should not matter.
>>>>
>>>> True, but for commons-site it is very simple.
>>>>
>>>>>> Also as I said before the duplication is very minimal and what is
>>>>>> there now in commons-site is very straight forward. So I don't see any
>>>>>> advantage in over-complicating this and the rest of our parent pom
>>>>>> structure.
>>>>>
>>>>> I don't see this as complicating things, on the contrary, it is meant to
>>>>> make things less complicated and more clear. Compare this to how you
>>>>> would use inheritance in Java.
>>>>
>>>> Its an extra pom just to remove the duplication of mailing list info.
>>>> One less layer in our pom hierarchy for components is a good thing
>>>> IMO. Having two commons pom ancestors for components is going in the
>>>> wrong direction IMO and for virtually no benefit.
>>>>
>>>> Niall
>>>>
>>>>>>
>>>>>> Niall
>>>>>>
>>>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>>> Niall
>>>>>>>>>>
>>>>>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>>
>>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> >> Niall
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>>>>>
>>>>>>>>>>> Still shows external links for me.
>>>>>>>>>>>
>>>>>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>>>>>> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 18:35, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-13 17:58, Niall Pemberton wrote:
>>> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>>>>> >> here:
>>>>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>>>>> >>
>>>>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>>>>> >> its time to move to m2.
>>>>>>>>>>> >
>>>>>>>>>>> > +1, thanks for doing this.
>>>>>>>>>>> >
>>>>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>>>>> >> generate the downloads)
>>>>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>>>>> >>
>>>>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>>>>> >>
>>>>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>>>>> >> are OK with this.
>>>>>>>>>>> >
>>>>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>>>>> > fixed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>>>>> from the list ;-)
>>>>>>>>>>
>>>>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>>>>> not work out how to get rid of it.
>>>>>>>>>
>>>>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>>>>> us more control over the main sites navigation.
>>>>>>>>
>>>>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>>>>> profile. This is a common way to achieve two things:
>>>>>>>>
>>>>>>>> - Make the build faster if you don't want the reports
>>>>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>>>>> you explicitly activate the profile
>>>>>>>>
>>>>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>>>>> when you deploy the site, but this can easily be documented in our
>>>>>>>> release instructions.
>>>>>>>>
>>>>>>>> I can help with this if you think it's a good idea.
>>>>>>>
>>>>>>> I think the small amount of duplication (mailing list information) is
>>>>>>> probably better. It also didn't work out that well inheriting the
>>>>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>>>>> components/sandbox/dormant. We don't want to put that in the
>>>>>>> commons-parent site.xml as it would mean we needed to release
>>>>>>> commons-parent every time we wanted to do a menu change for a new
>>>>>>> module - or moved module. Also there is less control over the main
>>>>>>> site menu - because it needs to be geared towards being inherited by
>>>>>>> components - this way we are freed up to have a slightly different
>>>>>>> menu - no constrained by what modules require.
>>>>>>
>>>>>> I understand. We could create another POM project to handle this. Move
>>>>>> the stuff that is only interesting for components to a
>>>>>> commons-component-parent and let all our components inherit from that
>>>>>> POM. What is left in commons-parent should work well for commons-site
>>>>>> and other non-components that might occur.
>>>>>>
>>>>>> commons-parent (minus reporting and component-specific navigation)
>>>>>> |
>>>>>> +-- commons-site
>>>>>> |
>>>>>> +-- commons-component (reporting and component-specific navigation)
>>>>>> |
>>>>>> +-- commons-bar
>>>>>> |
>>>>>> +-- commons-foo
>>>>>> ...
>>>>>>
>>>>>
>>>>> The disadvantage of this is that we now would have two parent poms
>>>>> that we need to release but besides that I don't see how this is any
>>>>> better than just having commons-site inherit directly from Apache
>>>>> parent.
>>>>
>>>> With reporting and component-specific navigation removed from
>>>> commons-parent, I see that POM having fewer releases going forward.
>>>
>>> It would still mean an additional pom to release though.
>>
>> Yes it would.
>>
>>>> The benefit of this setup is that you get a clear separation between
>>>> what is needed for Commons components and other Commons projects.
>>>
>>> What other commons projects - besides the main site?
>>
>> commons-build
>
> This is an m1 project, so doesn't apply.
>
>> commons-build-plugin
>
> This is like a component so will always inherit from the same pom as components.
>
>> commons-skin
>
> Skin is just a set of resources - I can't see how this would benefit
> at all from inheriting from some *reporting* pom?
Right, that's why commons-skin would inherit from the POM that has no
reporting in it, namely the new commons-parent.
>
> Niall
>
>>>>> In fact since we never release commons-site - then not having
>>>>> to depend on anything else we release seems like a big advantage to
>>>>> me.
>>>>
>>>> Since commons-site is constantly evolving and deployed you don't
>>>> necessarily need for it to have a non-SNAPSHOT parent when you deploy
>>>> it. So the number of ancestors in the POM hierarchy should not matter.
>>>
>>> True, but for commons-site it is very simple.
>>>
>>>>> Also as I said before the duplication is very minimal and what is
>>>>> there now in commons-site is very straight forward. So I don't see any
>>>>> advantage in over-complicating this and the rest of our parent pom
>>>>> structure.
>>>>
>>>> I don't see this as complicating things, on the contrary, it is meant to
>>>> make things less complicated and more clear. Compare this to how you
>>>> would use inheritance in Java.
>>>
>>> Its an extra pom just to remove the duplication of mailing list info.
>>> One less layer in our pom hierarchy for components is a good thing
>>> IMO. Having two commons pom ancestors for components is going in the
>>> wrong direction IMO and for virtually no benefit.
>>>
>>> Niall
>>>
>>>>>
>>>>> Niall
>>>>>
>>>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>>>>> Niall
>>>>>>>>>
>>>>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>>>>
>>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> >> Niall
>>>>>>>>>>> >>
>>>>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>>>>
>>>>>>>>>> Still shows external links for me.
>>>>>>>>>>
>>>>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>>>>> >>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dennis Lundberg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-13 17:58, Niall Pemberton wrote:
>> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>>>> >> here:
>>>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>>>> >>
>>>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>>>> >> its time to move to m2.
>>>>>>>>>> >
>>>>>>>>>> > +1, thanks for doing this.
>>>>>>>>>> >
>>>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>>>> >> generate the downloads)
>>>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>>>> >>
>>>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>>>> >>
>>>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>>>> >> are OK with this.
>>>>>>>>>> >
>>>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>>>> > fixed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>>>> from the list ;-)
>>>>>>>>>
>>>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>>>> not work out how to get rid of it.
>>>>>>>>
>>>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>>>> us more control over the main sites navigation.
>>>>>>>
>>>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>>>> profile. This is a common way to achieve two things:
>>>>>>>
>>>>>>> - Make the build faster if you don't want the reports
>>>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>>>> you explicitly activate the profile
>>>>>>>
>>>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>>>> when you deploy the site, but this can easily be documented in our
>>>>>>> release instructions.
>>>>>>>
>>>>>>> I can help with this if you think it's a good idea.
>>>>>>
>>>>>> I think the small amount of duplication (mailing list information) is
>>>>>> probably better. It also didn't work out that well inheriting the
>>>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>>>> components/sandbox/dormant. We don't want to put that in the
>>>>>> commons-parent site.xml as it would mean we needed to release
>>>>>> commons-parent every time we wanted to do a menu change for a new
>>>>>> module - or moved module. Also there is less control over the main
>>>>>> site menu - because it needs to be geared towards being inherited by
>>>>>> components - this way we are freed up to have a slightly different
>>>>>> menu - no constrained by what modules require.
>>>>>
>>>>> I understand. We could create another POM project to handle this. Move
>>>>> the stuff that is only interesting for components to a
>>>>> commons-component-parent and let all our components inherit from that
>>>>> POM. What is left in commons-parent should work well for commons-site
>>>>> and other non-components that might occur.
>>>>>
>>>>> commons-parent (minus reporting and component-specific navigation)
>>>>> |
>>>>> +-- commons-site
>>>>> |
>>>>> +-- commons-component (reporting and component-specific navigation)
>>>>> |
>>>>> +-- commons-bar
>>>>> |
>>>>> +-- commons-foo
>>>>> ...
>>>>>
>>>>
>>>> The disadvantage of this is that we now would have two parent poms
>>>> that we need to release but besides that I don't see how this is any
>>>> better than just having commons-site inherit directly from Apache
>>>> parent.
>>>
>>> With reporting and component-specific navigation removed from
>>> commons-parent, I see that POM having fewer releases going forward.
>>
>> It would still mean an additional pom to release though.
>
> Yes it would.
>
>>> The benefit of this setup is that you get a clear separation between
>>> what is needed for Commons components and other Commons projects.
>>
>> What other commons projects - besides the main site?
>
> commons-build
This is an m1 project, so doesn't apply.
> commons-build-plugin
This is like a component so will always inherit from the same pom as components.
> commons-skin
Skin is just a set of resources - I can't see how this would benefit
at all from inheriting from some *reporting* pom?
Niall
>>>> In fact since we never release commons-site - then not having
>>>> to depend on anything else we release seems like a big advantage to
>>>> me.
>>>
>>> Since commons-site is constantly evolving and deployed you don't
>>> necessarily need for it to have a non-SNAPSHOT parent when you deploy
>>> it. So the number of ancestors in the POM hierarchy should not matter.
>>
>> True, but for commons-site it is very simple.
>>
>>>> Also as I said before the duplication is very minimal and what is
>>>> there now in commons-site is very straight forward. So I don't see any
>>>> advantage in over-complicating this and the rest of our parent pom
>>>> structure.
>>>
>>> I don't see this as complicating things, on the contrary, it is meant to
>>> make things less complicated and more clear. Compare this to how you
>>> would use inheritance in Java.
>>
>> Its an extra pom just to remove the duplication of mailing list info.
>> One less layer in our pom hierarchy for components is a good thing
>> IMO. Having two commons pom ancestors for components is going in the
>> wrong direction IMO and for virtually no benefit.
>>
>> Niall
>>
>>>>
>>>> Niall
>>>>
>>>>>>
>>>>>> Niall
>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>>>
>>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> >> Niall
>>>>>>>>>> >>
>>>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>>>
>>>>>>>>> Still shows external links for me.
>>>>>>>>>
>>>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>>>> >>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 5:07 PM, Paul Benedict <pb...@apache.org> wrote:
> I am late to the game. What about making commons-site a POM project,
It is already:
http://svn.apache.org/repos/asf/commons/proper/commons-site/
> and inherit it as a dependency during the site build?
Don't understand this at all. How does this relate to having an m2
build for the main commons site and whats been setup so far?
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Paul Benedict <pb...@apache.org>.
I am late to the game. What about making commons-site a POM project,
and inherit it as a dependency during the site build?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 17:58, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>>> >> here:
>>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>>> >>
>>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>>> >> its time to move to m2.
>>>>>>>>> >
>>>>>>>>> > +1, thanks for doing this.
>>>>>>>>> >
>>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>>> >> generate the downloads)
>>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>>> >>
>>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>>> >>
>>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>>> >> are OK with this.
>>>>>>>>> >
>>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>>> > fixed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>>> from the list ;-)
>>>>>>>>
>>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>>> not work out how to get rid of it.
>>>>>>>
>>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>>> us more control over the main sites navigation.
>>>>>>
>>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>>> profile. This is a common way to achieve two things:
>>>>>>
>>>>>> - Make the build faster if you don't want the reports
>>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>>> you explicitly activate the profile
>>>>>>
>>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>>> when you deploy the site, but this can easily be documented in our
>>>>>> release instructions.
>>>>>>
>>>>>> I can help with this if you think it's a good idea.
>>>>>
>>>>> I think the small amount of duplication (mailing list information) is
>>>>> probably better. It also didn't work out that well inheriting the
>>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>>> components/sandbox/dormant. We don't want to put that in the
>>>>> commons-parent site.xml as it would mean we needed to release
>>>>> commons-parent every time we wanted to do a menu change for a new
>>>>> module - or moved module. Also there is less control over the main
>>>>> site menu - because it needs to be geared towards being inherited by
>>>>> components - this way we are freed up to have a slightly different
>>>>> menu - no constrained by what modules require.
>>>>
>>>> I understand. We could create another POM project to handle this. Move
>>>> the stuff that is only interesting for components to a
>>>> commons-component-parent and let all our components inherit from that
>>>> POM. What is left in commons-parent should work well for commons-site
>>>> and other non-components that might occur.
>>>>
>>>> commons-parent (minus reporting and component-specific navigation)
>>>> |
>>>> +-- commons-site
>>>> |
>>>> +-- commons-component (reporting and component-specific navigation)
>>>> |
>>>> +-- commons-bar
>>>> |
>>>> +-- commons-foo
>>>> ...
>>>>
>>>
>>> The disadvantage of this is that we now would have two parent poms
>>> that we need to release but besides that I don't see how this is any
>>> better than just having commons-site inherit directly from Apache
>>> parent.
>>
>> With reporting and component-specific navigation removed from
>> commons-parent, I see that POM having fewer releases going forward.
>
> It would still mean an additional pom to release though.
Yes it would.
>> The benefit of this setup is that you get a clear separation between
>> what is needed for Commons components and other Commons projects.
>
> What other commons projects - besides the main site?
commons-build
commons-build-plugin
commons-skin
>
>>> In fact since we never release commons-site - then not having
>>> to depend on anything else we release seems like a big advantage to
>>> me.
>>
>> Since commons-site is constantly evolving and deployed you don't
>> necessarily need for it to have a non-SNAPSHOT parent when you deploy
>> it. So the number of ancestors in the POM hierarchy should not matter.
>
> True, but for commons-site it is very simple.
>
>>> Also as I said before the duplication is very minimal and what is
>>> there now in commons-site is very straight forward. So I don't see any
>>> advantage in over-complicating this and the rest of our parent pom
>>> structure.
>>
>> I don't see this as complicating things, on the contrary, it is meant to
>> make things less complicated and more clear. Compare this to how you
>> would use inheritance in Java.
>
> Its an extra pom just to remove the duplication of mailing list info.
> One less layer in our pom hierarchy for components is a good thing
> IMO. Having two commons pom ancestors for components is going in the
> wrong direction IMO and for virtually no benefit.
>
> Niall
>
>>>
>>> Niall
>>>
>>>>>
>>>>> Niall
>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>>
>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> >> Niall
>>>>>>>>> >>
>>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>>
>>>>>>>> Still shows external links for me.
>>>>>>>>
>>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>>> >>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-13 17:33, Niall Pemberton wrote:
>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>>> >> here:
>>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>>> >>
>>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>>> >> its time to move to m2.
>>>>>>>> >
>>>>>>>> > +1, thanks for doing this.
>>>>>>>> >
>>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>>> >> generate the downloads)
>>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>>> >>
>>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>>> >>
>>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>>> >> are OK with this.
>>>>>>>> >
>>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>>> > fixed.
>>>>>>>>
>>>>>>>>
>>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>>> from the list ;-)
>>>>>>>
>>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>>> not work out how to get rid of it.
>>>>>>
>>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>>> us more control over the main sites navigation.
>>>>>
>>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>>> profile. This is a common way to achieve two things:
>>>>>
>>>>> - Make the build faster if you don't want the reports
>>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>>> you explicitly activate the profile
>>>>>
>>>>> The only drawback is that you need to supply the -Preporting parameter
>>>>> when you deploy the site, but this can easily be documented in our
>>>>> release instructions.
>>>>>
>>>>> I can help with this if you think it's a good idea.
>>>>
>>>> I think the small amount of duplication (mailing list information) is
>>>> probably better. It also didn't work out that well inheriting the
>>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>>> components/sandbox/dormant. We don't want to put that in the
>>>> commons-parent site.xml as it would mean we needed to release
>>>> commons-parent every time we wanted to do a menu change for a new
>>>> module - or moved module. Also there is less control over the main
>>>> site menu - because it needs to be geared towards being inherited by
>>>> components - this way we are freed up to have a slightly different
>>>> menu - no constrained by what modules require.
>>>
>>> I understand. We could create another POM project to handle this. Move
>>> the stuff that is only interesting for components to a
>>> commons-component-parent and let all our components inherit from that
>>> POM. What is left in commons-parent should work well for commons-site
>>> and other non-components that might occur.
>>>
>>> commons-parent (minus reporting and component-specific navigation)
>>> |
>>> +-- commons-site
>>> |
>>> +-- commons-component (reporting and component-specific navigation)
>>> |
>>> +-- commons-bar
>>> |
>>> +-- commons-foo
>>> ...
>>>
>>
>> The disadvantage of this is that we now would have two parent poms
>> that we need to release but besides that I don't see how this is any
>> better than just having commons-site inherit directly from Apache
>> parent.
>
> With reporting and component-specific navigation removed from
> commons-parent, I see that POM having fewer releases going forward.
It would still mean an additional pom to release though.
> The benefit of this setup is that you get a clear separation between
> what is needed for Commons components and other Commons projects.
What other commons projects - besides the main site?
>> In fact since we never release commons-site - then not having
>> to depend on anything else we release seems like a big advantage to
>> me.
>
> Since commons-site is constantly evolving and deployed you don't
> necessarily need for it to have a non-SNAPSHOT parent when you deploy
> it. So the number of ancestors in the POM hierarchy should not matter.
True, but for commons-site it is very simple.
>> Also as I said before the duplication is very minimal and what is
>> there now in commons-site is very straight forward. So I don't see any
>> advantage in over-complicating this and the rest of our parent pom
>> structure.
>
> I don't see this as complicating things, on the contrary, it is meant to
> make things less complicated and more clear. Compare this to how you
> would use inheritance in Java.
Its an extra pom just to remove the duplication of mailing list info.
One less layer in our pom hierarchy for components is a good thing
IMO. Having two commons pom ancestors for components is going in the
wrong direction IMO and for virtually no benefit.
Niall
>>
>> Niall
>>
>>>>
>>>> Niall
>>>>
>>>>>> Niall
>>>>>>
>>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>>
>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>>
>>>>>>>>
>>>>>>>> >> Niall
>>>>>>>> >>
>>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>>
>>>>>>> Still shows external links for me.
>>>>>>>
>>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>>> >>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 17:33, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>>> >> here:
>>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>>> >>
>>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>>> >> its time to move to m2.
>>>>>>> >
>>>>>>> > +1, thanks for doing this.
>>>>>>> >
>>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>>> >> generate the downloads)
>>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>>> >>
>>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>>> >>
>>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>>> >> are OK with this.
>>>>>>> >
>>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>>> > fixed.
>>>>>>>
>>>>>>>
>>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>>> from the list ;-)
>>>>>>
>>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>>> not work out how to get rid of it.
>>>>>
>>>>> I've changed the pom's parent from commons-parent to apache - this
>>>>> means we don't inherit the reports specified (such as surefure) and
>>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>>> us more control over the main sites navigation.
>>>>
>>>> We could move all the reposting stuff in commons parent to a "reporting"
>>>> profile. This is a common way to achieve two things:
>>>>
>>>> - Make the build faster if you don't want the reports
>>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>>> you explicitly activate the profile
>>>>
>>>> The only drawback is that you need to supply the -Preporting parameter
>>>> when you deploy the site, but this can easily be documented in our
>>>> release instructions.
>>>>
>>>> I can help with this if you think it's a good idea.
>>>
>>> I think the small amount of duplication (mailing list information) is
>>> probably better. It also didn't work out that well inheriting the
>>> site.xml from commons-proper. The old m1 site had expanding menus for
>>> components/sandbox/dormant. We don't want to put that in the
>>> commons-parent site.xml as it would mean we needed to release
>>> commons-parent every time we wanted to do a menu change for a new
>>> module - or moved module. Also there is less control over the main
>>> site menu - because it needs to be geared towards being inherited by
>>> components - this way we are freed up to have a slightly different
>>> menu - no constrained by what modules require.
>>
>> I understand. We could create another POM project to handle this. Move
>> the stuff that is only interesting for components to a
>> commons-component-parent and let all our components inherit from that
>> POM. What is left in commons-parent should work well for commons-site
>> and other non-components that might occur.
>>
>> commons-parent (minus reporting and component-specific navigation)
>> |
>> +-- commons-site
>> |
>> +-- commons-component (reporting and component-specific navigation)
>> |
>> +-- commons-bar
>> |
>> +-- commons-foo
>> ...
>>
>
> The disadvantage of this is that we now would have two parent poms
> that we need to release but besides that I don't see how this is any
> better than just having commons-site inherit directly from Apache
> parent.
With reporting and component-specific navigation removed from
commons-parent, I see that POM having fewer releases going forward.
The benefit of this setup is that you get a clear separation between
what is needed for Commons components and other Commons projects.
> In fact since we never release commons-site - then not having
> to depend on anything else we release seems like a big advantage to
> me.
Since commons-site is constantly evolving and deployed you don't
necessarily need for it to have a non-SNAPSHOT parent when you deploy
it. So the number of ancestors in the POM hierarchy should not matter.
> Also as I said before the duplication is very minimal and what is
> there now in commons-site is very straight forward. So I don't see any
> advantage in over-complicating this and the rest of our parent pom
> structure.
I don't see this as complicating things, on the contrary, it is meant to
make things less complicated and more clear. Compare this to how you
would use inheritance in Java.
>
> Niall
>
>>>
>>> Niall
>>>
>>>>> Niall
>>>>>
>>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>>
>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>>
>>>>>>>
>>>>>>> >> Niall
>>>>>>> >>
>>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>>
>>>>>> Still shows external links for me.
>>>>>>
>>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-13 16:54, Niall Pemberton wrote:
>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>>> >> here:
>>>>>> >> http://people.apache.org/~niallp/commons/
>>>>>> >>
>>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>>> >> its time to move to m2.
>>>>>> >
>>>>>> > +1, thanks for doing this.
>>>>>> >
>>>>>> >> * The new releases page[4] points to the download pages on the
>>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>>> >> generate the downloads)
>>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>>> >>
>>>>>> >> Feel free to jump in and correct/improve anything.
>>>>>> >>
>>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>>> >> are OK with this.
>>>>>> >
>>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>>> > fixed.
>>>>>>
>>>>>>
>>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>>> from the list ;-)
>>>>>
>>>>> The Surefire report is not relevant - and is confusing - but I could
>>>>> not work out how to get rid of it.
>>>>
>>>> I've changed the pom's parent from commons-parent to apache - this
>>>> means we don't inherit the reports specified (such as surefure) and
>>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>>> us more control over the main sites navigation.
>>>
>>> We could move all the reposting stuff in commons parent to a "reporting"
>>> profile. This is a common way to achieve two things:
>>>
>>> - Make the build faster if you don't want the reports
>>> - Prevent some children (like commons-site) from inheriting stuff unless
>>> you explicitly activate the profile
>>>
>>> The only drawback is that you need to supply the -Preporting parameter
>>> when you deploy the site, but this can easily be documented in our
>>> release instructions.
>>>
>>> I can help with this if you think it's a good idea.
>>
>> I think the small amount of duplication (mailing list information) is
>> probably better. It also didn't work out that well inheriting the
>> site.xml from commons-proper. The old m1 site had expanding menus for
>> components/sandbox/dormant. We don't want to put that in the
>> commons-parent site.xml as it would mean we needed to release
>> commons-parent every time we wanted to do a menu change for a new
>> module - or moved module. Also there is less control over the main
>> site menu - because it needs to be geared towards being inherited by
>> components - this way we are freed up to have a slightly different
>> menu - no constrained by what modules require.
>
> I understand. We could create another POM project to handle this. Move
> the stuff that is only interesting for components to a
> commons-component-parent and let all our components inherit from that
> POM. What is left in commons-parent should work well for commons-site
> and other non-components that might occur.
>
> commons-parent (minus reporting and component-specific navigation)
> |
> +-- commons-site
> |
> +-- commons-component (reporting and component-specific navigation)
> |
> +-- commons-bar
> |
> +-- commons-foo
> ...
>
The disadvantage of this is that we now would have two parent poms
that we need to release but besides that I don't see how this is any
better than just having commons-site inherit directly from Apache
parent. In fact since we never release commons-site - then not having
to depend on anything else we release seems like a big advantage to
me. Also as I said before the duplication is very minimal and what is
there now in commons-site is very straight forward. So I don't see any
advantage in over-complicating this and the rest of our parent pom
structure.
Niall
>>
>> Niall
>>
>>>> Niall
>>>>
>>>>>> http://people.apache.org/~niallp/commons/
>>>>>>
>>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>>
>>>>>>
>>>>>> >> Niall
>>>>>> >>
>>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>>
>>>>> Still shows external links for me.
>>>>>
>>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-13 16:54, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>>> >> here:
>>>>> >> http://people.apache.org/~niallp/commons/
>>>>> >>
>>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>>> >> its time to move to m2.
>>>>> >
>>>>> > +1, thanks for doing this.
>>>>> >
>>>>> >> * The new releases page[4] points to the download pages on the
>>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>>> >> generate the downloads)
>>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>>> >>
>>>>> >> Feel free to jump in and correct/improve anything.
>>>>> >>
>>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>>> >> are OK with this.
>>>>> >
>>>>> > There seem to be rather too many links marked as "external". I don't
>>>>> > know if this is a side effect of creating a demo build or whether this
>>>>> > would be seen in a live deployment - if so, then this needs to be
>>>>> > fixed.
>>>>>
>>>>>
>>>>> OK fixed alot of them - some of these links are now broken on my
>>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>>
>>>>
>>>> Thanks!
>>>>
>>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>>> links for Commits and Issues. Just noticed that Announce is missing
>>>> from the list ;-)
>>>>
>>>> The Surefire report is not relevant - and is confusing - but I could
>>>> not work out how to get rid of it.
>>>
>>> I've changed the pom's parent from commons-parent to apache - this
>>> means we don't inherit the reports specified (such as surefure) and
>>> also the site.xml. Not inheriting site.xml from commons-parent gives
>>> us more control over the main sites navigation.
>>
>> We could move all the reposting stuff in commons parent to a "reporting"
>> profile. This is a common way to achieve two things:
>>
>> - Make the build faster if you don't want the reports
>> - Prevent some children (like commons-site) from inheriting stuff unless
>> you explicitly activate the profile
>>
>> The only drawback is that you need to supply the -Preporting parameter
>> when you deploy the site, but this can easily be documented in our
>> release instructions.
>>
>> I can help with this if you think it's a good idea.
>
> I think the small amount of duplication (mailing list information) is
> probably better. It also didn't work out that well inheriting the
> site.xml from commons-proper. The old m1 site had expanding menus for
> components/sandbox/dormant. We don't want to put that in the
> commons-parent site.xml as it would mean we needed to release
> commons-parent every time we wanted to do a menu change for a new
> module - or moved module. Also there is less control over the main
> site menu - because it needs to be geared towards being inherited by
> components - this way we are freed up to have a slightly different
> menu - no constrained by what modules require.
I understand. We could create another POM project to handle this. Move
the stuff that is only interesting for components to a
commons-component-parent and let all our components inherit from that
POM. What is left in commons-parent should work well for commons-site
and other non-components that might occur.
commons-parent (minus reporting and component-specific navigation)
|
+-- commons-site
|
+-- commons-component (reporting and component-specific navigation)
|
+-- commons-bar
|
+-- commons-foo
...
>
> Niall
>
>>> Niall
>>>
>>>>> http://people.apache.org/~niallp/commons/
>>>>>
>>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>>
>>>>>
>>>>> >> Niall
>>>>> >>
>>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>>
>>>> Still shows external links for me.
>>>>
>>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>>> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <de...@apache.org> wrote:
> On 2010-03-12 11:34, Niall Pemberton wrote:
>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>>> >> here:
>>>> >> http://people.apache.org/~niallp/commons/
>>>> >>
>>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>>> >> its time to move to m2.
>>>> >
>>>> > +1, thanks for doing this.
>>>> >
>>>> >> * The new releases page[4] points to the download pages on the
>>>> >> components' sites (removing the need for the current XSLT ant task to
>>>> >> generate the downloads)
>>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>>> >>
>>>> >> Feel free to jump in and correct/improve anything.
>>>> >>
>>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>>> >> are OK with this.
>>>> >
>>>> > There seem to be rather too many links marked as "external". I don't
>>>> > know if this is a side effect of creating a demo build or whether this
>>>> > would be seen in a live deployment - if so, then this needs to be
>>>> > fixed.
>>>>
>>>>
>>>> OK fixed alot of them - some of these links are now broken on my
>>>> *demo* site - but would be fine once deployed to the normal location:
>>>>
>>>
>>> Thanks!
>>>
>>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>>> links for Commits and Issues. Just noticed that Announce is missing
>>> from the list ;-)
>>>
>>> The Surefire report is not relevant - and is confusing - but I could
>>> not work out how to get rid of it.
>>
>> I've changed the pom's parent from commons-parent to apache - this
>> means we don't inherit the reports specified (such as surefure) and
>> also the site.xml. Not inheriting site.xml from commons-parent gives
>> us more control over the main sites navigation.
>
> We could move all the reposting stuff in commons parent to a "reporting"
> profile. This is a common way to achieve two things:
>
> - Make the build faster if you don't want the reports
> - Prevent some children (like commons-site) from inheriting stuff unless
> you explicitly activate the profile
>
> The only drawback is that you need to supply the -Preporting parameter
> when you deploy the site, but this can easily be documented in our
> release instructions.
>
> I can help with this if you think it's a good idea.
I think the small amount of duplication (mailing list information) is
probably better. It also didn't work out that well inheriting the
site.xml from commons-proper. The old m1 site had expanding menus for
components/sandbox/dormant. We don't want to put that in the
commons-parent site.xml as it would mean we needed to release
commons-parent every time we wanted to do a menu change for a new
module - or moved module. Also there is less control over the main
site menu - because it needs to be geared towards being inherited by
components - this way we are freed up to have a slightly different
menu - no constrained by what modules require.
Niall
>> Niall
>>
>>>> http://people.apache.org/~niallp/commons/
>>>>
>>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>>
>>>>
>>>> >> Niall
>>>> >>
>>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>>
>>> Still shows external links for me.
>>>
>>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>>> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-03-12 11:34, Niall Pemberton wrote:
> On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
>> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>>> >> replacement for the m1 site[3] that we currently have - you can see it
>>> >> here:
>>> >> http://people.apache.org/~niallp/commons/
>>> >>
>>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>>> >> its time to move to m2.
>>> >
>>> > +1, thanks for doing this.
>>> >
>>> >> * The new releases page[4] points to the download pages on the
>>> >> components' sites (removing the need for the current XSLT ant task to
>>> >> generate the downloads)
>>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>>> >>
>>> >> Feel free to jump in and correct/improve anything.
>>> >>
>>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>>> >> would be welcome. If anyone objects please shout or I'll assume people
>>> >> are OK with this.
>>> >
>>> > There seem to be rather too many links marked as "external". I don't
>>> > know if this is a side effect of creating a demo build or whether this
>>> > would be seen in a live deployment - if so, then this needs to be
>>> > fixed.
>>>
>>>
>>> OK fixed alot of them - some of these links are now broken on my
>>> *demo* site - but would be fine once deployed to the normal location:
>>>
>>
>> Thanks!
>>
>> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
>> links for Commits and Issues. Just noticed that Announce is missing
>> from the list ;-)
>>
>> The Surefire report is not relevant - and is confusing - but I could
>> not work out how to get rid of it.
>
> I've changed the pom's parent from commons-parent to apache - this
> means we don't inherit the reports specified (such as surefure) and
> also the site.xml. Not inheriting site.xml from commons-parent gives
> us more control over the main sites navigation.
We could move all the reposting stuff in commons parent to a "reporting"
profile. This is a common way to achieve two things:
- Make the build faster if you don't want the reports
- Prevent some children (like commons-site) from inheriting stuff unless
you explicitly activate the profile
The only drawback is that you need to supply the -Preporting parameter
when you deploy the site, but this can easily be documented in our
release instructions.
I can help with this if you think it's a good idea.
>
> Niall
>
>>> http://people.apache.org/~niallp/commons/
>>>
>>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>>
>>>
>>> >> Niall
>>> >>
>>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>>
>> Still shows external links for me.
>>
>>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>>> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>> >> replacement for the m1 site[3] that we currently have - you can see it
>> >> here:
>> >> http://people.apache.org/~niallp/commons/
>> >>
>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>> >> its time to move to m2.
>> >
>> > +1, thanks for doing this.
>> >
>> >> * The new releases page[4] points to the download pages on the
>> >> components' sites (removing the need for the current XSLT ant task to
>> >> generate the downloads)
>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>> >>
>> >> Feel free to jump in and correct/improve anything.
>> >>
>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>> >> would be welcome. If anyone objects please shout or I'll assume people
>> >> are OK with this.
>> >
>> > There seem to be rather too many links marked as "external". I don't
>> > know if this is a side effect of creating a demo build or whether this
>> > would be seen in a live deployment - if so, then this needs to be
>> > fixed.
>>
>>
>> OK fixed alot of them - some of these links are now broken on my
>> *demo* site - but would be fine once deployed to the normal location:
>>
>
> Thanks!
>
> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
> links for Commits and Issues. Just noticed that Announce is missing
> from the list ;-)
>
> The Surefire report is not relevant - and is confusing - but I could
> not work out how to get rid of it.
I've changed the pom's parent from commons-parent to apache - this
means we don't inherit the reports specified (such as surefure) and
also the site.xml. Not inheriting site.xml from commons-parent gives
us more control over the main sites navigation.
Niall
>> http://people.apache.org/~niallp/commons/
>>
>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>
>>
>> >> Niall
>> >>
>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>
> Still shows external links for me.
>
>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 12, 2010 at 3:12 AM, sebb <se...@gmail.com> wrote:
> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
>> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> >> I have created a m2 site for Commons[1][2] as (hopefully) a
>> >> replacement for the m1 site[3] that we currently have - you can see it
>> >> here:
>> >> http://people.apache.org/~niallp/commons/
>> >>
>> >> IMO its a PITA to have to switch to m1 to build the commons site and
>> >> its time to move to m2.
>> >
>> > +1, thanks for doing this.
>> >
>> >> * The new releases page[4] points to the download pages on the
>> >> components' sites (removing the need for the current XSLT ant task to
>> >> generate the downloads)
>> >> * I've put PMC members in the pom - so we have a page showing them[5]
>> >>
>> >> Feel free to jump in and correct/improve anything.
>> >>
>> >> Opinions/feedback on switching from the old m1 site to this m2 site
>> >> would be welcome. If anyone objects please shout or I'll assume people
>> >> are OK with this.
>> >
>> > There seem to be rather too many links marked as "external". I don't
>> > know if this is a side effect of creating a demo build or whether this
>> > would be seen in a live deployment - if so, then this needs to be
>> > fixed.
>>
>>
>> OK fixed alot of them - some of these links are now broken on my
>> *demo* site - but would be fine once deployed to the normal location:
>>
>
> Thanks!
>
> BTW, I updated the parent pom.xml in trunk to get rid of the <post>
> links for Commits and Issues. Just noticed that Announce is missing
> from the list ;-)
>
> The Surefire report is not relevant - and is confusing - but I could
> not work out how to get rid of it.
Me neither - its picked up from the commons-parent pom
>> http://people.apache.org/~niallp/commons/
>>
>> http://svn.apache.org/viewvc?view=revision&revision=922120
>>
>>
>> >> Niall
>> >>
>> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>
> Still shows external links for me.
>
>> >> [5] http://people.apache.org/~niallp/commons/team-list.html
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by sebb <se...@gmail.com>.
On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
> > On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> >> I have created a m2 site for Commons[1][2] as (hopefully) a
> >> replacement for the m1 site[3] that we currently have - you can see it
> >> here:
> >> http://people.apache.org/~niallp/commons/
> >>
> >> IMO its a PITA to have to switch to m1 to build the commons site and
> >> its time to move to m2.
> >
> > +1, thanks for doing this.
> >
> >> * The new releases page[4] points to the download pages on the
> >> components' sites (removing the need for the current XSLT ant task to
> >> generate the downloads)
> >> * I've put PMC members in the pom - so we have a page showing them[5]
> >>
> >> Feel free to jump in and correct/improve anything.
> >>
> >> Opinions/feedback on switching from the old m1 site to this m2 site
> >> would be welcome. If anyone objects please shout or I'll assume people
> >> are OK with this.
> >
> > There seem to be rather too many links marked as "external". I don't
> > know if this is a side effect of creating a demo build or whether this
> > would be seen in a live deployment - if so, then this needs to be
> > fixed.
>
>
> OK fixed alot of them - some of these links are now broken on my
> *demo* site - but would be fine once deployed to the normal location:
>
Thanks!
BTW, I updated the parent pom.xml in trunk to get rid of the <post>
links for Commits and Issues. Just noticed that Announce is missing
from the list ;-)
The Surefire report is not relevant - and is confusing - but I could
not work out how to get rid of it.
> http://people.apache.org/~niallp/commons/
>
> http://svn.apache.org/viewvc?view=revision&revision=922120
>
>
> >> Niall
> >>
> >> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
> >> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
> >> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
> >> [4] http://people.apache.org/~niallp/commons/downloads/index.html
Still shows external links for me.
> >> [5] http://people.apache.org/~niallp/commons/team-list.html
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 12, 2010 at 2:07 AM, sebb <se...@gmail.com> wrote:
> On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> I have created a m2 site for Commons[1][2] as (hopefully) a
>> replacement for the m1 site[3] that we currently have - you can see it
>> here:
>> http://people.apache.org/~niallp/commons/
>>
>> IMO its a PITA to have to switch to m1 to build the commons site and
>> its time to move to m2.
>
> +1, thanks for doing this.
>
>> * The new releases page[4] points to the download pages on the
>> components' sites (removing the need for the current XSLT ant task to
>> generate the downloads)
>> * I've put PMC members in the pom - so we have a page showing them[5]
>>
>> Feel free to jump in and correct/improve anything.
>>
>> Opinions/feedback on switching from the old m1 site to this m2 site
>> would be welcome. If anyone objects please shout or I'll assume people
>> are OK with this.
>
> There seem to be rather too many links marked as "external". I don't
> know if this is a side effect of creating a demo build or whether this
> would be seen in a live deployment - if so, then this needs to be
> fixed.
OK fixed alot of them - some of these links are now broken on my
*demo* site - but would be fine once deployed to the normal location:
http://people.apache.org/~niallp/commons/
http://svn.apache.org/viewvc?view=revision&revision=922120
>> Niall
>>
>> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> [4] http://people.apache.org/~niallp/commons/downloads/index.html
>> [5] http://people.apache.org/~niallp/commons/team-list.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by sebb <se...@gmail.com>.
On 12/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> I have created a m2 site for Commons[1][2] as (hopefully) a
> replacement for the m1 site[3] that we currently have - you can see it
> here:
> http://people.apache.org/~niallp/commons/
>
> IMO its a PITA to have to switch to m1 to build the commons site and
> its time to move to m2.
+1, thanks for doing this.
> * The new releases page[4] points to the download pages on the
> components' sites (removing the need for the current XSLT ant task to
> generate the downloads)
> * I've put PMC members in the pom - so we have a page showing them[5]
>
> Feel free to jump in and correct/improve anything.
>
> Opinions/feedback on switching from the old m1 site to this m2 site
> would be welcome. If anyone objects please shout or I'll assume people
> are OK with this.
There seem to be rather too many links marked as "external". I don't
know if this is a side effect of creating a demo build or whether this
would be seen in a live deployment - if so, then this needs to be
fixed.
> Niall
>
> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
> [4] http://people.apache.org/~niallp/commons/downloads/index.html
> [5] http://people.apache.org/~niallp/commons/team-list.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 14, 2010 at 1:19 AM, sebb <se...@gmail.com> wrote:
> On 14/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> I believe the new m2 site is at least as good as the old one - so I've
>> deployed it to http://commons.apache.org/ - if there are any problems
>> or anyone objects, we can always revert back to the old m1 site.
>
> The ApacheCon logo ought to be removed, as it is rather out of date...
>
> I don't think there is a new one yet.
I asked on the ConCom list and they just sent through ApacheCon logos
for Atlanta 2010 - should appear after the next sync.
Niall
>> One of the main changes is that the releases page now points to the
>> download page on each component's site:
>>
>> http://commons.apache.org/downloads/index.html
>>
>> If people are happy to keep this new m2 site, then we need to change
>> the download links on components where they still point to the old
>> pages. Also probably would be a good idea to redirect from the old
>> pages to the new ones.
>>
>> Niall
>>
>>
>> On Fri, Mar 12, 2010 at 1:25 AM, Niall Pemberton
>>
>> <ni...@gmail.com> wrote:
>>
>> > I have created a m2 site for Commons[1][2] as (hopefully) a
>> > replacement for the m1 site[3] that we currently have - you can see it
>> > here:
>> > http://people.apache.org/~niallp/commons/
>> >
>> > IMO its a PITA to have to switch to m1 to build the commons site and
>> > its time to move to m2.
>> >
>> > * The new releases page[4] points to the download pages on the
>> > components' sites (removing the need for the current XSLT ant task to
>> > generate the downloads)
>> > * I've put PMC members in the pom - so we have a page showing them[5]
>> >
>> > Feel free to jump in and correct/improve anything.
>> >
>> > Opinions/feedback on switching from the old m1 site to this m2 site
>> > would be welcome. If anyone objects please shout or I'll assume people
>> > are OK with this.
>> >
>> > Niall
>> >
>> > [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> > [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> > [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> > [4] http://people.apache.org/~niallp/commons/downloads/index.html
>> > [5] http://people.apache.org/~niallp/commons/team-list.html
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 14, 2010 at 1:19 AM, sebb <se...@gmail.com> wrote:
> On 14/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
>> I believe the new m2 site is at least as good as the old one - so I've
>> deployed it to http://commons.apache.org/ - if there are any problems
>> or anyone objects, we can always revert back to the old m1 site.
>
> The ApacheCon logo ought to be removed, as it is rather out of date...
This is pulled in by the stylesheet and we just replace it when the
new one comes out - its the same for all the component sites.
Niall
> I don't think there is a new one yet.
>
>> One of the main changes is that the releases page now points to the
>> download page on each component's site:
>>
>> http://commons.apache.org/downloads/index.html
>>
>> If people are happy to keep this new m2 site, then we need to change
>> the download links on components where they still point to the old
>> pages. Also probably would be a good idea to redirect from the old
>> pages to the new ones.
>>
>> Niall
>>
>>
>> On Fri, Mar 12, 2010 at 1:25 AM, Niall Pemberton
>>
>> <ni...@gmail.com> wrote:
>>
>> > I have created a m2 site for Commons[1][2] as (hopefully) a
>> > replacement for the m1 site[3] that we currently have - you can see it
>> > here:
>> > http://people.apache.org/~niallp/commons/
>> >
>> > IMO its a PITA to have to switch to m1 to build the commons site and
>> > its time to move to m2.
>> >
>> > * The new releases page[4] points to the download pages on the
>> > components' sites (removing the need for the current XSLT ant task to
>> > generate the downloads)
>> > * I've put PMC members in the pom - so we have a page showing them[5]
>> >
>> > Feel free to jump in and correct/improve anything.
>> >
>> > Opinions/feedback on switching from the old m1 site to this m2 site
>> > would be welcome. If anyone objects please shout or I'll assume people
>> > are OK with this.
>> >
>> > Niall
>> >
>> > [1] http://svn.apache.org/viewvc?view=revision&revision=922094
>> > [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
>> > [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
>> > [4] http://people.apache.org/~niallp/commons/downloads/index.html
>> > [5] http://people.apache.org/~niallp/commons/team-list.html
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by sebb <se...@gmail.com>.
On 14/03/2010, Niall Pemberton <ni...@gmail.com> wrote:
> I believe the new m2 site is at least as good as the old one - so I've
> deployed it to http://commons.apache.org/ - if there are any problems
> or anyone objects, we can always revert back to the old m1 site.
The ApacheCon logo ought to be removed, as it is rather out of date...
I don't think there is a new one yet.
> One of the main changes is that the releases page now points to the
> download page on each component's site:
>
> http://commons.apache.org/downloads/index.html
>
> If people are happy to keep this new m2 site, then we need to change
> the download links on components where they still point to the old
> pages. Also probably would be a good idea to redirect from the old
> pages to the new ones.
>
> Niall
>
>
> On Fri, Mar 12, 2010 at 1:25 AM, Niall Pemberton
>
> <ni...@gmail.com> wrote:
>
> > I have created a m2 site for Commons[1][2] as (hopefully) a
> > replacement for the m1 site[3] that we currently have - you can see it
> > here:
> > http://people.apache.org/~niallp/commons/
> >
> > IMO its a PITA to have to switch to m1 to build the commons site and
> > its time to move to m2.
> >
> > * The new releases page[4] points to the download pages on the
> > components' sites (removing the need for the current XSLT ant task to
> > generate the downloads)
> > * I've put PMC members in the pom - so we have a page showing them[5]
> >
> > Feel free to jump in and correct/improve anything.
> >
> > Opinions/feedback on switching from the old m1 site to this m2 site
> > would be welcome. If anyone objects please shout or I'll assume people
> > are OK with this.
> >
> > Niall
> >
> > [1] http://svn.apache.org/viewvc?view=revision&revision=922094
> > [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
> > [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
> > [4] http://people.apache.org/~niallp/commons/downloads/index.html
> > [5] http://people.apache.org/~niallp/commons/team-list.html
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 14, 2010 at 6:05 AM, Mladen Turk <mt...@apache.org> wrote:
> On 03/14/2010 01:56 AM, Niall Pemberton wrote:
>>
>> I believe the new m2 site is at least as good as the old one - so I've
>> deployed it to http://commons.apache.org/ - if there are any problems
>> or anyone objects, we can always revert back to the old m1 site.
>>
>> One of the main changes is that the releases page now points to the
>> download page on each component's site:
>>
>
> Each sandbox component link returns 404.
Thanks, should be fixed after the next sync.
We also have a problem with *dormant* components - looks like when
that was set up their sites were never moved into the *dormant* folder
- it currently just has an index.html
Niall
> Regards
> --
> ^TM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Mladen Turk <mt...@apache.org>.
On 03/14/2010 01:56 AM, Niall Pemberton wrote:
> I believe the new m2 site is at least as good as the old one - so I've
> deployed it to http://commons.apache.org/ - if there are any problems
> or anyone objects, we can always revert back to the old m1 site.
>
> One of the main changes is that the releases page now points to the
> download page on each component's site:
>
Each sandbox component link returns 404.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Replace Commons Site m1 build with m2 version
Posted by Niall Pemberton <ni...@gmail.com>.
I believe the new m2 site is at least as good as the old one - so I've
deployed it to http://commons.apache.org/ - if there are any problems
or anyone objects, we can always revert back to the old m1 site.
One of the main changes is that the releases page now points to the
download page on each component's site:
http://commons.apache.org/downloads/index.html
If people are happy to keep this new m2 site, then we need to change
the download links on components where they still point to the old
pages. Also probably would be a good idea to redirect from the old
pages to the new ones.
Niall
On Fri, Mar 12, 2010 at 1:25 AM, Niall Pemberton
<ni...@gmail.com> wrote:
> I have created a m2 site for Commons[1][2] as (hopefully) a
> replacement for the m1 site[3] that we currently have - you can see it
> here:
> http://people.apache.org/~niallp/commons/
>
> IMO its a PITA to have to switch to m1 to build the commons site and
> its time to move to m2.
>
> * The new releases page[4] points to the download pages on the
> components' sites (removing the need for the current XSLT ant task to
> generate the downloads)
> * I've put PMC members in the pom - so we have a page showing them[5]
>
> Feel free to jump in and correct/improve anything.
>
> Opinions/feedback on switching from the old m1 site to this m2 site
> would be welcome. If anyone objects please shout or I'll assume people
> are OK with this.
>
> Niall
>
> [1] http://svn.apache.org/viewvc?view=revision&revision=922094
> [2] http://svn.apache.org/viewvc/commons/proper/commons-site/
> [3] http://svn.apache.org/viewvc/commons/proper/commons-build/trunk/
> [4] http://people.apache.org/~niallp/commons/downloads/index.html
> [5] http://people.apache.org/~niallp/commons/team-list.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org