On Mon, Dec 16, 2013 at 1:30 AM, Hervé BOUTEMY <[email protected]> wrote: > you're right: a new phase could be a solution, and we need to have a higher > look at the objective > > the requirement to me is that commands to publish site with svnpubsub are like > mvn -Preporting site-deploy > and if deplyment fails (since it uses network), you can "mvn site:deploy", > without renerating the site content > > > at the moment, with svnpubsub, we have: > mvn -Preporting site site:stage > mvn scm-publish:publish-scm > > there are 2 problems: > - 2 executions: execution of scm-publish at end can help doing one command > - "scm-publish:publish-scm" is really really harder to type than > "site:deploy": I know, that's stupid, but it's usability > > perhaps we can avoid site:stage when introducing scm-publish at end, since the > copy into svn checkout can perhaps be done on each module from site > > > notice that this scm-publish plugin is probably not really used much outside > svnpubsub, so perhaps we're trying to do too much: good instruction for Maven > compoennts publication, so Maven devs copy/paste are perhaps really sufficient
Some thoughts. There was a bunch of traffic about a WAGON bug which, if fixed, would have purported to make this all just work with a sufficiently devious wagon. Various members of our fraternity declined, I think because it was too hard. There was also the brief flurry of discussion about 'POM 5'. My sense was the one of the problems here was the difficulty of cramming enough information into the scm element of the pom. Can we think of a hack that works around the pom limitation and allows the whole publish process to be stuffed into the wagon system after all? The github publisher wagon out there seems suspiciously related. If we were aiming at git instead of svn, would this be easier? Wait, here's an idea. What if the 'real site' in svn were composed of svn:externals for all the submodules. So, the build process could just many checkouts, one for each module, and do plain old site:site and site:deploy. The main site would then 'get' the externals and everything would be in place. Site:stage has the purpose, if I recall, of assembling the pieces of a multi-module project in a hierarchy without intervening target/site directories so that the links work. OK, so, here comes another stupid suggestion: make a mode of the site plugin in which we don't need site:stage, because site:site in a multi-module build directly writes to TOPLEVEL/target/site/WHATEVER. That requires some way to communicate the .. pathname to TOPLEVEL so that site:site anywhere works. > > Regards, > > Hervé > > Le dimanche 15 décembre 2013 17:39:51 Benson Margulies a écrit : >> On Sun, Dec 15, 2013 at 5:30 PM, Hervé BOUTEMY <[email protected]> > wrote: >> > nice! >> > >> > the first step IMHO is to add deployAtEnd feature: you're a specialist :) >> > >> > then, deploy should detect "scm:" url to avoid classical wagon deployment >> > but instead: >> > 1. stage content when not at end >> > 2. scm-publish when at end >> > >> > from a pure logical point of view, I think this is the thing to do >> > but from a practical point of view, the fact that deploy goal will mix its >> > initial wagon-deploy algorithm, with stage and scm-publish:publish-scm, >> > the >> > code will likely become hardly maintainable. There will be a lot of >> > parameters too, used only for "scm:" urls, but not used in the most >> > frequent cases >> > >> > Any other idea to do something easier to use and more maintainable? >> >> Can anyone explain the relationship of this to my failed attempt to >> make a lifecycle in the scm publish plugin? >> >> > Regards, >> > >> > Hervé >> > >> > Le dimanche 15 décembre 2013 16:22:18 Robert Scholte a écrit : >> >> > the ideal situation would be a site:deploy goal that does all the magic >> >> > incase of scm: dist management site url >> >> > anybody interested in trying to do it with me? >> >> >> >> Sure, I'd like to help >> >> >> >> Robert >> >> >> >> Op Tue, 10 Dec 2013 01:54:14 +0100 schreef Hervé BOUTEMY >> >> >> >> <[email protected]>: >> >> > Le mardi 10 décembre 2013 01:05:30 Michael-O a écrit : >> >> >> Am 2013-12-10 00:58, schrieb Hervé BOUTEMY: >> >> >> >> >> >> <content>${project.build.directory}/staging/${maven.site.path}</conten >> >> >> t> >> >> >> >> >> >> > is not really necessary here, since skins are never multi-module, >> >> >> >> >> >> then no >> >> >> >> >> >> > need to site:stage >> >> >> > >> >> >> > that's not a blocking issue, since it will work: just need to do >> >> >> > extra >> >> >> > site:stage step, not usually needed >> >> >> >> >> >> I am aware of that. That change was intentional. It conforms to all >> >> >> other POMs and to the procedure described in the docs. Nothing more, >> >> >> nothing less. >> >> > >> >> > not really what I wanted to express with "if the component has multiple >> >> > modules, locally stage the site:" >> >> > but staging in every situation has the advantage that instructions >> >> > would >> >> > not >> >> > be different for mono-module and multi-module >> >> > >> >> > I don't know what you all prefer: simpler instructions for mono-module >> >> > (but >> >> > require a little thinking to know in which situation a build is) or >> >> > uniform >> >> > instructions (even if it is a little more complex than absolutely >> >> > necessary >> >> > for mono-modules) >> >> > >> >> > the ideal situation would be a site:deploy goal that does all the magic >> >> > in >> >> > case of scm: dist management site url >> >> > anybody interested in trying to do it with me? >> >> > >> >> > Regards, >> >> > >> >> > Hervé >> >> > >> >> >> > Le lundi 9 décembre 2013 14:08:29 [email protected] a écrit : >> >> >> >> Author: michaelo >> >> >> >> Date: Mon Dec 9 14:08:28 2013 >> >> >> >> New Revision: 1549574 >> >> >> >> >> >> >> >> URL: http://svn.apache.org/r1549574 >> >> >> >> Log: >> >> >> >> Align ${maven.site.path} and <content> style with the rest of the >> >> >> >> >> >> Maven >> >> >> >> >> >> >> components. >> >> >> >> >> >> >> >> Modified: >> >> >> >> maven/skins/trunk/maven-skins/pom.xml >> >> >> >> >> >> >> >> Modified: maven/skins/trunk/maven-skins/pom.xml >> >> >> >> >> >> >> URL: >> >> >> http://svn.apache.org/viewvc/maven/skins/trunk/maven-skins/pom.xml?rev >> >> >> =15 >> >> >> >> >> >> >> 49 >> >> >> >> 574&r1=1549573&r2=1549574&view=diff >> >> >> >> >> >> ====================================================================== >> >> >> === >> >> >> >> >> >> >> == >> >> >> >> === --- maven/skins/trunk/maven-skins/pom.xml (original) >> >> >> >> +++ maven/skins/trunk/maven-skins/pom.xml Mon Dec 9 14:08:28 2013 >> >> >> >> @@ -60,7 +60,7 @@ under the License. >> >> >> >> >> >> >> >> </distributionManagement> >> >> >> >> >> >> >> >> <properties> >> >> >> >> >> >> >> >> - >> >> >> >> >> >> <maven.site.path>skins-archives/${project.artifactId}-LATEST</maven.si >> >> >> te. >> >> >> >> >> >> >> pa >> >> >> >> th> + >> >> >> >> <maven.site.path>skins-archives/maven-skins-LATEST</maven.site.path >> >> >> >> > >> >> >> >> <sitePluginVersion>3.3</sitePluginVersion> >> >> >> >> >> >> >> >> </properties> >> >> >> >> >> >> >> >> @@ -91,7 +91,7 @@ under the License. >> >> >> >> >> >> >> >> <groupId>org.apache.maven.plugins</groupId> >> >> >> >> <artifactId>maven-scm-publish-plugin</artifactId> >> >> >> >> <configuration> >> >> >> >> >> >> >> >> - <content>${project.reporting.outputDirectory}</content> >> >> >> >> + >> >> >> >> >> >> <content>${project.build.directory}/staging/${maven.site.path}</conten >> >> >> t> >> >> >> >> >> >> <pubScmUrl>scm:svn:https://svn.apache.org/repos/infra/websites/product >> >> >> ion >> >> >> >> >> >> >> /m >> >> >> >> aven/content/${maven.site.path}</pubScmUrl> >> >> >> >> >> >> <checkoutDirectory>${maven.site.cache}/${maven.site.path}</checkoutDir >> >> >> ect >> >> >> >> >> >> >> or >> >> >> >> y> <tryUpdate>true</tryUpdate> >> >> >> > >> >> >> > -------------------------------------------------------------------- >> >> >> > - >> >> >> > To unsubscribe, e-mail: [email protected] >> >> >> > For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: [email protected] >> >> >> For additional commands, e-mail: [email protected] >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
