Re: getting involved again

[Ben Walding]

Here are some easy things to do that we are too lazy to do. I'm also 
wary of allocating anything that would be redone in maven-new. No point 
reinventing the wheel.

MAVEN-419 - Perhaps a migration to the new tigris style might be in 
order as well style.tigris.org / styles.tigris.org
MAVEN-159 - Not sure what this is about, but pretty simple and 
self-contained
MAVEN-396 - Someone with a pint of XSL skills could fix the hack I did here
MAVEN-395 - Will probably clash with maven-new
MAVEN-391 - XSL / JSL

MAVEN-386 Work out a good way to get & into navigation and xdoc pages
MAVEN-367 Might be simple, looks like some kind of transformation problem
MAVEN-272 Velocity hack
That'll keep you busy

If it turns out that they are already fixed, let me know so I can close 
them.



Brett Porter wrote:

Hi,

Now that I have a bit more time on my hands again, I'd like to get involved
in improving Maven (last time I said that it promptly disappeared of
course!)
I'm just wondering if there are any particular areas I could focus on, or
any reading I can do about maven-new. I've been working through a few things
on JIRA, but a lot I can't replicate, can't fix without making significant
changes, or are likely to disappear just due to the maven-new structure.
For now I'm just going to try and fix the things that affect me when I use
maven to build my "real" work - but with any luck that will run out soon ;)
Thanks,
Brett
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

getting involved again

[Brett Porter]

Hi,

Now that I have a bit more time on my hands again, I'd like to get involved
in improving Maven (last time I said that it promptly disappeared of
course!)

I'm just wondering if there are any particular areas I could focus on, or
any reading I can do about maven-new. I've been working through a few things
on JIRA, but a lot I can't replicate, can't fix without making significant
changes, or are likely to disappear just due to the maven-new structure.

For now I'm just going to try and fix the things that affect me when I use
maven to build my "real" work - but with any luck that will run out soon ;)

Thanks,
Brett

cvs commit: maven/src/test/touchstone-build/src/reactor-build/standard project.properties

[jvanzyl]

jvanzyl 2003/06/06 18:27:53

  Modified:.project.xml
   src/conf driver.properties
   src/java/org/apache/maven MavenConstants.java
MavenUtils.java
   src/test/touchstone-build maven.xml
   src/test/touchstone-build/src/reactor-build/standard
project.properties
  Added:   src/conf defaults.properties
  Log:
  o MAVEN-294
  
Applying John Casey's patches for dealing with property values that are
present in driver.properties that need to be overriden.
  
  Revision  ChangesPath
  1.276 +1 -2  maven/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/maven/project.xml,v
  retrieving revision 1.275
  retrieving revision 1.276
  diff -u -r1.275 -r1.276
  --- project.xml   28 May 2003 23:13:44 -  1.275
  +++ project.xml   7 Jun 2003 01:27:52 -   1.276
  @@ -525,9 +525,8 @@
 *.xsd
 *.dtd
 *.mod
  -  log4j.properties
  +  *.properties
 driver.jelly
  -  driver.properties
   
 
 
  
  
  
  1.7   +0 -48 maven/src/conf/driver.properties
  
  Index: driver.properties
  ===
  RCS file: /home/cvs/maven/src/conf/driver.properties,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- driver.properties 4 May 2003 23:44:31 -   1.6
  +++ driver.properties 7 Jun 2003 01:27:52 -   1.7
  @@ -2,60 +2,12 @@
   # D R I V E R  P R O P E R T I E S
   # ---
   
  -maven.home.local = ${user.home}/.maven
  -
  -maven.src.dir = ${basedir}/src
  -maven.conf.dir = ${basedir}/conf
  -maven.build.dir = ${basedir}/target
  -maven.build.src = ${maven.build.dir}/src
  -maven.build.dest = ${maven.build.dir}/classes
  -
  -maven.compile.debug = on
  -maven.compile.optimize = off
  -maven.compile.deprecation = off
  -
  -maven.jar.excludes = **/package.html
  -
   maven.final.name = ${pom.artifactId}-${pom.currentVersion}
   maven.final.dir = ${basedir}/${maven.final.name}
   
   
   # ---
  -# M A V E N  L O C A L  R E P O
  -# ---
  -maven.repo.local = ${maven.home.local}/repository
  -
  -# ---
  -# M A V E N  P L U G - I N  D I R E C T O R Y
  -# ---
  -maven.plugin.dir = ${maven.home}/plugins
  -maven.plugin.unpacked.dir = ${maven.home.local}/plugins
  -
  -# ---
  -# M A V E N  R E M O T E  R E P O S
  -# ---
  -maven.repo.remote = http://www.ibiblio.org/maven
  -maven.repo.central = login.ibiblio.org
  -maven.repo.central.directory = /public/html/maven
  -maven.repo.remote.enabled = true
  -
  -# ---
  -# M A V E N  D I S T R I B U T I O N S
  -# ---
  -maven.distBuildDirectory = ${basedir}/target
  -maven.distBuildIndicator = DIST_BUILD_DIRECTORY
  -maven.distDirectory = ${basedir}/dist
  -
  -# ---
  -# E N V I R O N M E N T  D E P E N D E N T  T O O L S
  -# ---
  -maven.scp.executable = scp
  -maven.ssh.executable = ssh
  -
  -# ---
   # Mark the defaults as loaded - PLEASE DON'T OVERRIDE
   # ---
   maven.defaults.loaded = true
   
  -maven.build = MAVEN_BUILD_NOT_SET
  -maven.username = USERNAME_NOT_SET
  
  
  
  1.1  maven/src/conf/defaults.properties
  
  Index: defaults.properties
  ===
  # ---
  # D R I V E R  P R O P E R T I E S
  # ---
  
  maven.home.local = ${user.home}/.maven
  
  maven.src.dir = ${basedir}/src
  maven.conf.dir = ${basedir}/conf
  maven.build.dir = ${basedir}/target
  maven.build.src = ${maven.build.dir}/src
  maven.build.dest = ${maven.build.dir}/classes
  
  maven.compile.debug = on
  maven.compile.optimize = off
  maven.compile.deprecation = off
  
  maven.jar.excludes = **/package.html
  
  # ---
  # M A V E N  L O C A L  R E P O 
  # --

Re: mm.mysql on ibiblio - illegal in JAR dep

[Ben Walding]

I have copied mm.mysql to mm-mysql, and renamed the artifacts appropriately.

Now stop using it so it can be removed one day!  (this will ultimately 
break when we move to a hierarchical directory structure that is 
predicated on using . in groupIds to set the structure - ala java packages)

Cheers,

Ben

Ben Walding wrote:

It was disabled again shortly after beta9, for that and a few other 
reasons.

Brett Porter wrote:

Sorry, I was too broad.

groupId is fine - you are right. It is artifactId with a '.' that is 
a problem.

Extension-Name is what is provided in the JAR manifest when 
generated. Its broken in a couple of places in -beta-9.

Cheers,
Brett
Martin Skopp wrote:

On Mon, 2003-05-19 at 09:33, Brett Porter wrote:

Hi,

Due to the extension mechanism metadata in JARs, mm.mysql is an 
invalid artifact name.

Since this is the only offender, can this be renamed to mm-mysql on 
ibiblio and '.' made illegal in an artifactId/groupId?




Don't know this "extension mechanism" - what is it?
I have "com.myname" here in my inhouse repo without problems.
From the docs I understand that the  is especially used to


specify such prefixes like "org.apache" or "com.sun" etc.
So - the '.' should not be illegal?!?





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Ibiblio Request] Latest Mysql connector 3.0.7

[Ben Walding]

Seems like 3.0.7 is no longer the latest.

I've uploaded 3.0.8-stable.

Let me know if you really really want 3.0.7

Luke Taylor wrote:

http://www.mysql.com/downloads/api-jdbc-stable.html

There's a jar file inside the zip or tgz download.

