commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [all] Replace Commons Site m1 build with m2 version
Date Sat, 13 Mar 2010 19:50:25 GMT
On Sat, Mar 13, 2010 at 6:59 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> 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.

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


Mime
View raw message