I did minimal reading on mod_dav_svn, and posted a message to infrastructure@ to ask what they think of it.
I think we'd still need an extra maven plugin to organize deletions of no-longer-valid files. I'll start sketching something into the sandbox soon in the form of a pair of goals: one to run at the start and one to run at the end. What exactly happens is different if we're expecting to talk to dav as opposed to using the scm provider. Hervé or another site expert: can you think of a way for the first execution to pass the pathname of the site plugin of the place to deploy to, assuming for the moment the non-site trick? Obviously, it can just be done explicitly in the POM to start with. If site-folks think that deletion management (on the assumption of a wagon API for the purpose) should be a core site plugin feature, I could be easily roped into working on where to put it in there. --benson On Sun, Feb 12, 2012 at 4:58 PM, Benson Margulies <[email protected]>wrote: > 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] > > >
