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