Thanks a lot,

Luke.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [IBIBLIO] Upload Tapestry latest

[Ben Walding]

Done.

[EMAIL PROTECTED] wrote:

Please upload the latest Tapestry JARs to Maven repository.

project.xml and jars are at

http://jakarta.apache.org/~hlship

Thanks!

--
[EMAIL PROTECTED]
Creator, Tapestry: Java Web 
Components
http://jakarta.apache.org/tapestry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven/src/plugins-build/repository/src/plugin-resources repository-audit.xml

[bwalding]

bwalding2003/06/06 16:38:06

  Modified:src/plugins-build/repository/src/plugin-resources
repository-audit.xml
  Log:
  Tanuki service wrapper (MIT) and EnterpriseDT ftp client (LGPL)
  
  Revision  ChangesPath
  1.25  +14 -0 
maven/src/plugins-build/repository/src/plugin-resources/repository-audit.xml
  
  Index: repository-audit.xml
  ===
  RCS file: 
/home/cvs/maven/src/plugins-build/repository/src/plugin-resources/repository-audit.xml,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- repository-audit.xml  1 Jun 2003 10:30:10 -   1.24
  +++ repository-audit.xml  6 Jun 2003 23:38:06 -   1.25
  @@ -533,6 +533,13 @@
 
   
 
  +edtftp
  +http://www.enterprisedt.com/downloads/ftp.html
  +http://www.enterprisedt.com/downloads/ftp.html
  +LGPL - The download contains the license in doc/LICENSE.TXT
  +  
  +
  +  
   excalibur-altrmi
   http://jakarta.apache.org/avalon/excalibur/altrmi/index.html
   
http://cvs.apache.org/viewcvs.cgi/*checkout*/avalon-excalibur/LICENSE.txt
  @@ -1548,6 +1555,13 @@
Apache license
doesn't seem to be downloadable in this form though..
   
  +  
  +
  +  
  +wrapper
  +http://sourceforge.net/projects/wrapper/
  +http://sourceforge.net/projects/wrapper/
  +MIT License - The download contains the license in 
doc/license.txt
 
   
 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Repository Upload Request]Upgrade Jakarta Commons Codec

[Ben Walding]

Done.

[EMAIL PROTECTED] wrote:

Guys,

please upgrade Apache Jakarta Commons Codec from 1.0-dev to 1.1

Download from http://jakarta.apache.org/site/sourceindex.cgi

into http://www.ibiblio.org/maven/commons-codec/jars/

thanx
Martin
-
This mail sent through IMP: http://horde.org/imp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Repository Upload Request] xalan 2.5.1 & xercesImpl 2.4.0

[Ben Walding]

Done

Scott Eade wrote:

Can someone please upload xalan-2.5.1.jar & xercesImpl-2.4-0.jar to 
ibiblio.

I have put a copy of these jars at: 
http://members.iinet.net.au/~seade/public_html/

I haven't bothered with the resource template as the values are pretty 
obvious for these jars.

I am not a subscriber to the maven dev list, so please reply to me 
directly if anything further is required.

Thanks,

Scott



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PROPOSAL] Maven POM re-org to address deps + test issues

[Brett Porter]

Hi,

Based on the discussions about "test levels" and about isolating test, 
runtime and compile time dependencies, I thought about some changes to 
the POM that might help, and got a bit carried away ;)
This is a work in progress with a few limitations discussed later, but I 
thought it might be a good starting point for a discussion to address 
some of the issues. Bear in mind I wrote this on the train at 7am this 
morning ;)

What I propose is remove  and everything in it. Move 
 to that level, and then add the following elements:


  
required-name

  set-name
  other-set-name


  ...
  
...
  
  
...
  


  


  


  
  
...
  
  
...
  


  
  value

  
  


Finally, you can includes/exclude sets from the command line to avoid 
processing certain sets:
maven -Dexclude.sets=perf-test,integ-test
or
maven -Dinclude.sets=gen-jaxb,default

Now the problems I see with it:
* Not that comfortable with the extends syntax - bit too similar to POM 
inheritance. Could be used to fold subprojects. However, need a way to 
include deps and classpath built sources of other sets without 
duplication. Any thoughts on this?
* This pattern allows multiple source trees. It does takes care of 
generated source (antlr, jaxb) more cleanly (source would be the 
descriptor files, then plugin uses addPath for java sources). However, 
could be used to have multiple java source trees for a real project. 
Maybe this is ok - let those who've demanded it have it, but perhaps 
display a warning every run that it is a bad practice :)
* The specification of plugins does worry me a bit, but I don't see 
alternatives. Certain things should make use of new plugins 
automatically (some site related plugin should apply to all source 
trees), but others must be blocked out.

Also, how does this fit with maven-new's structure?

Cheers,
Brett
--
Web Developer
f2 network ~ everything essential
02 8596 4437
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Mailing List URLs are stale

[nick . minutello]

Hi,

The Mailing List URL's on the Maven site are stale:
http://maven.apache.org/mail-lists.html
What are they now?
-Nick






This message and any attachments (the "message") is
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

-

