On 2010-03-13 18:35, Niall Pemberton wrote: > On Sat, Mar 13, 2010 at 5:04 PM, Dennis Lundberg <denn...@apache.org> wrote: >> On 2010-03-13 17:58, Niall Pemberton wrote: >>> 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. >> >> 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. > > 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-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 >>> >>> >> >> >> -- >> 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 > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
