"Noel J. Bergman" <[EMAIL PROTECTED]> 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
>
It'd be very easy to do in Maven, or Ant.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Michael Becke <[EMAIL PROTECTED]> 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 actua
robert burrell donkin wrote:
On 22 Nov 2003, at 21:09, Noel J. Bergman wrote:
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 re
On 22 Nov 2003, at 21:36, Phil Steitz wrote:
robert burrell donkin wrote:
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 prop
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: [EMAIL PROTECTED]
For additional commands, e-mail
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
---
> > 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
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
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 configurabl
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 u
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 redund
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 bui
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 IM
On 22 Nov 2003, at 21:09, Noel J. Bergman wrote:
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 cur
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 diff
> 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
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 togeth
> 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 s
18 matches
Mail list logo