Ce message et toutes les pieces jointes (ci-apres le 
"message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf 
autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Repository Upload question

[Ben Walding]

Either is fine, but things get lost on the list - usually if it's not 
done in about 3 days, ping the list again.  Ultimately if something is 
in JIRA it will get done - just might take a while.

This time round, just send it to the list. I'll do them all tomorrow 
morning.

Kevin Ross wrote:

FAQ says the request goes to the list.  Would you rather have me put it
in Jira so you can keep track?
If so, no problem.

Kevin Ross

-Original Message-
From: Ben Walding [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 05, 2003 6:34 PM
To: Maven Developers List
Subject: Re: Repository Upload question

One project template per group id is ok for now.  We will get more 
regimental as time goes by.

The important thing is the license that for new groups.

So we'd create

xmldb/jars/xmldb-dep1-1.1.jar
xmldb/jars/xmldb-dep2-1.2.jar
xmldb/jars/xmldb-dep3-1.n.jar
xmldb/jars/xmldb-dep4-2.4.jar
etc

That being said, I usually do my uploads on Saturday morning which is 
24hours from now, so the backlog should be cleared - especially if they 
are in JIRA and tagged with the right category.

Cheers,

Ben

Kevin Ross wrote:

 

I'm a commiter on the Xindice project and want to start mavenizing the
dependencies.  In particular, the xmldb*.jars are from xmldb.org.  I
   

can
 

of course make the descriptor template for xmldb.  My question is, with
4 jars, do I need separate project template for each jar?  They all use
the same license.  Can I just list all artifacts in the one project
   

xml,
 

or is that a no-no?



-Kevin Ross



   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Repository Upload question

[Kevin Ross]

FAQ says the request goes to the list.  Would you rather have me put it
in Jira so you can keep track?

If so, no problem.

Kevin Ross

-Original Message-
From: Ben Walding [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 05, 2003 6:34 PM
To: Maven Developers List
Subject: Re: Repository Upload question

One project template per group id is ok for now.  We will get more 
regimental as time goes by.

The important thing is the license that for new groups.

So we'd create

xmldb/jars/xmldb-dep1-1.1.jar
xmldb/jars/xmldb-dep2-1.2.jar
xmldb/jars/xmldb-dep3-1.n.jar
xmldb/jars/xmldb-dep4-2.4.jar

etc


That being said, I usually do my uploads on Saturday morning which is 
24hours from now, so the backlog should be cleared - especially if they 
are in JIRA and tagged with the right category.


Cheers,

Ben

Kevin Ross wrote:

>I'm a commiter on the Xindice project and want to start mavenizing the
>dependencies.  In particular, the xmldb*.jars are from xmldb.org.  I
can
>of course make the descriptor template for xmldb.  My question is, with
>4 jars, do I need separate project template for each jar?  They all use
>the same license.  Can I just list all artifacts in the one project
xml,
>or is that a no-no?
>
> 
>
>-Kevin Ross
>
>
>  
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Repository Upload question

[Ben Walding]

One project template per group id is ok for now.  We will get more 
regimental as time goes by.

The important thing is the license that for new groups.

So we'd create

xmldb/jars/xmldb-dep1-1.1.jar
xmldb/jars/xmldb-dep2-1.2.jar
xmldb/jars/xmldb-dep3-1.n.jar
xmldb/jars/xmldb-dep4-2.4.jar
etc

That being said, I usually do my uploads on Saturday morning which is 
24hours from now, so the backlog should be cleared - especially if they 
are in JIRA and tagged with the right category.

Cheers,

Ben

Kevin Ross wrote:

I'm a commiter on the Xindice project and want to start mavenizing the
dependencies.  In particular, the xmldb*.jars are from xmldb.org.  I can
of course make the descriptor template for xmldb.  My question is, with
4 jars, do I need separate project template for each jar?  They all use
the same license.  Can I just list all artifacts in the one project xml,
or is that a no-no?


-Kevin Ross

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCEMENT] Commons FileUpload 1.0 Release Candidate 1 Released

[Henning Schmiedehausen]

Hi,

could someone please put this jar on ibiblio? Thanks.

Regards
Henning


>Path: news.hometree.net!not-for-mail
>From: Martin Cooper <[EMAIL PROTECTED]>
>Newsgroups: hometree.jakarta.announce
>Subject: [ANNOUNCEMENT] Commons FileUpload 1.0 Release Candidate 1 Released
>Date: Fri, 6 Jun 2003 15:03:25 + (UTC)
>Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
>Lines: 36
>Sender: [EMAIL PROTECTED]
>Approved: yes
>Message-ID: <[EMAIL PROTECTED]>
>NNTP-Posting-Host: news.hometree.net
>Mime-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Trace: tangens.hometree.net 1054911805 12712 212.34.181.127 (6 Jun 2003 15:03:25 
>GMT)
>X-Complaints-To: [EMAIL PROTECTED]
>NNTP-Posting-Date: Fri, 6 Jun 2003 15:03:25 + (UTC)
>Organisation: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
>X-To: [EMAIL PROTECTED]
>Xref: news.hometree.net hometree.jakarta.announce:186

The Commons FileUpload team is pleased to announce the release of
FileUpload 1.0 Release Candidate 1. This release includes some new
functionality, as well as fixes for a number of bugs which were reported
against earlier versions. The FileUpload team believes that this release
is ready for prime time, hence its designation as a release candidate.

For details of the changes in this release, see the Release Notes, here:

http://www.apache.org/dist/jakarta/commons/fileupload/RELEASE-NOTES.txt

The binary distribution is available at:

http://jakarta.apache.org/site/binindex.cgi

and the source distribution is available at:

http://jakarta.apache.org/site/sourceindex.cgi

When downloading from a mirror site, please remember to verify the
signatures of the distribution using the keys found on the main Apache web
site:

http://www.apache.org/dist/jakarta/commons/fileupload/KEYS

For more information on Commons FileUpload, see the FileUpload web site:

http://jakarta.apache.org/commons/fileupload/

--
Martin Cooper


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Repository Upload question

[Kevin Ross]

I'm a commiter on the Xindice project and want to start mavenizing the
dependencies.  In particular, the xmldb*.jars are from xmldb.org.  I can
of course make the descriptor template for xmldb.  My question is, with
4 jars, do I need separate project template for each jar?  They all use
the same license.  Can I just list all artifacts in the one project xml,
or is that a no-no?

 

-Kevin Ross

[Repository Upload Request] xmldb

[Kevin Ross]

Please upload these items to the repository at your convenience.  
 
jars
http://iverticalleap.com/maven/xmldb/jars/xmldb-api-20021118.jar
http://iverticalleap.com/maven/xmldb/jars/xmldb-api-sdk-20021118.jar
http://iverticalleap.com/maven/xmldb/jars/xmldb-common-20021220.jar
http://iverticalleap.com/maven/xmldb/jars/xmldb-xupdate-20021220.jar
 
 
license
http://iverticalleap.com/maven/xmldb/licenses/license.txt
 
pom
http://iverticalleap.com/maven/xmldb/poms/project.xml
 
 
Thank you,
 
Kevin Ross

cvs commit: maven/src/plugins-build/changes .cvsignore

[vmassol]

vmassol 2003/06/05 13:35:11

  Modified:src/plugins-build/changes .cvsignore
  Log:
  added build.properties to ignore list
  
  Revision  ChangesPath
  1.2   +1 -0  maven/src/plugins-build/changes/.cvsignore
  
  Index: .cvsignore
  ===
  RCS file: /home/cvs/maven/src/plugins-build/changes/.cvsignore,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- .cvsignore24 Feb 2003 13:05:07 -  1.1
  +++ .cvsignore5 Jun 2003 20:35:11 -   1.2
  @@ -1,3 +1,4 @@
   target
   velocity.log
   maven.log
  +build.properties
  \ No newline at end of file
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven/src/plugins-build/changes/xdocs changes.xml goals.xml index.xml navigation.xml properties.xml

[vmassol]

vmassol 2003/06/05 13:34:13

  Modified:src/plugins-build/changes plugin.jelly plugin.properties
project.xml
   src/plugins-build/changes/xdocs goals.xml index.xml
navigation.xml properties.xml
  Added:   src/plugins-build/changes/xdocs changes.xml
  Log:
  Fixed plugin documentation and lots of other "typos"...
  
  Revision  ChangesPath
  1.6   +2 -2  maven/src/plugins-build/changes/plugin.jelly
  
  Index: plugin.jelly
  ===
  RCS file: /home/cvs/maven/src/plugins-build/changes/plugin.jelly,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- plugin.jelly  30 Mar 2003 16:17:19 -  1.5
  +++ plugin.jelly  5 Jun 2003 20:34:13 -   1.6
  @@ -14,7 +14,7 @@
   
 

  @@ -29,7 +29,7 @@
 
   
 
 
  
  
  
  1.2   +0 -7  maven/src/plugins-build/changes/plugin.properties
  
  Index: plugin.properties
  ===
  RCS file: /home/cvs/maven/src/plugins-build/changes/plugin.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- plugin.properties 24 Feb 2003 13:04:43 -  1.1
  +++ plugin.properties 5 Jun 2003 20:34:13 -   1.2
  @@ -3,10 +3,3 @@
   # ---
   # changes plugin.
   # ---
  -# These three don't belong here.
  -maven.build.dir = ${basedir}/target
  -maven.gen.docs = ${maven.build.dir}/generated-xdocs
  -maven.docs.outputencoding = ISO-8859-1
  -
  -maven.changelog.range = 30
  -maven.changelog.factory = org.apache.maven.cvslib.CvsChangeLogFactory
  
  
  
  1.9   +27 -35maven/src/plugins-build/changes/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/maven/src/plugins-build/changes/project.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- project.xml   9 Apr 2003 01:06:44 -   1.8
  +++ project.xml   5 Jun 2003 20:34:13 -   1.9
  @@ -5,7 +5,7 @@
 3
 maven-changes-plugin
 Maven Changes Plug-in
  -  1.2
  +  1.2-SNAPSHOT
 Java Project Management Tools
 http://maven.apache.org/reference/plugins/changes/
 /www/maven.apache.org/reference/plugins/changes/
  @@ -13,8 +13,24 @@
   scm:cvs:pserver:[EMAIL 
PROTECTED]:/home/cvspublic:maven/src/plugins-build/changes/
   http://cvs.apache.org/viewcvs/maven/src/plugins-build/changes/
 
  +  
  +
  +  1.2
  +  1.2
  +  HEAD
  +
  +  
 
   
  +  Vincent Massol
  +  vmassol
  +  [EMAIL PROTECTED]
  +  Pivolis
  +  
  +Java Developer
  +  
  +
  +
 Ben Walding
 bwalding
 [EMAIL PROTECTED]
  @@ -24,38 +40,14 @@
 
   
 
  -  
  -
  -  ant
  -  1.5.1
  -  
  -root
  -  
  -
  -
  -  commons-jelly
  -  commons-jelly-tags-jsl
  -  20030211.143151
  -  
  -root.maven
  -  
  -
  -
  -  commons-jelly
  -  commons-jelly-tags-xml
  -  20030211.142705
  -  http://jakarta.apache.org/commons/jelly/libs/xml/
  -  
  -root.maven
  -  
  -
  -
  -  commons-logging
  -  1.0.1
  -
  -
  -  junit
  -  3.8.1
  -
  -  
  +  
  +  
  +maven-changes-plugin
  +maven-changelog-plugin
  +maven-file-activity-plugin
  +maven-developer-activity-plugin
  +maven-file-activity-plugin
  +maven-license-plugin
  +maven-linkcheck-plugin
  +  
   
  
  
  
  1.2   +10 -13maven/src/plugins-build/changes/xdocs/goals.xml
  
  Index: goals.xml
  ===
  RCS file: /home/cvs/maven/src/plugins-build/changes/xdocs/goals.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- goals.xml 24 Feb 2003 13:05:01 -  1.1
  +++ goals.xml 5 Jun 2003 20:34:13 -   1.2
  @@ -2,27 +2,24 @@
   
   
 
  -Maven Ant Plug-in Goals
  -dIon Gillard
  +Maven Changes Plug-in Goals
  +Vincent Massol
 
   
 
   
  +  
  +This plugin is called automatically by the
  +site plugin when it generates the project
  +web site.
  +  
 
   GoalDescription
   
  -  changelog
  +  report
 
  -This is the default goal of the plugin and simply attains
  -the changelog:generate goal.
  -  
  -
  -
  -  changelog:generate
  -  
  -Generates a report from the source control system showing
  -changes by date along with the messa

cvs commit: maven/src/plugins-build/cactus project.xml

[vmassol]

vmassol 2003/06/05 13:32:29

  Modified:src/plugins-build/cactus project.xml
  Log:
  Added useful missing reports that all maven plugins should have IMO
  
  Revision  ChangesPath
  1.26  +3 -0  maven/src/plugins-build/cactus/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/maven/src/plugins-build/cactus/project.xml,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- project.xml   5 Jun 2003 20:23:59 -   1.25
  +++ project.xml   5 Jun 2003 20:32:29 -   1.26
  @@ -127,6 +127,9 @@
   maven-changelog-plugin
   maven-file-activity-plugin
   maven-developer-activity-plugin
  +maven-file-activity-plugin
  +maven-license-plugin
  +maven-linkcheck-plugin
 
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven web site and Wiki

[Vincent Massol]

Hi Brian,

> -Original Message-
> From: Brian Ewins [mailto:[EMAIL PROTECTED]
> Sent: 06 June 2003 15:20
> To: Maven Developers List
> Subject: Re: Maven web site and Wiki
> 
> Vincent, are you just guessing that MoinMoin stores in xdoc format?
> 

nope... check:

Rendered page:
http://www.mockobjects.com/wiki

XML view:
http://www.mockobjects.com/wiki/FrontPage?action=format&mimetype=text/xm
l

This looks very very similar the old stylebook xdoc format to me.

>

> Section 1.3, Pages:
> "The pages are store exactly as they appear in the edit window in text
> format."
> 
> (actually this isn't entirely true. I read the code for Page.py and it
> supports loading xml files too; however the default is plain text, and
> theres nothing in there resembling xdoc that I could see)
> 
> I've written a few wikis in the past and what MoinMoin are doing is
far
> far easier than attempting to alter the edit-view of the page for
> storage (or, like UseModWiki, just serialize the in-memory page
> structure to disk). If you stored xdoc, and the xdocs could be edited
> directly as you describe, you'd need to implement round-tripping from
> xdoc to wiki markup and back again. Wiki markup isn't particularly
> expressive, I'd be surprised if this could be done well.

Maybe moinmoin stores as text (I haven't even looked at moinmoin
documentation) but with the "action" attribute it is possible to tell it
to transform it in xdocs, so I guess a hook could be used to format
after each edit and store the xml to cvs?

Thanks
-Vincent

> 
> - Baz
> 
> Vincent Massol wrote:
> 
> >
> >>-Original Message-
> >>From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
> >>Sent: 06 June 2003 14:13
> >>To: Maven Developers List
> >>Subject: Re: Maven web site and Wiki
> >>
> >>Wasnt the point to have a wiki site and then create the xdocs based
on
> >
> > the
> >
> >>wiki site?
> >
> >
> > Nope :-) The wiki automatically saves the topics in xdocs format and
in
> > CVS!
> >
> >
> >>If the wiki site cant commit the wiki entries as xdoc formatted docs
> >
> > in
> >
> >>the
> >>maven cvs, but can export the entries as xml I think wath I proposed
> >
> > would
> >
> >>be
> >>a rather simple solution. Its just a suggestion anyway, im not
> >
> > enlightned
> >
> >>with
> >>the inner workings of wiki sites.
> >
> >
> > Oh sure, but it would be much much easier to have the wiki directly
save
> > as xdocs (such as what moinmoin does by default).
> >
> > -Vincent
> >
> >
> >>Trygve
> >>
> >>Vincent Massol wrote:
> >>
> -Original Message-
> From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
> Sent: 06 June 2003 13:52
> To: Maven Developers List
> Subject: Re: Maven web site and Wiki
> 
> Hi
> 
> Sounds like a really good plan, but perhaps there should be
> >
> > installed a
> >
> normal wiki installation that can deliver xml exports.
> 
> Then a nighly cronjob could do this
> 1. Export the new/updated entries to a xml file
> 2. Use XSLT to transform the wiki xml to xdoc.
> 3. Use XSLT to take out the commend field and commit it into cvs
> 
> This way all that needs to be done is to write two rather simple
xsl
> tranformation sheets and the existing cvs mails will tell us about
> >
> > the
> >
> updates.
> >>>
> >>>
> >>>Why would you need to do all that? That is automatically done on
the
> >
> > fly
> >
> >>>when you edit topics in the wiki...
> >>>
> >>>Have a look at: http://www.mockobjects.com/wiki/
> >>>Here is an example of the generated XML :
> >>>
> >
> >
http://www.mockobjects.com/wiki/FrontPage?action=format&mimetype=text/xm
> >
> >>>l
> >>>(you might need to do a "view source" with IE).
> >>>
> >>>-Vincent
> >>>
> >>>
> >>>
> Trygve
> 
> Vincent Massol wrote:
> 
> 
> >Hi,
> >
> >Here are some facts:
> >- Our Maven web site contains lots of inaccuracies and would not
> >
> > suffer
> >
> >from additional documentation
> 
> >- Some Maven users would be happy to contribute if we gave them
> >
> > easy
> >
> >tools for that.
> >
> >The idea:
> >
> >- Transform our web site from a static web site into a Wiki web
> >
> > site.
> >
> >- But not any wiki! One that saves topics in XML format. For
> >
> > example
> >
> >>the
> >>
> >MoinMoin wiki saves topic in xdocs format (stylebook style
> >>
> >>unfortunately
> >>
> >but that's not too far from our xdocs format and could probably
be
> >easily modified )
> >- Second step: hook the wiki to CVS so that modifications are
saved
> >
> > in
> >
> >our Maven CVS, directly in xdocs format. This is possible with
> >
> > MoinMoin
> >
> >and probably with others too.
> >- Note: The MoinMoin wiki also has a "comment" field that could
be
> >
> > used
> >
> >as the CVS commit message. We could force the need to have a
> >
> > non-bla

cvs commit: maven/src/plugins-build/cactus project.xml

[vmassol]

vmassol 2003/06/05 13:23:59

  Modified:src/plugins-build/cactus project.xml
  Log:
  Added changes report
  
  Revision  ChangesPath
  1.25  +1 -0  maven/src/plugins-build/cactus/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/maven/src/plugins-build/cactus/project.xml,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- project.xml   23 May 2003 21:35:18 -  1.24
  +++ project.xml   5 Jun 2003 20:23:59 -   1.25
  @@ -123,6 +123,7 @@
 
   
 
  +maven-changes-plugin
   maven-changelog-plugin
   maven-file-activity-plugin
   maven-developer-activity-plugin
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven/src/plugins-build/cactus/sample .cvsignore

[vmassol]

vmassol 2003/06/05 13:21:18

  Modified:src/plugins-build/cactus/sample .cvsignore
  Log:
  added velocity.log to the ignore list
  
  Revision  ChangesPath
  1.3   +1 -0  maven/src/plugins-build/cactus/sample/.cvsignore
  
  Index: .cvsignore
  ===
  RCS file: /home/cvs/maven/src/plugins-build/cactus/sample/.cvsignore,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- .cvsignore24 May 2003 11:38:32 -  1.2
  +++ .cvsignore5 Jun 2003 20:21:18 -   1.3
  @@ -2,3 +2,4 @@
   cactus_client.log
   maven.log
   build.properties
  +velocity.log
  \ No newline at end of file
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven web site and Wiki

[Brian Ewins]

Vincent, are you just guessing that MoinMoin stores in xdoc format?


Section 1.3, Pages:
"The pages are store exactly as they appear in the edit window in text 
format."

(actually this isn't entirely true. I read the code for Page.py and it 
supports loading xml files too; however the default is plain text, and 
theres nothing in there resembling xdoc that I could see)

I've written a few wikis in the past and what MoinMoin are doing is far 
far easier than attempting to alter the edit-view of the page for 
storage (or, like UseModWiki, just serialize the in-memory page 
structure to disk). If you stored xdoc, and the xdocs could be edited 
directly as you describe, you'd need to implement round-tripping from 
xdoc to wiki markup and back again. Wiki markup isn't particularly 
expressive, I'd be surprised if this could be done well.

- Baz

Vincent Massol wrote:


-Original Message-
From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
Sent: 06 June 2003 14:13
To: Maven Developers List
Subject: Re: Maven web site and Wiki
Wasnt the point to have a wiki site and then create the xdocs based on
the

wiki site?


Nope :-) The wiki automatically saves the topics in xdocs format and in
CVS!

If the wiki site cant commit the wiki entries as xdoc formatted docs
in

the
maven cvs, but can export the entries as xml I think wath I proposed
would

be
a rather simple solution. Its just a suggestion anyway, im not
enlightned

with
the inner workings of wiki sites.


Oh sure, but it would be much much easier to have the wiki directly save
as xdocs (such as what moinmoin does by default).
-Vincent


Trygve

Vincent Massol wrote:

-Original Message-
From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
Sent: 06 June 2003 13:52
To: Maven Developers List
Subject: Re: Maven web site and Wiki
Hi

Sounds like a really good plan, but perhaps there should be
installed a

normal wiki installation that can deliver xml exports.

Then a nighly cronjob could do this
1. Export the new/updated entries to a xml file
2. Use XSLT to transform the wiki xml to xdoc.
3. Use XSLT to take out the commend field and commit it into cvs
This way all that needs to be done is to write two rather simple xsl
tranformation sheets and the existing cvs mails will tell us about
the

updates.


Why would you need to do all that? That is automatically done on the
fly

when you edit topics in the wiki...

Have a look at: http://www.mockobjects.com/wiki/
Here is an example of the generated XML :
http://www.mockobjects.com/wiki/FrontPage?action=format&mimetype=text/xm

l
(you might need to do a "view source" with IE).
-Vincent



Trygve

Vincent Massol wrote:


Hi,

Here are some facts:
- Our Maven web site contains lots of inaccuracies and would not
suffer

from additional documentation

- Some Maven users would be happy to contribute if we gave them
easy

tools for that.

The idea:

- Transform our web site from a static web site into a Wiki web
site.

- But not any wiki! One that saves topics in XML format. For
example

the

MoinMoin wiki saves topic in xdocs format (stylebook style
unfortunately

but that's not too far from our xdocs format and could probably be
easily modified )
- Second step: hook the wiki to CVS so that modifications are saved
in

our Maven CVS, directly in xdocs format. This is possible with
MoinMoin

and probably with others too.
- Note: The MoinMoin wiki also has a "comment" field that could be
used

as the CVS commit message. We could force the need to have a
non-blank

text if we wish to make sure there are commit messages.
- We get automatically CVS email notifications whenever pages are
modified and we can thus easily control the changes made to the
wiki

and

correct when and if needed.

Conclusion:
- We keep the advantage of our xdocs
- We can still edit xdocs directly should we wish
- Anyone can contribute easily to the documentation and we get good
and

up to date Maven documentation.

If we agree, there are things to do:
- We need to find a machine where the wiki could run (it could be a
machine provided by a Friend Of Maven or an Apache one if there's
one

available)
- We need someone to look at MoinMoin (or another wiki) to perform
the

following:
- find how to hook it to CVS
- find how to change the default style to be the Maven style
(stylesheet)
- find how to modify the DTD so that the xdocs are in the Maven
xdocs

format
- find how to define where xdocs are saved in CVS so that we try
to

match the existing locations of xdocs
- We need a Wiki admin
What do you think?

Thanks
-Vincent




-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-

cvs commit: maven/src/test/touchstone-build/src/reactor-build/username_test maven.xml project.xml

[jvanzyl]

jvanzyl 2003/06/05 12:55:03

  Modified:src/test/touchstone-build/src/reactor-build/username_test
maven.xml project.xml
  Log:
  o having to do a little coercion which means something is not right
in the core. Should probably just swap out the old core for the new.
  
  Revision  ChangesPath
  1.2   +28 -13
maven/src/test/touchstone-build/src/reactor-build/username_test/maven.xml
  
  Index: maven.xml
  ===
  RCS file: 
/home/cvs/maven/src/test/touchstone-build/src/reactor-build/username_test/maven.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- maven.xml 5 Jun 2003 19:17:14 -   1.1
  +++ maven.xml 5 Jun 2003 19:55:02 -   1.2
  @@ -1,13 +1,28 @@
  -
  -
  -
  -
  -
  -username_test: maven.username not properly assigned from root 
project.
  -
  -
  -
  -
  +
  +
  +
  +
  +  
  +  
  +  
  +  
  +  
  +username_test: maven.username not properly assigned from root 
project.
  +  
  +  
  +
  +
  +
  
  
  
  1.2   +24 -24
maven/src/test/touchstone-build/src/reactor-build/username_test/project.xml
  
  Index: project.xml
  ===
  RCS file: 
/home/cvs/maven/src/test/touchstone-build/src/reactor-build/username_test/project.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- project.xml   5 Jun 2003 19:17:14 -   1.1
  +++ project.xml   5 Jun 2003 19:55:02 -   1.2
  @@ -1,24 +1,24 @@
  -
  -
  -  3
  -  1.0
  -  maven username test when set outside reactor and used within
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -
  -
  -  
  -
  +
  +
  +  3
  +  1.0
  +  maven username test when set outside reactor and used within
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +
  +
  +  
  +
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven web site and Wiki

[Vincent Massol]

> -Original Message-
> From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
> Sent: 06 June 2003 14:13
> To: Maven Developers List
> Subject: Re: Maven web site and Wiki
> 
> Wasnt the point to have a wiki site and then create the xdocs based on
the
> wiki site?

Nope :-) The wiki automatically saves the topics in xdocs format and in
CVS!

