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 18:59:39 GMT
On 2010-03-13 18:35, Niall Pemberton wrote:
> On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>> 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
> 
> 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


Mime
View raw message