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:pg...@redhat.com] 
Gesendet: Donnerstag, 26. Mai 2011 20:54
An: dev@mojo.codehaus.org
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 <pg...@redhat.com
> <mailto:pg...@redhat.com>> 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


Reply via email to