> 
> If the wiki site cant commit the wiki entries as xdoc formatted docs
in
> the
> maven cvs, but can export the entries as xml I think wath I proposed
would
> be
> a rather simple solution. Its just a suggestion anyway, im not
enlightned
> with
> the inner workings of wiki sites.

Oh sure, but it would be much much easier to have the wiki directly save
as xdocs (such as what moinmoin does by default).

-Vincent

> 
> Trygve
> 
> Vincent Massol wrote:
> >
> >>-Original Message-
> >>From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
> >>Sent: 06 June 2003 13:52
> >>To: Maven Developers List
> >>Subject: Re: Maven web site and Wiki
> >>
> >>Hi
> >>
> >>Sounds like a really good plan, but perhaps there should be
installed a
> >>normal wiki installation that can deliver xml exports.
> >>
> >>Then a nighly cronjob could do this
> >>1. Export the new/updated entries to a xml file
> >>2. Use XSLT to transform the wiki xml to xdoc.
> >>3. Use XSLT to take out the commend field and commit it into cvs
> >>
> >>This way all that needs to be done is to write two rather simple xsl
> >>tranformation sheets and the existing cvs mails will tell us about
the
> >>updates.
> >
> >
> > Why would you need to do all that? That is automatically done on the
fly
> > when you edit topics in the wiki...
> >
> > Have a look at: http://www.mockobjects.com/wiki/
> > Here is an example of the generated XML :
> >
http://www.mockobjects.com/wiki/FrontPage?action=format&mimetype=text/xm
> > l
> > (you might need to do a "view source" with IE).
> >
> > -Vincent
> >
> >
> >>Trygve
> >>
> >>Vincent Massol wrote:
> >>
> >>>Hi,
> >>>
> >>>Here are some facts:
> >>>- Our Maven web site contains lots of inaccuracies and would not
suffer
> >>>from additional documentation
> >>>- Some Maven users would be happy to contribute if we gave them
easy
> >>>tools for that.
> >>>
> >>>The idea:
> >>>
> >>>- Transform our web site from a static web site into a Wiki web
site.
> >>>- But not any wiki! One that saves topics in XML format. For
example
> the
> >>>MoinMoin wiki saves topic in xdocs format (stylebook style
> unfortunately
> >>>but that's not too far from our xdocs format and could probably be
> >>>easily modified )
> >>>- Second step: hook the wiki to CVS so that modifications are saved
in
> >>>our Maven CVS, directly in xdocs format. This is possible with
MoinMoin
> >>>and probably with others too.
> >>>- Note: The MoinMoin wiki also has a "comment" field that could be
used
> >>>as the CVS commit message. We could force the need to have a
non-blank
> >>>text if we wish to make sure there are commit messages.
> >>>- We get automatically CVS email notifications whenever pages are
> >>>modified and we can thus easily control the changes made to the
wiki
> and
> >>>correct when and if needed.
> >>>
> >>>Conclusion:
> >>>- We keep the advantage of our xdocs
> >>>- We can still edit xdocs directly should we wish
> >>>- Anyone can contribute easily to the documentation and we get good
and
> >>>up to date Maven documentation.
> >>>
> >>>If we agree, there are things to do:
> >>>- We need to find a machine where the wiki could run (it could be a
> >>>machine provided by a Friend Of Maven or an Apache one if there's
one
> >>>available)
> >>>- We need someone to look at MoinMoin (or another wiki) to perform
the
> >>>following:
> >>>  - find how to hook it to CVS
> >>>  - find how to change the default style to be the Maven style
> >>>(stylesheet)
> >>>  - find how to modify the DTD so that the xdocs are in the Maven
xdocs
> >>>format
> >>>  - find how to define where xdocs are saved in CVS so that we try
to
> >>>match the existing locations of xdocs
> >>>- We need a Wiki admin
> >>>
> >>>What do you think?
> >>>
> >>>Thanks
> >>>-Vincent
> >>>
> >>>
> >>>
> >
> >
-
> >
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>
> >>
>
>>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe

