You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Gert Vanthienen <ge...@gmail.com> on 2012/09/03 20:50:40 UTC
Migration of website to svnpubsub
L.S.,
I have been looking into the mandatory migration of our website to
svnpubsub today and it looks like the easiest solution would be to
simply use the Wagen SVN provider to publish our existing website
pages to a location in Subversion. That would involve a few minor POM
changes and it worksfor both the main website project and the
documentation branches. We could e.g. configure them to publish to
https://svn.apache.org/repos/asf/servicemix/site
Once we modified those two projects, the only thing missing would be
the Confluence-generated content - I would suggest we just copy the
current contents as-is into the same SVN location, so we can keep
those pages around in http://servicemix.apache.org/old for now. The
contents is largely obsolete, but perhaps some people still depend on
some of this information for older ServiceMix 3.x deployments.
There a few drawbacks to that approach that I can see, but none of
them are really blocking in my mind:
- the commits to the website publishing location are being done by
wagon and they all have the same commit message - this should not be a
big problem because we still have the actual
servicemix-documentation/servicemix-website project commits to
communicate the actual change to the Scalate pages
- at present, the wagon mechanism is unable to delete files from the
publishing location that have been deleted from the Scalate codebase -
we actually have the same problem with the SCP publishing mechanism we
are using today
Once we have migrated to svnpubsub though, it also becomes easier to
delete the stale pages because we can just remove them from SVN. The
real benefit for us would be that those deletions as well as any
changes we make to the documentation or website will be published
immediately after we commit them.
If this sounds OK to everyone, I'll make the necessary changes to the
POMs tomorrow and will publish the result on a machine of mine, so we
can ensure that everything looks OK before we ask infra@ to flip the
switch for the main website.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Re: Migration of website to svnpubsub
Posted by Freeman Fang <fr...@gmail.com>.
+1 given we can still get back the old stuff if necessary.
Thanks
－－－－－－－－－－－－－
Freeman Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-9-22, at 下午10:24, Gert Vanthienen wrote:
> L.S.,
>
>
> As you might have noticed from the mails on the commits@ mailing list,
> I have been working on moving the generated contents from both our
> website and documentation subproject over to svn for publication using
> svnpubsub. I have temporarily made a copy of the resulting website
> available on http://people.apache.org/~gertv/smx/ for evaluation
> purposes and that seems to work out fine.
>
> While trying to move the old website contents over, I noticed it is
> quite a beefy commit (over 1300 pages, over 60 MB of contents) so I'll
> have to find a quiet time to commit that. But the real question is :
> do we really want to keep those pages around?
>
> We have already gone over that contents twice to find useful bits and
> migrate those to the website/documentation project, so perhaps we
> should just drop the '/old' stuff from the svnpubsub migration. If we
> encounter any useful bits that are missing afterwards, it probably
> makes more sense to have them in the documentation/website projects
> anyway (we can still cherry-pick that contents from Confluence using
> the Scalate plugin) where they can be maintained, so in my mind this
> would be a good time to get rid of the old website copy.
>
>
> Wdyt?
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
> On Mon, Sep 17, 2012 at 2:29 AM, Freeman Fang <fr...@gmail.com> wrote:
>> +1
>>
>> Thanks
>> Freeman
>> －－－－－－－－－－－－－
>> Freeman Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>> On 2012-9-17, at 上午4:10, Gert Vanthienen wrote:
>>
>>> L.S.,
>>>
>>>
>>> At the builds@ mailing list, a few people recommended the
>>> maven-scm-publish-plugin over the wagon-svn adapter, which can take
>>> care of the deletions and also allows for nicer commit messages. This
>>> would take care of the initial two drawbacks I mentioned in my initial
>>> mail in this thread.
>>>
>>> If that's OK for everyone, I'll start configuring our builds to use
>>> this and prepare for a temporary location so we can see the result
>>> before we ask infra to flip the switch.
>>>
>>> I have not yet been able to make much progress on getting the extra
>>> information required to further automate this using buildbot, but we
>>> can always pursue that separately afterwards if necessary. For now, I
>>> would prefer to get this migration to svnpubsub done so we can start
>>> leveraging the faster publishing to the public website.
>>>
>>>
>>> Wdyt?
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>> On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
>>> <ge...@gmail.com> wrote:
>>>> L.S.,
>>>>
>>>>> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>>>>>
>>>>> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
>>>>
>>>> Yeah, I think it should be possible to set that up as well - we are
>>>> using two external tools in the documentation generation process that
>>>> might be a problem: Pygments to generate the CSS-markup for the code
>>>> snippets and Prince XML to generate the PDF variants for the
>>>> documentation. We would have to get in touch with infra@ to figure
>>>> out what's possible - I think the former is already available (think I
>>>> have seen it being mentioned on the CMS/svnpubsub discussions before).
>>>> The real issue might be that we have separate builds for the website
>>>> and the documentation sections, to allow for version-based
>>>> documentation.
>>>>
>>>>
>>>>> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>>>>>
>>>>> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
>>>>
>>>> Personally, I'd rather spend time adding contents to our documentation
>>>> base than converting it to the CMS, but I'm open to anything here: if
>>>> someone wants to give this option a go or look into it, this is fine
>>>> for me too.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert
>>
Re: Migration of website to svnpubsub
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
OK, if we leave the old stuff out for now, the contents in
http://people.apache.org/~gertv/smx/ and
http://people.apache.org/~gertv/smx/docs/4.4.x/ is pretty much what we
want to move forward with. I'll give people until tomorrow to see if
there's anything obvious missing and then I'll ask INFRA to flip the
switch to the new svnpubsub website contents.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Sep 24, 2012 at 7:55 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> +1
>
> Regards
> JB
>
>
> On 09/22/2012 04:24 PM, Gert Vanthienen wrote:
>>
>> L.S.,
>>
>>
>> As you might have noticed from the mails on the commits@ mailing list,
>> I have been working on moving the generated contents from both our
>> website and documentation subproject over to svn for publication using
>> svnpubsub. I have temporarily made a copy of the resulting website
>> available on http://people.apache.org/~gertv/smx/ for evaluation
>> purposes and that seems to work out fine.
>>
>> While trying to move the old website contents over, I noticed it is
>> quite a beefy commit (over 1300 pages, over 60 MB of contents) so I'll
>> have to find a quiet time to commit that. But the real question is :
>> do we really want to keep those pages around?
>>
>> We have already gone over that contents twice to find useful bits and
>> migrate those to the website/documentation project, so perhaps we
>> should just drop the '/old' stuff from the svnpubsub migration. If we
>> encounter any useful bits that are missing afterwards, it probably
>> makes more sense to have them in the documentation/website projects
>> anyway (we can still cherry-pick that contents from Confluence using
>> the Scalate plugin) where they can be maintained, so in my mind this
>> would be a good time to get rid of the old website copy.
>>
>>
>> Wdyt?
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>> On Mon, Sep 17, 2012 at 2:29 AM, Freeman Fang <fr...@gmail.com>
>> wrote:
>>>
>>> +1
>>>
>>> Thanks
>>> Freeman
>>> －－－－－－－－－－－－－
>>> Freeman Fang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>> http://blog.sina.com.cn/u/1473905042
>>> weibo: http://weibo.com/u/1473905042
>>>
>>> On 2012-9-17, at 上午4:10, Gert Vanthienen wrote:
>>>
>>>> L.S.,
>>>>
>>>>
>>>> At the builds@ mailing list, a few people recommended the
>>>> maven-scm-publish-plugin over the wagon-svn adapter, which can take
>>>> care of the deletions and also allows for nicer commit messages. This
>>>> would take care of the initial two drawbacks I mentioned in my initial
>>>> mail in this thread.
>>>>
>>>> If that's OK for everyone, I'll start configuring our builds to use
>>>> this and prepare for a temporary location so we can see the result
>>>> before we ask infra to flip the switch.
>>>>
>>>> I have not yet been able to make much progress on getting the extra
>>>> information required to further automate this using buildbot, but we
>>>> can always pursue that separately afterwards if necessary. For now, I
>>>> would prefer to get this migration to svnpubsub done so we can start
>>>> leveraging the faster publishing to the public website.
>>>>
>>>>
>>>> Wdyt?
>>>>
>>>> Gert Vanthienen
>>>> ------------------------
>>>> FuseSource
>>>> Web: http://fusesource.com
>>>> Blog: http://gertvanthienen.blogspot.com/
>>>>
>>>>
>>>> On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
>>>> <ge...@gmail.com> wrote:
>>>>>
>>>>> L.S.,
>>>>>
>>>>>> CXF and Camel (and ActiveMQ) are a bit different in that they still
>>>>>> maintain their sites and all content in Confluence. ServiceMix has changed
>>>>>> to using a maven site stuff.
>>>>>>
>>>>>> HOWEVER, there may even be an easier solution. If the maven build
>>>>>> can be setup to accept and output directory (instead of target/site or
>>>>>> whatever), you can have infrastructure setup a buildbot build that will run
>>>>>> the build and automatically handle all the svn stuff. It would trigger on
>>>>>> checkin of the site source, build, publish, etc… all automatically.
>>>>>> Developers would never need to "site-deploy" or anything like that.
>>>>>
>>>>>
>>>>> Yeah, I think it should be possible to set that up as well - we are
>>>>> using two external tools in the documentation generation process that
>>>>> might be a problem: Pygments to generate the CSS-markup for the code
>>>>> snippets and Prince XML to generate the PDF variants for the
>>>>> documentation. We would have to get in touch with infra@ to figure
>>>>> out what's possible - I think the former is already available (think I
>>>>> have seen it being mentioned on the CMS/svnpubsub discussions before).
>>>>> The real issue might be that we have separate builds for the website
>>>>> and the documentation sections, to allow for version-based
>>>>> documentation.
>>>>>
>>>>>
>>>>>> Basically, CXF/Camel kind of "abuse" that by running maven to call a
>>>>>> Java program that does the export to the target directory. Infra then has
>>>>>> the script to add/rm/commit/etc… the output. Since CXF/Camel are in
>>>>>> confluence, they don't have the "trigger on checkin" option and instead are
>>>>>> timed builds.
>>>>>>
>>>>>> That said, depending on the amount of content, it might just be better
>>>>>> to go with the CMS. The CMS would allow others to "fork" the site, make
>>>>>> changes, submit diffs, make comments, etc… that we wouldn't get from the
>>>>>> Maven build.
>>>>>
>>>>>
>>>>> Personally, I'd rather spend time adding contents to our documentation
>>>>> base than converting it to the CMS, but I'm open to anything here: if
>>>>> someone wants to give this option a go or look into it, this is fine
>>>>> for me too.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gert
>>>
>>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Migration of website to svnpubsub
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
Regards
JB
On 09/22/2012 04:24 PM, Gert Vanthienen wrote:
> L.S.,
>
>
> As you might have noticed from the mails on the commits@ mailing list,
> I have been working on moving the generated contents from both our
> website and documentation subproject over to svn for publication using
> svnpubsub. I have temporarily made a copy of the resulting website
> available on http://people.apache.org/~gertv/smx/ for evaluation
> purposes and that seems to work out fine.
>
> While trying to move the old website contents over, I noticed it is
> quite a beefy commit (over 1300 pages, over 60 MB of contents) so I'll
> have to find a quiet time to commit that. But the real question is :
> do we really want to keep those pages around?
>
> We have already gone over that contents twice to find useful bits and
> migrate those to the website/documentation project, so perhaps we
> should just drop the '/old' stuff from the svnpubsub migration. If we
> encounter any useful bits that are missing afterwards, it probably
> makes more sense to have them in the documentation/website projects
> anyway (we can still cherry-pick that contents from Confluence using
> the Scalate plugin) where they can be maintained, so in my mind this
> would be a good time to get rid of the old website copy.
>
>
> Wdyt?
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
> On Mon, Sep 17, 2012 at 2:29 AM, Freeman Fang <fr...@gmail.com> wrote:
>> +1
>>
>> Thanks
>> Freeman
>> －－－－－－－－－－－－－
>> Freeman Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>> On 2012-9-17, at 上午4:10, Gert Vanthienen wrote:
>>
>>> L.S.,
>>>
>>>
>>> At the builds@ mailing list, a few people recommended the
>>> maven-scm-publish-plugin over the wagon-svn adapter, which can take
>>> care of the deletions and also allows for nicer commit messages. This
>>> would take care of the initial two drawbacks I mentioned in my initial
>>> mail in this thread.
>>>
>>> If that's OK for everyone, I'll start configuring our builds to use
>>> this and prepare for a temporary location so we can see the result
>>> before we ask infra to flip the switch.
>>>
>>> I have not yet been able to make much progress on getting the extra
>>> information required to further automate this using buildbot, but we
>>> can always pursue that separately afterwards if necessary. For now, I
>>> would prefer to get this migration to svnpubsub done so we can start
>>> leveraging the faster publishing to the public website.
>>>
>>>
>>> Wdyt?
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>> On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
>>> <ge...@gmail.com> wrote:
>>>> L.S.,
>>>>
>>>>> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>>>>>
>>>>> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
>>>>
>>>> Yeah, I think it should be possible to set that up as well - we are
>>>> using two external tools in the documentation generation process that
>>>> might be a problem: Pygments to generate the CSS-markup for the code
>>>> snippets and Prince XML to generate the PDF variants for the
>>>> documentation. We would have to get in touch with infra@ to figure
>>>> out what's possible - I think the former is already available (think I
>>>> have seen it being mentioned on the CMS/svnpubsub discussions before).
>>>> The real issue might be that we have separate builds for the website
>>>> and the documentation sections, to allow for version-based
>>>> documentation.
>>>>
>>>>
>>>>> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>>>>>
>>>>> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
>>>>
>>>> Personally, I'd rather spend time adding contents to our documentation
>>>> base than converting it to the CMS, but I'm open to anything here: if
>>>> someone wants to give this option a go or look into it, this is fine
>>>> for me too.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert
>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Migration of website to svnpubsub
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 22, 2012 at 4:24 PM, Gert Vanthienen
<ge...@gmail.com> wrote:
> L.S.,
>
>
> As you might have noticed from the mails on the commits@ mailing list,
> I have been working on moving the generated contents from both our
> website and documentation subproject over to svn for publication using
> svnpubsub. I have temporarily made a copy of the resulting website
> available on http://people.apache.org/~gertv/smx/ for evaluation
> purposes and that seems to work out fine.
>
> While trying to move the old website contents over, I noticed it is
> quite a beefy commit (over 1300 pages, over 60 MB of contents) so I'll
> have to find a quiet time to commit that. But the real question is :
> do we really want to keep those pages around?
>
> We have already gone over that contents twice to find useful bits and
> migrate those to the website/documentation project, so perhaps we
> should just drop the '/old' stuff from the svnpubsub migration. If we
> encounter any useful bits that are missing afterwards, it probably
> makes more sense to have them in the documentation/website projects
> anyway (we can still cherry-pick that contents from Confluence using
> the Scalate plugin) where they can be maintained, so in my mind this
> would be a good time to get rid of the old website copy.
>
>
> Wdyt?
>
+1 to get rid.
IMHO an up-to-date website that focuses on the 4.x platform of SMX would help
getting continued and more attraction to the SMX project.
And then it would be easier to find the TODO / gaps in the docs that
needs filling out.
For example as a new user to SMX you may read about what is is, and
you get a page
http://servicemix.apache.org/docs/4.4.x/architecture/what-is-smx4.html
That has many TODO markers.
So hopefully with this effort, the team and community would like to
contribute and help with the docs.
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
> On Mon, Sep 17, 2012 at 2:29 AM, Freeman Fang <fr...@gmail.com> wrote:
>> +1
>>
>> Thanks
>> Freeman
>> －－－－－－－－－－－－－
>> Freeman Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>> On 2012-9-17, at 上午4:10, Gert Vanthienen wrote:
>>
>>> L.S.,
>>>
>>>
>>> At the builds@ mailing list, a few people recommended the
>>> maven-scm-publish-plugin over the wagon-svn adapter, which can take
>>> care of the deletions and also allows for nicer commit messages. This
>>> would take care of the initial two drawbacks I mentioned in my initial
>>> mail in this thread.
>>>
>>> If that's OK for everyone, I'll start configuring our builds to use
>>> this and prepare for a temporary location so we can see the result
>>> before we ask infra to flip the switch.
>>>
>>> I have not yet been able to make much progress on getting the extra
>>> information required to further automate this using buildbot, but we
>>> can always pursue that separately afterwards if necessary. For now, I
>>> would prefer to get this migration to svnpubsub done so we can start
>>> leveraging the faster publishing to the public website.
>>>
>>>
>>> Wdyt?
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.blogspot.com/
>>>
>>>
>>> On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
>>> <ge...@gmail.com> wrote:
>>>> L.S.,
>>>>
>>>>> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>>>>>
>>>>> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
>>>>
>>>> Yeah, I think it should be possible to set that up as well - we are
>>>> using two external tools in the documentation generation process that
>>>> might be a problem: Pygments to generate the CSS-markup for the code
>>>> snippets and Prince XML to generate the PDF variants for the
>>>> documentation. We would have to get in touch with infra@ to figure
>>>> out what's possible - I think the former is already available (think I
>>>> have seen it being mentioned on the CMS/svnpubsub discussions before).
>>>> The real issue might be that we have separate builds for the website
>>>> and the documentation sections, to allow for version-based
>>>> documentation.
>>>>
>>>>
>>>>> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>>>>>
>>>>> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
>>>>
>>>> Personally, I'd rather spend time adding contents to our documentation
>>>> base than converting it to the CMS, but I'm open to anything here: if
>>>> someone wants to give this option a go or look into it, this is fine
>>>> for me too.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Migration of website to svnpubsub
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
As you might have noticed from the mails on the commits@ mailing list,
I have been working on moving the generated contents from both our
website and documentation subproject over to svn for publication using
svnpubsub. I have temporarily made a copy of the resulting website
available on http://people.apache.org/~gertv/smx/ for evaluation
purposes and that seems to work out fine.
While trying to move the old website contents over, I noticed it is
quite a beefy commit (over 1300 pages, over 60 MB of contents) so I'll
have to find a quiet time to commit that. But the real question is :
do we really want to keep those pages around?
We have already gone over that contents twice to find useful bits and
migrate those to the website/documentation project, so perhaps we
should just drop the '/old' stuff from the svnpubsub migration. If we
encounter any useful bits that are missing afterwards, it probably
makes more sense to have them in the documentation/website projects
anyway (we can still cherry-pick that contents from Confluence using
the Scalate plugin) where they can be maintained, so in my mind this
would be a good time to get rid of the old website copy.
Wdyt?
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Sep 17, 2012 at 2:29 AM, Freeman Fang <fr...@gmail.com> wrote:
> +1
>
> Thanks
> Freeman
> －－－－－－－－－－－－－
> Freeman Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
> On 2012-9-17, at 上午4:10, Gert Vanthienen wrote:
>
>> L.S.,
>>
>>
>> At the builds@ mailing list, a few people recommended the
>> maven-scm-publish-plugin over the wagon-svn adapter, which can take
>> care of the deletions and also allows for nicer commit messages. This
>> would take care of the initial two drawbacks I mentioned in my initial
>> mail in this thread.
>>
>> If that's OK for everyone, I'll start configuring our builds to use
>> this and prepare for a temporary location so we can see the result
>> before we ask infra to flip the switch.
>>
>> I have not yet been able to make much progress on getting the extra
>> information required to further automate this using buildbot, but we
>> can always pursue that separately afterwards if necessary. For now, I
>> would prefer to get this migration to svnpubsub done so we can start
>> leveraging the faster publishing to the public website.
>>
>>
>> Wdyt?
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>> On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
>> <ge...@gmail.com> wrote:
>>> L.S.,
>>>
>>>> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>>>>
>>>> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
>>>
>>> Yeah, I think it should be possible to set that up as well - we are
>>> using two external tools in the documentation generation process that
>>> might be a problem: Pygments to generate the CSS-markup for the code
>>> snippets and Prince XML to generate the PDF variants for the
>>> documentation. We would have to get in touch with infra@ to figure
>>> out what's possible - I think the former is already available (think I
>>> have seen it being mentioned on the CMS/svnpubsub discussions before).
>>> The real issue might be that we have separate builds for the website
>>> and the documentation sections, to allow for version-based
>>> documentation.
>>>
>>>
>>>> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>>>>
>>>> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
>>>
>>> Personally, I'd rather spend time adding contents to our documentation
>>> base than converting it to the CMS, but I'm open to anything here: if
>>> someone wants to give this option a go or look into it, this is fine
>>> for me too.
>>>
>>>
>>> Regards,
>>>
>>> Gert
>
Re: Migration of website to svnpubsub
Posted by Freeman Fang <fr...@gmail.com>.
+1
Thanks
Freeman
－－－－－－－－－－－－－
Freeman Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-9-17, at 上午4:10, Gert Vanthienen wrote:
> L.S.,
>
>
> At the builds@ mailing list, a few people recommended the
> maven-scm-publish-plugin over the wagon-svn adapter, which can take
> care of the deletions and also allows for nicer commit messages. This
> would take care of the initial two drawbacks I mentioned in my initial
> mail in this thread.
>
> If that's OK for everyone, I'll start configuring our builds to use
> this and prepare for a temporary location so we can see the result
> before we ask infra to flip the switch.
>
> I have not yet been able to make much progress on getting the extra
> information required to further automate this using buildbot, but we
> can always pursue that separately afterwards if necessary. For now, I
> would prefer to get this migration to svnpubsub done so we can start
> leveraging the faster publishing to the public website.
>
>
> Wdyt?
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
> On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
> <ge...@gmail.com> wrote:
>> L.S.,
>>
>>> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>>>
>>> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
>>
>> Yeah, I think it should be possible to set that up as well - we are
>> using two external tools in the documentation generation process that
>> might be a problem: Pygments to generate the CSS-markup for the code
>> snippets and Prince XML to generate the PDF variants for the
>> documentation. We would have to get in touch with infra@ to figure
>> out what's possible - I think the former is already available (think I
>> have seen it being mentioned on the CMS/svnpubsub discussions before).
>> The real issue might be that we have separate builds for the website
>> and the documentation sections, to allow for version-based
>> documentation.
>>
>>
>>> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>>>
>>> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
>>
>> Personally, I'd rather spend time adding contents to our documentation
>> base than converting it to the CMS, but I'm open to anything here: if
>> someone wants to give this option a go or look into it, this is fine
>> for me too.
>>
>>
>> Regards,
>>
>> Gert
Re: Migration of website to svnpubsub
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
At the builds@ mailing list, a few people recommended the
maven-scm-publish-plugin over the wagon-svn adapter, which can take
care of the deletions and also allows for nicer commit messages. This
would take care of the initial two drawbacks I mentioned in my initial
mail in this thread.
If that's OK for everyone, I'll start configuring our builds to use
this and prepare for a temporary location so we can see the result
before we ask infra to flip the switch.
I have not yet been able to make much progress on getting the extra
information required to further automate this using buildbot, but we
can always pursue that separately afterwards if necessary. For now, I
would prefer to get this migration to svnpubsub done so we can start
leveraging the faster publishing to the public website.
Wdyt?
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Tue, Sep 4, 2012 at 4:37 PM, Gert Vanthienen
<ge...@gmail.com> wrote:
> L.S.,
>
>> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>>
>> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
>
> Yeah, I think it should be possible to set that up as well - we are
> using two external tools in the documentation generation process that
> might be a problem: Pygments to generate the CSS-markup for the code
> snippets and Prince XML to generate the PDF variants for the
> documentation. We would have to get in touch with infra@ to figure
> out what's possible - I think the former is already available (think I
> have seen it being mentioned on the CMS/svnpubsub discussions before).
> The real issue might be that we have separate builds for the website
> and the documentation sections, to allow for version-based
> documentation.
>
>
>> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>>
>> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
>
> Personally, I'd rather spend time adding contents to our documentation
> base than converting it to the CMS, but I'm open to anything here: if
> someone wants to give this option a go or look into it, this is fine
> for me too.
>
>
> Regards,
>
> Gert
Re: Migration of website to svnpubsub
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
> CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
>
> HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
Yeah, I think it should be possible to set that up as well - we are
using two external tools in the documentation generation process that
might be a problem: Pygments to generate the CSS-markup for the code
snippets and Prince XML to generate the PDF variants for the
documentation. We would have to get in touch with infra@ to figure
out what's possible - I think the former is already available (think I
have seen it being mentioned on the CMS/svnpubsub discussions before).
The real issue might be that we have separate builds for the website
and the documentation sections, to allow for version-based
documentation.
> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
>
> That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
Personally, I'd rather spend time adding contents to our documentation
base than converting it to the CMS, but I'm open to anything here: if
someone wants to give this option a go or look into it, this is fine
for me too.
Regards,
Gert
Re: Migration of website to svnpubsub
Posted by Daniel Kulp <dk...@apache.org>.
On Sep 4, 2012, at 7:16 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi Gert
>
> I suggest to touch base with Dan K. He has migrated Apache CXF and is
> doing the same for Camel as well.
> I am not sure if what he has setup is the same as you are proposing.
> But would IMHO make the most sense if the Apache projects was similar.
> Then there is also ActiveMQ, has it been migrated?
CXF and Camel (and ActiveMQ) are a bit different in that they still maintain their sites and all content in Confluence. ServiceMix has changed to using a maven site stuff.
HOWEVER, there may even be an easier solution. If the maven build can be setup to accept and output directory (instead of target/site or whatever), you can have infrastructure setup a buildbot build that will run the build and automatically handle all the svn stuff. It would trigger on checkin of the site source, build, publish, etc… all automatically. Developers would never need to "site-deploy" or anything like that.
Basically, CXF/Camel kind of "abuse" that by running maven to call a Java program that does the export to the target directory. Infra then has the script to add/rm/commit/etc… the output. Since CXF/Camel are in confluence, they don't have the "trigger on checkin" option and instead are timed builds.
That said, depending on the amount of content, it might just be better to go with the CMS. The CMS would allow others to "fork" the site, make changes, submit diffs, make comments, etc… that we wouldn't get from the Maven build.
Dan
>
>
> On Mon, Sep 3, 2012 at 8:50 PM, Gert Vanthienen
> <ge...@gmail.com> wrote:
>> L.S.,
>>
>>
>> I have been looking into the mandatory migration of our website to
>> svnpubsub today and it looks like the easiest solution would be to
>> simply use the Wagen SVN provider to publish our existing website
>> pages to a location in Subversion. That would involve a few minor POM
>> changes and it worksfor both the main website project and the
>> documentation branches. We could e.g. configure them to publish to
>> https://svn.apache.org/repos/asf/servicemix/site
>>
>> Once we modified those two projects, the only thing missing would be
>> the Confluence-generated content - I would suggest we just copy the
>> current contents as-is into the same SVN location, so we can keep
>> those pages around in http://servicemix.apache.org/old for now. The
>> contents is largely obsolete, but perhaps some people still depend on
>> some of this information for older ServiceMix 3.x deployments.
>>
>> There a few drawbacks to that approach that I can see, but none of
>> them are really blocking in my mind:
>> - the commits to the website publishing location are being done by
>> wagon and they all have the same commit message - this should not be a
>> big problem because we still have the actual
>> servicemix-documentation/servicemix-website project commits to
>> communicate the actual change to the Scalate pages
>> - at present, the wagon mechanism is unable to delete files from the
>> publishing location that have been deleted from the Scalate codebase -
>> we actually have the same problem with the SCP publishing mechanism we
>> are using today
>>
>> Once we have migrated to svnpubsub though, it also becomes easier to
>> delete the stale pages because we can just remove them from SVN. The
>> real benefit for us would be that those deletions as well as any
>> changes we make to the documentation or website will be published
>> immediately after we commit them.
>>
>> If this sounds OK to everyone, I'll make the necessary changes to the
>> POMs tomorrow and will publish the result on a machine of mine, so we
>> can ensure that everything looks OK before we ask infra@ to flip the
>> switch for the main website.
>>
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Migration of website to svnpubsub
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Gert
I suggest to touch base with Dan K. He has migrated Apache CXF and is
doing the same for Camel as well.
I am not sure if what he has setup is the same as you are proposing.
But would IMHO make the most sense if the Apache projects was similar.
Then there is also ActiveMQ, has it been migrated?
On Mon, Sep 3, 2012 at 8:50 PM, Gert Vanthienen
<ge...@gmail.com> wrote:
> L.S.,
>
>
> I have been looking into the mandatory migration of our website to
> svnpubsub today and it looks like the easiest solution would be to
> simply use the Wagen SVN provider to publish our existing website
> pages to a location in Subversion. That would involve a few minor POM
> changes and it worksfor both the main website project and the
> documentation branches. We could e.g. configure them to publish to
> https://svn.apache.org/repos/asf/servicemix/site
>
> Once we modified those two projects, the only thing missing would be
> the Confluence-generated content - I would suggest we just copy the
> current contents as-is into the same SVN location, so we can keep
> those pages around in http://servicemix.apache.org/old for now. The
> contents is largely obsolete, but perhaps some people still depend on
> some of this information for older ServiceMix 3.x deployments.
>
> There a few drawbacks to that approach that I can see, but none of
> them are really blocking in my mind:
> - the commits to the website publishing location are being done by
> wagon and they all have the same commit message - this should not be a
> big problem because we still have the actual
> servicemix-documentation/servicemix-website project commits to
> communicate the actual change to the Scalate pages
> - at present, the wagon mechanism is unable to delete files from the
> publishing location that have been deleted from the Scalate codebase -
> we actually have the same problem with the SCP publishing mechanism we
> are using today
>
> Once we have migrated to svnpubsub though, it also becomes easier to
> delete the stale pages because we can just remove them from SVN. The
> real benefit for us would be that those deletions as well as any
> changes we make to the documentation or website will be published
> immediately after we commit them.
>
> If this sounds OK to everyone, I'll make the necessary changes to the
> POMs tomorrow and will publish the result on a machine of mine, so we
> can ensure that everything looks OK before we ask infra@ to flip the
> switch for the main website.
>
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Migration of website to svnpubsub
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
Regards
JB
On 09/03/2012 08:50 PM, Gert Vanthienen wrote:
> L.S.,
>
>
> I have been looking into the mandatory migration of our website to
> svnpubsub today and it looks like the easiest solution would be to
> simply use the Wagen SVN provider to publish our existing website
> pages to a location in Subversion. That would involve a few minor POM
> changes and it worksfor both the main website project and the
> documentation branches. We could e.g. configure them to publish to
> https://svn.apache.org/repos/asf/servicemix/site
>
> Once we modified those two projects, the only thing missing would be
> the Confluence-generated content - I would suggest we just copy the
> current contents as-is into the same SVN location, so we can keep
> those pages around in http://servicemix.apache.org/old for now. The
> contents is largely obsolete, but perhaps some people still depend on
> some of this information for older ServiceMix 3.x deployments.
>
> There a few drawbacks to that approach that I can see, but none of
> them are really blocking in my mind:
> - the commits to the website publishing location are being done by
> wagon and they all have the same commit message - this should not be a
> big problem because we still have the actual
> servicemix-documentation/servicemix-website project commits to
> communicate the actual change to the Scalate pages
> - at present, the wagon mechanism is unable to delete files from the
> publishing location that have been deleted from the Scalate codebase -
> we actually have the same problem with the SCP publishing mechanism we
> are using today
>
> Once we have migrated to svnpubsub though, it also becomes easier to
> delete the stale pages because we can just remove them from SVN. The
> real benefit for us would be that those deletions as well as any
> changes we make to the documentation or website will be published
> immediately after we commit them.
>
> If this sounds OK to everyone, I'll make the necessary changes to the
> POMs tomorrow and will publish the result on a machine of mine, so we
> can ensure that everything looks OK before we ask infra@ to flip the
> switch for the main website.
>
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Migration of website to svnpubsub
Posted by Freeman Fang <fr...@gmail.com>.
+1
Thanks
Freeman
－－－－－－－－－－－－－
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-9-4, at 上午2:50, Gert Vanthienen wrote:
> L.S.,
>
>
> I have been looking into the mandatory migration of our website to
> svnpubsub today and it looks like the easiest solution would be to
> simply use the Wagen SVN provider to publish our existing website
> pages to a location in Subversion. That would involve a few minor POM
> changes and it worksfor both the main website project and the
> documentation branches. We could e.g. configure them to publish to
> https://svn.apache.org/repos/asf/servicemix/site
>
> Once we modified those two projects, the only thing missing would be
> the Confluence-generated content - I would suggest we just copy the
> current contents as-is into the same SVN location, so we can keep
> those pages around in http://servicemix.apache.org/old for now. The
> contents is largely obsolete, but perhaps some people still depend on
> some of this information for older ServiceMix 3.x deployments.
>
> There a few drawbacks to that approach that I can see, but none of
> them are really blocking in my mind:
> - the commits to the website publishing location are being done by
> wagon and they all have the same commit message - this should not be a
> big problem because we still have the actual
> servicemix-documentation/servicemix-website project commits to
> communicate the actual change to the Scalate pages
> - at present, the wagon mechanism is unable to delete files from the
> publishing location that have been deleted from the Scalate codebase -
> we actually have the same problem with the SCP publishing mechanism we
> are using today
>
> Once we have migrated to svnpubsub though, it also becomes easier to
> delete the stale pages because we can just remove them from SVN. The
> real benefit for us would be that those deletions as well as any
> changes we make to the documentation or website will be published
> immediately after we commit them.
>
> If this sounds OK to everyone, I'll make the necessary changes to the
> POMs tomorrow and will publish the result on a machine of mine, so we
> can ensure that everything looks OK before we ask infra@ to flip the
> switch for the main website.
>
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/