You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Grobmeier <gr...@gmail.com> on 2012/12/10 09:07:32 UTC
We will not be able to update our websites...
starting from 1. January. Just saw a final reminder from Infra.
Commons is surely a LOT of work.
I would like to suggest we act immediately.
In other terms: let us request a commons-test cms where we can try things
out and prepare the new sites.
As Ralph Goers has already mentioned, we have a similar structure in
logging land (1 main site, several sub sites) which might fit to Commons
too.
Basically we have the Main-Site under CMS control; the subsites are
generated via Maven. The target of this generation is then copied to
another svn tree from which it will be taken and published.
Obviously we will have to generate sites for each component then, which
will be a tough job with x-mas arriving.
Thoughts?
--
http://www.grobmeier.de
https://www.timeandbill.de
Re: We will not be able to update our websites...
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Mon, Dec 10, 2012 at 09:07:32AM +0100, Christian Grobmeier wrote:
> starting from 1. January. Just saw a final reminder from Infra.
>
> Commons is surely a LOT of work.
>
> I would like to suggest we act immediately.
>
> In other terms: let us request a commons-test cms where we can try things
> out and prepare the new sites.
Or everything could be set up with the proper naming except that, until the
new sites are ready (or January 1, whichever comes first) the
commons.apache.org
name will still point to the old site.
For testing we would need a "commons-test.apache.org" address to point to
the new site.
Best regards,
Gilles
>
> As Ralph Goers has already mentioned, we have a similar structure in
> logging land (1 main site, several sub sites) which might fit to Commons
> too.
>
> Basically we have the Main-Site under CMS control; the subsites are
> generated via Maven. The target of this generation is then copied to
> another svn tree from which it will be taken and published.
>
> Obviously we will have to generate sites for each component then, which
> will be a tough job with x-mas arriving.
>
> Thoughts?
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Christian Grobmeier <gr...@gmail.com>.
On Mon, Dec 10, 2012 at 8:40 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 12/10/12 10:50 AM, Ralph Goers wrote:
>> All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first.
>
> Having now looked at [1], it looks to me like we can solve the
> immediate problem using svn pub-sub. The docs are not clear and
> they may not allow it, but in theory, we could in fact do this
> incrementally - start an svn repo and move the "mutable" portions
> there incrementally, understanding that only changes to the
> svn-migrated stuff will be propagated. If infra barfs on that, then
> we just commit the whole mess starting at the top level commons
> site, following the Ant example linked on [1]. Then to make
> changes, we follow the process that has been in place for the main
> ASF site for ages - maintain a local checkout of the generated site,
> re-gen when you want to update and check in.
>
> I know playing with the CMS might be fun and interesting; but a) we
> have no volunteers to do this and b) we do not have time to migrate
> all of the content.
Well, this is basically what we (Logging) did: we used extpath and did
care on our sites manually.
Everything in extpath is not editable for the CMS and needs to be
pushed manually.
Example of our svn repo:
https://svn.apache.org/repos/infra/websites/production/logging/content/
Still its a lot of work
Cheers
>
> Therefore, I suggest we just follow the Ant route; possibly moving
> incrementally if infra allows that.
>
> Phil
>
> [1] http://www.apache.org/dev/project-site.html
>>
>> I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS.
>>
>> Are all the sub-sites built with Maven? Any that are not could move to the CMS as part of the main site.
>>
>> Ralph
>>
>>
>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>
>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>> That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
>>> Do we really have to do it all at once?
>>>
>>> IIUC (which is quite possibly false), the intent here is to get
>>> everyone onto svn pub-sub and kill off the rsync processes from
>>> p.a.o to the live site. The stake in the ground is that the rsyncs
>>> are going to stop Jan 1. Do I have that right?
>>>
>>> Why can't we move to svn pub-sub incrementally somehow,
>>> understanding that until individual components move, their sites
>>> will be read-only? So basically, when you decide to make changes to
>>> a site, you get it set up for svn pub-sub? Note I am including the
>>> main site in this - i.e., it does not have to "move" until it needs
>>> to be changed. It would seem to me (again, may be missing something
>>> critical) that we could build the newly definitive source svn repo
>>> incrementally, with publishing always sourced from there, but "old"
>>> directories on the live host remaining until they get clobbered. In
>>> the worst case, if the live host *must* include only svn-published
>>> files, we could seed the new repo with the "old" content. But I
>>> don't get why that has to be the case; because if it is, we are in
>>> worse shape than Christian suggests - come Jan 1 we will be dark if
>>> we don't get everything moved to svn pub-sub.
>>>
>>> Sorry if above is naive. The intent is to avoid a huge amount of
>>> fiddling in a short period of time when quite a few component sites
>>> have not changed and will not change for some time to come.
>>>
>>> Phil
>>>
>>>
>>>> Ralph
>>>>
>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>>
>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>>> we have many components, unless you see a short cut.
>>>>> I thought we would create: commons-test.apache.org
>>>>> move all components to there and then make a switch from
>>>>> commons.apache.org to the new site
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>
>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>> Bah, let's pick one component and start there and skip a test site.
>>>>>>> But then there is only one component visible under the new commons.a.o?
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>>
>>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>>
>>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>>
>>>>>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>>>>>> out and prepare the new sites.
>>>>>>>>>
>>>>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>>>>> too.
>>>>>>>>>
>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>>
>>>>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.grobmeier.de
>>>>>>>>> https://www.timeandbill.de
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://www.grobmeier.de
>>>>>>> https://www.timeandbill.de
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
Ralph,
Thanks for your response, and sorry if I'm still being dense, but let's
just use the [lang] component as an example. Why can't I, at any point,
generate the component's site locally, then surgically modify svn so that
lang/ from the content root now contains the generated content? Where does
a diff become necessary?
Matt
On Mon, Dec 10, 2012 at 3:27 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> Yes, I think you are missing something fundamental.
>
> If you check in "the whole mess" you will never again be able to properly
> build a sub-project's site with Maven. This is because the process of
> updating the site would require first doing a diff and then deleting items
> that are not included in the new version. Someone created a Maven plugin to
> try to do this but it is not the way I would want to go at all.
>
> Ralph
>
> On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:
>
> > I don't think there's much percentage in moving to the CMS with a
> structure
> > like that of Commons. That said, checking in the whole mess, as Phil
> > suggests, seems perfectly doable and should not preclude updating parts
> of
> > the tree in quite a similar fashion as how updating a given component's
> > site is done today, except no ssh to mino. Am I missing something
> > fundamental?
> >
> > Matt
> >
> >
> > On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> >> On 12/10/12 11:40 AM, Phil Steitz wrote:
> >>> On 12/10/12 10:50 AM, Ralph Goers wrote:
> >>>> All the sub-sites are hooked off the main site. I would have no idea
> >> how to migrate anything without migrating the main site first.
> >>> Having now looked at [1], it looks to me like we can solve the
> >>> immediate problem using svn pub-sub. The docs are not clear and
> >>> they may not allow it, but in theory, we could in fact do this
> >>> incrementally - start an svn repo and move the "mutable" portions
> >>> there incrementally, understanding that only changes to the
> >>> svn-migrated stuff will be propagated. If infra barfs on that, then
> >>> we just commit the whole mess starting at the top level commons
> >>> site, following the Ant example linked on [1]. Then to make
> >>> changes, we follow the process that has been in place for the main
> >>> ASF site for ages - maintain a local checkout of the generated site,
> >>> re-gen when you want to update and check in.
> >>>
> >>> I know playing with the CMS might be fun and interesting; but a) we
> >>> have no volunteers to do this and b) we do not have time to migrate
> >>> all of the content.
> >>>
> >>> Therefore, I suggest we just follow the Ant route; possibly moving
> >>> incrementally if infra allows that.
> >>
> >> Let me modify the proposal to make it simpler and more palatable to
> >> infra:
> >>
> >> Just do like Ant - check in the whole mess.
> >>
> >> Phil
> >>>
> >>> Phil
> >>>
> >>> [1] http://www.apache.org/dev/project-site.html
> >>>> I suppose it is possible to point to the sub-sites in their current
> >> location but in logging we found it more beneficial to simply copy the
> >> content under the main site in the CMS.
> >>>>
> >>>> Are all the sub-sites built with Maven? Any that are not could move
> to
> >> the CMS as part of the main site.
> >>>>
> >>>> Ralph
> >>>>
> >>>>
> >>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
> >>>>
> >>>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
> >>>>>> That is what we did in logging. Changing it at the end is fairly
> >> easy. However, we don't have much time for testing.
> >>>>> Do we really have to do it all at once?
> >>>>>
> >>>>> IIUC (which is quite possibly false), the intent here is to get
> >>>>> everyone onto svn pub-sub and kill off the rsync processes from
> >>>>> p.a.o to the live site. The stake in the ground is that the rsyncs
> >>>>> are going to stop Jan 1. Do I have that right?
> >>>>>
> >>>>> Why can't we move to svn pub-sub incrementally somehow,
> >>>>> understanding that until individual components move, their sites
> >>>>> will be read-only? So basically, when you decide to make changes to
> >>>>> a site, you get it set up for svn pub-sub? Note I am including the
> >>>>> main site in this - i.e., it does not have to "move" until it needs
> >>>>> to be changed. It would seem to me (again, may be missing something
> >>>>> critical) that we could build the newly definitive source svn repo
> >>>>> incrementally, with publishing always sourced from there, but "old"
> >>>>> directories on the live host remaining until they get clobbered. In
> >>>>> the worst case, if the live host *must* include only svn-published
> >>>>> files, we could seed the new repo with the "old" content. But I
> >>>>> don't get why that has to be the case; because if it is, we are in
> >>>>> worse shape than Christian suggests - come Jan 1 we will be dark if
> >>>>> we don't get everything moved to svn pub-sub.
> >>>>>
> >>>>> Sorry if above is naive. The intent is to avoid a huge amount of
> >>>>> fiddling in a short period of time when quite a few component sites
> >>>>> have not changed and will not change for some time to come.
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
> >>>>>>
> >>>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <
> >> garydgregory@gmail.com> wrote:
> >>>>>>>> Well, we have to start somewhere. This is going to be a lot of
> work,
> >>>>>>>> we have many components, unless you see a short cut.
> >>>>>>> I thought we would create: commons-test.apache.org
> >>>>>>> move all components to there and then make a switch from
> >>>>>>> commons.apache.org to the new site
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <
> grobmeier@gmail.com>
> >> wrote:
> >>>>>>>>
> >>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
> >> garydgregory@gmail.com> wrote:
> >>>>>>>>>> Bah, let's pick one component and start there and skip a test
> >> site.
> >>>>>>>>> But then there is only one component visible under the new
> >> commons.a.o?
> >>>>>>>>>
> >>>>>>>>>> Gary
> >>>>>>>>>>
> >>>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <
> >> grobmeier@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
> >>>>>>>>>>>
> >>>>>>>>>>> Commons is surely a LOT of work.
> >>>>>>>>>>>
> >>>>>>>>>>> I would like to suggest we act immediately.
> >>>>>>>>>>>
> >>>>>>>>>>> In other terms: let us request a commons-test cms where we can
> >> try things
> >>>>>>>>>>> out and prepare the new sites.
> >>>>>>>>>>>
> >>>>>>>>>>> As Ralph Goers has already mentioned, we have a similar
> >> structure in
> >>>>>>>>>>> logging land (1 main site, several sub sites) which might fit
> to
> >> Commons
> >>>>>>>>>>> too.
> >>>>>>>>>>>
> >>>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
> >> are
> >>>>>>>>>>> generated via Maven. The target of this generation is then
> >> copied to
> >>>>>>>>>>> another svn tree from which it will be taken and published.
> >>>>>>>>>>>
> >>>>>>>>>>> Obviously we will have to generate sites for each component
> >> then, which
> >>>>>>>>>>> will be a tough job with x-mas arriving.
> >>>>>>>>>>>
> >>>>>>>>>>> Thoughts?
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> http://www.grobmeier.de
> >>>>>>>>>>> https://www.timeandbill.de
> >>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> http://www.grobmeier.de
> >>>>>>>>> https://www.timeandbill.de
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>> --
> >>>>>>> http://www.grobmeier.de
> >>>>>>> https://www.timeandbill.de
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
Still no response from infra https://issues.apache.org/jira/browse/INFRA-5657
So I don't know how to start importing content...
What to do is:
* upgrade to parent <version>28-SNAPSHOT</version>
* add a property <commons.site.path>exec</commons.site.path> which
contains the project path relative to commons.a.o
And that's it :-)
parent will need a change regarding a property
<commons.scmPubUrl>https://svn.apache.org/repos/asf/commons/cms-site/trunk/${commons.site.path}</commons.scmPubUrl>
which will be probably
<commons.scmPubUrl>https://svn.apache.org/repos/infra/websites/production/commons/content/${commons.site.path}</commons.scmPubUrl>
No way to test/deploy content atm.
2012/12/28 Phil Steitz <ph...@gmail.com>:
> On 12/18/12 2:32 PM, Olivier Lamy wrote:
>> 2012/12/18 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>> On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:
>>>>
>>>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>>> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>>>>>>
>>>>>>> Maybe could be simpler with committing your staged versionned site to
>>>>>>> log4j2-xxx (tru the maven plugin) for review and then modifying
>>>>>>> .htaccess file (too prevent huge checkout on your machine and to
>>>>>>> modify a symlink this probably won't work for windauze folks).
>>>>>>> With this, just to do: deploy the site tru scm-pub plugin then when
>>>>>>> vote passed only modify the .htaccess file
>>>>>>> (that's just an idea)
>>>>>> If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
>>>>>>
>>>>>> I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
>>>>>>
>>>>>> What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
>>>>> Part of the build so no manual steps (add, commit etc...)
>>>>> And do some cleanup: If content generated doesn't produce anymore
>>>>> file(s) which were in svn path they will be "svn rm".
>>>> Is this the plugin that has to checkout a copy and do a diff so that it can then figure out what to remove? If so, then it is going to take longer than the process I outlined as each commit to the production goes to a new location in svn.
>>>>
>>> yup.
>>> In your case (only versionned site/new location) that doesn't help.
>> But in the maven site case that helps as there is huge content.
>> Having a full copy is a bit too huge and not very useful.
>> So with using the plugin, just say you want to commit to
>> http:///blabla/bar/beer/wine, if the path doesn't exists it will be
>> created then content committed in.
>
> Tick, tock, guys. We are about to turn into a pumpkin :)
>
> I have some time over the next few days to help, but I have sort of
> lost the plot. Sorry to be slow and ignorant, but can someone post
> or point to a "horsey, ducky, lamby" set of instructions that I can
> use to start helping migrate stuff? I will start with [math],
> [dbcp] and [pool] if I can get pointed in the right direction.
>
> Thanks!
>
> Phil
>>
>>>> Ralph
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/18/12 2:32 PM, Olivier Lamy wrote:
> 2012/12/18 Olivier Lamy <ol...@apache.org>:
>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>> On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:
>>>
>>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>>>>>
>>>>>> Maybe could be simpler with committing your staged versionned site to
>>>>>> log4j2-xxx (tru the maven plugin) for review and then modifying
>>>>>> .htaccess file (too prevent huge checkout on your machine and to
>>>>>> modify a symlink this probably won't work for windauze folks).
>>>>>> With this, just to do: deploy the site tru scm-pub plugin then when
>>>>>> vote passed only modify the .htaccess file
>>>>>> (that's just an idea)
>>>>> If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
>>>>>
>>>>> I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
>>>>>
>>>>> What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
>>>> Part of the build so no manual steps (add, commit etc...)
>>>> And do some cleanup: If content generated doesn't produce anymore
>>>> file(s) which were in svn path they will be "svn rm".
>>> Is this the plugin that has to checkout a copy and do a diff so that it can then figure out what to remove? If so, then it is going to take longer than the process I outlined as each commit to the production goes to a new location in svn.
>>>
>> yup.
>> In your case (only versionned site/new location) that doesn't help.
> But in the maven site case that helps as there is huge content.
> Having a full copy is a bit too huge and not very useful.
> So with using the plugin, just say you want to commit to
> http:///blabla/bar/beer/wine, if the path doesn't exists it will be
> created then content committed in.
Tick, tock, guys. We are about to turn into a pumpkin :)
I have some time over the next few days to help, but I have sort of
lost the plot. Sorry to be slow and ignorant, but can someone post
or point to a "horsey, ducky, lamby" set of instructions that I can
use to start helping migrate stuff? I will start with [math],
[dbcp] and [pool] if I can get pointed in the right direction.
Thanks!
Phil
>
>>> Ralph
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
extpaths.txt operates by saying that everything under the subdirectories named in it is excluded from the CMS and must be manually managed. So what Logging does is have the main site be managed in the CMS. The links in the parent project point to generic project directories that are symlinks. For example, the parent might reference "proper/VFS/2.x " to get to the VFS web site. Then, we could have content/proper be listed in extpaths.txt. Then whenever a new VFS release is done it is uploaded to a directory named content/proper/VFS/vfs-2.n. The 2.x link is then modified to point to the newly uploaded content. Thus you never have to modify the parent (or the CMS) to update a subproject, nor do you need to commit it to any other location in subversion except for the production site which, of course, is managed by subversion.
Ralph
On Dec 18, 2012, at 10:56 AM, Matt Benson wrote:
> Let me see if I understand. Are you saying, Ralph, that when we have
> generated content to expose on the website, we should commit it directly to
> the production website svn and mark it in extpaths.txt back in our tree in
> mainrepo, basically because that avoids the duplication that is created by
> storing the generated content directly in mainrepo when it would only be
> copied out anyway? Do I finally grasp the intent of expaths.txt?
>
> Matt
>
>
> On Tue, Dec 18, 2012 at 12:51 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>>
>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>
>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>> I still don't understand why you are committing the subprojects to svn.
>> That is not required. Just use stage-deploy to deploy to a local
>> directory on your computer, then copy that under where you have the
>> production web site checked out and check it in. See
>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>
>>> As I can see in section "Managing Sub-project Sites" this doc says
>>> "Make sure all that is added to svn and commit it."
>>> So subsites must be checked in (here I configure this to be done tru a
>>> maven plugin and not manually)
>>> Infra will be able to use as production web site:
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>> but this one still doesn't exist, I will ping infra on the jira entry
>>> for their preference).
>>
>> Step 6 is referring to checking it in directly to
>> https://svn.apache.org/repos/infra/websites/production/logging/content/in the subdirectory that is listed in extpaths.txt, not some other
>> subversion location. If you look under log4j, for example, you will see a
>> directory for each release and a directory that is a symlink to the current
>> release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>
>>>
>>> So if you want sub-project sites available AFAIK this (check in all
>>> content) must be done (or I misunderstand something: -)).
>>>
>>> Makes sense ?
>>
>> Not really.
>>
>> Ralph
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
Let me see if I understand. Are you saying, Ralph, that when we have
generated content to expose on the website, we should commit it directly to
the production website svn and mark it in extpaths.txt back in our tree in
mainrepo, basically because that avoids the duplication that is created by
storing the generated content directly in mainrepo when it would only be
copied out anyway? Do I finally grasp the intent of expaths.txt?
Matt
On Tue, Dec 18, 2012 at 12:51 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>
> > 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
> >> I still don't understand why you are committing the subprojects to svn.
> That is not required. Just use stage-deploy to deploy to a local
> directory on your computer, then copy that under where you have the
> production web site checked out and check it in. See
> http://wiki.apache.org/logging/ManagingTheWebSite
> >>
> > As I can see in section "Managing Sub-project Sites" this doc says
> > "Make sure all that is added to svn and commit it."
> > So subsites must be checked in (here I configure this to be done tru a
> > maven plugin and not manually)
> > Infra will be able to use as production web site:
> > http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
> > https://svn.apache.org/repos/infra/websites/production/commons/content/
> > but this one still doesn't exist, I will ping infra on the jira entry
> > for their preference).
>
> Step 6 is referring to checking it in directly to
> https://svn.apache.org/repos/infra/websites/production/logging/content/in the subdirectory that is listed in extpaths.txt, not some other
> subversion location. If you look under log4j, for example, you will see a
> directory for each release and a directory that is a symlink to the current
> release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>
> >
> > So if you want sub-project sites available AFAIK this (check in all
> > content) must be done (or I misunderstand something: -)).
> >
> > Makes sense ?
>
> Not really.
>
> Ralph
>
>
>
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>
> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>
>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>
>>> On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:
>>>
>>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>>
>>>>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>>>>
>>>>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>>>> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>
>>>>>> As I can see in section "Managing Sub-project Sites" this doc says
>>>>>> "Make sure all that is added to svn and commit it."
>>>>>> So subsites must be checked in (here I configure this to be done tru a
>>>>>> maven plugin and not manually)
>>>>>> Infra will be able to use as production web site:
>>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>> but this one still doesn't exist, I will ping infra on the jira entry
>>>>>> for their preference).
>>>>>
>>>>> Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/ in the subdirectory that is listed in extpaths.txt, not some other subversion location. If you look under log4j, for example, you will see a directory for each release and a directory that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>>>>
>>>>>>
>>>>>> So if you want sub-project sites available AFAIK this (check in all
>>>>>> content) must be done (or I misunderstand something: -)).
>>>>>>
>>>>>> Makes sense ?
>>>>>
>>>>> Not really.
>>>> So maybe I misunderstood what you want to do.
>>>>
>>>> What I understood:
>>>> 1) main site is build from
>>>> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>> (and marked as cms content so possible to modify files via the cms ui)
>>>> technically a buildbot job run the maven build and commit the
>>>> generated site to
>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
>>>> will serve as infra for web site content staging then live) (note I
>>>> did the change for infra requirement on sources structure)
>>>> 2) due to #1 sub project content (take lang) must be committed to
>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
>>>
>>> This step is not necessary. sub-project content can be committed directly to https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n or https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n depending on what is in extpaths.txt
>>>
>>
>> Ok I see now (as I said in a previous mail) I believed you wanted to
>> use http://svn.apache.org/repos/asf/commons/cms-site/trunk/ rather
>> than https://svn.apache.org/repos/infra/websites/production/commons/content
>
> I'm not sure what http://svn.apache.org/repos/asf/commons/cms-site/trunk is. It doesn't seem to be the actual CMS site. That seems to be at http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/. Personally, I prefer commons/cms-site/trunk as the actually location for the CMS content instead of proper/commons-site/trunk. But only one of the two is needed and it would be where the CMS content resides.
>
Ok looks good for me too.
Content from /proper/commons-site/trunk/ must be copied. I can do that.
> As I understand it we don't have a choice, we have to use https://svn.apache.org/repos/infra/websites/production/commons/content for the production site.
>
> Ralph
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>
>> On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:
>>
>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>
>>>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>>>
>>>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>>> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>
>>>>> As I can see in section "Managing Sub-project Sites" this doc says
>>>>> "Make sure all that is added to svn and commit it."
>>>>> So subsites must be checked in (here I configure this to be done tru a
>>>>> maven plugin and not manually)
>>>>> Infra will be able to use as production web site:
>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>> but this one still doesn't exist, I will ping infra on the jira entry
>>>>> for their preference).
>>>>
>>>> Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/ in the subdirectory that is listed in extpaths.txt, not some other subversion location. If you look under log4j, for example, you will see a directory for each release and a directory that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>>>
>>>>>
>>>>> So if you want sub-project sites available AFAIK this (check in all
>>>>> content) must be done (or I misunderstand something: -)).
>>>>>
>>>>> Makes sense ?
>>>>
>>>> Not really.
>>> So maybe I misunderstood what you want to do.
>>>
>>> What I understood:
>>> 1) main site is build from
>>> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>> (and marked as cms content so possible to modify files via the cms ui)
>>> technically a buildbot job run the maven build and commit the
>>> generated site to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
>>> will serve as infra for web site content staging then live) (note I
>>> did the change for infra requirement on sources structure)
>>> 2) due to #1 sub project content (take lang) must be committed to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
>>
>> This step is not necessary. sub-project content can be committed directly to https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n or https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n depending on what is in extpaths.txt
>>
>
> Ok I see now (as I said in a previous mail) I believed you wanted to
> use http://svn.apache.org/repos/asf/commons/cms-site/trunk/ rather
> than https://svn.apache.org/repos/infra/websites/production/commons/content
I'm not sure what http://svn.apache.org/repos/asf/commons/cms-site/trunk is. It doesn't seem to be the actual CMS site. That seems to be at http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/. Personally, I prefer commons/cms-site/trunk as the actually location for the CMS content instead of proper/commons-site/trunk. But only one of the two is needed and it would be where the CMS content resides.
As I understand it we don't have a choice, we have to use https://svn.apache.org/repos/infra/websites/production/commons/content for the production site.
Ralph
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Olivier Lamy <ol...@apache.org>:
> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>
>> On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:
>>
>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>
>>>> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>>>>
>>>>>>
>>>>> Maybe could be simpler with committing your staged versionned site to
>>>>> log4j2-xxx (tru the maven plugin) for review and then modifying
>>>>> .htaccess file (too prevent huge checkout on your machine and to
>>>>> modify a symlink this probably won't work for windauze folks).
>>>>> With this, just to do: deploy the site tru scm-pub plugin then when
>>>>> vote passed only modify the .htaccess file
>>>>> (that's just an idea)
>>>>
>>>> If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
>>>>
>>>> I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
>>>>
>>>> What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
>>> Part of the build so no manual steps (add, commit etc...)
>>> And do some cleanup: If content generated doesn't produce anymore
>>> file(s) which were in svn path they will be "svn rm".
>>
>> Is this the plugin that has to checkout a copy and do a diff so that it can then figure out what to remove? If so, then it is going to take longer than the process I outlined as each commit to the production goes to a new location in svn.
>>
> yup.
> In your case (only versionned site/new location) that doesn't help.
But in the maven site case that helps as there is huge content.
Having a full copy is a bit too huge and not very useful.
So with using the plugin, just say you want to commit to
http:///blabla/bar/beer/wine, if the path doesn't exists it will be
created then content committed in.
>> Ralph
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>
> On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:
>
>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>
>>> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>>>
>>>>>
>>>> Maybe could be simpler with committing your staged versionned site to
>>>> log4j2-xxx (tru the maven plugin) for review and then modifying
>>>> .htaccess file (too prevent huge checkout on your machine and to
>>>> modify a symlink this probably won't work for windauze folks).
>>>> With this, just to do: deploy the site tru scm-pub plugin then when
>>>> vote passed only modify the .htaccess file
>>>> (that's just an idea)
>>>
>>> If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
>>>
>>> I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
>>>
>>> What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
>> Part of the build so no manual steps (add, commit etc...)
>> And do some cleanup: If content generated doesn't produce anymore
>> file(s) which were in svn path they will be "svn rm".
>
> Is this the plugin that has to checkout a copy and do a diff so that it can then figure out what to remove? If so, then it is going to take longer than the process I outlined as each commit to the production goes to a new location in svn.
>
yup.
In your case (only versionned site/new location) that doesn't help.
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:
> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>
>> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>>
>>>>
>>> Maybe could be simpler with committing your staged versionned site to
>>> log4j2-xxx (tru the maven plugin) for review and then modifying
>>> .htaccess file (too prevent huge checkout on your machine and to
>>> modify a symlink this probably won't work for windauze folks).
>>> With this, just to do: deploy the site tru scm-pub plugin then when
>>> vote passed only modify the .htaccess file
>>> (that's just an idea)
>>
>> If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
>>
>> I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
>>
>> What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
> Part of the build so no manual steps (add, commit etc...)
> And do some cleanup: If content generated doesn't produce anymore
> file(s) which were in svn path they will be "svn rm".
Is this the plugin that has to checkout a copy and do a diff so that it can then figure out what to remove? If so, then it is going to take longer than the process I outlined as each commit to the production goes to a new location in svn.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>
> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>
>>>
>> Maybe could be simpler with committing your staged versionned site to
>> log4j2-xxx (tru the maven plugin) for review and then modifying
>> .htaccess file (too prevent huge checkout on your machine and to
>> modify a symlink this probably won't work for windauze folks).
>> With this, just to do: deploy the site tru scm-pub plugin then when
>> vote passed only modify the .htaccess file
>> (that's just an idea)
>
> If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
>
> I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
>
> What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
Part of the build so no manual steps (add, commit etc...)
And do some cleanup: If content generated doesn't produce anymore
file(s) which were in svn path they will be "svn rm".
>
> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>>
> Maybe could be simpler with committing your staged versionned site to
> log4j2-xxx (tru the maven plugin) for review and then modifying
> .htaccess file (too prevent huge checkout on your machine and to
> modify a symlink this probably won't work for windauze folks).
> With this, just to do: deploy the site tru scm-pub plugin then when
> vote passed only modify the .htaccess file
> (that's just an idea)
If you follow the instructions on the wiki the checkout doesn't have to be huge. You will get the main part of the web site and then you can get the subproject parts you want individually.
I noticed that when you check out the site on Windows you get a file that represents the symlink. Of course, it doesn't do anything useful on windows as it would on a unix-based system, but I would expect you could hand modify it to update the link.
What does the scm-plugin do to deploy the site that makes it easier than doing a cp and svn commit?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>
> On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:
>
>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>
>>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>>
>>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>>> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>
>>>> As I can see in section "Managing Sub-project Sites" this doc says
>>>> "Make sure all that is added to svn and commit it."
>>>> So subsites must be checked in (here I configure this to be done tru a
>>>> maven plugin and not manually)
>>>> Infra will be able to use as production web site:
>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>> but this one still doesn't exist, I will ping infra on the jira entry
>>>> for their preference).
>>>
>>> Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/ in the subdirectory that is listed in extpaths.txt, not some other subversion location. If you look under log4j, for example, you will see a directory for each release and a directory that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>>
>>>>
>>>> So if you want sub-project sites available AFAIK this (check in all
>>>> content) must be done (or I misunderstand something: -)).
>>>>
>>>> Makes sense ?
>>>
>>> Not really.
>> So maybe I misunderstood what you want to do.
>>
>> What I understood:
>> 1) main site is build from
>> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>> (and marked as cms content so possible to modify files via the cms ui)
>> technically a buildbot job run the maven build and commit the
>> generated site to
>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
>> will serve as infra for web site content staging then live) (note I
>> did the change for infra requirement on sources structure)
>> 2) due to #1 sub project content (take lang) must be committed to
>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
>
> This step is not necessary. sub-project content can be committed directly to https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n or https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n depending on what is in extpaths.txt
>
Ok I see now (as I said in a previous mail) I believed you wanted to
use http://svn.apache.org/repos/asf/commons/cms-site/trunk/ rather
than https://svn.apache.org/repos/infra/websites/production/commons/content
>> 3) as lang is not generated by cms it must be added to extpaths file.
>
> This is true, unless it resides under a directory that was declared in extpaths.txt, (for example, "proper" as in the second url above.
>
Definitely this must be done too much paths in extpaths will go in a
very very long publish tru the cms.
>> 4) committing sub project content will be done using the maven
>> scm-publish plugin (that's what I started to do)
>
> I don't do this. I do mvn site:stage-deploy -DstaginngSiteURL=file:///Users/rgoers/log4j for my Log4j 2 web site. I zip it and publish it at p.a.o/~rgoers/log4j2 for review during a release and then I do a "cp -r ~/log4j/*" to where I want it to go under where I have the production web site checked out on my machine. After it is copied I remove the link from the old release and create a link to the new release and then do an svn commit.
>
Maybe could be simpler with committing your staged versionned site to
log4j2-xxx (tru the maven plugin) for review and then modifying
.htaccess file (too prevent huge checkout on your machine and to
modify a symlink this probably won't work for windauze folks).
With this, just to do: deploy the site tru scm-pub plugin then when
vote passed only modify the .htaccess file
(that's just an idea)
>>
>> Regarding your point on versionned subsites, I don't such structure
>> here (no commons.a.o/lang-2.x)
>
> Correct. We are doing this in logging because it makes it easy to deploy a new release of the web site.
>
>>
>> So let me know what is your plan ?
>> I proposed to help but it looks I don't know exactly what is the plan
>> so that will be a bit complicated for me.
>
> The plan would be to follow what is published in the logging wiki link. I'm not sure why you think it is complicated. It should be simpler than what you are doing.
>
Now I have the information (consider I was committing stuff because as
already said I didn't know which url to use)
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:
> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>
>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>
>>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>>> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>>>>
>>> As I can see in section "Managing Sub-project Sites" this doc says
>>> "Make sure all that is added to svn and commit it."
>>> So subsites must be checked in (here I configure this to be done tru a
>>> maven plugin and not manually)
>>> Infra will be able to use as production web site:
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>> but this one still doesn't exist, I will ping infra on the jira entry
>>> for their preference).
>>
>> Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/ in the subdirectory that is listed in extpaths.txt, not some other subversion location. If you look under log4j, for example, you will see a directory for each release and a directory that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>
>>>
>>> So if you want sub-project sites available AFAIK this (check in all
>>> content) must be done (or I misunderstand something: -)).
>>>
>>> Makes sense ?
>>
>> Not really.
> So maybe I misunderstood what you want to do.
>
> What I understood:
> 1) main site is build from
> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
> (and marked as cms content so possible to modify files via the cms ui)
> technically a buildbot job run the maven build and commit the
> generated site to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
> will serve as infra for web site content staging then live) (note I
> did the change for infra requirement on sources structure)
> 2) due to #1 sub project content (take lang) must be committed to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
This step is not necessary. sub-project content can be committed directly to https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n or https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n depending on what is in extpaths.txt
> 3) as lang is not generated by cms it must be added to extpaths file.
This is true, unless it resides under a directory that was declared in extpaths.txt, (for example, "proper" as in the second url above.
> 4) committing sub project content will be done using the maven
> scm-publish plugin (that's what I started to do)
I don't do this. I do mvn site:stage-deploy -DstaginngSiteURL=file:///Users/rgoers/log4j for my Log4j 2 web site. I zip it and publish it at p.a.o/~rgoers/log4j2 for review during a release and then I do a "cp -r ~/log4j/*" to where I want it to go under where I have the production web site checked out on my machine. After it is copied I remove the link from the old release and create a link to the new release and then do an svn commit.
>
> Regarding your point on versionned subsites, I don't such structure
> here (no commons.a.o/lang-2.x)
Correct. We are doing this in logging because it makes it easy to deploy a new release of the web site.
>
> So let me know what is your plan ?
> I proposed to help but it looks I don't know exactly what is the plan
> so that will be a bit complicated for me.
The plan would be to follow what is published in the logging wiki link. I'm not sure why you think it is complicated. It should be simpler than what you are doing.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>
> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>
>> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>>> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>>>
>> As I can see in section "Managing Sub-project Sites" this doc says
>> "Make sure all that is added to svn and commit it."
>> So subsites must be checked in (here I configure this to be done tru a
>> maven plugin and not manually)
>> Infra will be able to use as production web site:
>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>> but this one still doesn't exist, I will ping infra on the jira entry
>> for their preference).
>
> Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/ in the subdirectory that is listed in extpaths.txt, not some other subversion location. If you look under log4j, for example, you will see a directory for each release and a directory that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>
>>
>> So if you want sub-project sites available AFAIK this (check in all
>> content) must be done (or I misunderstand something: -)).
>>
>> Makes sense ?
>
> Not really.
So maybe I misunderstood what you want to do.
What I understood:
1) main site is build from
http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
(and marked as cms content so possible to modify files via the cms ui)
technically a buildbot job run the maven build and commit the
generated site to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
will serve as infra for web site content staging then live) (note I
did the change for infra requirement on sources structure)
2) due to #1 sub project content (take lang) must be committed to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
3) as lang is not generated by cms it must be added to extpaths file.
4) committing sub project content will be done using the maven
scm-publish plugin (that's what I started to do)
Regarding your point on versionned subsites, I don't such structure
here (no commons.a.o/lang-2.x)
So let me know what is your plan ?
I proposed to help but it looks I don't know exactly what is the plan
so that will be a bit complicated for me.
>
> Ralph
>
>
--
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
> 2012/12/18 Ralph Goers <ra...@dslextreme.com>:
>> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>>
> As I can see in section "Managing Sub-project Sites" this doc says
> "Make sure all that is added to svn and commit it."
> So subsites must be checked in (here I configure this to be done tru a
> maven plugin and not manually)
> Infra will be able to use as production web site:
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
> https://svn.apache.org/repos/infra/websites/production/commons/content/
> but this one still doesn't exist, I will ping infra on the jira entry
> for their preference).
Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/ in the subdirectory that is listed in extpaths.txt, not some other subversion location. If you look under log4j, for example, you will see a directory for each release and a directory that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>
> So if you want sub-project sites available AFAIK this (check in all
> content) must be done (or I misunderstand something: -)).
>
> Makes sense ?
Not really.
Ralph
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Ralph Goers <ra...@dslextreme.com>:
> I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
>
As I can see in section "Managing Sub-project Sites" this doc says
"Make sure all that is added to svn and commit it."
So subsites must be checked in (here I configure this to be done tru a
maven plugin and not manually)
Infra will be able to use as production web site:
http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
https://svn.apache.org/repos/infra/websites/production/commons/content/
but this one still doesn't exist, I will ping infra on the jira entry
for their preference).
So if you want sub-project sites available AFAIK this (check in all
content) must be done (or I misunderstand something: -)).
Makes sense ?
>
> Ralph
>
> On Dec 18, 2012, at 3:20 AM, Olivier Lamy wrote:
>
>> 2012/12/18 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/18 Phil Steitz <ph...@gmail.com>:
>>>> On 12/17/12 5:55 AM, Olivier Lamy wrote:
>>>>> ETA of the migration:
>>>>> collections and lang done.
>>>>>
>>>>> results:
>>>>> * http://people.apache.org/~olamy/commons/lang/
>>>>> * http://people.apache.org/~olamy/commons/collections/
>>>>>
>>>>> As Gary suggested old javadocs are
>>>>> http://people.apache.org/~olamy/commons/lang/javadocs
>>>>>
>>>>> NOTE I didn't import all previous versions. Does it make sense ?
>>>>
>>>> Makes sense to me. Older javadocs can be retrieved from the archives.
>>>>
>>>> THANKS for jumping on this, Olivier!
>>>>
>>>> Other than helping getting site builds working where they may be
>>>> broken, what can the rest of us do to help?
>>> Help me a bit on other components :-).
>>> There are a lot to do (end of proper then sandbox then dormant.
>>> What I can do is to import content manually for sandbox and dormant if
>>> folks want to redeploy website due to code/documentation change they
>>> will need to fix the pom (at least that will work for the migration)
>>> Changes are easy to apply.
>>>
>>> What about releasing the parent ? (I don't know what is the procedure
>>> for that here).
>>>
>>> Something else is the size of sites due to a lot of reporting
>>> (cobertura, findbug, pmd, etc..) and that make svn commit very long.
>>> What about using sonar ? We have an instance for asf projects
>>> (https://analysis.apache.org). I can at least setup this for proper
>>> projects.
>>>
>>> WDYT ?
>>
>> I have added 4 for testing (collections, cli, lang and ognl).
>> See result: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-proper-aggregator
>>
>> I missed to explain how to configure svnpubsub for site publication.
>>
>> Use last parent pom 28-SNAPSHOT
>>
>> add a property to define site path:
>> <commons.site.path>ognl</commons.site.path>
>> (http://commons.apache.org/ognl)
>> That will commit site content to
>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ognl/
>>
>> Then test it :-)
>> mvn clean site site:stage scm-publish:publish-scm
>> To pass your svn authz:
>> -Dusername=asf id
>> -Dpassword=asf password
>>
>> Once is done add the new path to
>> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/content/resources/extpaths.txt
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> Phil
>>>>>
>>>>> digester I have issues while building trunk
>>>>> [ERROR] Failed to execute goal
>>>>> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
>>>>> (default-testCompile) on project commons-digester3-ap: Compilation
>>>>> failure: Compilation failure:
>>>>> [ERROR] error: Impossible to generate class
>>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>>>> Attempt to recreate a file for type
>>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>>>> [ERROR] error: Impossible to generate class
>>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>>>> Attempt to recreate a file for type
>>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>>>> [ERROR] -> [Help 1]
>>>>> [ERROR]
>>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>>>> the -e switch.
>>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>>>
>>>>> So I stop for it as no idea on WTF here
>>>>>
>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>>> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>>>>>>>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
>>>>>>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>>>>>>> I will try to work on sub projects today (it's only a matter of
>>>>>>> configuring parent pom normally)
>>>>>>> And test with deploying to
>>>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
>>>>>> I will start with digester and collections.
>>>>>> As I can see there is a lot of content deployed manually. I think
>>>>>> about versionned documentation
>>>>>> (http://commons.apache.org/digester/commons-digester-3.1) so this will
>>>>>> need to be imported manually to
>>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>
>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>>>>>>>
>>>>>>>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>>>>>>>
>>>>>>>>> Ralph
>>>>>>>>>
>>>>>>>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>>>>>>>
>>>>>>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>>>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>>>>>>>> Olivier,
>>>>>>>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>>>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>>>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>>>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>>>>>>>> perusing your wiki link now.
>>>>>>>>>>>>
>>>>>>>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>>>>>>>> and website content from
>>>>>>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>>>>>>>
>>>>>>>>>>> I will update commons-site now to get it working for cms.
>>>>>>>>>>>
>>>>>>>>>> Done.
>>>>>>>>>>
>>>>>>>>>>> For deploying I can try make configuration easy if you accept to use
>>>>>>>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>>>>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>>>>>>>> ).
>>>>>>>>>>>
>>>>>>>>>>> Note that will need a release of your parent pom.
>>>>>>>>>>>
>>>>>>>>>>>> Matt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> /me listening here
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>>>>>>>
>>>>>>>>>>>>> The source tree need some modifications: see
>>>>>>>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>>>>>>>> which is dedicated to this purpose.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As I can see you are using this module
>>>>>>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>>>>>>>> for main site ?
>>>>>>>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>>>>>>>> both cms and mvn site.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>>>>>>>> this case mvn site-deploy works)
>>>>>>>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>>>>>>>> projects here ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Olivier
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> br,
>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>>>>>>>> we'd
>>>>>>>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>>>>>>>> doing
>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> "built by maven".
>>>>>>>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>>>>>>>> web
>>>>>>>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>>>>>>>> components'
>>>>>>>>>>>>>>> sites themselves are ready).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>>>>>>>> using a
>>>>>>>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>>>>>>>> exposed to
>>>>>>>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>>>>>>>> CMS a
>>>>>>>>>>>>>>>>> la
>>>>>>>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>>>>>>>> Actually
>>>>>>>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>>>>>>>> guess
>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>>>>>>>> commons-test
>>>>>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>>>>>>>> created a
>>>>>>>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>>>>>>>> want
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> go at
>>>>>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>>>>>>>> stale
>>>>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>>>>>>>> deal? I
>>>>>>>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>>>>>>>> releases, one
>>>>>>>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>>>>>>>> in,
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>>>>>>>> svnmucc
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>>>>>>>> component
>>>>>>>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>>>>>>>> tree.
>>>>>>>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>> perform
>>>>>>>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>>>>>>>> production
>>>>>>>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Olivier Lamy
>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
Ralph
On Dec 18, 2012, at 3:20 AM, Olivier Lamy wrote:
> 2012/12/18 Olivier Lamy <ol...@apache.org>:
>> 2012/12/18 Phil Steitz <ph...@gmail.com>:
>>> On 12/17/12 5:55 AM, Olivier Lamy wrote:
>>>> ETA of the migration:
>>>> collections and lang done.
>>>>
>>>> results:
>>>> * http://people.apache.org/~olamy/commons/lang/
>>>> * http://people.apache.org/~olamy/commons/collections/
>>>>
>>>> As Gary suggested old javadocs are
>>>> http://people.apache.org/~olamy/commons/lang/javadocs
>>>>
>>>> NOTE I didn't import all previous versions. Does it make sense ?
>>>
>>> Makes sense to me. Older javadocs can be retrieved from the archives.
>>>
>>> THANKS for jumping on this, Olivier!
>>>
>>> Other than helping getting site builds working where they may be
>>> broken, what can the rest of us do to help?
>> Help me a bit on other components :-).
>> There are a lot to do (end of proper then sandbox then dormant.
>> What I can do is to import content manually for sandbox and dormant if
>> folks want to redeploy website due to code/documentation change they
>> will need to fix the pom (at least that will work for the migration)
>> Changes are easy to apply.
>>
>> What about releasing the parent ? (I don't know what is the procedure
>> for that here).
>>
>> Something else is the size of sites due to a lot of reporting
>> (cobertura, findbug, pmd, etc..) and that make svn commit very long.
>> What about using sonar ? We have an instance for asf projects
>> (https://analysis.apache.org). I can at least setup this for proper
>> projects.
>>
>> WDYT ?
>
> I have added 4 for testing (collections, cli, lang and ognl).
> See result: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-proper-aggregator
>
> I missed to explain how to configure svnpubsub for site publication.
>
> Use last parent pom 28-SNAPSHOT
>
> add a property to define site path:
> <commons.site.path>ognl</commons.site.path>
> (http://commons.apache.org/ognl)
> That will commit site content to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ognl/
>
> Then test it :-)
> mvn clean site site:stage scm-publish:publish-scm
> To pass your svn authz:
> -Dusername=asf id
> -Dpassword=asf password
>
> Once is done add the new path to
> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/content/resources/extpaths.txt
>
>
>
>
>>
>>
>>>
>>> Phil
>>>>
>>>> digester I have issues while building trunk
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
>>>> (default-testCompile) on project commons-digester3-ap: Compilation
>>>> failure: Compilation failure:
>>>> [ERROR] error: Impossible to generate class
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>>> Attempt to recreate a file for type
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>>> [ERROR] error: Impossible to generate class
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>>> Attempt to recreate a file for type
>>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>>> [ERROR] -> [Help 1]
>>>> [ERROR]
>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>>> the -e switch.
>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>>
>>>> So I stop for it as no idea on WTF here
>>>>
>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>>>>>>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
>>>>>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>>>>>> I will try to work on sub projects today (it's only a matter of
>>>>>> configuring parent pom normally)
>>>>>> And test with deploying to
>>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
>>>>> I will start with digester and collections.
>>>>> As I can see there is a lot of content deployed manually. I think
>>>>> about versionned documentation
>>>>> (http://commons.apache.org/digester/commons-digester-3.1) so this will
>>>>> need to be imported manually to
>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>
>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>>>>>>
>>>>>>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>>>>>>
>>>>>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>>>>>>> Olivier,
>>>>>>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>>>>>>> perusing your wiki link now.
>>>>>>>>>>>
>>>>>>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>>>>>>> and website content from
>>>>>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>>>>>>
>>>>>>>>>> I will update commons-site now to get it working for cms.
>>>>>>>>>>
>>>>>>>>> Done.
>>>>>>>>>
>>>>>>>>>> For deploying I can try make configuration easy if you accept to use
>>>>>>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>>>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>>>>>>> ).
>>>>>>>>>>
>>>>>>>>>> Note that will need a release of your parent pom.
>>>>>>>>>>
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> /me listening here
>>>>>>>>>>>>
>>>>>>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>>>>>>
>>>>>>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>>>>>>
>>>>>>>>>>>> The source tree need some modifications: see
>>>>>>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>>>>>>
>>>>>>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>>>>>>> which is dedicated to this purpose.
>>>>>>>>>>>>
>>>>>>>>>>>> As I can see you are using this module
>>>>>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>>>>>>> for main site ?
>>>>>>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>>>>>>> both cms and mvn site.
>>>>>>>>>>>>
>>>>>>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>>>>>>> this case mvn site-deploy works)
>>>>>>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>>>>>>> projects here ?
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Olivier
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>>>>>>
>>>>>>>>>>>>> br,
>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>>>>>>> quite
>>>>>>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>>>>>>> we'd
>>>>>>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>>>>>>> doing
>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>>>>>>> are
>>>>>>>>>>>>>> "built by maven".
>>>>>>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>>>>>>> web
>>>>>>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>>>>>>> components'
>>>>>>>>>>>>>> sites themselves are ready).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>>>>>>> using a
>>>>>>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>>>>>>> exposed to
>>>>>>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>>>>>>> CMS a
>>>>>>>>>>>>>>>> la
>>>>>>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>>>>>>> Actually
>>>>>>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>>>>>>> guess
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>>>>>>> commons-test
>>>>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>>>>>>> and
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>>>>>>> created a
>>>>>>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>>>>>>> want
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> go at
>>>>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>>>>>>> stale
>>>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>>>>>>> deal? I
>>>>>>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>>>>>>> releases, one
>>>>>>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>>>>>>> in,
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>>>>>>> svnmucc
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>>>>>>> component
>>>>>>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>>>>>>> tree.
>>>>>>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>>>>>>> just
>>>>>>>>>>>>>>>> perform
>>>>>>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>>>>>>> production
>>>>>>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Olivier Lamy
>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Olivier Lamy
>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Olivier Lamy <ol...@apache.org>:
> 2012/12/18 Phil Steitz <ph...@gmail.com>:
>> On 12/17/12 5:55 AM, Olivier Lamy wrote:
>>> ETA of the migration:
>>> collections and lang done.
>>>
>>> results:
>>> * http://people.apache.org/~olamy/commons/lang/
>>> * http://people.apache.org/~olamy/commons/collections/
>>>
>>> As Gary suggested old javadocs are
>>> http://people.apache.org/~olamy/commons/lang/javadocs
>>>
>>> NOTE I didn't import all previous versions. Does it make sense ?
>>
>> Makes sense to me. Older javadocs can be retrieved from the archives.
>>
>> THANKS for jumping on this, Olivier!
>>
>> Other than helping getting site builds working where they may be
>> broken, what can the rest of us do to help?
> Help me a bit on other components :-).
> There are a lot to do (end of proper then sandbox then dormant.
> What I can do is to import content manually for sandbox and dormant if
> folks want to redeploy website due to code/documentation change they
> will need to fix the pom (at least that will work for the migration)
> Changes are easy to apply.
>
> What about releasing the parent ? (I don't know what is the procedure
> for that here).
>
> Something else is the size of sites due to a lot of reporting
> (cobertura, findbug, pmd, etc..) and that make svn commit very long.
> What about using sonar ? We have an instance for asf projects
> (https://analysis.apache.org). I can at least setup this for proper
> projects.
>
> WDYT ?
I have added 4 for testing (collections, cli, lang and ognl).
See result: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-proper-aggregator
I missed to explain how to configure svnpubsub for site publication.
Use last parent pom 28-SNAPSHOT
add a property to define site path:
<commons.site.path>ognl</commons.site.path>
(http://commons.apache.org/ognl)
That will commit site content to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/ognl/
Then test it :-)
mvn clean site site:stage scm-publish:publish-scm
To pass your svn authz:
-Dusername=asf id
-Dpassword=asf password
Once is done add the new path to
http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/content/resources/extpaths.txt
>
>
>>
>> Phil
>>>
>>> digester I have issues while building trunk
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
>>> (default-testCompile) on project commons-digester3-ap: Compilation
>>> failure: Compilation failure:
>>> [ERROR] error: Impossible to generate class
>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>> Attempt to recreate a file for type
>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>> [ERROR] error: Impossible to generate class
>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>>> Attempt to recreate a file for type
>>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>>> [ERROR] -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>> the -e switch.
>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>
>>> So I stop for it as no idea on WTF here
>>>
>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>>>>>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
>>>>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>>>>> I will try to work on sub projects today (it's only a matter of
>>>>> configuring parent pom normally)
>>>>> And test with deploying to
>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
>>>> I will start with digester and collections.
>>>> As I can see there is a lot of content deployed manually. I think
>>>> about versionned documentation
>>>> (http://commons.apache.org/digester/commons-digester-3.1) so this will
>>>> need to be imported manually to
>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>
>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>>>>>
>>>>>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>>>>>
>>>>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>>>>>> Olivier,
>>>>>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>>>>>> perusing your wiki link now.
>>>>>>>>>>
>>>>>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>>>>>> and website content from
>>>>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>>>>>
>>>>>>>>> I will update commons-site now to get it working for cms.
>>>>>>>>>
>>>>>>>> Done.
>>>>>>>>
>>>>>>>>> For deploying I can try make configuration easy if you accept to use
>>>>>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> Note that will need a release of your parent pom.
>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> /me listening here
>>>>>>>>>>>
>>>>>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>>>>>
>>>>>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>>>>>
>>>>>>>>>>> The source tree need some modifications: see
>>>>>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>>>>>
>>>>>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>>>>>
>>>>>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>>>>>> which is dedicated to this purpose.
>>>>>>>>>>>
>>>>>>>>>>> As I can see you are using this module
>>>>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>>>>>> for main site ?
>>>>>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>>>>>> both cms and mvn site.
>>>>>>>>>>>
>>>>>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>>>>>> this case mvn site-deploy works)
>>>>>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>>>>>> projects here ?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Olivier
>>>>>>>>>>>
>>>>>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>>>>>
>>>>>>>>>>>> br,
>>>>>>>>>>>> Matt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>>>>>> quite
>>>>>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>>>>>> we'd
>>>>>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>>>>>> doing
>>>>>>>>>>>>>> this.
>>>>>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>>>>>> are
>>>>>>>>>>>>> "built by maven".
>>>>>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>>>>>> web
>>>>>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>>>>>> components'
>>>>>>>>>>>>> sites themselves are ready).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>>>>>> using a
>>>>>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>>>>>> exposed to
>>>>>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>>>>>> CMS a
>>>>>>>>>>>>>>> la
>>>>>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>>>>>> you
>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>>>>>> Actually
>>>>>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>>>>>> guess
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>>>>>> commons-test
>>>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>>>>>> and
>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>>>>>> created a
>>>>>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>>>>>> want
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> go at
>>>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>>>>>> stale
>>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>>>>>> deal? I
>>>>>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>>>>>> releases, one
>>>>>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>>>>>> in,
>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>>>>>> svnmucc
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>>>>>> component
>>>>>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>>>>>> tree.
>>>>>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>>>>>> a
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>>>>>> just
>>>>>>>>>>>>>>> perform
>>>>>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>>>>>> production
>>>>>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Olivier Lamy
>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Olivier Lamy
>>>>>>>> Talend: http://coders.talend.com
>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/18 Phil Steitz <ph...@gmail.com>:
> On 12/17/12 5:55 AM, Olivier Lamy wrote:
>> ETA of the migration:
>> collections and lang done.
>>
>> results:
>> * http://people.apache.org/~olamy/commons/lang/
>> * http://people.apache.org/~olamy/commons/collections/
>>
>> As Gary suggested old javadocs are
>> http://people.apache.org/~olamy/commons/lang/javadocs
>>
>> NOTE I didn't import all previous versions. Does it make sense ?
>
> Makes sense to me. Older javadocs can be retrieved from the archives.
>
> THANKS for jumping on this, Olivier!
>
> Other than helping getting site builds working where they may be
> broken, what can the rest of us do to help?
Help me a bit on other components :-).
There are a lot to do (end of proper then sandbox then dormant.
What I can do is to import content manually for sandbox and dormant if
folks want to redeploy website due to code/documentation change they
will need to fix the pom (at least that will work for the migration)
Changes are easy to apply.
What about releasing the parent ? (I don't know what is the procedure
for that here).
Something else is the size of sites due to a lot of reporting
(cobertura, findbug, pmd, etc..) and that make svn commit very long.
What about using sonar ? We have an instance for asf projects
(https://analysis.apache.org). I can at least setup this for proper
projects.
WDYT ?
>
> Phil
>>
>> digester I have issues while building trunk
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
>> (default-testCompile) on project commons-digester3-ap: Compilation
>> failure: Compilation failure:
>> [ERROR] error: Impossible to generate class
>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>> Attempt to recreate a file for type
>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>> [ERROR] error: Impossible to generate class
>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
>> Attempt to recreate a file for type
>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
>> [ERROR] -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>
>> So I stop for it as no idea on WTF here
>>
>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>>>>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
>>>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>>>> I will try to work on sub projects today (it's only a matter of
>>>> configuring parent pom normally)
>>>> And test with deploying to
>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
>>> I will start with digester and collections.
>>> As I can see there is a lot of content deployed manually. I think
>>> about versionned documentation
>>> (http://commons.apache.org/digester/commons-digester-3.1) so this will
>>> need to be imported manually to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>
>>>>
>>>>> Ralph
>>>>>
>>>>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>>>>
>>>>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>>>>
>>>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>>>>> Olivier,
>>>>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>>>>> perusing your wiki link now.
>>>>>>>>>
>>>>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>>>>> and website content from
>>>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>>>>
>>>>>>>> I will update commons-site now to get it working for cms.
>>>>>>>>
>>>>>>> Done.
>>>>>>>
>>>>>>>> For deploying I can try make configuration easy if you accept to use
>>>>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>>>>> ).
>>>>>>>>
>>>>>>>> Note that will need a release of your parent pom.
>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> /me listening here
>>>>>>>>>>
>>>>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>>>>
>>>>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>>>>
>>>>>>>>>> The source tree need some modifications: see
>>>>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>>>>
>>>>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>>>>
>>>>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>>>>> which is dedicated to this purpose.
>>>>>>>>>>
>>>>>>>>>> As I can see you are using this module
>>>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>>>>> for main site ?
>>>>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>>>>> both cms and mvn site.
>>>>>>>>>>
>>>>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>>>>> this case mvn site-deploy works)
>>>>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>>>>> projects here ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Olivier
>>>>>>>>>>
>>>>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>>>>
>>>>>>>>>>> br,
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>>>>> quite
>>>>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>>>>> we'd
>>>>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>>>>> doing
>>>>>>>>>>>>> this.
>>>>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>>>>> are
>>>>>>>>>>>> "built by maven".
>>>>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>>>>> web
>>>>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>>>>> components'
>>>>>>>>>>>> sites themselves are ready).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Gilles
>>>>>>>>>>>>
>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>>>>> using a
>>>>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>>>>> exposed to
>>>>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>>>>> CMS a
>>>>>>>>>>>>>> la
>>>>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>>>>> you
>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>>>>> Actually
>>>>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>>>>> guess
>>>>>>>>>>>> we
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>>>>> commons-test
>>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>>>>> able to
>>>>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>>>>> and
>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>>>>> created a
>>>>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>>>>> want
>>>>>>>>>>>> to
>>>>>>>>>>>>>> go at
>>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>>>>> stale
>>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>>>>> deal? I
>>>>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>>>>> which
>>>>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>>>>> then
>>>>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>>>>> releases, one
>>>>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>>>>> in,
>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>>>>> svnmucc
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>>>>> component
>>>>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>>>>> tree.
>>>>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>>>>> a
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>>>>> just
>>>>>>>>>>>>>> perform
>>>>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>>>>> production
>>>>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Olivier Lamy
>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Olivier Lamy
>>>>>>>> Talend: http://coders.talend.com
>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Olivier Lamy
>>>>>>> Talend: http://coders.talend.com
>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/17/12 5:55 AM, Olivier Lamy wrote:
> ETA of the migration:
> collections and lang done.
>
> results:
> * http://people.apache.org/~olamy/commons/lang/
> * http://people.apache.org/~olamy/commons/collections/
>
> As Gary suggested old javadocs are
> http://people.apache.org/~olamy/commons/lang/javadocs
>
> NOTE I didn't import all previous versions. Does it make sense ?
Makes sense to me. Older javadocs can be retrieved from the archives.
THANKS for jumping on this, Olivier!
Other than helping getting site builds working where they may be
broken, what can the rest of us do to help?
Phil
>
> digester I have issues while building trunk
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
> (default-testCompile) on project commons-digester3-ap: Compilation
> failure: Compilation failure:
> [ERROR] error: Impossible to generate class
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
> Attempt to recreate a file for type
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
> [ERROR] error: Impossible to generate class
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
> Attempt to recreate a file for type
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> So I stop for it as no idea on WTF here
>
> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>>>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
>>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>>> I will try to work on sub projects today (it's only a matter of
>>> configuring parent pom normally)
>>> And test with deploying to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
>> I will start with digester and collections.
>> As I can see there is a lot of content deployed manually. I think
>> about versionned documentation
>> (http://commons.apache.org/digester/commons-digester-3.1) so this will
>> need to be imported manually to
>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>
>>>
>>>> Ralph
>>>>
>>>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>>>
>>>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>>>
>>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>>>> Olivier,
>>>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>>>> perusing your wiki link now.
>>>>>>>>
>>>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>>>> and website content from
>>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>>>
>>>>>>> I will update commons-site now to get it working for cms.
>>>>>>>
>>>>>> Done.
>>>>>>
>>>>>>> For deploying I can try make configuration easy if you accept to use
>>>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>>>> ).
>>>>>>>
>>>>>>> Note that will need a release of your parent pom.
>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> /me listening here
>>>>>>>>>
>>>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>>>
>>>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>>>
>>>>>>>>> The source tree need some modifications: see
>>>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>>>
>>>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>>>
>>>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>>>> which is dedicated to this purpose.
>>>>>>>>>
>>>>>>>>> As I can see you are using this module
>>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>>>> for main site ?
>>>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>>>> both cms and mvn site.
>>>>>>>>>
>>>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>>>> this case mvn site-deploy works)
>>>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>>>> projects here ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Olivier
>>>>>>>>>
>>>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>>>
>>>>>>>>>> br,
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>>>> quite
>>>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>>>> we'd
>>>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>>>> doing
>>>>>>>>>>>> this.
>>>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>>>> are
>>>>>>>>>>> "built by maven".
>>>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>>>> web
>>>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>>>> components'
>>>>>>>>>>> sites themselves are ready).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gilles
>>>>>>>>>>>
>>>>>>>>>>>> Matt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>>>> using a
>>>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>>>> exposed to
>>>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>>>> CMS a
>>>>>>>>>>>>> la
>>>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>>>> you
>>>>>>>>>>>>> follow
>>>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>>>> Actually
>>>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>>>> guess
>>>>>>>>>>> we
>>>>>>>>>>>>> can
>>>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>>>> commons-test
>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>>>> able to
>>>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>>>> the
>>>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>>>> and
>>>>>>>>>>> then
>>>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>>>> created a
>>>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>>>> want
>>>>>>>>>>> to
>>>>>>>>>>>>> go at
>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>>>> stale
>>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>>>> deal? I
>>>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>>>> which
>>>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>>>> then
>>>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>>>> releases, one
>>>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>>>> in,
>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>>>> svnmucc
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>>>> component
>>>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>>>> tree.
>>>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>>>> a
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>>>> just
>>>>>>>>>>>>> perform
>>>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>>>> production
>>>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Olivier Lamy
>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Olivier Lamy
>>>>>>> Talend: http://coders.talend.com
>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/15 Ralph Goers <ra...@dslextreme.com>:
> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>
Nope I propose to use both. very similar as flume, maven (maybe others).
Top site build with cms
subsites published manually.
But this need to add a lot of paths in extpaths.txt file as publishing
tru cms will be very very very long due to the number of path.
A solution is to generate subsite content to a dedicated svn path:
http://svn.apache.org/repos/asf/commons/cms-site/trunk/proper/ (or other name)
and add some redirect in .htaccess commons.a.o/io -> commons.a.o/proper/io
same for sandbox
makes sense ?
> Ralph
>
> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>
>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>> Olivier,
>>>> Thanks for your response and offer to contribute! We do have a few
>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>> intended to take [functor] multimodule before a release is made. I'm
>>>> perusing your wiki link now.
>>>>
>>>
>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>> and website content from
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>
>>> I will update commons-site now to get it working for cms.
>>>
>>
>> Done.
>>
>>> For deploying I can try make configuration easy if you accept to use
>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>> ).
>>>
>>> Note that will need a release of your parent pom.
>>>
>>>> Matt
>>>>
>>>>
>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>
>>>>> /me listening here
>>>>>
>>>>> Note maven.apache.org has been migrated this week.
>>>>>
>>>>> If you want to mix cms and maven site generation, we do that.
>>>>> Note: even the main site is generated with a maven build but we can
>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>
>>>>> The source tree need some modifications: see
>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>
>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>> do a bit of pom.xml stuff :-) )
>>>>>
>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>> which is dedicated to this purpose.
>>>>>
>>>>> As I can see you are using this module
>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>> for main site ?
>>>>> If you want I can do the necessary changes to make it working with
>>>>> both cms and mvn site.
>>>>>
>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>> this case mvn site-deploy works)
>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>> projects here ?
>>>>>
>>>>> --
>>>>> Olivier
>>>>>
>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>> I never questioned that the individual components would most likely
>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>> to bother laying out the main site when we have something that works.
>>>>>>
>>>>>> br,
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>> quite
>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>> we'd
>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>> doing
>>>>>>>> this.
>>>>>>>
>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>> are
>>>>>>> "built by maven".
>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>> web
>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>> button would point to the corresponding legacy site (until the
>>>>> components'
>>>>>>> sites themselves are ready).
>>>>>>>
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>> using a
>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>> exposed to
>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>> CMS a
>>>>>>>>> la
>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>> you
>>>>>>>>> follow
>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>> Actually
>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>> guess
>>>>>>> we
>>>>>>>>> can
>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>
>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>> commons-test
>>>>>>>>>>> site.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>> phil.steitz@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>> able to
>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>> the
>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>> and
>>>>>>> then
>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>> created a
>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>> want
>>>>>>> to
>>>>>>>>> go at
>>>>>>>>>>> all.
>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>> locally,
>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>> stale
>>>>>>>>> files
>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>
>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>> deal? I
>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>> which
>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>> then
>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>> existing
>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>> releases, one
>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>> in,
>>>>>>> it
>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>> where
>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>> svnmucc
>>>>>>>>> to
>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>> component
>>>>>>>>> subtree
>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>> when
>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>> tree.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>> a
>>>>>>>>> release
>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>> just
>>>>>>>>> perform
>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>> production
>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
ETA of the migration:
collections and lang done.
results:
* http://people.apache.org/~olamy/commons/lang/
* http://people.apache.org/~olamy/commons/collections/
As Gary suggested old javadocs are
http://people.apache.org/~olamy/commons/lang/javadocs
NOTE I didn't import all previous versions. Does it make sense ?
digester I have issues while building trunk
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
(default-testCompile) on project commons-digester3-ap: Compilation
failure: Compilation failure:
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
So I stop for it as no idea on WTF here
2012/12/15 Olivier Lamy <ol...@apache.org>:
> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
>> I started with main site and as I'm in eu I wanted to sleep a bit :-).
>> I will try to work on sub projects today (it's only a matter of
>> configuring parent pom normally)
>> And test with deploying to
>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
> I will start with digester and collections.
> As I can see there is a lot of content deployed manually. I think
> about versionned documentation
> (http://commons.apache.org/digester/commons-digester-3.1) so this will
> need to be imported manually to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>
>>
>>
>>>
>>> Ralph
>>>
>>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>>
>>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>>
>>>> Ralph
>>>>
>>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>>
>>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>>> Olivier,
>>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>>> perusing your wiki link now.
>>>>>>>
>>>>>>
>>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>>> and website content from
>>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>>
>>>>>> I will update commons-site now to get it working for cms.
>>>>>>
>>>>>
>>>>> Done.
>>>>>
>>>>>> For deploying I can try make configuration easy if you accept to use
>>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>>> ).
>>>>>>
>>>>>> Note that will need a release of your parent pom.
>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>>
>>>>>>>> /me listening here
>>>>>>>>
>>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>>
>>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>>
>>>>>>>> The source tree need some modifications: see
>>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>>
>>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>>
>>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>>> which is dedicated to this purpose.
>>>>>>>>
>>>>>>>> As I can see you are using this module
>>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>>> for main site ?
>>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>>> both cms and mvn site.
>>>>>>>>
>>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>>> this case mvn site-deploy works)
>>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>>> projects here ?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Olivier
>>>>>>>>
>>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>>
>>>>>>>>> br,
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>>> quite
>>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>>> we'd
>>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>>> doing
>>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>>> are
>>>>>>>>>> "built by maven".
>>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>>> web
>>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>>> components'
>>>>>>>>>> sites themselves are ready).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gilles
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>>> using a
>>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>>> exposed to
>>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>>> CMS a
>>>>>>>>>>>> la
>>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>>> you
>>>>>>>>>>>> follow
>>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>>> Actually
>>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>>> guess
>>>>>>>>>> we
>>>>>>>>>>>> can
>>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>>
>>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Gilles
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>>> commons-test
>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>>> able to
>>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>>> the
>>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>>> and
>>>>>>>>>> then
>>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>>> created a
>>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>>> want
>>>>>>>>>> to
>>>>>>>>>>>> go at
>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>>> stale
>>>>>>>>>>>> files
>>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>>> deal? I
>>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>>> which
>>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>>> then
>>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>>> existing
>>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>>> releases, one
>>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>>> in,
>>>>>>>>>> it
>>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>>> where
>>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>>> svnmucc
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>>> component
>>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>>> when
>>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>>> tree.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>>> a
>>>>>>>>>>>> release
>>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>>> just
>>>>>>>>>>>> perform
>>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>>> production
>>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Olivier Lamy
>>>>>>>> Talend: http://coders.talend.com
>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/15 Olivier Lamy <ol...@apache.org>:
> 2012/12/15 Ralph Goers <ra...@dslextreme.com>:
>> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
> I started with main site and as I'm in eu I wanted to sleep a bit :-).
> I will try to work on sub projects today (it's only a matter of
> configuring parent pom normally)
> And test with deploying to
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
I will start with digester and collections.
As I can see there is a lot of content deployed manually. I think
about versionned documentation
(http://commons.apache.org/digester/commons-digester-3.1) so this will
need to be imported manually to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/
>
>
>>
>> Ralph
>>
>> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>>
>>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>>
>>> Ralph
>>>
>>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>>
>>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>>> Olivier,
>>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>>> perusing your wiki link now.
>>>>>>
>>>>>
>>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>>> and website content from
>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>>
>>>>> I will update commons-site now to get it working for cms.
>>>>>
>>>>
>>>> Done.
>>>>
>>>>> For deploying I can try make configuration easy if you accept to use
>>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>>> ).
>>>>>
>>>>> Note that will need a release of your parent pom.
>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>>
>>>>>>> /me listening here
>>>>>>>
>>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>>
>>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>>
>>>>>>> The source tree need some modifications: see
>>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>>
>>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>>
>>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>>> which is dedicated to this purpose.
>>>>>>>
>>>>>>> As I can see you are using this module
>>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>>> for main site ?
>>>>>>> If you want I can do the necessary changes to make it working with
>>>>>>> both cms and mvn site.
>>>>>>>
>>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>>> this case mvn site-deploy works)
>>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>>> projects here ?
>>>>>>>
>>>>>>> --
>>>>>>> Olivier
>>>>>>>
>>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>>> I never questioned that the individual components would most likely
>>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>>
>>>>>>>> br,
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>>> quite
>>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>>> we'd
>>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>>> doing
>>>>>>>>>> this.
>>>>>>>>>
>>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>>> are
>>>>>>>>> "built by maven".
>>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>>> web
>>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>>> components'
>>>>>>>>> sites themselves are ready).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>>> using a
>>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>>> exposed to
>>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>>> CMS a
>>>>>>>>>>> la
>>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>>> you
>>>>>>>>>>> follow
>>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>>> Actually
>>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>>> guess
>>>>>>>>> we
>>>>>>>>>>> can
>>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>>
>>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Gilles
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Matt
>>>>>>>>>>>>
>>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>>> commons-test
>>>>>>>>>>>>> site.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>>> phil.steitz@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>>> able to
>>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>>> the
>>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>>> and
>>>>>>>>> then
>>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>>> created a
>>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>>> want
>>>>>>>>> to
>>>>>>>>>>> go at
>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>>> locally,
>>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>>> stale
>>>>>>>>>>> files
>>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>>> deal? I
>>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>>> which
>>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>>> then
>>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>>> existing
>>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>>> releases, one
>>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>>> in,
>>>>>>>>> it
>>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>>> where
>>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>>> svnmucc
>>>>>>>>>>> to
>>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>>> component
>>>>>>>>>>> subtree
>>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>>> when
>>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>>> tree.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>>> a
>>>>>>>>>>> release
>>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>>> just
>>>>>>>>>>> perform
>>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>>> production
>>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Olivier Lamy
>>>>>>> Talend: http://coders.talend.com
>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/15 Ralph Goers <ra...@dslextreme.com>:
> And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
I started with main site and as I'm in eu I wanted to sleep a bit :-).
I will try to work on sub projects today (it's only a matter of
configuring parent pom normally)
And test with deploying to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
>
> Ralph
>
> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>
>> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>>
>> Ralph
>>
>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>
>>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>>> Olivier,
>>>>> Thanks for your response and offer to contribute! We do have a few
>>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>> intended to take [functor] multimodule before a release is made. I'm
>>>>> perusing your wiki link now.
>>>>>
>>>>
>>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>>> and website content from
>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>
>>>> I will update commons-site now to get it working for cms.
>>>>
>>>
>>> Done.
>>>
>>>> For deploying I can try make configuration easy if you accept to use
>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>> ).
>>>>
>>>> Note that will need a release of your parent pom.
>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>>
>>>>>> /me listening here
>>>>>>
>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>
>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>
>>>>>> The source tree need some modifications: see
>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>
>>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>
>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>> which is dedicated to this purpose.
>>>>>>
>>>>>> As I can see you are using this module
>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>> for main site ?
>>>>>> If you want I can do the necessary changes to make it working with
>>>>>> both cms and mvn site.
>>>>>>
>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>> this case mvn site-deploy works)
>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>> projects here ?
>>>>>>
>>>>>> --
>>>>>> Olivier
>>>>>>
>>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>>> I never questioned that the individual components would most likely
>>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>>> to bother laying out the main site when we have something that works.
>>>>>>>
>>>>>>> br,
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>>> quite
>>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>>> we'd
>>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>>> doing
>>>>>>>>> this.
>>>>>>>>
>>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>>> are
>>>>>>>> "built by maven".
>>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>>> web
>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>>> button would point to the corresponding legacy site (until the
>>>>>> components'
>>>>>>>> sites themselves are ready).
>>>>>>>>
>>>>>>>>
>>>>>>>> Gilles
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>
>>>>>>>>>> Hi.
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>>> using a
>>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>>> exposed to
>>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>>> CMS a
>>>>>>>>>> la
>>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>>> you
>>>>>>>>>> follow
>>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>>> Actually
>>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>>> guess
>>>>>>>> we
>>>>>>>>>> can
>>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>>
>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Gilles
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>>> commons-test
>>>>>>>>>>>> site.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>>> phil.steitz@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>>> able to
>>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>>> the
>>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>>> and
>>>>>>>> then
>>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>>> created a
>>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>>> want
>>>>>>>> to
>>>>>>>>>> go at
>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>>> locally,
>>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>>> stale
>>>>>>>>>> files
>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>>> deal? I
>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>>> which
>>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>>> then
>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>>> existing
>>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>>> releases, one
>>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>>> in,
>>>>>>>> it
>>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>>> where
>>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>>> svnmucc
>>>>>>>>>> to
>>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>>> component
>>>>>>>>>> subtree
>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>>> when
>>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>>> tree.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>>> a
>>>>>>>>>> release
>>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>>> just
>>>>>>>>>> perform
>>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>>> production
>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
Ralph
On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
> So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
>
> Ralph
>
> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>
>> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>>> Olivier,
>>>> Thanks for your response and offer to contribute! We do have a few
>>>> multi-module components here. Of "proper" components, there is only [jci]
>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>> intended to take [functor] multimodule before a release is made. I'm
>>>> perusing your wiki link now.
>>>>
>>>
>>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>>> and website content from
>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>
>>> I will update commons-site now to get it working for cms.
>>>
>>
>> Done.
>>
>>> For deploying I can try make configuration easy if you accept to use
>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>> ).
>>>
>>> Note that will need a release of your parent pom.
>>>
>>>> Matt
>>>>
>>>>
>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>>
>>>>> /me listening here
>>>>>
>>>>> Note maven.apache.org has been migrated this week.
>>>>>
>>>>> If you want to mix cms and maven site generation, we do that.
>>>>> Note: even the main site is generated with a maven build but we can
>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>
>>>>> The source tree need some modifications: see
>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>
>>>>> Let me know if you need some help (I think I have karma here so I can
>>>>> do a bit of pom.xml stuff :-) )
>>>>>
>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>> which is dedicated to this purpose.
>>>>>
>>>>> As I can see you are using this module
>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>> for main site ?
>>>>> If you want I can do the necessary changes to make it working with
>>>>> both cms and mvn site.
>>>>>
>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>> this case mvn site-deploy works)
>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>> projects here ?
>>>>>
>>>>> --
>>>>> Olivier
>>>>>
>>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>>> I never questioned that the individual components would most likely
>>>>>> continue with the Maven-generated content. I do question whether we want
>>>>>> to bother laying out the main site when we have something that works.
>>>>>>
>>>>>> br,
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>>> quite
>>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>>> we'd
>>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>>> doing
>>>>>>>> this.
>>>>>>>
>>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>>> are
>>>>>>> "built by maven".
>>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>>> web
>>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>>> button would point to the corresponding legacy site (until the
>>>>> components'
>>>>>>> sites themselves are ready).
>>>>>>>
>>>>>>>
>>>>>>> Gilles
>>>>>>>
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>>> using a
>>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>>> exposed to
>>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>>> CMS a
>>>>>>>>> la
>>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>>> you
>>>>>>>>> follow
>>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>>> Actually
>>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>>> guess
>>>>>>> we
>>>>>>>>> can
>>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>>
>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>>> commons-test
>>>>>>>>>>> site.
>>>>>>>>>>>
>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>>> phil.steitz@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>>> able to
>>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>>> the
>>>>>>>>>>> process of updating the site would require first doing a diff
>>>>> and
>>>>>>> then
>>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>>> created a
>>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>>> want
>>>>>>> to
>>>>>>>>> go at
>>>>>>>>>>> all.
>>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>>> locally,
>>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>>> stale
>>>>>>>>> files
>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>
>>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>>> deal? I
>>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>>> which
>>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>>> then
>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>>> existing
>>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>>> releases, one
>>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>>> in,
>>>>>>> it
>>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>>> where
>>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>>> svnmucc
>>>>>>>>> to
>>>>>>>>>>>>>> replace the live component subtree with the staging
>>>>> component
>>>>>>>>> subtree
>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>>> when
>>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>>> tree.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>>> a
>>>>>>>>> release
>>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>>> just
>>>>>>>>> perform
>>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>>> production
>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
So now I'm confused. You are proposing to bypass the CMS altogether and only publish to the live site. Why? Even projects like Flume that use maven for the site build still do it in the CMS.
Ralph
On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
> 2012/12/15 Olivier Lamy <ol...@apache.org>:
>> 2012/12/15 Matt Benson <gu...@gmail.com>:
>>> Olivier,
>>> Thanks for your response and offer to contribute! We do have a few
>>> multi-module components here. Of "proper" components, there is only [jci]
>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>> intended to take [functor] multimodule before a release is made. I'm
>>> perusing your wiki link now.
>>>
>>
>> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
>> and website content from
>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>
>> I will update commons-site now to get it working for cms.
>>
>
> Done.
>
>> For deploying I can try make configuration easy if you accept to use
>> something like: mvn site site:stage scm-publish:publish-scm rather
>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>> ).
>>
>> Note that will need a release of your parent pom.
>>
>>> Matt
>>>
>>>
>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>> /me listening here
>>>>
>>>> Note maven.apache.org has been migrated this week.
>>>>
>>>> If you want to mix cms and maven site generation, we do that.
>>>> Note: even the main site is generated with a maven build but we can
>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>
>>>> The source tree need some modifications: see
>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>
>>>> Let me know if you need some help (I think I have karma here so I can
>>>> do a bit of pom.xml stuff :-) )
>>>>
>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>> which is dedicated to this purpose.
>>>>
>>>> As I can see you are using this module
>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>> for main site ?
>>>> If you want I can do the necessary changes to make it working with
>>>> both cms and mvn site.
>>>>
>>>> For sub projects, that's easy if all are mono modules projects (in
>>>> this case mvn site-deploy works)
>>>> For multi modules, it's a bit different. Is there any multi modules
>>>> projects here ?
>>>>
>>>> --
>>>> Olivier
>>>>
>>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>>>> I never questioned that the individual components would most likely
>>>>> continue with the Maven-generated content. I do question whether we want
>>>>> to bother laying out the main site when we have something that works.
>>>>>
>>>>> br,
>>>>> Matt
>>>>>
>>>>>
>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>
>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>> I've just added the directory to our svn tree so that there would be
>>>>>>> someplace at which to point it. I think the next step is to determine
>>>>>>> whether we want a "normal" CMS site like Logging has, in which case we
>>>>>>> could prop something up with e.g. Twitter bootstrap as is becoming
>>>> quite
>>>>>>> popular among ASF TLPs. If we like to keep a Maven-generated look,
>>>> we'd
>>>>>>> probably be best advised to consult the Maven folks on how they're
>>>> doing
>>>>>>> this.
>>>>>>
>>>>>> If I interpret correctly what I see, the "logging" site has both: The
>>>>>> top-level site is "powered by Twitter Bootstrap" while the "components"
>>>> are
>>>>>> "built by maven".
>>>>>> That looks like a nice starting point. I.e. we should have the top-level
>>>>>> web
>>>>>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>>>>> button would point to the corresponding legacy site (until the
>>>> components'
>>>>>> sites themselves are ready).
>>>>>>
>>>>>>
>>>>>> Gilles
>>>>>>
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>>>>>>>> I've been talking to Joe S. on #asfinfra about this; rather than
>>>>>> using a
>>>>>>>>> test site infra would prefer we request the CMS site, just not
>>>>>> exposed to
>>>>>>>>> commons.a.o until we're satisfied with it. Do we want to use the
>>>>>> CMS a
>>>>>>>> la
>>>>>>>>> Apache Logging, or do we want to explore keeping the main site
>>>>>>>>> Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>>> you
>>>>>>>> follow
>>>>>>>>> Commons MLs?) may be able to help us if we want to go that way.
>>>>>> Actually
>>>>>>>>> Maven still seems to be using the CMS at some level [1], so I
>>>> guess
>>>>>> we
>>>>>>>> can
>>>>>>>>> just request the CMS site and go from there. Issue created. [2]
>>>>>>>>
>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Gilles
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>
>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>>>>> ralph.goers@dslextreme.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> At the very least, someone should file a Jira asking for a
>>>>>> commons-test
>>>>>>>>>> site.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>>>>>>>>>
>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 10 December 2012 21:53, Phil Steitz <
>>>> phil.steitz@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>>>>>>>>>>>> Yes, I think you are missing something fundamental.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you check in "the whole mess" you will never again be
>>>>>> able to
>>>>>>>>>> properly build a sub-project's site with Maven. This is because
>>>>>> the
>>>>>>>>>> process of updating the site would require first doing a diff
>>>> and
>>>>>> then
>>>>>>>>>> deleting items that are not included in the new version. Someone
>>>>>>>> created a
>>>>>>>>>> Maven plugin to try to do this but it is not the way I would
>>>> want
>>>>>> to
>>>>>>>> go at
>>>>>>>>>> all.
>>>>>>>>>>>>>> Sorry, I don't get it. Why won't the following work:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>> 1) check all of that into an svn repo
>>>>>>>>>>>>>> 2) when I want to update, say, math, I generate the content
>>>>>>>> locally,
>>>>>>>>>>>>>> copy it to the /math subtree and check it in.
>>>>>>>>>>>>> There would need to be some extra work done to ensure that
>>>>>> stale
>>>>>>>> files
>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>
>>>>>>>>>>> I get it now. In practice, with maven sites, is this a big
>>>>>> deal? I
>>>>>>>>>>> don't remember seeing lots of cruft accumulating on p.a.o,
>>>> which
>>>>>>>>>>> would happen if this were common. If it is not that common,
>>>> then
>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>>>
>>>>>>>>>>>>> For some projects, it would be possible to just delete the
>>>>>> existing
>>>>>>>>>>>>> sub-tree and check the whole new site in.
>>>>>>>>>>>>> [This can be done as one transaction in svnmucc]
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, for sites that retain Javadoc etc. for older
>>>>>> releases, one
>>>>>>>>>>>>> would need to re-instate that part of the tree somehow.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Given that svnpubsub immediately publishes what is checked
>>>> in,
>>>>>> it
>>>>>>>>>>>>> might be sensible to have a parallel staging directory tree
>>>>>> where
>>>>>>>>>>>>> files can be updated piecemeal if necessary, and then use
>>>>>> svnmucc
>>>>>>>> to
>>>>>>>>>>>>> replace the live component subtree with the staging
>>>> component
>>>>>>>> subtree
>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There would need to be some co-ordination between committers
>>>>>> when
>>>>>>>>>>>>> updating commons parent, as that would affect the whole
>>>> tree.
>>>>>>>>>>>>>
>>>>>>>>>>>> Yes. This is why Logging used the extpath approach where each
>>>>>>>>>> subproject commits directly to production. Each release goes to
>>>> a
>>>>>>>> release
>>>>>>>>>> subdirectory under each subproject's directory. Then you can
>>>> just
>>>>>>>> perform
>>>>>>>>>> your maven site build to a local directory, copy that into the
>>>>>>>> production
>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>
>>>>>>>>>>>> See "Managing the subproject sites" at
>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/15 Olivier Lamy <ol...@apache.org>:
> 2012/12/15 Matt Benson <gu...@gmail.com>:
>> Olivier,
>> Thanks for your response and offer to contribute! We do have a few
>> multi-module components here. Of "proper" components, there is only [jci]
>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>> intended to take [functor] multimodule before a release is made. I'm
>> perusing your wiki link now.
>>
>
> Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
> and website content from
> https://svn.apache.org/repos/infra/websites/production/commons/content/
>
> I will update commons-site now to get it working for cms.
>
Done.
> For deploying I can try make configuration easy if you accept to use
> something like: mvn site site:stage scm-publish:publish-scm rather
> than mvn site-deploy (btw that won't be possible for multi modules :-)
> ).
>
> Note that will need a release of your parent pom.
>
>> Matt
>>
>>
>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> /me listening here
>>>
>>> Note maven.apache.org has been migrated this week.
>>>
>>> If you want to mix cms and maven site generation, we do that.
>>> Note: even the main site is generated with a maven build but we can
>>> edit files (apt/xdoc/markdown) with the cms editor
>>>
>>> The source tree need some modifications: see
>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>
>>> Let me know if you need some help (I think I have karma here so I can
>>> do a bit of pom.xml stuff :-) )
>>>
>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>> which is dedicated to this purpose.
>>>
>>> As I can see you are using this module
>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>> for main site ?
>>> If you want I can do the necessary changes to make it working with
>>> both cms and mvn site.
>>>
>>> For sub projects, that's easy if all are mono modules projects (in
>>> this case mvn site-deploy works)
>>> For multi modules, it's a bit different. Is there any multi modules
>>> projects here ?
>>>
>>> --
>>> Olivier
>>>
>>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>>> > I never questioned that the individual components would most likely
>>> > continue with the Maven-generated content. I do question whether we want
>>> > to bother laying out the main site when we have something that works.
>>> >
>>> > br,
>>> > Matt
>>> >
>>> >
>>> > On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>> > gilles@harfang.homelinux.org> wrote:
>>> >
>>> >> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>> >> > I've just added the directory to our svn tree so that there would be
>>> >> > someplace at which to point it. I think the next step is to determine
>>> >> > whether we want a "normal" CMS site like Logging has, in which case we
>>> >> > could prop something up with e.g. Twitter bootstrap as is becoming
>>> quite
>>> >> > popular among ASF TLPs. If we like to keep a Maven-generated look,
>>> we'd
>>> >> > probably be best advised to consult the Maven folks on how they're
>>> doing
>>> >> > this.
>>> >>
>>> >> If I interpret correctly what I see, the "logging" site has both: The
>>> >> top-level site is "powered by Twitter Bootstrap" while the "components"
>>> are
>>> >> "built by maven".
>>> >> That looks like a nice starting point. I.e. we should have the top-level
>>> >> web
>>> >> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>>> >> button would point to the corresponding legacy site (until the
>>> components'
>>> >> sites themselves are ready).
>>> >>
>>> >>
>>> >> Gilles
>>> >>
>>> >> >
>>> >> > Matt
>>> >> >
>>> >> >
>>> >> > On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>> >> > gilles@harfang.homelinux.org> wrote:
>>> >> >
>>> >> > > Hi.
>>> >> > >
>>> >> > > On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>>> >> > > > I've been talking to Joe S. on #asfinfra about this; rather than
>>> >> using a
>>> >> > > > test site infra would prefer we request the CMS site, just not
>>> >> exposed to
>>> >> > > > commons.a.o until we're satisfied with it. Do we want to use the
>>> >> CMS a
>>> >> > > la
>>> >> > > > Apache Logging, or do we want to explore keeping the main site
>>> >> > > > Maven-generated? The Maven guys, particularly Olivier Lamy (do
>>> you
>>> >> > > follow
>>> >> > > > Commons MLs?) may be able to help us if we want to go that way.
>>> >> Actually
>>> >> > > > Maven still seems to be using the CMS at some level [1], so I
>>> guess
>>> >> we
>>> >> > > can
>>> >> > > > just request the CMS site and go from there. Issue created. [2]
>>> >> > >
>>> >> > > Is the new (empty, I guess) cms-web site accessible?
>>> >> > >
>>> >> > > Regards,
>>> >> > > Gilles
>>> >> > >
>>> >> > > >
>>> >> > > > Matt
>>> >> > > >
>>> >> > > > [1] http://maventest.apache.org
>>> >> > > > [2] https://issues.apache.org/jira/browse/INFRA-5657
>>> >> > > >
>>> >> > > > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>>> >> ralph.goers@dslextreme.com
>>> >> > > >wrote:
>>> >> > > >
>>> >> > > > > At the very least, someone should file a Jira asking for a
>>> >> commons-test
>>> >> > > > > site.
>>> >> > > > >
>>> >> > > > > Ralph
>>> >> > > > >
>>> >> > > > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>>> >> > > > >
>>> >> > > > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
>>> >> > > > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>> >> > > > > >>
>>> >> > > > > >>> On 10 December 2012 21:53, Phil Steitz <
>>> phil.steitz@gmail.com>
>>> >> > > wrote:
>>> >> > > > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>> >> > > > > >>>>> Yes, I think you are missing something fundamental.
>>> >> > > > > >>>>>
>>> >> > > > > >>>>> If you check in "the whole mess" you will never again be
>>> >> able to
>>> >> > > > > properly build a sub-project's site with Maven. This is because
>>> >> the
>>> >> > > > > process of updating the site would require first doing a diff
>>> and
>>> >> then
>>> >> > > > > deleting items that are not included in the new version. Someone
>>> >> > > created a
>>> >> > > > > Maven plugin to try to do this but it is not the way I would
>>> want
>>> >> to
>>> >> > > go at
>>> >> > > > > all.
>>> >> > > > > >>>> Sorry, I don't get it. Why won't the following work:
>>> >> > > > > >>>>
>>> >> > > > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>> >> > > > > >>>> 1) check all of that into an svn repo
>>> >> > > > > >>>> 2) when I want to update, say, math, I generate the content
>>> >> > > locally,
>>> >> > > > > >>>> copy it to the /math subtree and check it in.
>>> >> > > > > >>> There would need to be some extra work done to ensure that
>>> >> stale
>>> >> > > files
>>> >> > > > > >>> are deleted.
>>> >> > > > > >
>>> >> > > > > > I get it now. In practice, with maven sites, is this a big
>>> >> deal? I
>>> >> > > > > > don't remember seeing lots of cruft accumulating on p.a.o,
>>> which
>>> >> > > > > > would happen if this were common. If it is not that common,
>>> then
>>> >> > > > > > manual svn rm's would not be that onerous.
>>> >> > > > > >
>>> >> > > > > > Phil
>>> >> > > > > >>>
>>> >> > > > > >>> For some projects, it would be possible to just delete the
>>> >> existing
>>> >> > > > > >>> sub-tree and check the whole new site in.
>>> >> > > > > >>> [This can be done as one transaction in svnmucc]
>>> >> > > > > >>>
>>> >> > > > > >>> However, for sites that retain Javadoc etc. for older
>>> >> releases, one
>>> >> > > > > >>> would need to re-instate that part of the tree somehow.
>>> >> > > > > >>>
>>> >> > > > > >>> Given that svnpubsub immediately publishes what is checked
>>> in,
>>> >> it
>>> >> > > > > >>> might be sensible to have a parallel staging directory tree
>>> >> where
>>> >> > > > > >>> files can be updated piecemeal if necessary, and then use
>>> >> svnmucc
>>> >> > > to
>>> >> > > > > >>> replace the live component subtree with the staging
>>> component
>>> >> > > subtree
>>> >> > > > > >>> as part of a single transaction.
>>> >> > > > > >>>
>>> >> > > > > >>> There would need to be some co-ordination between committers
>>> >> when
>>> >> > > > > >>> updating commons parent, as that would affect the whole
>>> tree.
>>> >> > > > > >>>
>>> >> > > > > >> Yes. This is why Logging used the extpath approach where each
>>> >> > > > > subproject commits directly to production. Each release goes to
>>> a
>>> >> > > release
>>> >> > > > > subdirectory under each subproject's directory. Then you can
>>> just
>>> >> > > perform
>>> >> > > > > your maven site build to a local directory, copy that into the
>>> >> > > production
>>> >> > > > > svn location, and commit it.
>>> >> > > > > >>
>>> >> > > > > >> See "Managing the subproject sites" at
>>> >> > > > > http://wiki.apache.org/logging/ManagingTheWebSite
>>> >> > > > > >>
>>> >> > > > > >> Ralph
>>> >> > > > > >
>>> >> > > > > >
>>> >> > > > > >
>>> >> ---------------------------------------------------------------------
>>> >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>>> >> > > > > >
>>> >> > > > >
>>> >> > > > >
>>> >> > > > >
>>> >> ---------------------------------------------------------------------
>>> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> > > > > For additional commands, e-mail: dev-help@commons.apache.org
>>> >> > > > >
>>> >> > > > >
>>> >> > >
>>> >> > >
>>> ---------------------------------------------------------------------
>>> >> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> > > For additional commands, e-mail: dev-help@commons.apache.org
>>> >> > >
>>> >> > >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/15 Matt Benson <gu...@gmail.com>:
> Olivier,
> Thanks for your response and offer to contribute! We do have a few
> multi-module components here. Of "proper" components, there is only [jci]
> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
> intended to take [functor] multimodule before a release is made. I'm
> perusing your wiki link now.
>
Maybe you can update the jira entry to say you want a solution "Ã la" maven ?
and website content from
https://svn.apache.org/repos/infra/websites/production/commons/content/
I will update commons-site now to get it working for cms.
For deploying I can try make configuration easy if you accept to use
something like: mvn site site:stage scm-publish:publish-scm rather
than mvn site-deploy (btw that won't be possible for multi modules :-)
).
Note that will need a release of your parent pom.
> Matt
>
>
> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> /me listening here
>>
>> Note maven.apache.org has been migrated this week.
>>
>> If you want to mix cms and maven site generation, we do that.
>> Note: even the main site is generated with a maven build but we can
>> edit files (apt/xdoc/markdown) with the cms editor
>>
>> The source tree need some modifications: see
>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>
>> Let me know if you need some help (I think I have karma here so I can
>> do a bit of pom.xml stuff :-) )
>>
>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>> you could use https://svn.apache.org/repos/infra/websites/production/
>> which is dedicated to this purpose.
>>
>> As I can see you are using this module
>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>> for main site ?
>> If you want I can do the necessary changes to make it working with
>> both cms and mvn site.
>>
>> For sub projects, that's easy if all are mono modules projects (in
>> this case mvn site-deploy works)
>> For multi modules, it's a bit different. Is there any multi modules
>> projects here ?
>>
>> --
>> Olivier
>>
>> 2012/12/14 Matt Benson <gu...@gmail.com>:
>> > I never questioned that the individual components would most likely
>> > continue with the Maven-generated content. I do question whether we want
>> > to bother laying out the main site when we have something that works.
>> >
>> > br,
>> > Matt
>> >
>> >
>> > On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>> > gilles@harfang.homelinux.org> wrote:
>> >
>> >> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>> >> > I've just added the directory to our svn tree so that there would be
>> >> > someplace at which to point it. I think the next step is to determine
>> >> > whether we want a "normal" CMS site like Logging has, in which case we
>> >> > could prop something up with e.g. Twitter bootstrap as is becoming
>> quite
>> >> > popular among ASF TLPs. If we like to keep a Maven-generated look,
>> we'd
>> >> > probably be best advised to consult the Maven folks on how they're
>> doing
>> >> > this.
>> >>
>> >> If I interpret correctly what I see, the "logging" site has both: The
>> >> top-level site is "powered by Twitter Bootstrap" while the "components"
>> are
>> >> "built by maven".
>> >> That looks like a nice starting point. I.e. we should have the top-level
>> >> web
>> >> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>> >> button would point to the corresponding legacy site (until the
>> components'
>> >> sites themselves are ready).
>> >>
>> >>
>> >> Gilles
>> >>
>> >> >
>> >> > Matt
>> >> >
>> >> >
>> >> > On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>> >> > gilles@harfang.homelinux.org> wrote:
>> >> >
>> >> > > Hi.
>> >> > >
>> >> > > On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>> >> > > > I've been talking to Joe S. on #asfinfra about this; rather than
>> >> using a
>> >> > > > test site infra would prefer we request the CMS site, just not
>> >> exposed to
>> >> > > > commons.a.o until we're satisfied with it. Do we want to use the
>> >> CMS a
>> >> > > la
>> >> > > > Apache Logging, or do we want to explore keeping the main site
>> >> > > > Maven-generated? The Maven guys, particularly Olivier Lamy (do
>> you
>> >> > > follow
>> >> > > > Commons MLs?) may be able to help us if we want to go that way.
>> >> Actually
>> >> > > > Maven still seems to be using the CMS at some level [1], so I
>> guess
>> >> we
>> >> > > can
>> >> > > > just request the CMS site and go from there. Issue created. [2]
>> >> > >
>> >> > > Is the new (empty, I guess) cms-web site accessible?
>> >> > >
>> >> > > Regards,
>> >> > > Gilles
>> >> > >
>> >> > > >
>> >> > > > Matt
>> >> > > >
>> >> > > > [1] http://maventest.apache.org
>> >> > > > [2] https://issues.apache.org/jira/browse/INFRA-5657
>> >> > > >
>> >> > > > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>> >> ralph.goers@dslextreme.com
>> >> > > >wrote:
>> >> > > >
>> >> > > > > At the very least, someone should file a Jira asking for a
>> >> commons-test
>> >> > > > > site.
>> >> > > > >
>> >> > > > > Ralph
>> >> > > > >
>> >> > > > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>> >> > > > >
>> >> > > > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
>> >> > > > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>> >> > > > > >>
>> >> > > > > >>> On 10 December 2012 21:53, Phil Steitz <
>> phil.steitz@gmail.com>
>> >> > > wrote:
>> >> > > > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>> >> > > > > >>>>> Yes, I think you are missing something fundamental.
>> >> > > > > >>>>>
>> >> > > > > >>>>> If you check in "the whole mess" you will never again be
>> >> able to
>> >> > > > > properly build a sub-project's site with Maven. This is because
>> >> the
>> >> > > > > process of updating the site would require first doing a diff
>> and
>> >> then
>> >> > > > > deleting items that are not included in the new version. Someone
>> >> > > created a
>> >> > > > > Maven plugin to try to do this but it is not the way I would
>> want
>> >> to
>> >> > > go at
>> >> > > > > all.
>> >> > > > > >>>> Sorry, I don't get it. Why won't the following work:
>> >> > > > > >>>>
>> >> > > > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>> >> > > > > >>>> 1) check all of that into an svn repo
>> >> > > > > >>>> 2) when I want to update, say, math, I generate the content
>> >> > > locally,
>> >> > > > > >>>> copy it to the /math subtree and check it in.
>> >> > > > > >>> There would need to be some extra work done to ensure that
>> >> stale
>> >> > > files
>> >> > > > > >>> are deleted.
>> >> > > > > >
>> >> > > > > > I get it now. In practice, with maven sites, is this a big
>> >> deal? I
>> >> > > > > > don't remember seeing lots of cruft accumulating on p.a.o,
>> which
>> >> > > > > > would happen if this were common. If it is not that common,
>> then
>> >> > > > > > manual svn rm's would not be that onerous.
>> >> > > > > >
>> >> > > > > > Phil
>> >> > > > > >>>
>> >> > > > > >>> For some projects, it would be possible to just delete the
>> >> existing
>> >> > > > > >>> sub-tree and check the whole new site in.
>> >> > > > > >>> [This can be done as one transaction in svnmucc]
>> >> > > > > >>>
>> >> > > > > >>> However, for sites that retain Javadoc etc. for older
>> >> releases, one
>> >> > > > > >>> would need to re-instate that part of the tree somehow.
>> >> > > > > >>>
>> >> > > > > >>> Given that svnpubsub immediately publishes what is checked
>> in,
>> >> it
>> >> > > > > >>> might be sensible to have a parallel staging directory tree
>> >> where
>> >> > > > > >>> files can be updated piecemeal if necessary, and then use
>> >> svnmucc
>> >> > > to
>> >> > > > > >>> replace the live component subtree with the staging
>> component
>> >> > > subtree
>> >> > > > > >>> as part of a single transaction.
>> >> > > > > >>>
>> >> > > > > >>> There would need to be some co-ordination between committers
>> >> when
>> >> > > > > >>> updating commons parent, as that would affect the whole
>> tree.
>> >> > > > > >>>
>> >> > > > > >> Yes. This is why Logging used the extpath approach where each
>> >> > > > > subproject commits directly to production. Each release goes to
>> a
>> >> > > release
>> >> > > > > subdirectory under each subproject's directory. Then you can
>> just
>> >> > > perform
>> >> > > > > your maven site build to a local directory, copy that into the
>> >> > > production
>> >> > > > > svn location, and commit it.
>> >> > > > > >>
>> >> > > > > >> See "Managing the subproject sites" at
>> >> > > > > http://wiki.apache.org/logging/ManagingTheWebSite
>> >> > > > > >>
>> >> > > > > >> Ralph
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> ---------------------------------------------------------------------
>> >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>> >> > > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > >
>> >> ---------------------------------------------------------------------
>> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > > > > For additional commands, e-mail: dev-help@commons.apache.org
>> >> > > > >
>> >> > > > >
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > > For additional commands, e-mail: dev-help@commons.apache.org
>> >> > >
>> >> > >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
Olivier,
Thanks for your response and offer to contribute! We do have a few
multi-module components here. Of "proper" components, there is only [jci]
that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
intended to take [functor] multimodule before a release is made. I'm
perusing your wiki link now.
Matt
On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote:
> /me listening here
>
> Note maven.apache.org has been migrated this week.
>
> If you want to mix cms and maven site generation, we do that.
> Note: even the main site is generated with a maven build but we can
> edit files (apt/xdoc/markdown) with the cms editor
>
> The source tree need some modifications: see
> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
> documentation here: http://apache.org/dev/cmsadoption#maven .
>
> Let me know if you need some help (I think I have karma here so I can
> do a bit of pom.xml stuff :-) )
>
> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
> you could use https://svn.apache.org/repos/infra/websites/production/
> which is dedicated to this purpose.
>
> As I can see you are using this module
> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
> for main site ?
> If you want I can do the necessary changes to make it working with
> both cms and mvn site.
>
> For sub projects, that's easy if all are mono modules projects (in
> this case mvn site-deploy works)
> For multi modules, it's a bit different. Is there any multi modules
> projects here ?
>
> --
> Olivier
>
> 2012/12/14 Matt Benson <gu...@gmail.com>:
> > I never questioned that the individual components would most likely
> > continue with the Maven-generated content. I do question whether we want
> > to bother laying out the main site when we have something that works.
> >
> > br,
> > Matt
> >
> >
> > On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
> > gilles@harfang.homelinux.org> wrote:
> >
> >> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
> >> > I've just added the directory to our svn tree so that there would be
> >> > someplace at which to point it. I think the next step is to determine
> >> > whether we want a "normal" CMS site like Logging has, in which case we
> >> > could prop something up with e.g. Twitter bootstrap as is becoming
> quite
> >> > popular among ASF TLPs. If we like to keep a Maven-generated look,
> we'd
> >> > probably be best advised to consult the Maven folks on how they're
> doing
> >> > this.
> >>
> >> If I interpret correctly what I see, the "logging" site has both: The
> >> top-level site is "powered by Twitter Bootstrap" while the "components"
> are
> >> "built by maven".
> >> That looks like a nice starting point. I.e. we should have the top-level
> >> web
> >> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
> >> button would point to the corresponding legacy site (until the
> components'
> >> sites themselves are ready).
> >>
> >>
> >> Gilles
> >>
> >> >
> >> > Matt
> >> >
> >> >
> >> > On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
> >> > gilles@harfang.homelinux.org> wrote:
> >> >
> >> > > Hi.
> >> > >
> >> > > On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
> >> > > > I've been talking to Joe S. on #asfinfra about this; rather than
> >> using a
> >> > > > test site infra would prefer we request the CMS site, just not
> >> exposed to
> >> > > > commons.a.o until we're satisfied with it. Do we want to use the
> >> CMS a
> >> > > la
> >> > > > Apache Logging, or do we want to explore keeping the main site
> >> > > > Maven-generated? The Maven guys, particularly Olivier Lamy (do
> you
> >> > > follow
> >> > > > Commons MLs?) may be able to help us if we want to go that way.
> >> Actually
> >> > > > Maven still seems to be using the CMS at some level [1], so I
> guess
> >> we
> >> > > can
> >> > > > just request the CMS site and go from there. Issue created. [2]
> >> > >
> >> > > Is the new (empty, I guess) cms-web site accessible?
> >> > >
> >> > > Regards,
> >> > > Gilles
> >> > >
> >> > > >
> >> > > > Matt
> >> > > >
> >> > > > [1] http://maventest.apache.org
> >> > > > [2] https://issues.apache.org/jira/browse/INFRA-5657
> >> > > >
> >> > > > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
> >> ralph.goers@dslextreme.com
> >> > > >wrote:
> >> > > >
> >> > > > > At the very least, someone should file a Jira asking for a
> >> commons-test
> >> > > > > site.
> >> > > > >
> >> > > > > Ralph
> >> > > > >
> >> > > > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
> >> > > > >
> >> > > > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
> >> > > > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
> >> > > > > >>
> >> > > > > >>> On 10 December 2012 21:53, Phil Steitz <
> phil.steitz@gmail.com>
> >> > > wrote:
> >> > > > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
> >> > > > > >>>>> Yes, I think you are missing something fundamental.
> >> > > > > >>>>>
> >> > > > > >>>>> If you check in "the whole mess" you will never again be
> >> able to
> >> > > > > properly build a sub-project's site with Maven. This is because
> >> the
> >> > > > > process of updating the site would require first doing a diff
> and
> >> then
> >> > > > > deleting items that are not included in the new version. Someone
> >> > > created a
> >> > > > > Maven plugin to try to do this but it is not the way I would
> want
> >> to
> >> > > go at
> >> > > > > all.
> >> > > > > >>>> Sorry, I don't get it. Why won't the following work:
> >> > > > > >>>>
> >> > > > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
> >> > > > > >>>> 1) check all of that into an svn repo
> >> > > > > >>>> 2) when I want to update, say, math, I generate the content
> >> > > locally,
> >> > > > > >>>> copy it to the /math subtree and check it in.
> >> > > > > >>> There would need to be some extra work done to ensure that
> >> stale
> >> > > files
> >> > > > > >>> are deleted.
> >> > > > > >
> >> > > > > > I get it now. In practice, with maven sites, is this a big
> >> deal? I
> >> > > > > > don't remember seeing lots of cruft accumulating on p.a.o,
> which
> >> > > > > > would happen if this were common. If it is not that common,
> then
> >> > > > > > manual svn rm's would not be that onerous.
> >> > > > > >
> >> > > > > > Phil
> >> > > > > >>>
> >> > > > > >>> For some projects, it would be possible to just delete the
> >> existing
> >> > > > > >>> sub-tree and check the whole new site in.
> >> > > > > >>> [This can be done as one transaction in svnmucc]
> >> > > > > >>>
> >> > > > > >>> However, for sites that retain Javadoc etc. for older
> >> releases, one
> >> > > > > >>> would need to re-instate that part of the tree somehow.
> >> > > > > >>>
> >> > > > > >>> Given that svnpubsub immediately publishes what is checked
> in,
> >> it
> >> > > > > >>> might be sensible to have a parallel staging directory tree
> >> where
> >> > > > > >>> files can be updated piecemeal if necessary, and then use
> >> svnmucc
> >> > > to
> >> > > > > >>> replace the live component subtree with the staging
> component
> >> > > subtree
> >> > > > > >>> as part of a single transaction.
> >> > > > > >>>
> >> > > > > >>> There would need to be some co-ordination between committers
> >> when
> >> > > > > >>> updating commons parent, as that would affect the whole
> tree.
> >> > > > > >>>
> >> > > > > >> Yes. This is why Logging used the extpath approach where each
> >> > > > > subproject commits directly to production. Each release goes to
> a
> >> > > release
> >> > > > > subdirectory under each subproject's directory. Then you can
> just
> >> > > perform
> >> > > > > your maven site build to a local directory, copy that into the
> >> > > production
> >> > > > > svn location, and commit it.
> >> > > > > >>
> >> > > > > >> See "Managing the subproject sites" at
> >> > > > > http://wiki.apache.org/logging/ManagingTheWebSite
> >> > > > > >>
> >> > > > > >> Ralph
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > > > >
> >> > > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > >
> >> > >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: We will not be able to update our websites...
Posted by Olivier Lamy <ol...@apache.org>.
/me listening here
Note maven.apache.org has been migrated this week.
If you want to mix cms and maven site generation, we do that.
Note: even the main site is generated with a maven build but we can
edit files (apt/xdoc/markdown) with the cms editor
The source tree need some modifications: see
https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
documentation here: http://apache.org/dev/cmsadoption#maven .
Let me know if you need some help (I think I have karma here so I can
do a bit of pom.xml stuff :-) )
Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
you could use https://svn.apache.org/repos/infra/websites/production/
which is dedicated to this purpose.
As I can see you are using this module
https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
for main site ?
If you want I can do the necessary changes to make it working with
both cms and mvn site.
For sub projects, that's easy if all are mono modules projects (in
this case mvn site-deploy works)
For multi modules, it's a bit different. Is there any multi modules
projects here ?
--
Olivier
2012/12/14 Matt Benson <gu...@gmail.com>:
> I never questioned that the individual components would most likely
> continue with the Maven-generated content. I do question whether we want
> to bother laying out the main site when we have something that works.
>
> br,
> Matt
>
>
> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>> > I've just added the directory to our svn tree so that there would be
>> > someplace at which to point it. I think the next step is to determine
>> > whether we want a "normal" CMS site like Logging has, in which case we
>> > could prop something up with e.g. Twitter bootstrap as is becoming quite
>> > popular among ASF TLPs. If we like to keep a Maven-generated look, we'd
>> > probably be best advised to consult the Maven folks on how they're doing
>> > this.
>>
>> If I interpret correctly what I see, the "logging" site has both: The
>> top-level site is "powered by Twitter Bootstrap" while the "components" are
>> "built by maven".
>> That looks like a nice starting point. I.e. we should have the top-level
>> web
>> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
>> button would point to the corresponding legacy site (until the components'
>> sites themselves are ready).
>>
>>
>> Gilles
>>
>> >
>> > Matt
>> >
>> >
>> > On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>> > gilles@harfang.homelinux.org> wrote:
>> >
>> > > Hi.
>> > >
>> > > On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
>> > > > I've been talking to Joe S. on #asfinfra about this; rather than
>> using a
>> > > > test site infra would prefer we request the CMS site, just not
>> exposed to
>> > > > commons.a.o until we're satisfied with it. Do we want to use the
>> CMS a
>> > > la
>> > > > Apache Logging, or do we want to explore keeping the main site
>> > > > Maven-generated? The Maven guys, particularly Olivier Lamy (do you
>> > > follow
>> > > > Commons MLs?) may be able to help us if we want to go that way.
>> Actually
>> > > > Maven still seems to be using the CMS at some level [1], so I guess
>> we
>> > > can
>> > > > just request the CMS site and go from there. Issue created. [2]
>> > >
>> > > Is the new (empty, I guess) cms-web site accessible?
>> > >
>> > > Regards,
>> > > Gilles
>> > >
>> > > >
>> > > > Matt
>> > > >
>> > > > [1] http://maventest.apache.org
>> > > > [2] https://issues.apache.org/jira/browse/INFRA-5657
>> > > >
>> > > > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
>> ralph.goers@dslextreme.com
>> > > >wrote:
>> > > >
>> > > > > At the very least, someone should file a Jira asking for a
>> commons-test
>> > > > > site.
>> > > > >
>> > > > > Ralph
>> > > > >
>> > > > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>> > > > >
>> > > > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
>> > > > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>> > > > > >>
>> > > > > >>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com>
>> > > wrote:
>> > > > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>> > > > > >>>>> Yes, I think you are missing something fundamental.
>> > > > > >>>>>
>> > > > > >>>>> If you check in "the whole mess" you will never again be
>> able to
>> > > > > properly build a sub-project's site with Maven. This is because
>> the
>> > > > > process of updating the site would require first doing a diff and
>> then
>> > > > > deleting items that are not included in the new version. Someone
>> > > created a
>> > > > > Maven plugin to try to do this but it is not the way I would want
>> to
>> > > go at
>> > > > > all.
>> > > > > >>>> Sorry, I don't get it. Why won't the following work:
>> > > > > >>>>
>> > > > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>> > > > > >>>> 1) check all of that into an svn repo
>> > > > > >>>> 2) when I want to update, say, math, I generate the content
>> > > locally,
>> > > > > >>>> copy it to the /math subtree and check it in.
>> > > > > >>> There would need to be some extra work done to ensure that
>> stale
>> > > files
>> > > > > >>> are deleted.
>> > > > > >
>> > > > > > I get it now. In practice, with maven sites, is this a big
>> deal? I
>> > > > > > don't remember seeing lots of cruft accumulating on p.a.o, which
>> > > > > > would happen if this were common. If it is not that common, then
>> > > > > > manual svn rm's would not be that onerous.
>> > > > > >
>> > > > > > Phil
>> > > > > >>>
>> > > > > >>> For some projects, it would be possible to just delete the
>> existing
>> > > > > >>> sub-tree and check the whole new site in.
>> > > > > >>> [This can be done as one transaction in svnmucc]
>> > > > > >>>
>> > > > > >>> However, for sites that retain Javadoc etc. for older
>> releases, one
>> > > > > >>> would need to re-instate that part of the tree somehow.
>> > > > > >>>
>> > > > > >>> Given that svnpubsub immediately publishes what is checked in,
>> it
>> > > > > >>> might be sensible to have a parallel staging directory tree
>> where
>> > > > > >>> files can be updated piecemeal if necessary, and then use
>> svnmucc
>> > > to
>> > > > > >>> replace the live component subtree with the staging component
>> > > subtree
>> > > > > >>> as part of a single transaction.
>> > > > > >>>
>> > > > > >>> There would need to be some co-ordination between committers
>> when
>> > > > > >>> updating commons parent, as that would affect the whole tree.
>> > > > > >>>
>> > > > > >> Yes. This is why Logging used the extpath approach where each
>> > > > > subproject commits directly to production. Each release goes to a
>> > > release
>> > > > > subdirectory under each subproject's directory. Then you can just
>> > > perform
>> > > > > your maven site build to a local directory, copy that into the
>> > > production
>> > > > > svn location, and commit it.
>> > > > > >>
>> > > > > >> See "Managing the subproject sites" at
>> > > > > http://wiki.apache.org/logging/ManagingTheWebSite
>> > > > > >>
>> > > > > >> Ralph
>> > > > > >
>> > > > > >
>> > > > > >
>> ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > > > For additional commands, e-mail: dev-help@commons.apache.org
>> > > > >
>> > > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
I never questioned that the individual components would most likely
continue with the Maven-generated content. I do question whether we want
to bother laying out the main site when we have something that works.
br,
Matt
On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
> > I've just added the directory to our svn tree so that there would be
> > someplace at which to point it. I think the next step is to determine
> > whether we want a "normal" CMS site like Logging has, in which case we
> > could prop something up with e.g. Twitter bootstrap as is becoming quite
> > popular among ASF TLPs. If we like to keep a Maven-generated look, we'd
> > probably be best advised to consult the Maven folks on how they're doing
> > this.
>
> If I interpret correctly what I see, the "logging" site has both: The
> top-level site is "powered by Twitter Bootstrap" while the "components" are
> "built by maven".
> That looks like a nice starting point. I.e. we should have the top-level
> web
> CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
> button would point to the corresponding legacy site (until the components'
> sites themselves are ready).
>
>
> Gilles
>
> >
> > Matt
> >
> >
> > On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
> > gilles@harfang.homelinux.org> wrote:
> >
> > > Hi.
> > >
> > > On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
> > > > I've been talking to Joe S. on #asfinfra about this; rather than
> using a
> > > > test site infra would prefer we request the CMS site, just not
> exposed to
> > > > commons.a.o until we're satisfied with it. Do we want to use the
> CMS a
> > > la
> > > > Apache Logging, or do we want to explore keeping the main site
> > > > Maven-generated? The Maven guys, particularly Olivier Lamy (do you
> > > follow
> > > > Commons MLs?) may be able to help us if we want to go that way.
> Actually
> > > > Maven still seems to be using the CMS at some level [1], so I guess
> we
> > > can
> > > > just request the CMS site and go from there. Issue created. [2]
> > >
> > > Is the new (empty, I guess) cms-web site accessible?
> > >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > Matt
> > > >
> > > > [1] http://maventest.apache.org
> > > > [2] https://issues.apache.org/jira/browse/INFRA-5657
> > > >
> > > > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <
> ralph.goers@dslextreme.com
> > > >wrote:
> > > >
> > > > > At the very least, someone should file a Jira asking for a
> commons-test
> > > > > site.
> > > > >
> > > > > Ralph
> > > > >
> > > > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
> > > > >
> > > > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
> > > > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
> > > > > >>
> > > > > >>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com>
> > > wrote:
> > > > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
> > > > > >>>>> Yes, I think you are missing something fundamental.
> > > > > >>>>>
> > > > > >>>>> If you check in "the whole mess" you will never again be
> able to
> > > > > properly build a sub-project's site with Maven. This is because
> the
> > > > > process of updating the site would require first doing a diff and
> then
> > > > > deleting items that are not included in the new version. Someone
> > > created a
> > > > > Maven plugin to try to do this but it is not the way I would want
> to
> > > go at
> > > > > all.
> > > > > >>>> Sorry, I don't get it. Why won't the following work:
> > > > > >>>>
> > > > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
> > > > > >>>> 1) check all of that into an svn repo
> > > > > >>>> 2) when I want to update, say, math, I generate the content
> > > locally,
> > > > > >>>> copy it to the /math subtree and check it in.
> > > > > >>> There would need to be some extra work done to ensure that
> stale
> > > files
> > > > > >>> are deleted.
> > > > > >
> > > > > > I get it now. In practice, with maven sites, is this a big
> deal? I
> > > > > > don't remember seeing lots of cruft accumulating on p.a.o, which
> > > > > > would happen if this were common. If it is not that common, then
> > > > > > manual svn rm's would not be that onerous.
> > > > > >
> > > > > > Phil
> > > > > >>>
> > > > > >>> For some projects, it would be possible to just delete the
> existing
> > > > > >>> sub-tree and check the whole new site in.
> > > > > >>> [This can be done as one transaction in svnmucc]
> > > > > >>>
> > > > > >>> However, for sites that retain Javadoc etc. for older
> releases, one
> > > > > >>> would need to re-instate that part of the tree somehow.
> > > > > >>>
> > > > > >>> Given that svnpubsub immediately publishes what is checked in,
> it
> > > > > >>> might be sensible to have a parallel staging directory tree
> where
> > > > > >>> files can be updated piecemeal if necessary, and then use
> svnmucc
> > > to
> > > > > >>> replace the live component subtree with the staging component
> > > subtree
> > > > > >>> as part of a single transaction.
> > > > > >>>
> > > > > >>> There would need to be some co-ordination between committers
> when
> > > > > >>> updating commons parent, as that would affect the whole tree.
> > > > > >>>
> > > > > >> Yes. This is why Logging used the extpath approach where each
> > > > > subproject commits directly to production. Each release goes to a
> > > release
> > > > > subdirectory under each subproject's directory. Then you can just
> > > perform
> > > > > your maven site build to a local directory, copy that into the
> > > production
> > > > > svn location, and commit it.
> > > > > >>
> > > > > >> See "Managing the subproject sites" at
> > > > > http://wiki.apache.org/logging/ManagingTheWebSite
> > > > > >>
> > > > > >> Ralph
> > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: We will not be able to update our websites...
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
> I've just added the directory to our svn tree so that there would be
> someplace at which to point it. I think the next step is to determine
> whether we want a "normal" CMS site like Logging has, in which case we
> could prop something up with e.g. Twitter bootstrap as is becoming quite
> popular among ASF TLPs. If we like to keep a Maven-generated look, we'd
> probably be best advised to consult the Maven folks on how they're doing
> this.
If I interpret correctly what I see, the "logging" site has both: The
top-level site is "powered by Twitter Bootstrap" while the "components" are
"built by maven".
That looks like a nice starting point. I.e. we should have the top-level web
CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
button would point to the corresponding legacy site (until the components'
sites themselves are ready).
Gilles
>
> Matt
>
>
> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
> > Hi.
> >
> > On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
> > > I've been talking to Joe S. on #asfinfra about this; rather than using a
> > > test site infra would prefer we request the CMS site, just not exposed to
> > > commons.a.o until we're satisfied with it. Do we want to use the CMS a
> > la
> > > Apache Logging, or do we want to explore keeping the main site
> > > Maven-generated? The Maven guys, particularly Olivier Lamy (do you
> > follow
> > > Commons MLs?) may be able to help us if we want to go that way. Actually
> > > Maven still seems to be using the CMS at some level [1], so I guess we
> > can
> > > just request the CMS site and go from there. Issue created. [2]
> >
> > Is the new (empty, I guess) cms-web site accessible?
> >
> > Regards,
> > Gilles
> >
> > >
> > > Matt
> > >
> > > [1] http://maventest.apache.org
> > > [2] https://issues.apache.org/jira/browse/INFRA-5657
> > >
> > > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <ralph.goers@dslextreme.com
> > >wrote:
> > >
> > > > At the very least, someone should file a Jira asking for a commons-test
> > > > site.
> > > >
> > > > Ralph
> > > >
> > > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
> > > >
> > > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
> > > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
> > > > >>
> > > > >>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com>
> > wrote:
> > > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
> > > > >>>>> Yes, I think you are missing something fundamental.
> > > > >>>>>
> > > > >>>>> If you check in "the whole mess" you will never again be able to
> > > > properly build a sub-project's site with Maven. This is because the
> > > > process of updating the site would require first doing a diff and then
> > > > deleting items that are not included in the new version. Someone
> > created a
> > > > Maven plugin to try to do this but it is not the way I would want to
> > go at
> > > > all.
> > > > >>>> Sorry, I don't get it. Why won't the following work:
> > > > >>>>
> > > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
> > > > >>>> 1) check all of that into an svn repo
> > > > >>>> 2) when I want to update, say, math, I generate the content
> > locally,
> > > > >>>> copy it to the /math subtree and check it in.
> > > > >>> There would need to be some extra work done to ensure that stale
> > files
> > > > >>> are deleted.
> > > > >
> > > > > I get it now. In practice, with maven sites, is this a big deal? I
> > > > > don't remember seeing lots of cruft accumulating on p.a.o, which
> > > > > would happen if this were common. If it is not that common, then
> > > > > manual svn rm's would not be that onerous.
> > > > >
> > > > > Phil
> > > > >>>
> > > > >>> For some projects, it would be possible to just delete the existing
> > > > >>> sub-tree and check the whole new site in.
> > > > >>> [This can be done as one transaction in svnmucc]
> > > > >>>
> > > > >>> However, for sites that retain Javadoc etc. for older releases, one
> > > > >>> would need to re-instate that part of the tree somehow.
> > > > >>>
> > > > >>> Given that svnpubsub immediately publishes what is checked in, it
> > > > >>> might be sensible to have a parallel staging directory tree where
> > > > >>> files can be updated piecemeal if necessary, and then use svnmucc
> > to
> > > > >>> replace the live component subtree with the staging component
> > subtree
> > > > >>> as part of a single transaction.
> > > > >>>
> > > > >>> There would need to be some co-ordination between committers when
> > > > >>> updating commons parent, as that would affect the whole tree.
> > > > >>>
> > > > >> Yes. This is why Logging used the extpath approach where each
> > > > subproject commits directly to production. Each release goes to a
> > release
> > > > subdirectory under each subproject's directory. Then you can just
> > perform
> > > > your maven site build to a local directory, copy that into the
> > production
> > > > svn location, and commit it.
> > > > >>
> > > > >> See "Managing the subproject sites" at
> > > > http://wiki.apache.org/logging/ManagingTheWebSite
> > > > >>
> > > > >> Ralph
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
I've just added the directory to our svn tree so that there would be
someplace at which to point it. I think the next step is to determine
whether we want a "normal" CMS site like Logging has, in which case we
could prop something up with e.g. Twitter bootstrap as is becoming quite
popular among ASF TLPs. If we like to keep a Maven-generated look, we'd
probably be best advised to consult the Maven folks on how they're doing
this.
Matt
On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:
> Hi.
>
> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
> > I've been talking to Joe S. on #asfinfra about this; rather than using a
> > test site infra would prefer we request the CMS site, just not exposed to
> > commons.a.o until we're satisfied with it. Do we want to use the CMS a
> la
> > Apache Logging, or do we want to explore keeping the main site
> > Maven-generated? The Maven guys, particularly Olivier Lamy (do you
> follow
> > Commons MLs?) may be able to help us if we want to go that way. Actually
> > Maven still seems to be using the CMS at some level [1], so I guess we
> can
> > just request the CMS site and go from there. Issue created. [2]
>
> Is the new (empty, I guess) cms-web site accessible?
>
> Regards,
> Gilles
>
> >
> > Matt
> >
> > [1] http://maventest.apache.org
> > [2] https://issues.apache.org/jira/browse/INFRA-5657
> >
> > On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <ralph.goers@dslextreme.com
> >wrote:
> >
> > > At the very least, someone should file a Jira asking for a commons-test
> > > site.
> > >
> > > Ralph
> > >
> > > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
> > >
> > > > On 12/10/12 5:10 PM, Ralph Goers wrote:
> > > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
> > > >>
> > > >>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com>
> wrote:
> > > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
> > > >>>>> Yes, I think you are missing something fundamental.
> > > >>>>>
> > > >>>>> If you check in "the whole mess" you will never again be able to
> > > properly build a sub-project's site with Maven. This is because the
> > > process of updating the site would require first doing a diff and then
> > > deleting items that are not included in the new version. Someone
> created a
> > > Maven plugin to try to do this but it is not the way I would want to
> go at
> > > all.
> > > >>>> Sorry, I don't get it. Why won't the following work:
> > > >>>>
> > > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
> > > >>>> 1) check all of that into an svn repo
> > > >>>> 2) when I want to update, say, math, I generate the content
> locally,
> > > >>>> copy it to the /math subtree and check it in.
> > > >>> There would need to be some extra work done to ensure that stale
> files
> > > >>> are deleted.
> > > >
> > > > I get it now. In practice, with maven sites, is this a big deal? I
> > > > don't remember seeing lots of cruft accumulating on p.a.o, which
> > > > would happen if this were common. If it is not that common, then
> > > > manual svn rm's would not be that onerous.
> > > >
> > > > Phil
> > > >>>
> > > >>> For some projects, it would be possible to just delete the existing
> > > >>> sub-tree and check the whole new site in.
> > > >>> [This can be done as one transaction in svnmucc]
> > > >>>
> > > >>> However, for sites that retain Javadoc etc. for older releases, one
> > > >>> would need to re-instate that part of the tree somehow.
> > > >>>
> > > >>> Given that svnpubsub immediately publishes what is checked in, it
> > > >>> might be sensible to have a parallel staging directory tree where
> > > >>> files can be updated piecemeal if necessary, and then use svnmucc
> to
> > > >>> replace the live component subtree with the staging component
> subtree
> > > >>> as part of a single transaction.
> > > >>>
> > > >>> There would need to be some co-ordination between committers when
> > > >>> updating commons parent, as that would affect the whole tree.
> > > >>>
> > > >> Yes. This is why Logging used the extpath approach where each
> > > subproject commits directly to production. Each release goes to a
> release
> > > subdirectory under each subproject's directory. Then you can just
> perform
> > > your maven site build to a local directory, copy that into the
> production
> > > svn location, and commit it.
> > > >>
> > > >> See "Managing the subproject sites" at
> > > http://wiki.apache.org/logging/ManagingTheWebSite
> > > >>
> > > >> Ralph
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: We will not be able to update our websites...
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
> I've been talking to Joe S. on #asfinfra about this; rather than using a
> test site infra would prefer we request the CMS site, just not exposed to
> commons.a.o until we're satisfied with it. Do we want to use the CMS a la
> Apache Logging, or do we want to explore keeping the main site
> Maven-generated? The Maven guys, particularly Olivier Lamy (do you follow
> Commons MLs?) may be able to help us if we want to go that way. Actually
> Maven still seems to be using the CMS at some level [1], so I guess we can
> just request the CMS site and go from there. Issue created. [2]
Is the new (empty, I guess) cms-web site accessible?
Regards,
Gilles
>
> Matt
>
> [1] http://maventest.apache.org
> [2] https://issues.apache.org/jira/browse/INFRA-5657
>
> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> > At the very least, someone should file a Jira asking for a commons-test
> > site.
> >
> > Ralph
> >
> > On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
> >
> > > On 12/10/12 5:10 PM, Ralph Goers wrote:
> > >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
> > >>
> > >>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com> wrote:
> > >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
> > >>>>> Yes, I think you are missing something fundamental.
> > >>>>>
> > >>>>> If you check in "the whole mess" you will never again be able to
> > properly build a sub-project's site with Maven. This is because the
> > process of updating the site would require first doing a diff and then
> > deleting items that are not included in the new version. Someone created a
> > Maven plugin to try to do this but it is not the way I would want to go at
> > all.
> > >>>> Sorry, I don't get it. Why won't the following work:
> > >>>>
> > >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
> > >>>> 1) check all of that into an svn repo
> > >>>> 2) when I want to update, say, math, I generate the content locally,
> > >>>> copy it to the /math subtree and check it in.
> > >>> There would need to be some extra work done to ensure that stale files
> > >>> are deleted.
> > >
> > > I get it now. In practice, with maven sites, is this a big deal? I
> > > don't remember seeing lots of cruft accumulating on p.a.o, which
> > > would happen if this were common. If it is not that common, then
> > > manual svn rm's would not be that onerous.
> > >
> > > Phil
> > >>>
> > >>> For some projects, it would be possible to just delete the existing
> > >>> sub-tree and check the whole new site in.
> > >>> [This can be done as one transaction in svnmucc]
> > >>>
> > >>> However, for sites that retain Javadoc etc. for older releases, one
> > >>> would need to re-instate that part of the tree somehow.
> > >>>
> > >>> Given that svnpubsub immediately publishes what is checked in, it
> > >>> might be sensible to have a parallel staging directory tree where
> > >>> files can be updated piecemeal if necessary, and then use svnmucc to
> > >>> replace the live component subtree with the staging component subtree
> > >>> as part of a single transaction.
> > >>>
> > >>> There would need to be some co-ordination between committers when
> > >>> updating commons parent, as that would affect the whole tree.
> > >>>
> > >> Yes. This is why Logging used the extpath approach where each
> > subproject commits directly to production. Each release goes to a release
> > subdirectory under each subproject's directory. Then you can just perform
> > your maven site build to a local directory, copy that into the production
> > svn location, and commit it.
> > >>
> > >> See "Managing the subproject sites" at
> > http://wiki.apache.org/logging/ManagingTheWebSite
> > >>
> > >> Ralph
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
I've been talking to Joe S. on #asfinfra about this; rather than using a
test site infra would prefer we request the CMS site, just not exposed to
commons.a.o until we're satisfied with it. Do we want to use the CMS a la
Apache Logging, or do we want to explore keeping the main site
Maven-generated? The Maven guys, particularly Olivier Lamy (do you follow
Commons MLs?) may be able to help us if we want to go that way. Actually
Maven still seems to be using the CMS at some level [1], so I guess we can
just request the CMS site and go from there. Issue created. [2]
Matt
[1] http://maventest.apache.org
[2] https://issues.apache.org/jira/browse/INFRA-5657
On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> At the very least, someone should file a Jira asking for a commons-test
> site.
>
> Ralph
>
> On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
>
> > On 12/10/12 5:10 PM, Ralph Goers wrote:
> >> On Dec 10, 2012, at 4:12 PM, sebb wrote:
> >>
> >>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com> wrote:
> >>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
> >>>>> Yes, I think you are missing something fundamental.
> >>>>>
> >>>>> If you check in "the whole mess" you will never again be able to
> properly build a sub-project's site with Maven. This is because the
> process of updating the site would require first doing a diff and then
> deleting items that are not included in the new version. Someone created a
> Maven plugin to try to do this but it is not the way I would want to go at
> all.
> >>>> Sorry, I don't get it. Why won't the following work:
> >>>>
> >>>> 0) Grab all of, say p.a.o/www/commons.apache.org
> >>>> 1) check all of that into an svn repo
> >>>> 2) when I want to update, say, math, I generate the content locally,
> >>>> copy it to the /math subtree and check it in.
> >>> There would need to be some extra work done to ensure that stale files
> >>> are deleted.
> >
> > I get it now. In practice, with maven sites, is this a big deal? I
> > don't remember seeing lots of cruft accumulating on p.a.o, which
> > would happen if this were common. If it is not that common, then
> > manual svn rm's would not be that onerous.
> >
> > Phil
> >>>
> >>> For some projects, it would be possible to just delete the existing
> >>> sub-tree and check the whole new site in.
> >>> [This can be done as one transaction in svnmucc]
> >>>
> >>> However, for sites that retain Javadoc etc. for older releases, one
> >>> would need to re-instate that part of the tree somehow.
> >>>
> >>> Given that svnpubsub immediately publishes what is checked in, it
> >>> might be sensible to have a parallel staging directory tree where
> >>> files can be updated piecemeal if necessary, and then use svnmucc to
> >>> replace the live component subtree with the staging component subtree
> >>> as part of a single transaction.
> >>>
> >>> There would need to be some co-ordination between committers when
> >>> updating commons parent, as that would affect the whole tree.
> >>>
> >> Yes. This is why Logging used the extpath approach where each
> subproject commits directly to production. Each release goes to a release
> subdirectory under each subproject's directory. Then you can just perform
> your maven site build to a local directory, copy that into the production
> svn location, and commit it.
> >>
> >> See "Managing the subproject sites" at
> http://wiki.apache.org/logging/ManagingTheWebSite
> >>
> >> Ralph
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
At the very least, someone should file a Jira asking for a commons-test site.
Ralph
On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:
> On 12/10/12 5:10 PM, Ralph Goers wrote:
>> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>>
>>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>>> Yes, I think you are missing something fundamental.
>>>>>
>>>>> If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
>>>> Sorry, I don't get it. Why won't the following work:
>>>>
>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>> 1) check all of that into an svn repo
>>>> 2) when I want to update, say, math, I generate the content locally,
>>>> copy it to the /math subtree and check it in.
>>> There would need to be some extra work done to ensure that stale files
>>> are deleted.
>
> I get it now. In practice, with maven sites, is this a big deal? I
> don't remember seeing lots of cruft accumulating on p.a.o, which
> would happen if this were common. If it is not that common, then
> manual svn rm's would not be that onerous.
>
> Phil
>>>
>>> For some projects, it would be possible to just delete the existing
>>> sub-tree and check the whole new site in.
>>> [This can be done as one transaction in svnmucc]
>>>
>>> However, for sites that retain Javadoc etc. for older releases, one
>>> would need to re-instate that part of the tree somehow.
>>>
>>> Given that svnpubsub immediately publishes what is checked in, it
>>> might be sensible to have a parallel staging directory tree where
>>> files can be updated piecemeal if necessary, and then use svnmucc to
>>> replace the live component subtree with the staging component subtree
>>> as part of a single transaction.
>>>
>>> There would need to be some co-ordination between committers when
>>> updating commons parent, as that would affect the whole tree.
>>>
>> Yes. This is why Logging used the extpath approach where each subproject commits directly to production. Each release goes to a release subdirectory under each subproject's directory. Then you can just perform your maven site build to a local directory, copy that into the production svn location, and commit it.
>>
>> See "Managing the subproject sites" at http://wiki.apache.org/logging/ManagingTheWebSite
>>
>> Ralph
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/10/12 5:10 PM, Ralph Goers wrote:
> On Dec 10, 2012, at 4:12 PM, sebb wrote:
>
>> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com> wrote:
>>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>>> Yes, I think you are missing something fundamental.
>>>>
>>>> If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
>>> Sorry, I don't get it. Why won't the following work:
>>>
>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>> 1) check all of that into an svn repo
>>> 2) when I want to update, say, math, I generate the content locally,
>>> copy it to the /math subtree and check it in.
>> There would need to be some extra work done to ensure that stale files
>> are deleted.
I get it now. In practice, with maven sites, is this a big deal? I
don't remember seeing lots of cruft accumulating on p.a.o, which
would happen if this were common. If it is not that common, then
manual svn rm's would not be that onerous.
Phil
>>
>> For some projects, it would be possible to just delete the existing
>> sub-tree and check the whole new site in.
>> [This can be done as one transaction in svnmucc]
>>
>> However, for sites that retain Javadoc etc. for older releases, one
>> would need to re-instate that part of the tree somehow.
>>
>> Given that svnpubsub immediately publishes what is checked in, it
>> might be sensible to have a parallel staging directory tree where
>> files can be updated piecemeal if necessary, and then use svnmucc to
>> replace the live component subtree with the staging component subtree
>> as part of a single transaction.
>>
>> There would need to be some co-ordination between committers when
>> updating commons parent, as that would affect the whole tree.
>>
> Yes. This is why Logging used the extpath approach where each subproject commits directly to production. Each release goes to a release subdirectory under each subproject's directory. Then you can just perform your maven site build to a local directory, copy that into the production svn location, and commit it.
>
> See "Managing the subproject sites" at http://wiki.apache.org/logging/ManagingTheWebSite
>
> Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 10, 2012, at 4:12 PM, sebb wrote:
> On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com> wrote:
>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>> Yes, I think you are missing something fundamental.
>>>
>>> If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
>>
>> Sorry, I don't get it. Why won't the following work:
>>
>> 0) Grab all of, say p.a.o/www/commons.apache.org
>> 1) check all of that into an svn repo
>> 2) when I want to update, say, math, I generate the content locally,
>> copy it to the /math subtree and check it in.
>
> There would need to be some extra work done to ensure that stale files
> are deleted.
>
> For some projects, it would be possible to just delete the existing
> sub-tree and check the whole new site in.
> [This can be done as one transaction in svnmucc]
>
> However, for sites that retain Javadoc etc. for older releases, one
> would need to re-instate that part of the tree somehow.
>
> Given that svnpubsub immediately publishes what is checked in, it
> might be sensible to have a parallel staging directory tree where
> files can be updated piecemeal if necessary, and then use svnmucc to
> replace the live component subtree with the staging component subtree
> as part of a single transaction.
>
> There would need to be some co-ordination between committers when
> updating commons parent, as that would affect the whole tree.
>
Yes. This is why Logging used the extpath approach where each subproject commits directly to production. Each release goes to a release subdirectory under each subproject's directory. Then you can just perform your maven site build to a local directory, copy that into the production svn location, and commit it.
See "Managing the subproject sites" at http://wiki.apache.org/logging/ManagingTheWebSite
Ralph
Re: We will not be able to update our websites...
Posted by sebb <se...@gmail.com>.
On 10 December 2012 21:53, Phil Steitz <ph...@gmail.com> wrote:
> On 12/10/12 1:27 PM, Ralph Goers wrote:
>> Yes, I think you are missing something fundamental.
>>
>> If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
>
> Sorry, I don't get it. Why won't the following work:
>
> 0) Grab all of, say p.a.o/www/commons.apache.org
> 1) check all of that into an svn repo
> 2) when I want to update, say, math, I generate the content locally,
> copy it to the /math subtree and check it in.
There would need to be some extra work done to ensure that stale files
are deleted.
For some projects, it would be possible to just delete the existing
sub-tree and check the whole new site in.
[This can be done as one transaction in svnmucc]
However, for sites that retain Javadoc etc. for older releases, one
would need to re-instate that part of the tree somehow.
Given that svnpubsub immediately publishes what is checked in, it
might be sensible to have a parallel staging directory tree where
files can be updated piecemeal if necessary, and then use svnmucc to
replace the live component subtree with the staging component subtree
as part of a single transaction.
There would need to be some co-ordination between committers when
updating commons parent, as that would affect the whole tree.
> I guess this is not "proper" from the maven perspective because it
> does not use maven deployment. No big loss, IMHO. Am I missing
> something else?
>
> Phil
>
>>
>> Ralph
>>
>> On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:
>>
>>> I don't think there's much percentage in moving to the CMS with a structure
>>> like that of Commons. That said, checking in the whole mess, as Phil
>>> suggests, seems perfectly doable and should not preclude updating parts of
>>> the tree in quite a similar fashion as how updating a given component's
>>> site is done today, except no ssh to mino. Am I missing something
>>> fundamental?
>>>
>>> Matt
>>>
>>>
>>> On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>> On 12/10/12 11:40 AM, Phil Steitz wrote:
>>>>> On 12/10/12 10:50 AM, Ralph Goers wrote:
>>>>>> All the sub-sites are hooked off the main site. I would have no idea
>>>> how to migrate anything without migrating the main site first.
>>>>> Having now looked at [1], it looks to me like we can solve the
>>>>> immediate problem using svn pub-sub. The docs are not clear and
>>>>> they may not allow it, but in theory, we could in fact do this
>>>>> incrementally - start an svn repo and move the "mutable" portions
>>>>> there incrementally, understanding that only changes to the
>>>>> svn-migrated stuff will be propagated. If infra barfs on that, then
>>>>> we just commit the whole mess starting at the top level commons
>>>>> site, following the Ant example linked on [1]. Then to make
>>>>> changes, we follow the process that has been in place for the main
>>>>> ASF site for ages - maintain a local checkout of the generated site,
>>>>> re-gen when you want to update and check in.
>>>>>
>>>>> I know playing with the CMS might be fun and interesting; but a) we
>>>>> have no volunteers to do this and b) we do not have time to migrate
>>>>> all of the content.
>>>>>
>>>>> Therefore, I suggest we just follow the Ant route; possibly moving
>>>>> incrementally if infra allows that.
>>>> Let me modify the proposal to make it simpler and more palatable to
>>>> infra:
>>>>
>>>> Just do like Ant - check in the whole mess.
>>>>
>>>> Phil
>>>>> Phil
>>>>>
>>>>> [1] http://www.apache.org/dev/project-site.html
>>>>>> I suppose it is possible to point to the sub-sites in their current
>>>> location but in logging we found it more beneficial to simply copy the
>>>> content under the main site in the CMS.
>>>>>> Are all the sub-sites built with Maven? Any that are not could move to
>>>> the CMS as part of the main site.
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>>>>>
>>>>>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>>>>>> That is what we did in logging. Changing it at the end is fairly
>>>> easy. However, we don't have much time for testing.
>>>>>>> Do we really have to do it all at once?
>>>>>>>
>>>>>>> IIUC (which is quite possibly false), the intent here is to get
>>>>>>> everyone onto svn pub-sub and kill off the rsync processes from
>>>>>>> p.a.o to the live site. The stake in the ground is that the rsyncs
>>>>>>> are going to stop Jan 1. Do I have that right?
>>>>>>>
>>>>>>> Why can't we move to svn pub-sub incrementally somehow,
>>>>>>> understanding that until individual components move, their sites
>>>>>>> will be read-only? So basically, when you decide to make changes to
>>>>>>> a site, you get it set up for svn pub-sub? Note I am including the
>>>>>>> main site in this - i.e., it does not have to "move" until it needs
>>>>>>> to be changed. It would seem to me (again, may be missing something
>>>>>>> critical) that we could build the newly definitive source svn repo
>>>>>>> incrementally, with publishing always sourced from there, but "old"
>>>>>>> directories on the live host remaining until they get clobbered. In
>>>>>>> the worst case, if the live host *must* include only svn-published
>>>>>>> files, we could seed the new repo with the "old" content. But I
>>>>>>> don't get why that has to be the case; because if it is, we are in
>>>>>>> worse shape than Christian suggests - come Jan 1 we will be dark if
>>>>>>> we don't get everything moved to svn pub-sub.
>>>>>>>
>>>>>>> Sorry if above is naive. The intent is to avoid a huge amount of
>>>>>>> fiddling in a short period of time when quite a few component sites
>>>>>>> have not changed and will not change for some time to come.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>>>>>>
>>>>>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <
>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>>>>>>> we have many components, unless you see a short cut.
>>>>>>>>> I thought we would create: commons-test.apache.org
>>>>>>>>> move all components to there and then make a switch from
>>>>>>>>> commons.apache.org to the new site
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com>
>>>> wrote:
>>>>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
>>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>>> Bah, let's pick one component and start there and skip a test
>>>> site.
>>>>>>>>>>> But then there is only one component visible under the new
>>>> commons.a.o?
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <
>>>> grobmeier@gmail.com> wrote:
>>>>>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other terms: let us request a commons-test cms where we can
>>>> try things
>>>>>>>>>>>>> out and prepare the new sites.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As Ralph Goers has already mentioned, we have a similar
>>>> structure in
>>>>>>>>>>>>> logging land (1 main site, several sub sites) which might fit to
>>>> Commons
>>>>>>>>>>>>> too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
>>>> are
>>>>>>>>>>>>> generated via Maven. The target of this generation is then
>>>> copied to
>>>>>>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously we will have to generate sites for each component
>>>> then, which
>>>>>>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>>>>> https://www.timeandbill.de
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>>> https://www.timeandbill.de
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.grobmeier.de
>>>>>>>>> https://www.timeandbill.de
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/10/12 1:27 PM, Ralph Goers wrote:
> Yes, I think you are missing something fundamental.
>
> If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
Sorry, I don't get it. Why won't the following work:
0) Grab all of, say p.a.o/www/commons.apache.org
1) check all of that into an svn repo
2) when I want to update, say, math, I generate the content locally,
copy it to the /math subtree and check it in.
I guess this is not "proper" from the maven perspective because it
does not use maven deployment. No big loss, IMHO. Am I missing
something else?
Phil
>
> Ralph
>
> On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:
>
>> I don't think there's much percentage in moving to the CMS with a structure
>> like that of Commons. That said, checking in the whole mess, as Phil
>> suggests, seems perfectly doable and should not preclude updating parts of
>> the tree in quite a similar fashion as how updating a given component's
>> site is done today, except no ssh to mino. Am I missing something
>> fundamental?
>>
>> Matt
>>
>>
>> On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>> On 12/10/12 11:40 AM, Phil Steitz wrote:
>>>> On 12/10/12 10:50 AM, Ralph Goers wrote:
>>>>> All the sub-sites are hooked off the main site. I would have no idea
>>> how to migrate anything without migrating the main site first.
>>>> Having now looked at [1], it looks to me like we can solve the
>>>> immediate problem using svn pub-sub. The docs are not clear and
>>>> they may not allow it, but in theory, we could in fact do this
>>>> incrementally - start an svn repo and move the "mutable" portions
>>>> there incrementally, understanding that only changes to the
>>>> svn-migrated stuff will be propagated. If infra barfs on that, then
>>>> we just commit the whole mess starting at the top level commons
>>>> site, following the Ant example linked on [1]. Then to make
>>>> changes, we follow the process that has been in place for the main
>>>> ASF site for ages - maintain a local checkout of the generated site,
>>>> re-gen when you want to update and check in.
>>>>
>>>> I know playing with the CMS might be fun and interesting; but a) we
>>>> have no volunteers to do this and b) we do not have time to migrate
>>>> all of the content.
>>>>
>>>> Therefore, I suggest we just follow the Ant route; possibly moving
>>>> incrementally if infra allows that.
>>> Let me modify the proposal to make it simpler and more palatable to
>>> infra:
>>>
>>> Just do like Ant - check in the whole mess.
>>>
>>> Phil
>>>> Phil
>>>>
>>>> [1] http://www.apache.org/dev/project-site.html
>>>>> I suppose it is possible to point to the sub-sites in their current
>>> location but in logging we found it more beneficial to simply copy the
>>> content under the main site in the CMS.
>>>>> Are all the sub-sites built with Maven? Any that are not could move to
>>> the CMS as part of the main site.
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>>>>
>>>>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>>>>> That is what we did in logging. Changing it at the end is fairly
>>> easy. However, we don't have much time for testing.
>>>>>> Do we really have to do it all at once?
>>>>>>
>>>>>> IIUC (which is quite possibly false), the intent here is to get
>>>>>> everyone onto svn pub-sub and kill off the rsync processes from
>>>>>> p.a.o to the live site. The stake in the ground is that the rsyncs
>>>>>> are going to stop Jan 1. Do I have that right?
>>>>>>
>>>>>> Why can't we move to svn pub-sub incrementally somehow,
>>>>>> understanding that until individual components move, their sites
>>>>>> will be read-only? So basically, when you decide to make changes to
>>>>>> a site, you get it set up for svn pub-sub? Note I am including the
>>>>>> main site in this - i.e., it does not have to "move" until it needs
>>>>>> to be changed. It would seem to me (again, may be missing something
>>>>>> critical) that we could build the newly definitive source svn repo
>>>>>> incrementally, with publishing always sourced from there, but "old"
>>>>>> directories on the live host remaining until they get clobbered. In
>>>>>> the worst case, if the live host *must* include only svn-published
>>>>>> files, we could seed the new repo with the "old" content. But I
>>>>>> don't get why that has to be the case; because if it is, we are in
>>>>>> worse shape than Christian suggests - come Jan 1 we will be dark if
>>>>>> we don't get everything moved to svn pub-sub.
>>>>>>
>>>>>> Sorry if above is naive. The intent is to avoid a huge amount of
>>>>>> fiddling in a short period of time when quite a few component sites
>>>>>> have not changed and will not change for some time to come.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>>>>>
>>>>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <
>>> garydgregory@gmail.com> wrote:
>>>>>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>>>>>> we have many components, unless you see a short cut.
>>>>>>>> I thought we would create: commons-test.apache.org
>>>>>>>> move all components to there and then make a switch from
>>>>>>>> commons.apache.org to the new site
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com>
>>> wrote:
>>>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>> Bah, let's pick one component and start there and skip a test
>>> site.
>>>>>>>>>> But then there is only one component visible under the new
>>> commons.a.o?
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <
>>> grobmeier@gmail.com> wrote:
>>>>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>>>>>
>>>>>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>>>>>
>>>>>>>>>>>> In other terms: let us request a commons-test cms where we can
>>> try things
>>>>>>>>>>>> out and prepare the new sites.
>>>>>>>>>>>>
>>>>>>>>>>>> As Ralph Goers has already mentioned, we have a similar
>>> structure in
>>>>>>>>>>>> logging land (1 main site, several sub sites) which might fit to
>>> Commons
>>>>>>>>>>>> too.
>>>>>>>>>>>>
>>>>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
>>> are
>>>>>>>>>>>> generated via Maven. The target of this generation is then
>>> copied to
>>>>>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>>>>>
>>>>>>>>>>>> Obviously we will have to generate sites for each component
>>> then, which
>>>>>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>>>> https://www.timeandbill.de
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>> https://www.timeandbill.de
>>>>>>>>>>
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.grobmeier.de
>>>>>>>> https://www.timeandbill.de
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, I think you are missing something fundamental.
If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
Ralph
On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:
> I don't think there's much percentage in moving to the CMS with a structure
> like that of Commons. That said, checking in the whole mess, as Phil
> suggests, seems perfectly doable and should not preclude updating parts of
> the tree in quite a similar fashion as how updating a given component's
> site is done today, except no ssh to mino. Am I missing something
> fundamental?
>
> Matt
>
>
> On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 12/10/12 11:40 AM, Phil Steitz wrote:
>>> On 12/10/12 10:50 AM, Ralph Goers wrote:
>>>> All the sub-sites are hooked off the main site. I would have no idea
>> how to migrate anything without migrating the main site first.
>>> Having now looked at [1], it looks to me like we can solve the
>>> immediate problem using svn pub-sub. The docs are not clear and
>>> they may not allow it, but in theory, we could in fact do this
>>> incrementally - start an svn repo and move the "mutable" portions
>>> there incrementally, understanding that only changes to the
>>> svn-migrated stuff will be propagated. If infra barfs on that, then
>>> we just commit the whole mess starting at the top level commons
>>> site, following the Ant example linked on [1]. Then to make
>>> changes, we follow the process that has been in place for the main
>>> ASF site for ages - maintain a local checkout of the generated site,
>>> re-gen when you want to update and check in.
>>>
>>> I know playing with the CMS might be fun and interesting; but a) we
>>> have no volunteers to do this and b) we do not have time to migrate
>>> all of the content.
>>>
>>> Therefore, I suggest we just follow the Ant route; possibly moving
>>> incrementally if infra allows that.
>>
>> Let me modify the proposal to make it simpler and more palatable to
>> infra:
>>
>> Just do like Ant - check in the whole mess.
>>
>> Phil
>>>
>>> Phil
>>>
>>> [1] http://www.apache.org/dev/project-site.html
>>>> I suppose it is possible to point to the sub-sites in their current
>> location but in logging we found it more beneficial to simply copy the
>> content under the main site in the CMS.
>>>>
>>>> Are all the sub-sites built with Maven? Any that are not could move to
>> the CMS as part of the main site.
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>>>
>>>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>>>> That is what we did in logging. Changing it at the end is fairly
>> easy. However, we don't have much time for testing.
>>>>> Do we really have to do it all at once?
>>>>>
>>>>> IIUC (which is quite possibly false), the intent here is to get
>>>>> everyone onto svn pub-sub and kill off the rsync processes from
>>>>> p.a.o to the live site. The stake in the ground is that the rsyncs
>>>>> are going to stop Jan 1. Do I have that right?
>>>>>
>>>>> Why can't we move to svn pub-sub incrementally somehow,
>>>>> understanding that until individual components move, their sites
>>>>> will be read-only? So basically, when you decide to make changes to
>>>>> a site, you get it set up for svn pub-sub? Note I am including the
>>>>> main site in this - i.e., it does not have to "move" until it needs
>>>>> to be changed. It would seem to me (again, may be missing something
>>>>> critical) that we could build the newly definitive source svn repo
>>>>> incrementally, with publishing always sourced from there, but "old"
>>>>> directories on the live host remaining until they get clobbered. In
>>>>> the worst case, if the live host *must* include only svn-published
>>>>> files, we could seed the new repo with the "old" content. But I
>>>>> don't get why that has to be the case; because if it is, we are in
>>>>> worse shape than Christian suggests - come Jan 1 we will be dark if
>>>>> we don't get everything moved to svn pub-sub.
>>>>>
>>>>> Sorry if above is naive. The intent is to avoid a huge amount of
>>>>> fiddling in a short period of time when quite a few component sites
>>>>> have not changed and will not change for some time to come.
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>>>>
>>>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <
>> garydgregory@gmail.com> wrote:
>>>>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>>>>> we have many components, unless you see a short cut.
>>>>>>> I thought we would create: commons-test.apache.org
>>>>>>> move all components to there and then make a switch from
>>>>>>> commons.apache.org to the new site
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com>
>> wrote:
>>>>>>>>
>>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
>> garydgregory@gmail.com> wrote:
>>>>>>>>>> Bah, let's pick one component and start there and skip a test
>> site.
>>>>>>>>> But then there is only one component visible under the new
>> commons.a.o?
>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <
>> grobmeier@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>>>>
>>>>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>>>>
>>>>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>>>>
>>>>>>>>>>> In other terms: let us request a commons-test cms where we can
>> try things
>>>>>>>>>>> out and prepare the new sites.
>>>>>>>>>>>
>>>>>>>>>>> As Ralph Goers has already mentioned, we have a similar
>> structure in
>>>>>>>>>>> logging land (1 main site, several sub sites) which might fit to
>> Commons
>>>>>>>>>>> too.
>>>>>>>>>>>
>>>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
>> are
>>>>>>>>>>> generated via Maven. The target of this generation is then
>> copied to
>>>>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>>>>
>>>>>>>>>>> Obviously we will have to generate sites for each component
>> then, which
>>>>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>>> https://www.timeandbill.de
>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.grobmeier.de
>>>>>>>>> https://www.timeandbill.de
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> --
>>>>>>> http://www.grobmeier.de
>>>>>>> https://www.timeandbill.de
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
I don't think there's much percentage in moving to the CMS with a structure
like that of Commons. That said, checking in the whole mess, as Phil
suggests, seems perfectly doable and should not preclude updating parts of
the tree in quite a similar fashion as how updating a given component's
site is done today, except no ssh to mino. Am I missing something
fundamental?
Matt
On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 12/10/12 11:40 AM, Phil Steitz wrote:
> > On 12/10/12 10:50 AM, Ralph Goers wrote:
> >> All the sub-sites are hooked off the main site. I would have no idea
> how to migrate anything without migrating the main site first.
> > Having now looked at [1], it looks to me like we can solve the
> > immediate problem using svn pub-sub. The docs are not clear and
> > they may not allow it, but in theory, we could in fact do this
> > incrementally - start an svn repo and move the "mutable" portions
> > there incrementally, understanding that only changes to the
> > svn-migrated stuff will be propagated. If infra barfs on that, then
> > we just commit the whole mess starting at the top level commons
> > site, following the Ant example linked on [1]. Then to make
> > changes, we follow the process that has been in place for the main
> > ASF site for ages - maintain a local checkout of the generated site,
> > re-gen when you want to update and check in.
> >
> > I know playing with the CMS might be fun and interesting; but a) we
> > have no volunteers to do this and b) we do not have time to migrate
> > all of the content.
> >
> > Therefore, I suggest we just follow the Ant route; possibly moving
> > incrementally if infra allows that.
>
> Let me modify the proposal to make it simpler and more palatable to
> infra:
>
> Just do like Ant - check in the whole mess.
>
> Phil
> >
> > Phil
> >
> > [1] http://www.apache.org/dev/project-site.html
> >> I suppose it is possible to point to the sub-sites in their current
> location but in logging we found it more beneficial to simply copy the
> content under the main site in the CMS.
> >>
> >> Are all the sub-sites built with Maven? Any that are not could move to
> the CMS as part of the main site.
> >>
> >> Ralph
> >>
> >>
> >> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
> >>
> >>> On 12/10/12 7:55 AM, Ralph Goers wrote:
> >>>> That is what we did in logging. Changing it at the end is fairly
> easy. However, we don't have much time for testing.
> >>> Do we really have to do it all at once?
> >>>
> >>> IIUC (which is quite possibly false), the intent here is to get
> >>> everyone onto svn pub-sub and kill off the rsync processes from
> >>> p.a.o to the live site. The stake in the ground is that the rsyncs
> >>> are going to stop Jan 1. Do I have that right?
> >>>
> >>> Why can't we move to svn pub-sub incrementally somehow,
> >>> understanding that until individual components move, their sites
> >>> will be read-only? So basically, when you decide to make changes to
> >>> a site, you get it set up for svn pub-sub? Note I am including the
> >>> main site in this - i.e., it does not have to "move" until it needs
> >>> to be changed. It would seem to me (again, may be missing something
> >>> critical) that we could build the newly definitive source svn repo
> >>> incrementally, with publishing always sourced from there, but "old"
> >>> directories on the live host remaining until they get clobbered. In
> >>> the worst case, if the live host *must* include only svn-published
> >>> files, we could seed the new repo with the "old" content. But I
> >>> don't get why that has to be the case; because if it is, we are in
> >>> worse shape than Christian suggests - come Jan 1 we will be dark if
> >>> we don't get everything moved to svn pub-sub.
> >>>
> >>> Sorry if above is naive. The intent is to avoid a huge amount of
> >>> fiddling in a short period of time when quite a few component sites
> >>> have not changed and will not change for some time to come.
> >>>
> >>> Phil
> >>>
> >>>
> >>>> Ralph
> >>>>
> >>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
> >>>>
> >>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <
> garydgregory@gmail.com> wrote:
> >>>>>> Well, we have to start somewhere. This is going to be a lot of work,
> >>>>>> we have many components, unless you see a short cut.
> >>>>> I thought we would create: commons-test.apache.org
> >>>>> move all components to there and then make a switch from
> >>>>> commons.apache.org to the new site
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
> garydgregory@gmail.com> wrote:
> >>>>>>>> Bah, let's pick one component and start there and skip a test
> site.
> >>>>>>> But then there is only one component visible under the new
> commons.a.o?
> >>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <
> grobmeier@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
> >>>>>>>>>
> >>>>>>>>> Commons is surely a LOT of work.
> >>>>>>>>>
> >>>>>>>>> I would like to suggest we act immediately.
> >>>>>>>>>
> >>>>>>>>> In other terms: let us request a commons-test cms where we can
> try things
> >>>>>>>>> out and prepare the new sites.
> >>>>>>>>>
> >>>>>>>>> As Ralph Goers has already mentioned, we have a similar
> structure in
> >>>>>>>>> logging land (1 main site, several sub sites) which might fit to
> Commons
> >>>>>>>>> too.
> >>>>>>>>>
> >>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
> are
> >>>>>>>>> generated via Maven. The target of this generation is then
> copied to
> >>>>>>>>> another svn tree from which it will be taken and published.
> >>>>>>>>>
> >>>>>>>>> Obviously we will have to generate sites for each component
> then, which
> >>>>>>>>> will be a tough job with x-mas arriving.
> >>>>>>>>>
> >>>>>>>>> Thoughts?
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> http://www.grobmeier.de
> >>>>>>>>> https://www.timeandbill.de
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>> --
> >>>>>>> http://www.grobmeier.de
> >>>>>>> https://www.timeandbill.de
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>> --
> >>>>> http://www.grobmeier.de
> >>>>> https://www.timeandbill.de
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/10/12 11:40 AM, Phil Steitz wrote:
> On 12/10/12 10:50 AM, Ralph Goers wrote:
>> All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first.
> Having now looked at [1], it looks to me like we can solve the
> immediate problem using svn pub-sub. The docs are not clear and
> they may not allow it, but in theory, we could in fact do this
> incrementally - start an svn repo and move the "mutable" portions
> there incrementally, understanding that only changes to the
> svn-migrated stuff will be propagated. If infra barfs on that, then
> we just commit the whole mess starting at the top level commons
> site, following the Ant example linked on [1]. Then to make
> changes, we follow the process that has been in place for the main
> ASF site for ages - maintain a local checkout of the generated site,
> re-gen when you want to update and check in.
>
> I know playing with the CMS might be fun and interesting; but a) we
> have no volunteers to do this and b) we do not have time to migrate
> all of the content.
>
> Therefore, I suggest we just follow the Ant route; possibly moving
> incrementally if infra allows that.
Let me modify the proposal to make it simpler and more palatable to
infra:
Just do like Ant - check in the whole mess.
Phil
>
> Phil
>
> [1] http://www.apache.org/dev/project-site.html
>> I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS.
>>
>> Are all the sub-sites built with Maven? Any that are not could move to the CMS as part of the main site.
>>
>> Ralph
>>
>>
>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>
>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>> That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
>>> Do we really have to do it all at once?
>>>
>>> IIUC (which is quite possibly false), the intent here is to get
>>> everyone onto svn pub-sub and kill off the rsync processes from
>>> p.a.o to the live site. The stake in the ground is that the rsyncs
>>> are going to stop Jan 1. Do I have that right?
>>>
>>> Why can't we move to svn pub-sub incrementally somehow,
>>> understanding that until individual components move, their sites
>>> will be read-only? So basically, when you decide to make changes to
>>> a site, you get it set up for svn pub-sub? Note I am including the
>>> main site in this - i.e., it does not have to "move" until it needs
>>> to be changed. It would seem to me (again, may be missing something
>>> critical) that we could build the newly definitive source svn repo
>>> incrementally, with publishing always sourced from there, but "old"
>>> directories on the live host remaining until they get clobbered. In
>>> the worst case, if the live host *must* include only svn-published
>>> files, we could seed the new repo with the "old" content. But I
>>> don't get why that has to be the case; because if it is, we are in
>>> worse shape than Christian suggests - come Jan 1 we will be dark if
>>> we don't get everything moved to svn pub-sub.
>>>
>>> Sorry if above is naive. The intent is to avoid a huge amount of
>>> fiddling in a short period of time when quite a few component sites
>>> have not changed and will not change for some time to come.
>>>
>>> Phil
>>>
>>>
>>>> Ralph
>>>>
>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>>
>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>>> we have many components, unless you see a short cut.
>>>>> I thought we would create: commons-test.apache.org
>>>>> move all components to there and then make a switch from
>>>>> commons.apache.org to the new site
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>
>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>>> Bah, let's pick one component and start there and skip a test site.
>>>>>>> But then there is only one component visible under the new commons.a.o?
>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>>
>>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>>
>>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>>
>>>>>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>>>>>> out and prepare the new sites.
>>>>>>>>>
>>>>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>>>>> too.
>>>>>>>>>
>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>>
>>>>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.grobmeier.de
>>>>>>>>> https://www.timeandbill.de
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> --
>>>>>>> http://www.grobmeier.de
>>>>>>> https://www.timeandbill.de
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/10/12 10:50 AM, Ralph Goers wrote:
> All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first.
Having now looked at [1], it looks to me like we can solve the
immediate problem using svn pub-sub. The docs are not clear and
they may not allow it, but in theory, we could in fact do this
incrementally - start an svn repo and move the "mutable" portions
there incrementally, understanding that only changes to the
svn-migrated stuff will be propagated. If infra barfs on that, then
we just commit the whole mess starting at the top level commons
site, following the Ant example linked on [1]. Then to make
changes, we follow the process that has been in place for the main
ASF site for ages - maintain a local checkout of the generated site,
re-gen when you want to update and check in.
I know playing with the CMS might be fun and interesting; but a) we
have no volunteers to do this and b) we do not have time to migrate
all of the content.
Therefore, I suggest we just follow the Ant route; possibly moving
incrementally if infra allows that.
Phil
[1] http://www.apache.org/dev/project-site.html
>
> I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS.
>
> Are all the sub-sites built with Maven? Any that are not could move to the CMS as part of the main site.
>
> Ralph
>
>
> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>
>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>> That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
>> Do we really have to do it all at once?
>>
>> IIUC (which is quite possibly false), the intent here is to get
>> everyone onto svn pub-sub and kill off the rsync processes from
>> p.a.o to the live site. The stake in the ground is that the rsyncs
>> are going to stop Jan 1. Do I have that right?
>>
>> Why can't we move to svn pub-sub incrementally somehow,
>> understanding that until individual components move, their sites
>> will be read-only? So basically, when you decide to make changes to
>> a site, you get it set up for svn pub-sub? Note I am including the
>> main site in this - i.e., it does not have to "move" until it needs
>> to be changed. It would seem to me (again, may be missing something
>> critical) that we could build the newly definitive source svn repo
>> incrementally, with publishing always sourced from there, but "old"
>> directories on the live host remaining until they get clobbered. In
>> the worst case, if the live host *must* include only svn-published
>> files, we could seed the new repo with the "old" content. But I
>> don't get why that has to be the case; because if it is, we are in
>> worse shape than Christian suggests - come Jan 1 we will be dark if
>> we don't get everything moved to svn pub-sub.
>>
>> Sorry if above is naive. The intent is to avoid a huge amount of
>> fiddling in a short period of time when quite a few component sites
>> have not changed and will not change for some time to come.
>>
>> Phil
>>
>>
>>> Ralph
>>>
>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>
>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>> we have many components, unless you see a short cut.
>>>> I thought we would create: commons-test.apache.org
>>>> move all components to there and then make a switch from
>>>> commons.apache.org to the new site
>>>>
>>>>
>>>>
>>>>
>>>>> Gary
>>>>>
>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>
>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> Bah, let's pick one component and start there and skip a test site.
>>>>>> But then there is only one component visible under the new commons.a.o?
>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>>
>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>
>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>
>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>
>>>>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>>>>> out and prepare the new sites.
>>>>>>>>
>>>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>>>> too.
>>>>>>>>
>>>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>
>>>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.grobmeier.de
>>>>>>>> https://www.timeandbill.de
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.grobmeier.de
>>>>>> https://www.timeandbill.de
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Matt Benson <gu...@gmail.com>.
They should all be built w/ Maven AFAIK.
Matt
On Mon, Dec 10, 2012 at 12:50 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> All the sub-sites are hooked off the main site. I would have no idea how
> to migrate anything without migrating the main site first.
>
> I suppose it is possible to point to the sub-sites in their current
> location but in logging we found it more beneficial to simply copy the
> content under the main site in the CMS.
>
> Are all the sub-sites built with Maven? Any that are not could move to
> the CMS as part of the main site.
>
> Ralph
>
>
> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>
> > On 12/10/12 7:55 AM, Ralph Goers wrote:
> >> That is what we did in logging. Changing it at the end is fairly easy.
> However, we don't have much time for testing.
> >
> > Do we really have to do it all at once?
> >
> > IIUC (which is quite possibly false), the intent here is to get
> > everyone onto svn pub-sub and kill off the rsync processes from
> > p.a.o to the live site. The stake in the ground is that the rsyncs
> > are going to stop Jan 1. Do I have that right?
> >
> > Why can't we move to svn pub-sub incrementally somehow,
> > understanding that until individual components move, their sites
> > will be read-only? So basically, when you decide to make changes to
> > a site, you get it set up for svn pub-sub? Note I am including the
> > main site in this - i.e., it does not have to "move" until it needs
> > to be changed. It would seem to me (again, may be missing something
> > critical) that we could build the newly definitive source svn repo
> > incrementally, with publishing always sourced from there, but "old"
> > directories on the live host remaining until they get clobbered. In
> > the worst case, if the live host *must* include only svn-published
> > files, we could seed the new repo with the "old" content. But I
> > don't get why that has to be the case; because if it is, we are in
> > worse shape than Christian suggests - come Jan 1 we will be dark if
> > we don't get everything moved to svn pub-sub.
> >
> > Sorry if above is naive. The intent is to avoid a huge amount of
> > fiddling in a short period of time when quite a few component sites
> > have not changed and will not change for some time to come.
> >
> > Phil
> >
> >
> >>
> >> Ralph
> >>
> >> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
> >>
> >>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>>> Well, we have to start somewhere. This is going to be a lot of work,
> >>>> we have many components, unless you see a short cut.
> >>> I thought we would create: commons-test.apache.org
> >>> move all components to there and then make a switch from
> >>> commons.apache.org to the new site
> >>>
> >>>
> >>>
> >>>
> >>>> Gary
> >>>>
> >>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com>
> wrote:
> >>>>
> >>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
> garydgregory@gmail.com> wrote:
> >>>>>> Bah, let's pick one component and start there and skip a test site.
> >>>>> But then there is only one component visible under the new
> commons.a.o?
> >>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> starting from 1. January. Just saw a final reminder from Infra.
> >>>>>>>
> >>>>>>> Commons is surely a LOT of work.
> >>>>>>>
> >>>>>>> I would like to suggest we act immediately.
> >>>>>>>
> >>>>>>> In other terms: let us request a commons-test cms where we can try
> things
> >>>>>>> out and prepare the new sites.
> >>>>>>>
> >>>>>>> As Ralph Goers has already mentioned, we have a similar structure
> in
> >>>>>>> logging land (1 main site, several sub sites) which might fit to
> Commons
> >>>>>>> too.
> >>>>>>>
> >>>>>>> Basically we have the Main-Site under CMS control; the subsites are
> >>>>>>> generated via Maven. The target of this generation is then copied
> to
> >>>>>>> another svn tree from which it will be taken and published.
> >>>>>>>
> >>>>>>> Obviously we will have to generate sites for each component then,
> which
> >>>>>>> will be a tough job with x-mas arriving.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>> --
> >>>>>>> http://www.grobmeier.de
> >>>>>>> https://www.timeandbill.de
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://www.grobmeier.de
> >>>>> https://www.timeandbill.de
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>
> >>>
> >>> --
> >>> http://www.grobmeier.de
> >>> https://www.timeandbill.de
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: We will not be able to update our websites...
Posted by Christian Grobmeier <gr...@gmail.com>.
On Mon, Dec 10, 2012 at 7:50 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first.
>
> I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS.
>
> Are all the sub-sites built with Maven?
Yes, but to my knowledge different versions of maven (2 vs 3).
> Any that are not could move to the CMS as part of the main site.
Actually I think it would be good for Commons too. Some projects may
keep some old version websites. Therefore it might be nice to maintain
the mainsite with the CMS and copy/paste the components to the svn
part.
Just my 2 cents.
>
> Ralph
>
>
> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>
>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>> That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
>>
>> Do we really have to do it all at once?
>>
>> IIUC (which is quite possibly false), the intent here is to get
>> everyone onto svn pub-sub and kill off the rsync processes from
>> p.a.o to the live site. The stake in the ground is that the rsyncs
>> are going to stop Jan 1. Do I have that right?
>>
>> Why can't we move to svn pub-sub incrementally somehow,
>> understanding that until individual components move, their sites
>> will be read-only? So basically, when you decide to make changes to
>> a site, you get it set up for svn pub-sub? Note I am including the
>> main site in this - i.e., it does not have to "move" until it needs
>> to be changed. It would seem to me (again, may be missing something
>> critical) that we could build the newly definitive source svn repo
>> incrementally, with publishing always sourced from there, but "old"
>> directories on the live host remaining until they get clobbered. In
>> the worst case, if the live host *must* include only svn-published
>> files, we could seed the new repo with the "old" content. But I
>> don't get why that has to be the case; because if it is, we are in
>> worse shape than Christian suggests - come Jan 1 we will be dark if
>> we don't get everything moved to svn pub-sub.
>>
>> Sorry if above is naive. The intent is to avoid a huge amount of
>> fiddling in a short period of time when quite a few component sites
>> have not changed and will not change for some time to come.
>>
>> Phil
>>
>>
>>>
>>> Ralph
>>>
>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>
>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>> we have many components, unless you see a short cut.
>>>> I thought we would create: commons-test.apache.org
>>>> move all components to there and then make a switch from
>>>> commons.apache.org to the new site
>>>>
>>>>
>>>>
>>>>
>>>>> Gary
>>>>>
>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>
>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> Bah, let's pick one component and start there and skip a test site.
>>>>>> But then there is only one component visible under the new commons.a.o?
>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>>
>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>
>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>
>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>
>>>>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>>>>> out and prepare the new sites.
>>>>>>>>
>>>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>>>> too.
>>>>>>>>
>>>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>
>>>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.grobmeier.de
>>>>>>>> https://www.timeandbill.de
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.grobmeier.de
>>>>>> https://www.timeandbill.de
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first.
I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS.
Are all the sub-sites built with Maven? Any that are not could move to the CMS as part of the main site.
Ralph
On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
> On 12/10/12 7:55 AM, Ralph Goers wrote:
>> That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
>
> Do we really have to do it all at once?
>
> IIUC (which is quite possibly false), the intent here is to get
> everyone onto svn pub-sub and kill off the rsync processes from
> p.a.o to the live site. The stake in the ground is that the rsyncs
> are going to stop Jan 1. Do I have that right?
>
> Why can't we move to svn pub-sub incrementally somehow,
> understanding that until individual components move, their sites
> will be read-only? So basically, when you decide to make changes to
> a site, you get it set up for svn pub-sub? Note I am including the
> main site in this - i.e., it does not have to "move" until it needs
> to be changed. It would seem to me (again, may be missing something
> critical) that we could build the newly definitive source svn repo
> incrementally, with publishing always sourced from there, but "old"
> directories on the live host remaining until they get clobbered. In
> the worst case, if the live host *must* include only svn-published
> files, we could seed the new repo with the "old" content. But I
> don't get why that has to be the case; because if it is, we are in
> worse shape than Christian suggests - come Jan 1 we will be dark if
> we don't get everything moved to svn pub-sub.
>
> Sorry if above is naive. The intent is to avoid a huge amount of
> fiddling in a short period of time when quite a few component sites
> have not changed and will not change for some time to come.
>
> Phil
>
>
>>
>> Ralph
>>
>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>
>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>> we have many components, unless you see a short cut.
>>> I thought we would create: commons-test.apache.org
>>> move all components to there and then make a switch from
>>> commons.apache.org to the new site
>>>
>>>
>>>
>>>
>>>> Gary
>>>>
>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>
>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>> Bah, let's pick one component and start there and skip a test site.
>>>>> But then there is only one component visible under the new commons.a.o?
>>>>>
>>>>>> Gary
>>>>>>
>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>>
>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>
>>>>>>> Commons is surely a LOT of work.
>>>>>>>
>>>>>>> I would like to suggest we act immediately.
>>>>>>>
>>>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>>>> out and prepare the new sites.
>>>>>>>
>>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>>> too.
>>>>>>>
>>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>
>>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> --
>>>>>>> http://www.grobmeier.de
>>>>>>> https://www.timeandbill.de
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Phil Steitz <ph...@gmail.com>.
On 12/10/12 7:55 AM, Ralph Goers wrote:
> That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
Do we really have to do it all at once?
IIUC (which is quite possibly false), the intent here is to get
everyone onto svn pub-sub and kill off the rsync processes from
p.a.o to the live site. The stake in the ground is that the rsyncs
are going to stop Jan 1. Do I have that right?
Why can't we move to svn pub-sub incrementally somehow,
understanding that until individual components move, their sites
will be read-only? So basically, when you decide to make changes to
a site, you get it set up for svn pub-sub? Note I am including the
main site in this - i.e., it does not have to "move" until it needs
to be changed. It would seem to me (again, may be missing something
critical) that we could build the newly definitive source svn repo
incrementally, with publishing always sourced from there, but "old"
directories on the live host remaining until they get clobbered. In
the worst case, if the live host *must* include only svn-published
files, we could seed the new repo with the "old" content. But I
don't get why that has to be the case; because if it is, we are in
worse shape than Christian suggests - come Jan 1 we will be dark if
we don't get everything moved to svn pub-sub.
Sorry if above is naive. The intent is to avoid a huge amount of
fiddling in a short period of time when quite a few component sites
have not changed and will not change for some time to come.
Phil
>
> Ralph
>
> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>
>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>>> Well, we have to start somewhere. This is going to be a lot of work,
>>> we have many components, unless you see a short cut.
>> I thought we would create: commons-test.apache.org
>> move all components to there and then make a switch from
>> commons.apache.org to the new site
>>
>>
>>
>>
>>> Gary
>>>
>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>>
>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> Bah, let's pick one component and start there and skip a test site.
>>>> But then there is only one component visible under the new commons.a.o?
>>>>
>>>>> Gary
>>>>>
>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>>
>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>
>>>>>> Commons is surely a LOT of work.
>>>>>>
>>>>>> I would like to suggest we act immediately.
>>>>>>
>>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>>> out and prepare the new sites.
>>>>>>
>>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>>> too.
>>>>>>
>>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>>> generated via Maven. The target of this generation is then copied to
>>>>>> another svn tree from which it will be taken and published.
>>>>>>
>>>>>> Obviously we will have to generate sites for each component then, which
>>>>>> will be a tough job with x-mas arriving.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> --
>>>>>> http://www.grobmeier.de
>>>>>> https://www.timeandbill.de
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Ralph Goers <ra...@dslextreme.com>.
That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing.
Ralph
On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
>> Well, we have to start somewhere. This is going to be a lot of work,
>> we have many components, unless you see a short cut.
>
> I thought we would create: commons-test.apache.org
> move all components to there and then make a switch from
> commons.apache.org to the new site
>
>
>
>
>> Gary
>>
>> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>>
>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>> Bah, let's pick one component and start there and skip a test site.
>>>
>>> But then there is only one component visible under the new commons.a.o?
>>>
>>>> Gary
>>>>
>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>>
>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>
>>>>> Commons is surely a LOT of work.
>>>>>
>>>>> I would like to suggest we act immediately.
>>>>>
>>>>> In other terms: let us request a commons-test cms where we can try things
>>>>> out and prepare the new sites.
>>>>>
>>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>>> too.
>>>>>
>>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>>> generated via Maven. The target of this generation is then copied to
>>>>> another svn tree from which it will be taken and published.
>>>>>
>>>>> Obviously we will have to generate sites for each component then, which
>>>>> will be a tough job with x-mas arriving.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Gary Gregory <ga...@gmail.com>.
Hm... or publish to SVN until we have it all and then switch, until then
the site will be static.
G
On Mon, Dec 10, 2012 at 7:34 AM, Christian Grobmeier <gr...@gmail.com>wrote:
> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> > Well, we have to start somewhere. This is going to be a lot of work,
> > we have many components, unless you see a short cut.
>
> I thought we would create: commons-test.apache.org
> move all components to there and then make a switch from
> commons.apache.org to the new site
>
>
>
>
> > Gary
> >
> > On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com>
> wrote:
> >
> >> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>> Bah, let's pick one component and start there and skip a test site.
> >>
> >> But then there is only one component visible under the new commons.a.o?
> >>
> >>> Gary
> >>>
> >>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com>
> wrote:
> >>>
> >>>> starting from 1. January. Just saw a final reminder from Infra.
> >>>>
> >>>> Commons is surely a LOT of work.
> >>>>
> >>>> I would like to suggest we act immediately.
> >>>>
> >>>> In other terms: let us request a commons-test cms where we can try
> things
> >>>> out and prepare the new sites.
> >>>>
> >>>> As Ralph Goers has already mentioned, we have a similar structure in
> >>>> logging land (1 main site, several sub sites) which might fit to
> Commons
> >>>> too.
> >>>>
> >>>> Basically we have the Main-Site under CMS control; the subsites are
> >>>> generated via Maven. The target of this generation is then copied to
> >>>> another svn tree from which it will be taken and published.
> >>>>
> >>>> Obviously we will have to generate sites for each component then,
> which
> >>>> will be a tough job with x-mas arriving.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> --
> >>>> http://www.grobmeier.de
> >>>> https://www.timeandbill.de
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> http://www.grobmeier.de
> >> https://www.timeandbill.de
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: We will not be able to update our websites...
Posted by Christian Grobmeier <gr...@gmail.com>.
On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <ga...@gmail.com> wrote:
> Well, we have to start somewhere. This is going to be a lot of work,
> we have many components, unless you see a short cut.
I thought we would create: commons-test.apache.org
move all components to there and then make a switch from
commons.apache.org to the new site
> Gary
>
> On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
>
>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>>> Bah, let's pick one component and start there and skip a test site.
>>
>> But then there is only one component visible under the new commons.a.o?
>>
>>> Gary
>>>
>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>>
>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>
>>>> Commons is surely a LOT of work.
>>>>
>>>> I would like to suggest we act immediately.
>>>>
>>>> In other terms: let us request a commons-test cms where we can try things
>>>> out and prepare the new sites.
>>>>
>>>> As Ralph Goers has already mentioned, we have a similar structure in
>>>> logging land (1 main site, several sub sites) which might fit to Commons
>>>> too.
>>>>
>>>> Basically we have the Main-Site under CMS control; the subsites are
>>>> generated via Maven. The target of this generation is then copied to
>>>> another svn tree from which it will be taken and published.
>>>>
>>>> Obviously we will have to generate sites for each component then, which
>>>> will be a tough job with x-mas arriving.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Gary Gregory <ga...@gmail.com>.
Well, we have to start somewhere. This is going to be a lot of work,
we have many components, unless you see a short cut.
Gary
On Dec 10, 2012, at 7:13, Christian Grobmeier <gr...@gmail.com> wrote:
> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
>> Bah, let's pick one component and start there and skip a test site.
>
> But then there is only one component visible under the new commons.a.o?
>
>> Gary
>>
>> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>>
>>> starting from 1. January. Just saw a final reminder from Infra.
>>>
>>> Commons is surely a LOT of work.
>>>
>>> I would like to suggest we act immediately.
>>>
>>> In other terms: let us request a commons-test cms where we can try things
>>> out and prepare the new sites.
>>>
>>> As Ralph Goers has already mentioned, we have a similar structure in
>>> logging land (1 main site, several sub sites) which might fit to Commons
>>> too.
>>>
>>> Basically we have the Main-Site under CMS control; the subsites are
>>> generated via Maven. The target of this generation is then copied to
>>> another svn tree from which it will be taken and published.
>>>
>>> Obviously we will have to generate sites for each component then, which
>>> will be a tough job with x-mas arriving.
>>>
>>> Thoughts?
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Christian Grobmeier <gr...@gmail.com>.
On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <ga...@gmail.com> wrote:
> Bah, let's pick one component and start there and skip a test site.
But then there is only one component visible under the new commons.a.o?
> Gary
>
> On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
>
>> starting from 1. January. Just saw a final reminder from Infra.
>>
>> Commons is surely a LOT of work.
>>
>> I would like to suggest we act immediately.
>>
>> In other terms: let us request a commons-test cms where we can try things
>> out and prepare the new sites.
>>
>> As Ralph Goers has already mentioned, we have a similar structure in
>> logging land (1 main site, several sub sites) which might fit to Commons
>> too.
>>
>> Basically we have the Main-Site under CMS control; the subsites are
>> generated via Maven. The target of this generation is then copied to
>> another svn tree from which it will be taken and published.
>>
>> Obviously we will have to generate sites for each component then, which
>> will be a tough job with x-mas arriving.
>>
>> Thoughts?
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: We will not be able to update our websites...
Posted by Gary Gregory <ga...@gmail.com>.
Bah, let's pick one component and start there and skip a test site.
Gary
On Dec 10, 2012, at 3:08, Christian Grobmeier <gr...@gmail.com> wrote:
> starting from 1. January. Just saw a final reminder from Infra.
>
> Commons is surely a LOT of work.
>
> I would like to suggest we act immediately.
>
> In other terms: let us request a commons-test cms where we can try things
> out and prepare the new sites.
>
> As Ralph Goers has already mentioned, we have a similar structure in
> logging land (1 main site, several sub sites) which might fit to Commons
> too.
>
> Basically we have the Main-Site under CMS control; the subsites are
> generated via Maven. The target of this generation is then copied to
> another svn tree from which it will be taken and published.
>
> Obviously we will have to generate sites for each component then, which
> will be a tough job with x-mas arriving.
>
> Thoughts?
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org