cvs commit: maven/src/test/touchstone-build/src/reactor-build/username_test maven.xml project.xml

[jvanzyl]

jvanzyl 2003/06/05 12:17:15

  Added:   src/test/touchstone-build/src/reactor-build/username_test
maven.xml project.xml
  Log:
  o test case for john casey's patch for properties handling in the reactor.
  
  Revision  ChangesPath
  1.1  
maven/src/test/touchstone-build/src/reactor-build/username_test/maven.xml
  
  Index: maven.xml
  ===
  
  
  
  
  
  username_test: maven.username not properly assigned from root 
project.
  
  
  
  
  
  
  
  1.1  
maven/src/test/touchstone-build/src/reactor-build/username_test/project.xml
  
  Index: project.xml
  ===
  
  
3
1.0
maven username test when set outside reactor and used within















  
  

  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven/src/test/touchstone-build/src/reactor-build/username_test - New directory

[jvanzyl]

jvanzyl 2003/06/05 12:16:32

  maven/src/test/touchstone-build/src/reactor-build/username_test - New directory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven web site and Wiki

[Cocell | Trygve Laugstøl]

Wasnt the point to have a wiki site and then create the xdocs based on the
wiki site?
If the wiki site cant commit the wiki entries as xdoc formatted docs in the
maven cvs, but can export the entries as xml I think wath I proposed would be
a rather simple solution. Its just a suggestion anyway, im not enlightned with
the inner workings of wiki sites.
Trygve

