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? 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
