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 22:07:19 GMT
On Sat, Mar 13, 2010 at 9:35 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> On 2010-03-13 20:50, Niall Pemberton wrote:
>> 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?
>
> 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


Mime
View raw message