Vincent Massol wrote:

-Original Message-
From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
Sent: 06 June 2003 13:52
To: Maven Developers List
Subject: Re: Maven web site and Wiki
Hi

Sounds like a really good plan, but perhaps there should be installed a
normal wiki installation that can deliver xml exports.
Then a nighly cronjob could do this
1. Export the new/updated entries to a xml file
2. Use XSLT to transform the wiki xml to xdoc.
3. Use XSLT to take out the commend field and commit it into cvs
This way all that needs to be done is to write two rather simple xsl
tranformation sheets and the existing cvs mails will tell us about the
updates.


Why would you need to do all that? That is automatically done on the fly
when you edit topics in the wiki...
Have a look at: http://www.mockobjects.com/wiki/
Here is an example of the generated XML :
http://www.mockobjects.com/wiki/FrontPage?action=format&mimetype=text/xm
l
(you might need to do a "view source" with IE).
-Vincent


Trygve

Vincent Massol wrote:

Hi,

Here are some facts:
- Our Maven web site contains lots of inaccuracies and would not suffer
from additional documentation
- Some Maven users would be happy to contribute if we gave them easy
tools for that.
The idea:

- Transform our web site from a static web site into a Wiki web site.
- But not any wiki! One that saves topics in XML format. For example the
MoinMoin wiki saves topic in xdocs format (stylebook style unfortunately
but that's not too far from our xdocs format and could probably be
easily modified )
- Second step: hook the wiki to CVS so that modifications are saved in
our Maven CVS, directly in xdocs format. This is possible with MoinMoin
and probably with others too.
- Note: The MoinMoin wiki also has a "comment" field that could be used
as the CVS commit message. We could force the need to have a non-blank
text if we wish to make sure there are commit messages.
- We get automatically CVS email notifications whenever pages are
modified and we can thus easily control the changes made to the wiki and
correct when and if needed.
Conclusion:
- We keep the advantage of our xdocs
- We can still edit xdocs directly should we wish
- Anyone can contribute easily to the documentation and we get good and
up to date Maven documentation.
If we agree, there are things to do:
- We need to find a machine where the wiki could run (it could be a
machine provided by a Friend Of Maven or an Apache one if there's one
available)
- We need someone to look at MoinMoin (or another wiki) to perform the
following:
 - find how to hook it to CVS
 - find how to change the default style to be the Maven style
(stylesheet)
 - find how to modify the DTD so that the xdocs are in the Maven xdocs
format
 - find how to define where xdocs are saved in CVS so that we try to
match the existing locations of xdocs
- We need a Wiki admin
What do you think?

Thanks
-Vincent


