On Sat, Mar 13, 2010 at 4:24 PM, Dennis Lundberg <denn...@apache.org> wrote: > On 2010-03-13 16:54, Niall Pemberton wrote: >> On Sat, Mar 13, 2010 at 3:39 PM, Dennis Lundberg <denn...@apache.org> wrote: >>> On 2010-03-12 11:34, Niall Pemberton wrote: >>>> On Fri, Mar 12, 2010 at 3:12 AM, sebb <seb...@gmail.com> wrote: >>>>> On 12/03/2010, Niall Pemberton <niall.pember...@gmail.com> wrote: >>>>>> On Fri, Mar 12, 2010 at 2:07 AM, sebb <seb...@gmail.com> wrote: >>>>>> > On 12/03/2010, Niall Pemberton <niall.pember...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
