You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/02/07 21:12:54 UTC
[general] Maven 'LATEST-RELEASE' tag suggestion
I've been playing a little with multiproject stuff on a personal project
[http://www.osjava.org/genjava] and one problem I hit is the classic one
where I have a new component to release but I have to rebuild the whole
site to get the navigation updated. At the same time, I don't want to
rebuild the whole site as other components may not be ready for their
xdocs, source-xref, javadoc and test-xref to be updated when it's not
their released version. We have the same problem in Commons.
I think I'm going to solve it by having a LATEST-RELEASE tag in CVS, that
I move for each compoennt on each new release. The site is always built
from LATEST-RELEASE, and when I release a new component I 'cvs tag -F'
that with the LR tag.
While I've not played with it yet, it feels like a good solution, so
thought I'd suggest it here.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Maybe you/we could migrate that into the
/jakarta-commons/commons-build/maven.xml file?
-Mark
Stephen Colebourne wrote:
> See the [collections] website for one way of doing this.
>
> The main site is always bleeding edge.
> But, the navigation has explicit links to versioned javadoc.
> The maven xml grabs the cvs tagged code to create the additional javadoc.
> It seems quite neat (but then I did it...;-)
>
> Stephen
>
> From: "Mark R. Diggory" <md...@latte.harvard.edu>
>
>>No, thats a really good point about versioned javadoc. Javadoc for
>>version 1.0, 2.0, ..., Current of a subproject.
>>
>>This would require maintaining the content of previous release site
>>generations, pushing into a special directory reserved for its archiving.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by Stephen Colebourne <sc...@btopenworld.com>.
See the [collections] website for one way of doing this.
The main site is always bleeding edge.
But, the navigation has explicit links to versioned javadoc.
The maven xml grabs the cvs tagged code to create the additional javadoc.
It seems quite neat (but then I did it...;-)
Stephen
From: "Mark R. Diggory" <md...@latte.harvard.edu>
> No, thats a really good point about versioned javadoc. Javadoc for
> version 1.0, 2.0, ..., Current of a subproject.
>
> This would require maintaining the content of previous release site
> generations, pushing into a special directory reserved for its archiving.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by Gus Heck <gu...@olin.edu>.
Sounds like you want something called "date space" directories... where
you have /var/www/html/site/2004/02/09/foo and symlinks are used to
point to the correct date so that the world can find the current version
at http://example.org/foo or a specific version at
http://example.org/2004/02/09/foo. (somewhat like w3c recs). One of the
issues with this is that over time if you have a site where various
sections update at different intervals, and some sections have one or
more un-released incomplete next-versions, the symlinks begin to
represent fairly valuable information, which is not backed up anywhere.
Since this describes the site I work on, I wrote an ant task that will
record and re-create symlinks using properties files. So if you go this
route you may (or may not) want to check it out ant's <symlink> task and
set up some scripts or targets to maintain this information. However,
this may not be as neccessary because in your case, there are one or
more people for each sub-section that can probably manually maintain a
few such links each. In my case I have over a dozen sections and there
is just one of me so I automate it :).
-Gus
robert burrell donkin wrote:
>
> On 7 Feb 2004, at 21:32, Mark R. Diggory wrote:
>
>> robert burrell donkin wrote:
>>
>>> On 7 Feb 2004, at 20:53, Mark R. Diggory wrote:
>>> <snip>
>>>
>>>> It also gives developers some room to work. If there is a global
>>>> nightly/weekly process for generating the commons site and its
>>>> sub-projects then in reality they probibly don't want the site
>>>> xref/xdocs generated off of thier bleeding edge all the time.
>>>
>>> hmmm...
>>> i'd probably want the best of both worlds - the latest and greatest
>>> version but also versions of the site for each release. i suppose
>>> that it'd be possible to do something with directories so
>>> commons/kool/current would contain the latest version but
>>> commons/kool/7.12.89/ would contain the documentation which was
>>> current when 7.12.89 was released.
>>> just a suggestion (rather than a criticism)...
>>> - robert
>>
>>
>> No, thats a really good point about versioned javadoc. Javadoc for
>> version 1.0, 2.0, ..., Current of a subproject.
>>
>> This would require maintaining the content of previous release site
>> generations, pushing into a special directory reserved for its
>> archiving.
>
>
> craig advocated something similar in the original commons release
> documents (but only kept the last release). it shouldn't be too great
> a burden to copy the current website into a specially numbered
> directory when a release is cut.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Feb 2004, at 21:32, Mark R. Diggory wrote:
> robert burrell donkin wrote:
>
>> On 7 Feb 2004, at 20:53, Mark R. Diggory wrote:
>> <snip>
>>> It also gives developers some room to work. If there is a global
>>> nightly/weekly process for generating the commons site and its
>>> sub-projects then in reality they probibly don't want the site
>>> xref/xdocs generated off of thier bleeding edge all the time.
>> hmmm...
>> i'd probably want the best of both worlds - the latest and greatest
>> version but also versions of the site for each release. i suppose
>> that it'd be possible to do something with directories so
>> commons/kool/current would contain the latest version but
>> commons/kool/7.12.89/ would contain the documentation which was
>> current when 7.12.89 was released.
>> just a suggestion (rather than a criticism)...
>> - robert
>
> No, thats a really good point about versioned javadoc. Javadoc for
> version 1.0, 2.0, ..., Current of a subproject.
>
> This would require maintaining the content of previous release site
> generations, pushing into a special directory reserved for its
> archiving.
craig advocated something similar in the original commons release
documents (but only kept the last release). it shouldn't be too great a
burden to copy the current website into a specially numbered directory
when a release is cut.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
robert burrell donkin wrote:
> On 7 Feb 2004, at 20:53, Mark R. Diggory wrote:
>
> <snip>
>
>> It also gives developers some room to work. If there is a global
>> nightly/weekly process for generating the commons site and its
>> sub-projects then in reality they probibly don't want the site
>> xref/xdocs generated off of thier bleeding edge all the time.
>
>
> hmmm...
>
> i'd probably want the best of both worlds - the latest and greatest
> version but also versions of the site for each release. i suppose that
> it'd be possible to do something with directories so
> commons/kool/current would contain the latest version but
> commons/kool/7.12.89/ would contain the documentation which was current
> when 7.12.89 was released.
>
> just a suggestion (rather than a criticism)...
>
> - robert
No, thats a really good point about versioned javadoc. Javadoc for
version 1.0, 2.0, ..., Current of a subproject.
This would require maintaining the content of previous release site
generations, pushing into a special directory reserved for its archiving.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 7 Feb 2004, at 20:53, Mark R. Diggory wrote:
<snip>
> It also gives developers some room to work. If there is a global
> nightly/weekly process for generating the commons site and its
> sub-projects then in reality they probibly don't want the site
> xref/xdocs generated off of thier bleeding edge all the time.
hmmm...
i'd probably want the best of both worlds - the latest and greatest
version but also versions of the site for each release. i suppose that
it'd be possible to do something with directories so
commons/kool/current would contain the latest version but
commons/kool/7.12.89/ would contain the documentation which was current
when 7.12.89 was released.
just a suggestion (rather than a criticism)...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general] Maven 'LATEST-RELEASE' tag suggestion
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
This make sense, but makes the developers job a little tougher, if they
want a xdoc to be in the LASTEST_RELEASE, they have to move the tag
after they commit.
(Of course, this also makes our developers more aware of their actions
and the state of a particular change in the CVS, which is actually a
positive effect).
It also gives developers some room to work. If there is a global
nightly/weekly process for generating the commons site and its
sub-projects then in reality they probibly don't want the site
xref/xdocs generated off of thier bleeding edge all the time.
+1
-Mark
Henri Yandell wrote:
> I've been playing a little with multiproject stuff on a personal project
> [http://www.osjava.org/genjava] and one problem I hit is the classic one
> where I have a new component to release but I have to rebuild the whole
> site to get the navigation updated. At the same time, I don't want to
> rebuild the whole site as other components may not be ready for their
> xdocs, source-xref, javadoc and test-xref to be updated when it's not
> their released version. We have the same problem in Commons.
>
> I think I'm going to solve it by having a LATEST-RELEASE tag in CVS, that
> I move for each compoennt on each new release. The site is always built
> from LATEST-RELEASE, and when I release a new component I 'cvs tag -F'
> that with the LR tag.
>
> While I've not played with it yet, it feels like a good solution, so
> thought I'd suggest it here.
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org