On Sat, Mar 13, 2010 at 4:52 PM, Dennis Lundberg <denn...@apache.org> wrote: > On 2010-03-13 17:33, Niall Pemberton wrote: >> 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. > > 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. > 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? >> 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-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 >> >> > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > 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
