You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christian Grobmeier <gr...@gmail.com> on 2012/05/20 14:23:59 UTC
maven-site-scm-publish Plugin
Hello folks,
what is the state of the maven-site-scm-publish plugin?
As I could understand, it checks out a specific svn repository path,
diffs/merges it with my locally generated site, and then commits it
back to the specific repository. This is basically what apache
projects could need with svnpubsub.
Is the plugin already working? What is left to leave sandbox?
Thanks!
Christian
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-site-scm-publish Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 20 mai 2012 20:36:14 Christian Grobmeier a écrit :
> > is it better to continue this discussion on Maven list or on logging?
>
> I think only less people from logging are subscribed to the maven
> lists. If you would join us at general@logging.apache.org, then it
> would help much. Thanks!
> See you on general@
ok, I'm now subscribed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-site-scm-publish Plugin
Posted by Christian Grobmeier <gr...@gmail.com>.
On Sun, May 20, 2012 at 7:28 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> Le dimanche 20 mai 2012 18:46:06 Christian Grobmeier a écrit :
>> That being said, we have not had a vote on that, but it seems that the
>> majority of us doesn't want to use the CMS directly. Therefore we were
>> initially looking for a mvn based solution. Did I understand you
>> correct that the "main site" should be cared on CMS level while for
>> example API docs are updated with m-scm-publish? Why can't we use mvn
>> site together with m-scm-publish?
> that's the problem with the CMS: there are multiple parts, some are good for
> us Maven users, some are not. And using the CMS doesn't mean using its
> internal site generation engine: you can have the CMS do "mvn site" to
> generate html from apt, xdoc and so on. That's what's done for
> maventest.apache.org.
Oh cool! Didn't know that!
>> Cool, thanks for your help.
> is it better to continue this discussion on Maven list or on logging?
I think only less people from logging are subscribed to the maven
lists. If you would join us at general@logging.apache.org, then it
would help much. Thanks!
>> We are speaking of logging.apache.org. Inside are several components,
>> like log4j1, the brandnew log4j2 which is blocked by the site release
>> process, log4php, log4net and so on. The biggest problem is log4j1 and
>> another urgent one is log4j2. We have the recommendation to use ASF
>> CMS but so far we would prefer to use maven only solutions. All
>> projects are independent, no parent project. We have a main site which
>> links to the several subprojects.
>>
>> One of the ideas which is currently in place is to "do something with
>> maven" which commits to a svn repos which is read by svnpubsub.
> then with a little pom configuration, we should be able to do "mvn -Preporting
> site-stage scm-publish:publish-scm" in one pass or in 2 pass "mvn -Preporting
> site-stage" then "mvn scm-publish:publish-scm"
That would be fine. Its still easy to use.
>
>> The
>> repos could look like:
>>
>> /$asfrepos/logging/pubsub/logging/index.html --> main site
>> /$asfrepos/logging/pubsub/logging/log4j/index.html --> logj41 site
>> /$asfrepos/logging/pubsub/logging/log4j2/index.html --> logj42 site
>> and so on.
>>
>> What do you think about that?
> that's the structure we have in maventest with the main site and every
> components. Everything is generated with Maven with "mvn site", the main site
> being generated through the CMS.
> The main site must take care to not delete components when updating, since it
> is not responsible of their directories. The CMS does this by declaring
> directories in extpaths.txt.
> For logging, we'll have to work on it given the choice you'll make for main
> site publishing.
Thanks. Joe from Infra explained it to me/us, but not it slowly makes
sense to me.
>
> After that, everythin can be ok with "mvn -Preporting site-stage scm-
> publish:publish-scm". It can be as simple as that as soon as you don't want
> subtle things like a directory by minor version or staging, which will require
> some more work/knowledge.
>
> more precisely, if I use conventions Joe gave me for maventest, the repo would
> be:
> asfrepos=https://svn.apache.org/repos/infra/websites/production
> $asfrepos/logging/content/index.html --> main site
> $asfrepos/logging/content/log4j/index.html --> logj41 site
> $asfrepos/logging/content/log4j2/index.html --> logj42 site
I think that would be fine too.
>> Thanks again! I feel a little bit lost and your help is highly appreciated.
> Logging is the first project to ask for help, but I suppose you won't be the
> only one :)
> With the CMS, infra is making Maven users sick, but Maven users are making
> infra mad in return: I think we should be able to show a simple path for
> everybody.
Actually I am pretty glad I asked here and that you responded so
kindly. We had some good information from Infra but we are still
stuck. Hopefully we can generate some docs out of our experiences and
help others with this information. What I have missed was always the
"step by step" information and the new tools are not really easy to
understand.
See you on general@
Cheers,
Christian
>
> Regards,
>
> Hervé
>
>>
>> Christian
>>
>> >> Thanks!
>> >
>> > somebody interested, nice!
>> >
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >> Christian
>> >
>> > [1] http://maventest.apache.org/
>> >
>> > [2]
>> > https://svn.apache.org/repos/infra/websites/production/maventest/content/p
>> > lugins/
>> >
>> > [3]
>> > http://maventest.apache.org/developers/release/maven-plugin-release.html
>> >
>> > [4] http://maven.apache.org/sandbox/plugins/maven-scm-publish-plugin
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-site-scm-publish Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 20 mai 2012 18:46:06 Christian Grobmeier a écrit :
> That being said, we have not had a vote on that, but it seems that the
> majority of us doesn't want to use the CMS directly. Therefore we were
> initially looking for a mvn based solution. Did I understand you
> correct that the "main site" should be cared on CMS level while for
> example API docs are updated with m-scm-publish? Why can't we use mvn
> site together with m-scm-publish?
that's the problem with the CMS: there are multiple parts, some are good for
us Maven users, some are not. And using the CMS doesn't mean using its
internal site generation engine: you can have the CMS do "mvn site" to
generate html from apt, xdoc and so on. That's what's done for
maventest.apache.org.
But we'll look at that later, since that's not your priority.
>
> >> What is left to leave sandbox?
> >
> > 1. interest/feedback
>
> Interest!! :-)
nice to hear, I was starting to feel a little bit alone
> > That won't change the release process question but at least ease usage:
> > "mvn - Preporting site-deploy"
>
> would look nice, but I am really not looking for pure beauty. I would
> be glad to solve our problems first, then look for beauty.
>
> > for the moment, I just published latest documentation: [4] (sync
> > pending...) tel me what project/component you want to migrate to
> > svnpubsub and we can work toward this precise case
>
> Cool, thanks for your help.
is it better to continue this discussion on Maven list or on logging?
>
> We are speaking of logging.apache.org. Inside are several components,
> like log4j1, the brandnew log4j2 which is blocked by the site release
> process, log4php, log4net and so on. The biggest problem is log4j1 and
> another urgent one is log4j2. We have the recommendation to use ASF
> CMS but so far we would prefer to use maven only solutions. All
> projects are independent, no parent project. We have a main site which
> links to the several subprojects.
>
> One of the ideas which is currently in place is to "do something with
> maven" which commits to a svn repos which is read by svnpubsub.
then with a little pom configuration, we should be able to do "mvn -Preporting
site-stage scm-publish:publish-scm" in one pass or in 2 pass "mvn -Preporting
site-stage" then "mvn scm-publish:publish-scm"
> The
> repos could look like:
>
> /$asfrepos/logging/pubsub/logging/index.html --> main site
> /$asfrepos/logging/pubsub/logging/log4j/index.html --> logj41 site
> /$asfrepos/logging/pubsub/logging/log4j2/index.html --> logj42 site
> and so on.
>
> What do you think about that?
that's the structure we have in maventest with the main site and every
components. Everything is generated with Maven with "mvn site", the main site
being generated through the CMS.
The main site must take care to not delete components when updating, since it
is not responsible of their directories. The CMS does this by declaring
directories in extpaths.txt.
For logging, we'll have to work on it given the choice you'll make for main
site publishing.
After that, everythin can be ok with "mvn -Preporting site-stage scm-
publish:publish-scm". It can be as simple as that as soon as you don't want
subtle things like a directory by minor version or staging, which will require
some more work/knowledge.
more precisely, if I use conventions Joe gave me for maventest, the repo would
be:
asfrepos=https://svn.apache.org/repos/infra/websites/production
$asfrepos/logging/content/index.html --> main site
$asfrepos/logging/content/log4j/index.html --> logj41 site
$asfrepos/logging/content/log4j2/index.html --> logj42 site
>
> > And hopefully you'll have projects with less content than Maven itself,
> > because Maven migration to svnpubsub is really a big task: I'd be happy to
> > start with smaller content
>
> Sure!
>
> Thanks again! I feel a little bit lost and your help is highly appreciated.
Logging is the first project to ask for help, but I suppose you won't be the
only one :)
With the CMS, infra is making Maven users sick, but Maven users are making
infra mad in return: I think we should be able to show a simple path for
everybody.
Regards,
Hervé
>
> Christian
>
> >> Thanks!
> >
> > somebody interested, nice!
> >
> >
> > Regards,
> >
> > Hervé
> >
> >> Christian
> >
> > [1] http://maventest.apache.org/
> >
> > [2]
> > https://svn.apache.org/repos/infra/websites/production/maventest/content/p
> > lugins/
> >
> > [3]
> > http://maventest.apache.org/developers/release/maven-plugin-release.html
> >
> > [4] http://maven.apache.org/sandbox/plugins/maven-scm-publish-plugin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-site-scm-publish Plugin
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi Hervé,
>> As I could understand, it checks out a specific svn repository path,
>> diffs/merges it with my locally generated site, and then commits it
>> back to the specific repository. This is basically what apache
>> projects could need with svnpubsub.
> exactly
> notice that if you have unversioned site like maven site (not plugins or
> whatever component for which documentation is published only during release),
> we're directly using CMS (with its bookmarklet) to automatically publish
> content at each commit, without the m-scm-publish-p: see [1]
we (thats the logging project) use "mvn site" for our docs and
currently we have at least one weird process which is scp'ing the docs
to localhost. From there it is committed to svn and from there we run
"svn up". This is true for one project, the others have different
processes.
That being said, we have not had a vote on that, but it seems that the
majority of us doesn't want to use the CMS directly. Therefore we were
initially looking for a mvn based solution. Did I understand you
correct that the "main site" should be cared on CMS level while for
example API docs are updated with m-scm-publish? Why can't we use mvn
site together with m-scm-publish?
>> What is left to leave sandbox?
> 1. interest/feedback
Interest!! :-)
> interest/feedback is the most lacking, because the plugin is in a point where
> it is working pretty well, but not easy to use in real world, since svnpubsub
> has consequences on release practices. I made a proposal on [3], asked for
> feedback, but got none for the moment
Well, we need to clean up our release process. We are not ready for
the svnpubsub requirement. Therefore we are looking at this plugin.
> There is only one known "hard" limitation I know of for the moment: in the
> case of a multi-module project publishing content not only in a single
> directory but in multiple (like surefire or plugin-tools, which have their root
> directory but also some directory under /plugins/), committing staged content
> in svn won't work at all. But that case is rare, and we could propably change
> their structure to work more like archetype on future releases.
We are not one of these cases, luckily.
> Ideally, I'd like to improve wagon-scm directory support, to commit whole
> directory content in one commit (without suppressing modules content), then
> integrate maven-site-plugin conveniently since you could simply use a scm url
> in distributionManagement.
> That won't change the release process question but at least ease usage: "mvn -
> Preporting site-deploy"
would look nice, but I am really not looking for pure beauty. I would
be glad to solve our problems first, then look for beauty.
> for the moment, I just published latest documentation: [4] (sync pending...)
> tel me what project/component you want to migrate to svnpubsub and we can work
> toward this precise case
Cool, thanks for your help.
We are speaking of logging.apache.org. Inside are several components,
like log4j1, the brandnew log4j2 which is blocked by the site release
process, log4php, log4net and so on. The biggest problem is log4j1 and
another urgent one is log4j2. We have the recommendation to use ASF
CMS but so far we would prefer to use maven only solutions. All
projects are independent, no parent project. We have a main site which
links to the several subprojects.
One of the ideas which is currently in place is to "do something with
maven" which commits to a svn repos which is read by svnpubsub. The
repos could look like:
/$asfrepos/logging/pubsub/logging/index.html --> main site
/$asfrepos/logging/pubsub/logging/log4j/index.html --> logj41 site
/$asfrepos/logging/pubsub/logging/log4j2/index.html --> logj42 site
and so on.
What do you think about that?
> And hopefully you'll have projects with less content than Maven itself,
> because Maven migration to svnpubsub is really a big task: I'd be happy to
> start with smaller content
Sure!
Thanks again! I feel a little bit lost and your help is highly appreciated.
Christian
>
>>
>> Thanks!
> somebody interested, nice!
>
> Regards,
>
> Hervé
>
>> Christian
>
> [1] http://maventest.apache.org/
>
> [2]
> https://svn.apache.org/repos/infra/websites/production/maventest/content/plugins/
>
> [3] http://maventest.apache.org/developers/release/maven-plugin-release.html
>
> [4] http://maven.apache.org/sandbox/plugins/maven-scm-publish-plugin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-site-scm-publish Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 20 mai 2012 14:23:59 Christian Grobmeier a écrit :
> Hello folks,
>
> what is the state of the maven-site-scm-publish plugin?
>
> As I could understand, it checks out a specific svn repository path,
> diffs/merges it with my locally generated site, and then commits it
> back to the specific repository. This is basically what apache
> projects could need with svnpubsub.
exactly
notice that if you have unversioned site like maven site (not plugins or
whatever component for which documentation is published only during release),
we're directly using CMS (with its bookmarklet) to automatically publish
content at each commit, without the m-scm-publish-p: see [1]
>
> Is the plugin already working?
yes, I used it to inject 10 plugin documentation histories [2] with great
success. Notice it caused a great load on commit mailing list (tens if not
hundreds MB), then I'll have to work with infra IMHO when I import actual 5GB
of data...
> What is left to leave sandbox?
1. interest/feedback
2. time, since I'm actually working on plugin-tools
interest/feedback is the most lacking, because the plugin is in a point where
it is working pretty well, but not easy to use in real world, since svnpubsub
has consequences on release practices. I made a proposal on [3], asked for
feedback, but got none for the moment
I'm not fully happy for the moment, since there are much command-line for
release process, independently from the pure svnpubsub.
There is only one known "hard" limitation I know of for the moment: in the
case of a multi-module project publishing content not only in a single
directory but in multiple (like surefire or plugin-tools, which have their root
directory but also some directory under /plugins/), committing staged content
in svn won't work at all. But that case is rare, and we could propably change
their structure to work more like archetype on future releases.
Ideally, I'd like to improve wagon-scm directory support, to commit whole
directory content in one commit (without suppressing modules content), then
integrate maven-site-plugin conveniently since you could simply use a scm url
in distributionManagement.
That won't change the release process question but at least ease usage: "mvn -
Preporting site-deploy"
for the moment, I just published latest documentation: [4] (sync pending...)
tel me what project/component you want to migrate to svnpubsub and we can work
toward this precise case
>
> Thanks!
somebody interested, nice!
And hopefully you'll have projects with less content than Maven itself,
because Maven migration to svnpubsub is really a big task: I'd be happy to
start with smaller content
Regards,
Hervé
> Christian
[1] http://maventest.apache.org/
[2]
https://svn.apache.org/repos/infra/websites/production/maventest/content/plugins/
[3] http://maventest.apache.org/developers/release/maven-plugin-release.html
[4] http://maven.apache.org/sandbox/plugins/maven-scm-publish-plugin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org