If Ben turns on rewrite rules in .htaccess, we can push a .htaccess with an antrun as part of the release profile.
On Fri, May 27, 2011 at 3:48 AM, Markus Mahlberg <[email protected]> wrote: > Thw hole point is that relying on symlinks is simply not a portable way to do > it. > Neither do all operating systems support symbolic links nor does even the > Apache httpd necessarily follow them. > > And the idea should be to solve that issue once and for all, shouldn't it? > > I'll post a modified pom.xml to achieve a versioned site on the weekend, > since it's really not too much of a problem to achieve what is required. > > Kind regards, > > Markus > > -----Ursprüngliche Nachricht----- > Von: Paul Gier [mailto:[email protected]] > Gesendet: Donnerstag, 26. Mai 2011 20:54 > An: [email protected] > Betreff: Re: [mojo-dev] Alternative idea about site publication > > I was thinking the directory structure is the same as at Apache, so a > separate directory for each version of the site. > > http://maven.apache.org/plugins/maven-antrun-plugin/ > http://maven.apache.org/plugins/maven-antrun-plugin-1.5/ > http://maven.apache.org/plugins/maven-antrun-plugin-1.6/ > > The current version is the directory with no version, and that would > just be a file system symbolic link to the directory of the current release. > > maven-antrun-plugin -> maven-antrun-plugin-1.6 > > I think Apache would handle this without any problems, but I haven't > tested it. When the next release is staged, the site is deployed to > > maven-antrun-plugin-1.7 > > Assuming that the release went fine, you just update the link to the new > directory. > > maven-antrun-plugin -> maven-antrun-plugin-1.7 > > On 05/24/2011 11:53 PM, Anders Hammar wrote: >> I see lots of benefits of deploying each version of the site to a >> different location. However, when you say symlink, do do you mean file >> system symbolic link? Wouldn't that mean that we need to keep the >> versioned site deployment in different folder tree than the latest one? >> That could make some other web server configuration more cumbersome >> (need to add aliases possibly). >> >> I think it would great if >> http://mojo.codehaus.org/awesome-maven-plugin/ >> would take me to the latest (official) site of this plugin. If I want to >> view a specific version of the site, I'd just add the version (or >> similar) number: >> http://mojo.codehaus.org/buildnumber-maven-plugin/1.0/ >> >> An automatic solution would be good, but I don't see a problem with >> having a manual step. Hey, there are lots of manual steps in the release >> process already. >> >> /Anders >> >> On Wed, May 25, 2011 at 04:44, Paul Gier <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 05/21/2011 07:30 PM, Markus Mahlberg wrote: >> > For what it's worth, I agree with you about versioned docs, but >> we surely have to talk about the technical details. >> > >> > You are assuming that .htaccess files are taken into consideration >> by the webserver, which isn't neccessarily so. >> > Most of the httpds out there don't, the Apache httpd being the >> only one as far as I know. >> > And even the Apache httpd does not necessarily obey the directives >> of the .htaccess files. As a result, relying on the .htaccess files >> would >> > "condemn" every mirror (if existing) and mojo.codehaus.org >> <http://mojo.codehaus.org> to use the Apache httpd from now on, not >> to mention a certain configuration of the apache which had to be >> obeyed (and documented, tested, maintained, *mumble* ...) >> > >> > That beeing said, we could think of creating a site with multiple >> versions of itself in case according tags are present in the used >> SCM system. >> > But to be honest with you, I have a strong feeling that this would >> easily lead to configuration monsters. >> > >> > Propably the easiest way to achieve what you want is to simply add >> a version number to every "release site" directory and link them >> manually. >> > >> >> I like the idea of adding a version number to each site deployment, and >> then just creating a symlink to point to the current release. That >> would allow for easy staging, and when the release is finished, just >> update the link. Anyone else open to this idea? >> >> >> > Another idea would be to have a directory structure like >> > >> > foo-plugin-site/ >> > |-- 1.0 >> > |-- 1.1 >> > |-- 1.2 >> > `-- 1.3 >> > >> > on the server and have the site-plugin write an index.html >> according to the existing directories, probably with the help of a >> meta file in 'foo-plugin-site'. >> > But even the concept would have a major impact on the whole >> community (since it has an impact on a well introduced behavior) and >> therefor has to be _carefully_ planned and discussed. >> > >> > >> > Kind regards, >> > >> > Markus >> > >> > Am 22.05.2011 um 01:38 schrieb Benson Margulies: >> > >> >> Something tells me that you've all considered and rejected this >> before, but ... >> >> >> >> What if the site deployment URL was set to include a version number >> >> element, and then part of the release process was to update a >> >> .htaccess to point to the latest release? >> >> >> >> Then you could deploy a snapshot site, and people who really >> wanted to >> >> could look at old release sites, and a new release wouldn't >> occupy the >> >> main URL until after the vote passed. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe from this list, please visit: >> >> >> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this list, please visit: >> > >> > http://xircles.codehaus.org/manage_email >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