-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven web site and Wiki

[Vincent Massol]

> -Original Message-
> From: Cocell | Trygve Laugstøl [mailto:[EMAIL PROTECTED]
> Sent: 06 June 2003 13:52
> To: Maven Developers List
> Subject: Re: Maven web site and Wiki
> 
> Hi
> 
> Sounds like a really good plan, but perhaps there should be installed
a
> normal wiki installation that can deliver xml exports.
> 
> Then a nighly cronjob could do this
> 1. Export the new/updated entries to a xml file
> 2. Use XSLT to transform the wiki xml to xdoc.
> 3. Use XSLT to take out the commend field and commit it into cvs
> 
> This way all that needs to be done is to write two rather simple xsl
> tranformation sheets and the existing cvs mails will tell us about the
> updates.

Why would you need to do all that? That is automatically done on the fly
when you edit topics in the wiki...

Have a look at: http://www.mockobjects.com/wiki/
Here is an example of the generated XML :
http://www.mockobjects.com/wiki/FrontPage?action=format&mimetype=text/xm
l
(you might need to do a "view source" with IE).

-Vincent

> 
> Trygve
> 
> Vincent Massol wrote:
> > Hi,
> >
> > Here are some facts:
> > - Our Maven web site contains lots of inaccuracies and would not
suffer
> > from additional documentation
> > - Some Maven users would be happy to contribute if we gave them easy
> > tools for that.
> >
> > The idea:
> >
> > - Transform our web site from a static web site into a Wiki web
site.
> > - But not any wiki! One that saves topics in XML format. For example
the
> > MoinMoin wiki saves topic in xdocs format (stylebook style
unfortunately
> > but that's not too far from our xdocs format and could probably be
> > easily modified )
> > - Second step: hook the wiki to CVS so that modifications are saved
in
> > our Maven CVS, directly in xdocs format. This is possible with
MoinMoin
> > and probably with others too.
> > - Note: The MoinMoin wiki also has a "comment" field that could be
used
> > as the CVS commit message. We could force the need to have a
non-blank
> > text if we wish to make sure there are commit messages.
> > - We get automatically CVS email notifications whenever pages are
> > modified and we can thus easily control the changes made to the wiki
and
> > correct when and if needed.
> >
> > Conclusion:
> > - We keep the advantage of our xdocs
> > - We can still edit xdocs directly should we wish
> > - Anyone can contribute easily to the documentation and we get good
and
> > up to date Maven documentation.
> >
> > If we agree, there are things to do:
> > - We need to find a machine where the wiki could run (it could be a
> > machine provided by a Friend Of Maven or an Apache one if there's
one
> > available)
> > - We need someone to look at MoinMoin (or another wiki) to perform
the
> > following:
> >   - find how to hook it to CVS
> >   - find how to change the default style to be the Maven style
> > (stylesheet)
> >   - find how to modify the DTD so that the xdocs are in the Maven
xdocs
> > format
> >   - find how to define where xdocs are saved in CVS so that we try
to
> > match the existing locations of xdocs
> > - We need a Wiki admin
> >
> > What do you think?
> >
> > Thanks
> > -Vincent
> >
> >
> >
-
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven web site and Wiki

[Cocell | Trygve Laugstøl]

Hi

Sounds like a really good plan, but perhaps there should be installed a
normal wiki installation that can deliver xml exports.
Then a nighly cronjob could do this
1. Export the new/updated entries to a xml file
2. Use XSLT to transform the wiki xml to xdoc.
3. Use XSLT to take out the commend field and commit it into cvs
This way all that needs to be done is to write two rather simple xsl
tranformation sheets and the existing cvs mails will tell us about the updates.
Trygve

Vincent Massol wrote:
Hi,

Here are some facts:
- Our Maven web site contains lots of inaccuracies and would not suffer
from additional documentation
- Some Maven users would be happy to contribute if we gave them easy
tools for that.
The idea:

- Transform our web site from a static web site into a Wiki web site.
- But not any wiki! One that saves topics in XML format. For example the
MoinMoin wiki saves topic in xdocs format (stylebook style unfortunately
but that's not too far from our xdocs format and could probably be
easily modified )
- Second step: hook the wiki to CVS so that modifications are saved in
our Maven CVS, directly in xdocs format. This is possible with MoinMoin
and probably with others too.
- Note: The MoinMoin wiki also has a "comment" field that could be used
as the CVS commit message. We could force the need to have a non-blank
text if we wish to make sure there are commit messages.
- We get automatically CVS email notifications whenever pages are
modified and we can thus easily control the changes made to the wiki and
correct when and if needed.
Conclusion:
- We keep the advantage of our xdocs
- We can still edit xdocs directly should we wish
- Anyone can contribute easily to the documentation and we get good and
up to date Maven documentation.
If we agree, there are things to do:
- We need to find a machine where the wiki could run (it could be a
machine provided by a Friend Of Maven or an Apache one if there's one
available)
- We need someone to look at MoinMoin (or another wiki) to perform the
following:
  - find how to hook it to CVS
  - find how to change the default style to be the Maven style
(stylesheet)
  - find how to modify the DTD so that the xdocs are in the Maven xdocs
format
  - find how to define where xdocs are saved in CVS so that we try to
match the existing locations of xdocs
- We need a Wiki admin
What do you think?

Thanks
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven web site and Wiki

[Michal Maczka]

If we can make it happen it will be great.
Anything to improve documentation is a change in good direction (as long as
can be controlled)!

+1

Michal

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2003 1:01 PM
To: 'Maven Developers List'
Subject: Maven web site and Wiki

Hi,

Here are some facts:
- Our Maven web site contains lots of inaccuracies and would not suffer
from additional documentation
- Some Maven users would be happy to contribute if we gave them easy
tools for that.

The idea:

- Transform our web site from a static web site into a Wiki web site.
- But not any wiki! One that saves topics in XML format. For example the
MoinMoin wiki saves topic in xdocs format (stylebook style unfortunately
but that's not too far from our xdocs format and could probably be
easily modified )
- Second step: hook the wiki to CVS so that modifications are saved in
our Maven CVS, directly in xdocs format. This is possible with MoinMoin
and probably with others too.
- Note: The MoinMoin wiki also has a "comment" field that could be used
as the CVS commit message. We could force the need to have a non-blank
text if we wish to make sure there are commit messages.
- We get automatically CVS email notifications whenever pages are
modified and we can thus easily control the changes made to the wiki and
correct when and if needed.

Conclusion:
- We keep the advantage of our xdocs
- We can still edit xdocs directly should we wish
- Anyone can contribute easily to the documentation and we get good and
up to date Maven documentation.

If we agree, there are things to do:
- We need to find a machine where the wiki could run (it could be a
machine provided by a Friend Of Maven or an Apache one if there's one
available)
- We need someone to look at MoinMoin (or another wiki) to perform the
following:
  - find how to hook it to CVS
  - find how to change the default style to be the Maven style
(stylesheet)
  - find how to modify the DTD so that the xdocs are in the Maven xdocs
format
  - find how to define where xdocs are saved in CVS so that we try to
match the existing locations of xdocs
- We need a Wiki admin

What do you think?

Thanks
-Vincent


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven web site and Wiki

[Vincent Massol]

Hi,

Here are some facts:
- Our Maven web site contains lots of inaccuracies and would not suffer
from additional documentation
- Some Maven users would be happy to contribute if we gave them easy
tools for that.

The idea:

- Transform our web site from a static web site into a Wiki web site.
- But not any wiki! One that saves topics in XML format. For example the
MoinMoin wiki saves topic in xdocs format (stylebook style unfortunately
but that's not too far from our xdocs format and could probably be
easily modified )
- Second step: hook the wiki to CVS so that modifications are saved in
our Maven CVS, directly in xdocs format. This is possible with MoinMoin
and probably with others too.
- Note: The MoinMoin wiki also has a "comment" field that could be used
as the CVS commit message. We could force the need to have a non-blank
text if we wish to make sure there are commit messages.
- We get automatically CVS email notifications whenever pages are
modified and we can thus easily control the changes made to the wiki and
correct when and if needed.

Conclusion:
- We keep the advantage of our xdocs
- We can still edit xdocs directly should we wish
- Anyone can contribute easily to the documentation and we get good and
up to date Maven documentation.

If we agree, there are things to do:
- We need to find a machine where the wiki could run (it could be a
machine provided by a Friend Of Maven or an Apache one if there's one
available)
- We need someone to look at MoinMoin (or another wiki) to perform the
following:
  - find how to hook it to CVS
  - find how to change the default style to be the Maven style
(stylesheet)
  - find how to modify the DTD so that the xdocs are in the Maven xdocs
format
  - find how to define where xdocs are saved in CVS so that we try to
match the existing locations of xdocs
- We need a Wiki admin

What do you think?

Thanks
-Vincent


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Committers let's agree on how we make changes to a plugin

[Vincent Massol]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: 04 June 2003 22:46
> To: Maven Developers List
> Subject: Re: Committers let's agree on how we make changes to a plugin
> 
> On Wed, 2003-06-04 at 08:49, Vincent Massol wrote:
> > Hi,
> >
> > What do you think about the following process for making changes to
a
> > plugin (and for accepting patches):
> >
> > 1/ Update xdocs/changes.xml (create it if it does not exist) and
> > describe the change
> > 2/ Update the goals.xml/properties.xml and more generally the plugin
> > documentation if changes affecting users have been made
> > 3/ Ensure that the version in plugin.xml is a SNAPSHOT version (i.e.
not
> > delivered). Unless you're making a release of the plugin.
> > 4/ Make sure the  section of project.xml is up to date
> >
> > Almost everytime I make changes to a plugin I find that these simple
> > rules are not followed (Note: I know dIon is also careful about
them).
> >
> > What do you think?
> 
> +1
> 
> Document it and it will more than likely be followed.

I have started here:
http://nagoya.apache.org/wiki/apachewiki.cgi?Maven/PluginModificationGui
delines

I have also linked this page from the Development process page of the
maven web site (but I haven't republished it yet).

Thanks
-Vincent



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven/xdocs development-process.xml

[vmassol]

vmassol 2003/06/06 03:45:11

  Modified:xdocsdevelopment-process.xml
  Log:
  Added steps to follow when performing a  modification on a Maven plugin
  
  Revision  ChangesPath
  1.5   +7 -0  maven/xdocs/development-process.xml
  
  Index: development-process.xml
  ===
  RCS file: /home/cvs/maven/xdocs/development-process.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- development-process.xml   17 Aug 2002 02:41:07 -  1.4
  +++ development-process.xml   6 Jun 2003 10:45:11 -   1.5
  @@ -47,6 +47,13 @@
 to tag and branch your project.
   
 
  +  
  +http://nagoya.apache.org/wiki/apachewiki.cgi?Maven/PluginModificationGuidelines";>Modifying
 Plugins
  +
  +  Provides some guidelines to use when modifying plugins. This 
  +  includes steps that contributors and committers should follow.
  +
  +  
   
 
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Maven POM re-org to address deps + test issues

[dvillevalois]

Hi Bret,

IMHO, your proposal is the way maven should go. This is a generic way to
express any new kind of project topology.
I think Micha's proposal is just another extension that describe what
should be done, which is NOT good. I think maven's first essence was to
describe a project and not what should be done to build/document/... it!
So specifying what integration unit tests should be run is not the good
way. But specifying what is available for testing is a better way.
> 
>   
> required-name
> 
>   set-name
>   other-set-name
> 
> 
>   ...
>   
> ...
>   
>   
> ...
>   

[...]

> * Not that comfortable with the extends syntax - bit too similar to POM
>  inheritance. Could be used to fold subprojects. However, need a way to
>  include deps and classpath built sources of other sets without
> duplication. Any thoughts on this?

Maybe you additionnaly need something like restriction, the other form of
specialization. But then we must find how we would process this ? But this
is not wasted time as I do think too that POM needs a redesign.
A+. Didier.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL] Maven POM re-org to address deps + test issues

[Michal Maczka]

Hi Brett!

I would rather prefer to make it differently.

a) junit tests should be left as they are. (still no way to skip them!)
b) For other types of tests (integration tests, stress tests etc.) 
   we can make it similarly as it was done with Reports (plugable API):

   
  cactus
  httpUnit
  dbunit
  surefire (once Jason will finish it ;) )
   


