commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [all] Replace Commons Site m1 build with m2 version
Date Sat, 13 Mar 2010 17:04:58 GMT
On 2010-03-13 17:58, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>> On 2010-03-13 17:33, Niall Pemberton wrote:
>>> On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>>>> On 2010-03-13 16:54, Niall Pemberton wrote:
>>>>> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <dennisl@apache.org>
wrote:
>>>>>> On 2010-03-12 11:34, Niall Pemberton wrote:
>>>>>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <sebbaz@gmail.com>
wrote:
>>>>>>>> On 12/03/2010, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
>>>>>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <sebbaz@gmail.com>
wrote:
>>>>>>>>>  > On 12/03/2010, Niall Pemberton <niall.pemberton@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


Mime
View raw message