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 16:33:28 GMT
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. 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. 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.

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


Mime
View raw message