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 21:35:12 GMT
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.

> 
> 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


Mime
View raw message