You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Martin Cooper <ma...@apache.org> on 2003/11/22 20:56:25 UTC
[site] Non-Maven web sites
I've updated the wiki page with the current status of all Commons Proper
sites (and some of the sandbox sites). See:
http://nagoya.apache.org/wiki/apachewiki.cgi?CreatingStandardWebPresence
The main thing that struck me, when putting this together, is the number
of components that have both Maven and non-Maven sites. In all such cases,
the non-Maven site is the one linked to from the main Commons page. The
components in this state are:
BeanUtils
Collections
Digester
Discovery
Jexl
Lang
Logging
Modeler
Is there any reason why we should not switch over to the Maven sites as
the main sites right now, and "deprecate" the non-Maven versions?
Other notable issues with Commons Proper components:
* EL does not currently have a Maven site.
* Launcher has no web presence at all, despite being a Proper component.
The Sandbox is not a pretty sight at all, but IMHO we should get Proper to
where we want it to be first, and then bring Sandbox up to the same level.
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Dirk Verbeeck <di...@pandora.be>.
Michael Becke wrote:
> As far as the standard nav goes, I think the idea is good, but the
> current layout of it does not appeal to me. In particular some of the
> most important information, the Project Documentation section, is
> obfuscated by showing up at the end of the nav. Is this a configurable
> option?
I would collapse the "Components Repository" and "Sandbox Components" menus
and move them into the "About Us" section.
Then I would add a compact product listing on the commons homepage.
Something like the products section on the jakarta homepage.
This will make the menu more compact and is also easier for first time visitors.
-- Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Michael Becke <be...@u.washington.edu>.
On Nov 22, 2003, at 3:47 PM, Phil Steitz wrote:
> There are two things that need to be resolved to make this happen,
> AFAIK. First, we need to settle the issue of what goes in CVS. If
> "all generated HTML" is the answer, we need to get all of the
> maven-generated HTML committed (many megs of redundant content, many
> redundant commit messages IMHO). Second, we need to agree on a common
> nav (as stated on the Wiki page). My vote would be to use
> commons/incl_nav uniformly. Several of the existing maven sites (both
> linked and unlinked) don't include this. I also agree with the Wiki
> proposal for the "standard" pages (FAQ, examples, etc).
>
> I deployed the lang maven site a couple of weeks ago and have been
> waiting to see where the CVS debate ended up (and some cleanup of the
> main site, so I could safely regenerate and commit all of the nav
> changes) before linking it (with some fixes).
>
> I am willing to help with this, starting with [lang] and
> [collections], first getting the basic sites out and then adding the
> missing pages. I am also willing to help document whatever site
> generation / cvs update process we agree on.
>
> Can we agree to omit the maven-generated HTML from cvs and use
> commons/incl_nav for the standard nav?
I would certainly prefer to exclude the maven-generated HTML from CVS.
The state of the HttpClient site is currently in limbo pending a
consensus on this question.
As far as the standard nav goes, I think the idea is good, but the
current layout of it does not appeal to me. In particular some of the
most important information, the Project Documentation section, is
obfuscated by showing up at the end of the nav. Is this a configurable
option?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by di...@multitask.com.au.
It'd be very easy to do in Maven, or Ant.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Michael Becke <be...@u.washington.edu> wrote on 23/11/2003 10:25:46 AM:
> On Nov 22, 2003, at 5:59 PM, Paul Libbrecht wrote:
>
> > Well, would it really be hard to actually automate a
> > CVS-commit/CVS-remote-update within maven ?
>
> Not sure. I am by no means a maven expert. This sounds like a good
> solution though.
>
> Mike
>
>
> ---------------------------------------------------------------------
> 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: [site] Non-Maven web sites
Posted by Michael Becke <be...@u.washington.edu>.
On Nov 22, 2003, at 5:59 PM, Paul Libbrecht wrote:
> Well, would it really be hard to actually automate a
> CVS-commit/CVS-remote-update within maven ?
Not sure. I am by no means a maven expert. This sounds like a good
solution though.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Paul Libbrecht <pa...@activemath.org>.
Michael Becke wrote:
> On Nov 22, 2003, at 5:04 PM, Dirk Verbeeck wrote:
>
>> With the commit mail problem solved the only issue is disk space but
>> that is an infrastructure issue. If CVS backup/restore is the policy
>> then why not.
>
>
> The only other issue, though not major, is the inconvenience of having
> to go through CVS to update a site. Maven site:deploy is certainly easier.
Well, would it really be hard to actually automate a
CVS-commit/CVS-remote-update within maven ?
An elementary version (that does not delete files) would be very easily
done...
Site deploy also doesn't delete...
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Michael Becke <be...@u.washington.edu>.
On Nov 22, 2003, at 5:04 PM, Dirk Verbeeck wrote:
> With the commit mail problem solved the only issue is disk space but
> that is an infrastructure issue. If CVS backup/restore is the policy
> then why not.
The only other issue, though not major, is the inconvenience of having
to go through CVS to update a site. Maven site:deploy is certainly
easier.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Henri Yandell <ba...@generationjava.com>.
How about:
jakarta-site2/commons ?
Hen
On Sat, 22 Nov 2003, Dirk Verbeeck wrote:
> How about creating a jakarta-commons-site for the generated html.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Dirk Verbeeck <di...@pandora.be>.
How about creating a jakarta-commons-site for the generated html.
It solves the commit mail problem => separate non-mandatory list for html
commit mails.
It meets the requirements from the infrastructure team and we have a place to
store the generated javadocs/userguides from official release builds.
Generated:
/jakarta-commons-site/index.html => commons homepage
/jakarta-commons-site/component/index.html => current component overview
/jakarta-commons-site/component/userguide/ => current component userguide
/jakarta-commons-site/component/apidocs/ => current API (cvs head)
/jakarta-commons-site/component/1.0/ => version 1.0
/jakarta-commons-site/component/1.0/apidocs/
/jakarta-commons-site/component/1.0/userguide/
/jakarta-commons-site/sandbox/component/* => sandbox component
Source:
/jakarta-commons/xdocs/* => commons site source
/jakarta-commons/component/xdocs/ => component site source
/jakarta-commons-sandbox/component/xdocs/ => sandbox component
With the commit mail problem solved the only issue is disk space but that is
an infrastructure issue. If CVS backup/restore is the policy then why not.
-- Dirk
Noel J. Bergman wrote:
>>First, we need to settle the issue of what goes in CVS. If "all
>>generated HTML" is the answer, we need to get all of the maven-
>>generated HTML committed (many megs of redundant content, many
>>redundant commit messages IMHO).
>
>
> What makes that any different from any Anakia or Forrest built site?
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: DBCP - ReapingObjectPool
Posted by Juan Ignacio Cidre <ji...@sib.interbanking.com.ar>.
I saw AbandonedObjectPool but it is deprecated and is in the DBCP.
I was looking for an ObjectPool.
I've extended GenericObjectPool with similar features.
Here it is.
I'm using this as the ObjectPool of a PoolingDataSource and is working
perfectly well.
note:
TimestampedStackTrace is not generic, it responds to my particular
needs and can be taken away or replaced pretty simple.
N.
Dirk Verbeeck wrote:
> Actually we already have something similar: AbandonedObjectPool.
> http://jakarta.apache.org/commons/dbcp/xref/org/apache/commons/dbcp/AbandonedObjectPool.html
>
>
> Many enhancements are possible, I have been playing around the
> java.lang.ref package to see if it can provide a safe way to recover
> abandoned objects.
>
> Contributing is as simple as posting your improvements to the list.
> A whole new file or a patch for existing files.
> If there isn't a committer around then you can also make a bugzilla
> item for it. Writing comments to make the review easier helps and if
> you have junit tests then you can be sure your contribution won't go
> unnoticed.
> If you're thinking about doing a lot of work then first discuss it on
> the list just to make sure we are on the same line.
>
> Contributions are always welcome, bugfixes, enhancements, website
> updates, documentation, you name it...
>
> Cheers
> Dirk
>
>
> Juan Ignacio Cidre wrote:
>
>> I was needing an ObjectPool that 'remembers' the borrowed objects so
>> it can recollect them if not returned after a while.
>>
>> Is there something like that arround?
>>
>> I've extended GenericObjectPool to have that functionallity. I can
>> give it to the project if there is not a better option than mine.
>> Since this would be my first contribution to the project, and I don't
>> know the customs, I would need some help (I've read all the on-line
>> guides, already, )
>> N.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: DBCP - ReapingObjectPool
Posted by Dirk Verbeeck <di...@pandora.be>.
Actually we already have something similar: AbandonedObjectPool.
http://jakarta.apache.org/commons/dbcp/xref/org/apache/commons/dbcp/AbandonedObjectPool.html
Many enhancements are possible, I have been playing around the java.lang.ref
package to see if it can provide a safe way to recover abandoned objects.
Contributing is as simple as posting your improvements to the list.
A whole new file or a patch for existing files.
If there isn't a committer around then you can also make a bugzilla item for
it. Writing comments to make the review easier helps and if you have junit
tests then you can be sure your contribution won't go unnoticed.
If you're thinking about doing a lot of work then first discuss it on the list
just to make sure we are on the same line.
Contributions are always welcome, bugfixes, enhancements, website updates,
documentation, you name it...
Cheers
Dirk
Juan Ignacio Cidre wrote:
> I was needing an ObjectPool that 'remembers' the borrowed objects so it
> can recollect them if not returned after a while.
>
> Is there something like that arround?
>
> I've extended GenericObjectPool to have that functionallity. I can give
> it to the project if there is not a better option than mine.
> Since this would be my first contribution to the project, and I don't
> know the customs, I would need some help (I've read all the on-line
> guides, already, )
> N.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DBCP - ReapingObjectPool
Posted by Juan Ignacio Cidre <ji...@sib.interbanking.com.ar>.
I was needing an ObjectPool that 'remembers' the borrowed objects so it
can recollect them if not returned after a while.
Is there something like that arround?
I've extended GenericObjectPool to have that functionallity. I can give
it to the project if there is not a better option than mine.
Since this would be my first contribution to the project, and I don't
know the customs, I would need some help (I've read all the on-line
guides, already, )
N.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
> On 22 Nov 2003, at 21:36, Phil Steitz wrote:
>
>> robert burrell donkin wrote:
>
>
> <snip>
>
>>> i'd personally find it very difficult to read all the commit mails
>>> from all the components in jakarta-commons if we started storing the
>>> sites in maven. this would raise questions about whether
>>> jakarta-commons can be properly supervised.
>>
>>
>> It seems silly to me that "supervising" the site means reading HTML
>> diffs. The xdoc diffs contain all of the relevant changes and, like
>> code changes, the best way to validate changes is to update and build
>> locally. I understand the argument about disaster recovery, but there
>> are other (standard) ways to deal with that.
>
>
> supervising the source code means reading all commit messages. the
> ability to read each and every commit message from jakarta-commons is a
> crucial part of supervision. the jakarta pmc is responsible for legal
> oversight. it might seem silly to you but being able to effectively
> review all changes is a crucial part of that oversight.
>
> as a jakarta-commons committer, you should really read every commit
> email for each component that you're interested in. all commits are
> approved collectively by lazy consensus. if you have any reservations
> about any change, you can post a -1 against the cvs commit email. you
> should definitely -1 if you see any content that may put the ASF at risk.
I do that now, Robert (always for [collections], [lang] and [primitives]
and usually for several other components as well). My standard approach
is to first review the diffs and then build locally and verify
(sometimes with a couple of days lag, unless I see something that I
don't understand). I do the second step after each significant change,
in any case at least once a week, reviewing the modified code in context
and running all tests. Is this OK?
What I meant above was that for maven-generated html, the xdocs diffs
give me at least a better picture of what the content change is than the
(redundant, IMHO) HTML diffs. I use the same approach for these -- look
at the xdoc diffs and then (maybe with a little latency) build locally
to verify that the generated content looks good.
Sorry if my comments above indicated that I did not see the need to
review and validate all code and web site content. I certainly did not
mean that.
Phil
>
> - 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: [site] Non-Maven web sites
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 22 Nov 2003, at 21:36, Phil Steitz wrote:
> robert burrell donkin wrote:
<snip>
>> i'd personally find it very difficult to read all the commit mails
>> from all the components in jakarta-commons if we started storing the
>> sites in maven. this would raise questions about whether
>> jakarta-commons can be properly supervised.
>
> It seems silly to me that "supervising" the site means reading HTML
> diffs. The xdoc diffs contain all of the relevant changes and, like
> code changes, the best way to validate changes is to update and build
> locally. I understand the argument about disaster recovery, but there
> are other (standard) ways to deal with that.
supervising the source code means reading all commit messages. the
ability to read each and every commit message from jakarta-commons is a
crucial part of supervision. the jakarta pmc is responsible for legal
oversight. it might seem silly to you but being able to effectively
review all changes is a crucial part of that oversight.
as a jakarta-commons committer, you should really read every commit
email for each component that you're interested in. all commits are
approved collectively by lazy consensus. if you have any reservations
about any change, you can post a -1 against the cvs commit email. you
should definitely -1 if you see any content that may put the ASF at
risk.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by di...@multitask.com.au.
"Noel J. Bergman" <no...@devtech.com> wrote on 23/11/2003 10:20:46 AM:
> > > by default, maven generates a *lot* of pages and recreates them new
> > > everytime. it's easy to supervise an anakia generated site by
watching
> > > the cvs diffs. the quantity of commits from a mavenized build will
> > > probably obscure the actual substance of the changes.
>
> > Yes. "Little" lang's is 16MB, including lots of maven images and other
> > stuff that would be replicated across all of the maven sites.
>
> Is there a means to have a common location for shared stuff? This
sounds
> like something to ask the Maven folks. I know that JvZ just looked at
the
> maven file for Geronimo, and immediately mentioned a whole bunch of
things
> that could be done better.
Depends on what you mean. About the only 'common' stuff is the /images
content generated by maven.
Currently that's not shareable.
>
> > I understand the argument about disaster recovery, but there
> > are other (standard) ways to deal with that.
>
> Feel free to join the infrastructure list, and discuss a change in
policy.
I'm there, and it's not being discussed!
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > by default, maven generates a *lot* of pages and recreates them new
> > everytime. it's easy to supervise an anakia generated site by watching
> > the cvs diffs. the quantity of commits from a mavenized build will
> > probably obscure the actual substance of the changes.
> Yes. "Little" lang's is 16MB, including lots of maven images and other
> stuff that would be replicated across all of the maven sites.
Is there a means to have a common location for shared stuff? This sounds
like something to ask the Maven folks. I know that JvZ just looked at the
maven file for Geronimo, and immediately mentioned a whole bunch of things
that could be done better.
> I understand the argument about disaster recovery, but there
> are other (standard) ways to deal with that.
Feel free to join the infrastructure list, and discuss a change in policy.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
> On 22 Nov 2003, at 20:57, Noel J. Bergman wrote:
>
>>> First, we need to settle the issue of what goes in CVS. If "all
>>> generated HTML" is the answer, we need to get all of the maven-
>>> generated HTML committed (many megs of redundant content, many
>>> redundant commit messages IMHO).
>>
>>
>> What makes that any different from any Anakia or Forrest built site?
>
>
> it's a difference of scale.
>
> by default, maven generates a *lot* of pages and recreates them new
> everytime. it's easy to supervise an anakia generated site by watching
> the cvs diffs. the quantity of commits from a mavenized build will
> probably obscure the actual substance of the changes.
Yes. "Little" lang's is 16MB, including lots of maven images and other
stuff that would be replicated across all of the maven sites.
>
> i'd personally find it very difficult to read all the commit mails from
> all the components in jakarta-commons if we started storing the sites in
> maven. this would raise questions about whether jakarta-commons can be
> properly supervised.
It seems silly to me that "supervising" the site means reading HTML
diffs. The xdoc diffs contain all of the relevant changes and, like
code changes, the best way to validate changes is to update and build
locally. I understand the argument about disaster recovery, but there
are other (standard) ways to deal with that.
>
> i wonder whether we could create a separate reactor style build for the
> web site. this could generate the content for everything into docs
> (say). this would have the advantage that all projects would have their
> sites updated together but would mean that it'd take quite a time to
> regenerate everything.
Interesting idea. I naively thought at one point that the nightly build
did this ;-)
>
> maybe we could petition infrastructure to use moof to build the site
> automatically and then rsync to minotaur...
>
> - 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: [site] Non-Maven web sites
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 22 Nov 2003, at 20:57, Noel J. Bergman wrote:
>> First, we need to settle the issue of what goes in CVS. If "all
>> generated HTML" is the answer, we need to get all of the maven-
>> generated HTML committed (many megs of redundant content, many
>> redundant commit messages IMHO).
>
> What makes that any different from any Anakia or Forrest built site?
it's a difference of scale.
by default, maven generates a *lot* of pages and recreates them new
everytime. it's easy to supervise an anakia generated site by watching
the cvs diffs. the quantity of commits from a mavenized build will
probably obscure the actual substance of the changes.
i'd personally find it very difficult to read all the commit mails from
all the components in jakarta-commons if we started storing the sites
in maven. this would raise questions about whether jakarta-commons can
be properly supervised.
i wonder whether we could create a separate reactor style build for the
web site. this could generate the content for everything into docs
(say). this would have the advantage that all projects would have their
sites updated together but would mean that it'd take quite a time to
regenerate everything.
maybe we could petition infrastructure to use moof to build the site
automatically and then rsync to minotaur...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by di...@multitask.com.au.
"Noel J. Bergman" <no...@devtech.com> wrote on 23/11/2003 07:57:24 AM:
> > First, we need to settle the issue of what goes in CVS. If "all
> > generated HTML" is the answer, we need to get all of the maven-
> > generated HTML committed (many megs of redundant content, many
> > redundant commit messages IMHO).
>
> What makes that any different from any Anakia or Forrest built site?
Forrest doesn't generate cross references, unit test reports, link checks,
checkstyle reports, unit test coverage, changelogs etc.
Maven generates content. Forrest and Anakia (from my limited knowledge)
simply transform it from XML to HTML and other formats.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by "Noel J. Bergman" <no...@devtech.com>.
> First, we need to settle the issue of what goes in CVS. If "all
> generated HTML" is the answer, we need to get all of the maven-
> generated HTML committed (many megs of redundant content, many
> redundant commit messages IMHO).
What makes that any different from any Anakia or Forrest built site?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Phil Steitz <ph...@steitz.com>.
Martin Cooper wrote:
> I've updated the wiki page with the current status of all Commons Proper
> sites (and some of the sandbox sites). See:
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?CreatingStandardWebPresence
>
> The main thing that struck me, when putting this together, is the number
> of components that have both Maven and non-Maven sites. In all such cases,
> the non-Maven site is the one linked to from the main Commons page. The
> components in this state are:
>
> BeanUtils
> Collections
> Digester
> Discovery
> Jexl
> Lang
> Logging
> Modeler
>
> Is there any reason why we should not switch over to the Maven sites as
> the main sites right now, and "deprecate" the non-Maven versions?
There are two things that need to be resolved to make this happen,
AFAIK. First, we need to settle the issue of what goes in CVS. If "all
generated HTML" is the answer, we need to get all of the maven-generated
HTML committed (many megs of redundant content, many redundant commit
messages IMHO). Second, we need to agree on a common nav (as stated on
the Wiki page). My vote would be to use commons/incl_nav uniformly.
Several of the existing maven sites (both linked and unlinked) don't
include this. I also agree with the Wiki proposal for the "standard"
pages (FAQ, examples, etc).
I deployed the lang maven site a couple of weeks ago and have been
waiting to see where the CVS debate ended up (and some cleanup of the
main site, so I could safely regenerate and commit all of the nav
changes) before linking it (with some fixes).
I am willing to help with this, starting with [lang] and [collections],
first getting the basic sites out and then adding the missing pages. I
am also willing to help document whatever site generation / cvs update
process we agree on.
Can we agree to omit the maven-generated HTML from cvs and use
commons/incl_nav for the standard nav?
Phil
>
> Other notable issues with Commons Proper components:
>
> * EL does not currently have a Maven site.
> * Launcher has no web presence at all, despite being a Proper component.
>
> The Sandbox is not a pretty sight at all, but IMHO we should get Proper to
> where we want it to be first, and then bring Sandbox up to the same level.
>
> --
> Martin Cooper
>
>
> ---------------------------------------------------------------------
> 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
[all][site] Non-Maven web sites
Posted by Tim O'Brien <to...@discursive.com>.
I think storing HTML in CVS is a little redundant, but I also realize
that infrastructure is a set of hard working volunteers, and what's the
use of arguing.
That being said, where do we commit commons sites? jakarta-site2/commons/X?
Also, Robert brings up some good points about not rushing too fast,
Maven isn't 1.0 yet. That being said, I think that Jakarta Commons
needs a common look and feel yesterday, I think that having a confusing
website sends a confusing message and ultimately affects quality.
Tim
Phil Steitz wrote:
> robert burrell donkin wrote:
>
>> On 22 Nov 2003, at 21:09, Noel J. Bergman wrote:
>>
>> <snip>
>>
>>>> there are also some features that many of these web sites use that are
>>>> not (easily) available through maven.
>>>
>>>
>>>
>>> Have these been raised to the Maven project?
>>
>>
>>
>> it's mainly access to information related to a particular release.
>> this is static and is currently not stored in cvs. it should just be
>> a case of some careful re-organization.
>
>
> What I did in [lang] (which I am about to remove pending resolution of
> the cvs placement issue) was to use the existing link in the body of
> the main page to the "release" javadoc (leaving the files in place)
> and allow the Maven "project reports" section to point to the
> "current" javadoc. That seems natural to me and I don't think that
> this kind of thing will be that hard to handle. It will just require
> that we maintain directories for the non-maven generated content and
> correct links in the xdocs.
>
> After reviewing the archives and doing some more research, I now
> understand fully the rationale for storing all HTML in cvs and I don't
> think that there is much value in debating this issue any more. Sorry
> if I was beating a dead horse above.
>
> That said, to move forward with [lang] and [collections] I need a
> place to commit the maven-generated HTML. I could just add it all
> into jakarta-commons/lang (resp. collections). Is that what I should
> do (adding the other files in the current site that aren't in cvs as
> well)?
>
> Phil
>
>>
>> - 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by Phil Steitz <ph...@steitz.com>.
robert burrell donkin wrote:
> On 22 Nov 2003, at 21:09, Noel J. Bergman wrote:
>
> <snip>
>
>>> there are also some features that many of these web sites use that are
>>> not (easily) available through maven.
>>
>>
>> Have these been raised to the Maven project?
>
>
> it's mainly access to information related to a particular release. this
> is static and is currently not stored in cvs. it should just be a case
> of some careful re-organization.
What I did in [lang] (which I am about to remove pending resolution of
the cvs placement issue) was to use the existing link in the body of the
main page to the "release" javadoc (leaving the files in place) and
allow the Maven "project reports" section to point to the "current"
javadoc. That seems natural to me and I don't think that this kind of
thing will be that hard to handle. It will just require that we maintain
directories for the non-maven generated content and correct links in the
xdocs.
After reviewing the archives and doing some more research, I now
understand fully the rationale for storing all HTML in cvs and I don't
think that there is much value in debating this issue any more. Sorry
if I was beating a dead horse above.
That said, to move forward with [lang] and [collections] I need a place
to commit the maven-generated HTML. I could just add it all into
jakarta-commons/lang (resp. collections). Is that what I should do
(adding the other files in the current site that aren't in cvs as well)?
Phil
>
> - 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: [site] Non-Maven web sites
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 22 Nov 2003, at 21:09, Noel J. Bergman wrote:
<snip>
>> there are also some features that many of these web sites use that are
>> not (easily) available through maven.
>
> Have these been raised to the Maven project?
it's mainly access to information related to a particular release. this
is static and is currently not stored in cvs. it should just be a case
of some careful re-organization.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > FWIW, one of the Geronimo Committers is having a problem right now
> > because maven is crashing building their site, so he hasn't been
> > able to commit it.
> They haven't posted to the maven mailing lists yet, that'd help get it
> fixed faster.
You are preaching to the choir. But in this case, I caught Jason on IRC and
he was able to help them out. He has subscribed to their list, and also
provided a build that fixed some of their problems.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by di...@multitask.com.au.
"Noel J. Bergman" <no...@devtech.com> wrote on 23/11/2003 08:09:40 AM:
> > i think that mandating maven as the build system for all
> > components is quite a big change. i've often had to run
> > custom patched versions of maven and i'd prefer to wait
> > until a proper 1.0 release before we force everyone to use it.)
>
> FWIW, one of the Geronimo Committers is having a problem right now
because
> maven is crashing building their site, so he hasn't been able to commit
it.
They haven't posted to the maven mailing lists yet, that'd help get it
fixed faster.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [site] Non-Maven web sites
Posted by "Noel J. Bergman" <no...@devtech.com>.
> i think that mandating maven as the build system for all
> components is quite a big change. i've often had to run
> custom patched versions of maven and i'd prefer to wait
> until a proper 1.0 release before we force everyone to use it.)
FWIW, one of the Geronimo Committers is having a problem right now because
maven is crashing building their site, so he hasn't been able to commit it.
> there are also some features that many of these web sites use that are
> not (easily) available through maven.
Have these been raised to the Maven project?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [site] Non-Maven web sites
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 22 Nov 2003, at 19:56, Martin Cooper wrote:
> I've updated the wiki page with the current status of all Commons
> Proper
> sites (and some of the sandbox sites). See:
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?
> CreatingStandardWebPresence
>
> The main thing that struck me, when putting this together, is the
> number
> of components that have both Maven and non-Maven sites. In all such
> cases,
> the non-Maven site is the one linked to from the main Commons page. The
> components in this state are:
>
> BeanUtils
> Collections
> Digester
> Discovery
> Jexl
> Lang
> Logging
> Modeler
>
> Is there any reason why we should not switch over to the Maven sites as
> the main sites right now, and "deprecate" the non-Maven versions?
-1
for most of these components, the existing sites are the primary
maintained versions. the mavenized sites are secondary versions which
have been posted up but are not actively maintained by the committers
responsible for these components. it's important that the current
websites for these components are not replaced by outdated and possible
inaccurate information.
all components need to be given the chance to update their maven builds
and transfer their existing content before the existing sites are
removed. (i think that mandating maven as the build system for all
components is quite a big change. i've often had to run custom patched
versions of maven and i'd prefer to wait until a proper 1.0 release
before we force everyone to use it.)
there are also some features that many of these web sites use that are
not (easily) available through maven. in particular, maven javadocs are
created from head whereas the javadocs for the latest release are made
available at the moment. time is needed to resolve issues like this.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org