You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Manfred Moser <ma...@mosabuam.com> on 2012/08/15 23:01:09 UTC
Re: uses for site generation for internal enterprise software when
a CI server is in use?
Agreed... another benefit imho is that it is the easiest way to provide a
static website about your project for users of your artifacts.
Specifically if you are providing an API you can just host the javadoc and
potentially even the crosslinked source code right there and augement it
with further documentation and links to e.g. wiki, forums, mailing lsits
and more
With the new fluido skin and others you can even make it look okay..
manfred
On Wed, August 15, 2012 1:57 pm, Anders Hammar wrote:
> My opinion is that it is most useful for Maven plugins. It provides a
> common documentation interface that people using Maven are used to.
>
> /Anders
>
> On Wed, Aug 15, 2012 at 9:49 PM, KARR, DAVID <dk...@att.com> wrote:
>> I'm putting together a "Maven benefits" doc for an internal
>> organization. I was wondering if I could make any argument for the
>> value of Maven's "site generation" functionality. Our documentation is
>> on wikis, and we have a CI server that aggregates build and analysis
>> reports. Does anyone make good use of site generation when it seems
>> like it wouldn't provide any additional value?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: uses for site generation for internal enterprise software when
a CI server is in use?
Posted by Manfred Moser <ma...@mosabuam.com>.
Yes.. that is a problem. I never understood why the standard behaviour for
site deployment is to overwrite whatever is deployed. Very much in
contrast to deployments of snapshots (timestamping them) or releases (not
allowing redeployment)..
However an easy workaround that also has the benefit of allowing you to
make e.g. an old version of the site (or javadoc and so on) available in
parallel to new ones and also push snapshot and release sites and all have
them live side by side is to use this kind of approach..
<distributionManagement>
<site>
<id>nexus-site</id>
<!-- Site hosting in Nexus -->
<!-- requires hosted repository with format maven-site and the
repository id "site-internal"-->
<url>
dav:http://localhost:8081/nexus/content/sites/site-internal/${project.groupId}/${project.artifactId}/${project.version}
</url>
</site>
</distributionManagement>
<build>
<!-- necessary for the dav protocol for deployment to Nexus -->
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-webdav-jackrabbit</artifactId>
<version>2.2</version>
</extension>
</extensions>
And yes.. this is set up for Nexus but should work for deployment to any
server...
Then you have them all available side by side and can just use a entry
site or http redirectors to redirect where you want.
And you can also deploy a new site for each snapshot build (in which case
it would overwrite the prior snapshot but NOT the prior release...)
Manfred
PS: Yes that was another shameless plugin from the Nexus class material..
but I am sure the same works with other servers as well
On Wed, August 15, 2012 2:11 pm, Anders Hammar wrote:
> Sure, but the problem with that IMHO is that you have a static site.
> So what are you going to do when you find an error in the site or want
> to add more docs? Wait and add that in the next release coming out in
> 6 months? You don't want that.
> But crosslinking the source code is nice though. The Javadoc could be
> managed in Nexus and linked to there (oh, what a shameless plug!).
>
> /Anders
>
> On Wed, Aug 15, 2012 at 11:01 PM, Manfred Moser <ma...@mosabuam.com>
> wrote:
>> Agreed... another benefit imho is that it is the easiest way to provide
>> a
>> static website about your project for users of your artifacts.
>> Specifically if you are providing an API you can just host the javadoc
>> and
>> potentially even the crosslinked source code right there and augement it
>> with further documentation and links to e.g. wiki, forums, mailing lsits
>> and more
>>
>> With the new fluido skin and others you can even make it look okay..
>>
>> manfred
>>
>> On Wed, August 15, 2012 1:57 pm, Anders Hammar wrote:
>>> My opinion is that it is most useful for Maven plugins. It provides a
>>> common documentation interface that people using Maven are used to.
>>>
>>> /Anders
>>>
>>> On Wed, Aug 15, 2012 at 9:49 PM, KARR, DAVID <dk...@att.com> wrote:
>>>> I'm putting together a "Maven benefits" doc for an internal
>>>> organization. I was wondering if I could make any argument for the
>>>> value of Maven's "site generation" functionality. Our documentation
>>>> is
>>>> on wikis, and we have a CI server that aggregates build and analysis
>>>> reports. Does anyone make good use of site generation when it seems
>>>> like it wouldn't provide any additional value?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: uses for site generation for internal enterprise software when a
CI server is in use?
Posted by Anders Hammar <an...@hammar.net>.
Sure, but the problem with that IMHO is that you have a static site.
So what are you going to do when you find an error in the site or want
to add more docs? Wait and add that in the next release coming out in
6 months? You don't want that.
But crosslinking the source code is nice though. The Javadoc could be
managed in Nexus and linked to there (oh, what a shameless plug!).
/Anders
On Wed, Aug 15, 2012 at 11:01 PM, Manfred Moser <ma...@mosabuam.com> wrote:
> Agreed... another benefit imho is that it is the easiest way to provide a
> static website about your project for users of your artifacts.
> Specifically if you are providing an API you can just host the javadoc and
> potentially even the crosslinked source code right there and augement it
> with further documentation and links to e.g. wiki, forums, mailing lsits
> and more
>
> With the new fluido skin and others you can even make it look okay..
>
> manfred
>
> On Wed, August 15, 2012 1:57 pm, Anders Hammar wrote:
>> My opinion is that it is most useful for Maven plugins. It provides a
>> common documentation interface that people using Maven are used to.
>>
>> /Anders
>>
>> On Wed, Aug 15, 2012 at 9:49 PM, KARR, DAVID <dk...@att.com> wrote:
>>> I'm putting together a "Maven benefits" doc for an internal
>>> organization. I was wondering if I could make any argument for the
>>> value of Maven's "site generation" functionality. Our documentation is
>>> on wikis, and we have a CI server that aggregates build and analysis
>>> reports. Does anyone make good use of site generation when it seems
>>> like it wouldn't provide any additional value?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org