Each of those tests types will keep its own configuration settings etc
and course the possibility of running e.g.just cactus tests will still
remain.


Then integration test can be even integrated with of reports.

  
 ...
 iutest

  

There is a lot of details which I skipped (for example resource processing
for tests), but this is just a fresh idea.


what you think?


regards

Michal


-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 2:34 AM
To: Maven Developers List
Subject: [PROPOSAL] Maven POM re-org to address deps + test issues


Hi,

Based on the discussions about "test levels" and about isolating test, 
runtime and compile time dependencies, I thought about some changes to 
the POM that might help, and got a bit carried away ;)
This is a work in progress with a few limitations discussed later, but I 
thought it might be a good starting point for a discussion to address 
some of the issues. Bear in mind I wrote this on the train at 7am this 
morning ;)

What I propose is remove  and everything in it. Move 
 to that level, and then add the following elements:


   
 required-name
 
   set-name
   other-set-name
 
 
   ...
   
 ...
   
   
 ...
   
 
 
   
 
 
   
 
 
   
   
 ...
   
   
 ...
   
 
 
   
   value
 
   
   


Finally, you can includes/exclude sets from the command line to avoid 
processing certain sets:
maven -Dexclude.sets=perf-test,integ-test
or
maven -Dinclude.sets=gen-jaxb,default

Now the problems I see with it:
* Not that comfortable with the extends syntax - bit too similar to POM 
inheritance. Could be used to fold subprojects. However, need a way to 
include deps and classpath built sources of other sets without 
duplication. Any thoughts on this?
* This pattern allows multiple source trees. It does takes care of 
generated source (antlr, jaxb) more cleanly (source would be the 
descriptor files, then plugin uses addPath for java sources). However, 
could be used to have multiple java source trees for a real project. 
Maybe this is ok - let those who've demanded it have it, but perhaps 
display a warning every run that it is a bad practice :)
* The specification of plugins does worry me a bit, but I don't see 
alternatives. Certain things should make use of new plugins 
automatically (some site related plugin should apply to all source 
trees), but others must be blocked out.

Also, how does this fit with maven-new's structure?

Cheers,
Brett

-- 
Web Developer
f2 network ~ everything essential
02 8596 4437


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven/src/plugins-build/antlr/xdocs goals.xml

[vmassol]

vmassol 2003/06/06 00:46:52

  Modified:src/plugins-build/antlr/xdocs goals.xml
  Log:
  Fixed typo: Ant -> Antlr
  
  Revision  ChangesPath
  1.2   +1 -1  maven/src/plugins-build/antlr/xdocs/goals.xml
  
  Index: goals.xml
  ===
  RCS file: /home/cvs/maven/src/plugins-build/antlr/xdocs/goals.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- goals.xml 24 Jan 2003 03:44:36 -  1.1
  +++ goals.xml 6 Jun 2003 07:46:52 -   1.2
  @@ -2,7 +2,7 @@
   
   
 
  -Maven Ant Plug-in Goals
  +Maven Antlr Plug-in Goals
   dIon Gillard
 
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[IBIBLIO] Upload Tapestry latest

[hlship]

Please upload the latest Tapestry JARs to Maven repository.

project.xml and jars are at

http://jakarta.apache.org/~hlship


Thanks!


--
[EMAIL PROTECTED]

Creator, Tapestry: Java Web 
Components
http://jakarta.apache.org/tapestry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]