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 commons-build-plugin commons-skin > >>> 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
