On Sun, Feb 12, 2012 at 4:50 PM, Hervé BOUTEMY <[email protected]> wrote: > if this would work well for any project (even with modules), I see more > problems with maven site itself [1]: checking out the site will check out > every module ever done into Maven. > We'll need to find some way to limit the content checked out, IMHO
Yes. > > Regards, > > Hervé > > > [1] http://svn.apache.org/repos/asf/maven/site/trunk/ > > Le dimanche 12 février 2012 11:23:52 Benson Margulies a écrit : >> There are many Apache projects using Maven for some or all of their >> websites, and I think it would be a good public service to smooth >> their path to the requirement to use svnpubsub. >> >> After a bit of discussion on the infra list, I can now describe one >> scheme and I'd like to see what we can do to support it. >> >> First, assume that the user is going to have svn 1.7 as a client. >> We're aiming at our fellow Apache developers; if infra recommends 1.7, >> we can in conscience aim at that. >> >> So, the drill is as follows: >> >> 1) svn co a tree from svn used to publish the site. >> >> 2) remove all the local files, leaving the metadata. >> >> 3) run the site plugin aiming at this location. >> >> 4) svn remove all files in the metadata now absent from the tree, add >> all new files. >> >> 5) Pause, optionally, for review. >> >> 6) commit. >> >> I was thinking that this could be expressed as a plugin with a couple >> of goals to add to the site lifecycle, combined with the plain old >> ordinary local file wagon. I wonder if the scm provider API is strong >> enough to handle step 4, or whether this has to be coded from scratch, >> or whether it's reasonable to imagine extending the scm provider API >> to go here. >> >> Thoughts? >> >> --------------------------------------------------------------------- >> 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]
