On Sat, Mar 13, 2010 at 9:35 PM, Dennis Lundberg <denn...@apache.org> wrote: > On 2010-03-13 20:50, Niall Pemberton wrote: >> On Sat, Mar 13, 2010 at 6:59 PM, Dennis Lundberg <denn...@apache.org> wrote: >>> 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. >> >> OK but how does that benefit commons-skin? > > If we at some point would decide to give commons-skin its own site, then > that site wouldn't have a pointless Surefire report and the navigation > wouldn't have the usual component links in it.
I can't why we would ever want to do that and at the moment then, theres zero benefit. Niall >> Niall >> >>>> >>>> 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
