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 16:52:34 GMT
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.

The benefit of this setup is that you get a clear separation between
what is needed for Commons components and other Commons projects.

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

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

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


Mime
View raw message