date:20051202

2005-12-02 Thread Jagan Padmanabha Pillai -X \(jpadmana - Insight Solutions, Inc. at Cisco\)

Errors occurred while performing maven-1 to maven-2 repository conversion.

For more details, see:

http://test.maven.codehaus.org/reports/repoclean/03-Dec-2005_12.31.02/repository.report.txt

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

Re: Maven2 dependency classpath in Java plugin

2005-12-02 Thread Brett Porter

The expression you are looking for is:

${project.runtimeClasspathElements}

You might like to look at a plugin such as the WAR plugin for an example.

- Brett

Jagan Padmanabha Pillai -X (jpadmana - Insight Solutions, Inc. at Cisco)
wrote:
>  
> Hi,
> I am trying to get the mvn dependency classpath inside the plugin
> written using java.
> In maven 1 there seems to be a way for ant using
> {maven.dependency.classpath}. 
>  
> Does anyone know how to get this classpath in maven2 
>  
> Also in org.apache.maven.project.Project seems to have a method
> getdependecyClassPath(). But I am not sure which jar file is this
> Project class is in. when I put the above class in import statement its
> erroring out.
>  
> Please let me know 
>  
> Thanks
> Jagan
>  
>  
> 
> -
> 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: site-plugin broken

2005-12-02 Thread Brett Porter

Shouldn't mean it is broken - the old one should still be there?

Mike Perham wrote:
> It depends on:
> 
> org.codehaus.doxia:doxia-site-renderer:1.0-alpha-6-SNAPSHOT:jar
> 
> but doxia's groupId has changed:
> 
>   
> doxia
> org.apache.maven.doxia
> 1.0-alpha-6-SNAPSHOT
>   
>   doxia-site-renderer
> 
> 
> -
> 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: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together)

2005-12-02 Thread Wendy Smoak

On 12/2/05, Lukas Theussl <[EMAIL PROTECTED]> wrote:

> I wanted to ask Arnaud about that, i saw the same thing too but thought
> it would be something special about my setup. It only happens right
> after upgrading the plugin.

Clearing the cache seems to be what fixed it here.  Strange... but it
WORKS!  The right title and date and everything.  This is great! 
Thanks so much for your work on this. :)

But... I've got one project where the build files live in a separate
directory structure, and it's not working for that one:

/svn/struts/current/shale/build
$ maven pdf
...
fo:fo:
[echo] Generating e:\svn\struts\current\shale\build/target/pdf/project.fo fr
om ../xdocs/navigation.xml ...
[java]
[java] (Location of error unknown)XSLT Error (javax.xml.transform.Transforme
rException): java.io.FileNotFoundException: E:\svn\struts\current\shale\build\ta
rget\pdf\..\xdocs\navigation.xml (The system cannot find the path specified)

BUILD FAILED

It must be picking up maven.docs.src=../xdocs from the
project.properties file, but that doesn't make sense when appended to
target/pdf.

If you want to try it:
$ svn co http://svn.apache.org/repos/asf/struts/shale/trunk/ shale
$ cd shale/build
$ maven pdf

Thanks again,
--
Wendy

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

Re: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together)

2005-12-02 Thread Lukas Theussl


Hi Wendy,

I wanted to ask Arnaud about that, i saw the same thing too but thought 
it would be something special about my setup. It only happens right 
after upgrading the plugin. I don't know what exactly fixed it, but 
after playing around a bit, running other goals, uninstalling and 
re-installing, clearing cache, etc., eventually it started working 
again. Sounds weird, but I really couldn't tell what made it run again.


Good luck and patience! :)
-Lukas

PS Don't declare a dependency on 2.5 as I haven't published the SNAPSHOT 
yet.




Wendy Smoak wrote:

Lukas, I see that you've closed
http://jira.codehaus.org/browse/MPPDF-53 as fixed in 2.5.

I must be doing something *else* wrong... I tried both updating from
svn and building it (maven plugin:install), and also declaring a
dependency on 2.5-SNAPSHOT, (which downloaded a new version) and all I
get is:

/svn/struts/current/tiles
$ maven pdf
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download maven-pdf-plugin-2.5-SNAPSHOT.jar.
BUILD FAILED
Goal "pdf" does not exist in this project.
Total time: 2 seconds
Finished at: Fri Dec 02 18:40:42 MST 2005

I'm using Maven 1.0.2.  Any ideas what to try to get it to work?

Thanks,
--
Wendy

-
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]

Maven2 dependency classpath in Java plugin

 
Hi,
I am trying to get the mvn dependency classpath inside the plugin
written using java.
In maven 1 there seems to be a way for ant using
{maven.dependency.classpath}. 
 
Does anyone know how to get this classpath in maven2 
 
Also in org.apache.maven.project.Project seems to have a method
getdependecyClassPath(). But I am not sure which jar file is this
Project class is in. when I put the above class in import statement its
erroring out.
 
Please let me know 
 
Thanks
Jagan
 
 

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

[continuum build - FAILED - checkout] Sat Dec 3 01:30:00 GMT 2005

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051203.013000.txt

Re: [m1] PDF Plugin (was: Re: Using the latest xdoc and multiproject plugins together)

2005-12-02 Thread Wendy Smoak

Lukas, I see that you've closed
http://jira.codehaus.org/browse/MPPDF-53 as fixed in 2.5.

I must be doing something *else* wrong... I tried both updating from
svn and building it (maven plugin:install), and also declaring a
dependency on 2.5-SNAPSHOT, (which downloaded a new version) and all I
get is:

/svn/struts/current/tiles
$ maven pdf
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download maven-pdf-plugin-2.5-SNAPSHOT.jar.
BUILD FAILED
Goal "pdf" does not exist in this project.
Total time: 2 seconds
Finished at: Fri Dec 02 18:40:42 MST 2005

I'm using Maven 1.0.2.  Any ideas what to try to get it to work?

Thanks,
--
Wendy

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

[REPOCLEAN] Error(s) occurred while converting repository

Errors occurred while performing maven-1 to maven-2 repository conversion.

For more details, see:

http://test.maven.codehaus.org/reports/repoclean/02-Dec-2005_08.31.21/repository.report.txt

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

Re: Spawning surefire tests

2005-12-02 Thread Jesse McConnell

I believe it is getting some final patches applied and ought to be released
next week at the latest...it it isn't in the snapshots already

cheers
jesse

On 12/2/05, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
> I think that someone mentioned that they were working on this.  I am in
> great need of this feature.  Does anyone know the status of this?
>
>
> Regards,
> Alan
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

Re: Design - Replacing Continuum's Web Framework

2005-12-02 Thread Carlos Sanchez

I'm thinking that I can set it up quickly in a branch in Continuum,
that would work for you?

I don't have a lot of free time, so if you could set up the branch and
permissions to get me started I might have something done during next
weekend hackathon.

On 12/2/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> Carlos,
>
> do you have a simple sample that use acegi?
>
> Emmanuel
>
> Carlos Sanchez a écrit :
> > Acegi is based in servlet filters for the protection of urls, so the
> > web framework used won't impact its use.
> > Are you planning protecting just urls or any other stuff? acegi can do
> > authorization and authentication at class, method and instance level
> > too, but I think that's only needed in a few types of applications.
> >
> > I was in a project using JSF and seems that it's adoption is getting
> > speed, with different implementations and a lot of extensions,
> > utilities and tools. I've heard very good things about using
> > Facelets+JSF to create components, and also about Spring MVC, but
> > seems to me that people using Spring MVC is moving to JSF.
> >
> > My 2 cents
> >
> >
> > On 12/1/05, John Casey <[EMAIL PROTECTED]> wrote:
> >
> >>Hi everyone,
> >>
> >>We've been talking about this for quite awhile in various channels, and
> >>I wanted to take a few minutes and formalize the discussion. I'll
> >>capture the highlights of this discussion in the wiki afterwards. I'll
> >>start by posting my own thoughts, and let you all respond.
> >>
> >>Up to this point, Continuum has been built on a web framework called
> >>Summit, which is part of the Plexus project, and using Velocity as the
> >>page rendering technology. Summit is still a very young project, and as
> >>a result has its problems. Given the proliferation of web frameworks out
> >>there, it seems natural to wonder whether we couldn't find something
> >>more mainstream and mature that will fit our needs.
> >>
> >>The key goal here is to make the web tier as easy to understand as
> >>possible by the widest possible audience, without sacrificing anything
> >>in the way of quality. To that end, criteria might include:
> >>
> >>* tool support
> >>* maturity in the form of multiple final releases (or at least one)
> >>* good integration with JSP (it's the most widely-used rendering
> >> technology out there for java)
> >>* ready availability of good documentation
> >>* integration with a decent security library (think acegi)
> >>* others?
> >>
> >>Another big concern is that we need to be able to make this web
> >>framework integrate with Plexus without too much funny business. I don't
> >>expect that to be a big problem, but worth mentioning.
> >>
> >>I know that a certain amount of work has been done by Trygve and
> >>Emmanuel to get WebWork running inside Plexus. Is this the best
> >>framework? A quick check of Amazon showed three books, only one of which
> >>is completely concerned with WW. SpringMVC might be another option,
> >>since it has probably the most natural integration with Acegi. There is
> >>a certain amount of overlap between Spring and Plexus that we'd probably
> >>have to map with a custom Spring container or something, but that's
> >>likely to be everywhere, since dependency injection is such a hot topic
> >>(and very useful).
> >>
> >>What do you all think?
> >>
> >>-john
> >>
> >
> >
> >
> >
>
>

[maven2 build - SUCCESS - checkout] Sat Dec 3 00:15:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~maven/builds/m2-20051203.001500.tar.gz

Log:
http://maven.zones.apache.org/~maven/logs/m2-build-log-20051203.001500.txt

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

Re: [vote] Mike Perham as a committer to Maven SCM

2005-12-02 Thread John Casey


+1

dan tran wrote:

+1


 
On 12/2/05, *Brett Porter* <[EMAIL PROTECTED] > 
wrote:


+1

Emmanuel Venisse wrote:
 > Hi,
 >
 > Mike works on Perforce provider.
 > This is a vote to make him a committer.
 >
 > +1 from me.
 >
 > Emmanuel
 >

[jira] Closed: (MPARTIFACT-57) artifact:deploy needs deploy name to be overridable

 [ http://jira.codehaus.org/browse/MPARTIFACT-57?page=all ]
 
Lukas Theussl closed MPARTIFACT-57:
---

 Resolution: Fixed
Fix Version: 1.7

> artifact:deploy needs deploy name to be overridable
> ---
>
>  Key: MPARTIFACT-57
>  URL: http://jira.codehaus.org/browse/MPARTIFACT-57
>  Project: maven-artifact-plugin
> Type: Improvement
> Versions: 1.4.1
>  Environment: WinXP; Linux
> Reporter: Jason Mowat
> Priority: Minor
>  Fix For: 1.7

>
> Original Estimate: 2 hours
> Remaining: 2 hours
>
> When using the artifact:deploy command in my maven.xml, I am unable to 
> control the destination name of my deployed JAR as it is constructed from the 
> POM.  This is problematic when trying to deploy ejb-client JARs.
> Brett Porter posted the problem with a fix last year on the maven-ejb JIRA.  
> I find it a little odd that he is the project lead for artifact when it seems 
> that his proposed fix is for artifact.  Maybe I'm missing something.  
> Anyways, here it is again:
> I have not reviewed this, but just making sure the patch doesn't get lost. 
> Original is MPARTIFACT-35.
> from Neil Crow:
> I have created a NamedArtifactTypeHandler and added an artifactIdOveride 
> property to the DeployBean which allows the different names to be used for 
> the artifacts beiong installed.
> I have tested this against an ejb build which installs and deploys an 
> ejb-1.x.jar and a ejb-client-1.x.jar.
> Other build types are not affected and still work,
> The overide property is optional.
> The overide is invoked as per the example below:
>   
>   
>   
>prereqs="ejb:ejb-client"
> description="Install the ejb client in the local repository">
>  
>  artifact="${maven.ejb.build.dir}/${maven.ejb.client.final.name}.jar"
> artifactIdOveride="${maven.ejb.client.artifact.id}"
> type="jar"
> project="${pom}"/>
>   
> 
> Below I have pasted a patch in eclipse unified format.
> I dont have access to work on this issue in Jira, and therefore cannot find 
> the file upload button (or I am being dumb.)
> I can email the patch to any comitter that can apply it.
> Regards,
> Neil.
> Index: project.xml
> ===
> RCS file: /home/cvspublic/maven-plugins/artifact/project.xml,v
> retrieving revision 1.36
> diff -u -r1.36 project.xml
> --- project.xml 23 Oct 2004 12:11:50 - 1.36
> +++ project.xml 3 Dec 2004 15:37:19 -
> @@ -25,7 +25,7 @@
>Maven Artifact Plugin
>
>  
> - 1.4.1
> + 1.4.2
>Tools to manage artifacts and deployment.
>Tools to manage artifacts and 
> deployment
>http://maven.apache.org/reference/plugins/artifact/
> @@ -61,6 +61,11 @@
>1.4.1
>1.4.1
>MAVEN_ARTIFACT_1_4_1
> + 
> + 
> + 1.4.2
> + 1.4.2
> + MAVEN_ARTIFACT_1_4_2
>  
>
>
> Index: src/main/org/apache/maven/artifact/deployer/DeployBean.java
> ===
> RCS file: 
> /home/cvspublic/maven-plugins/artifact/src/main/org/apache/maven/artifact/deployer/DeployBean.java,v
> retrieving revision 1.6
> diff -u -r1.6 DeployBean.java
> --- src/main/org/apache/maven/artifact/deployer/DeployBean.java 23 Jun 2004 
> 13:04:28 - 1.6
> +++ src/main/org/apache/maven/artifact/deployer/DeployBean.java 3 Dec 2004 
> 15:37:19 -
> @@ -22,7 +22,6 @@
>  import org.apache.maven.artifact.deployer.DefaultArtifactDeployer;
>  import org.apache.maven.project.Project;
>  import org.apache.maven.repository.ArtifactTypeHandler;
> -import org.apache.maven.repository.DefaultArtifactTypeHandler;
>  
> /**
>   *
> @@ -40,6 +39,7 @@
>  private String artifact = null;
>  private String type = null;
>  private ArtifactTypeHandler typeHandler = null;
> + private String artifactIdOveride = null;
>  
> public DeployBean()
>  {
> @@ -79,6 +79,22 @@
>  }
>  
> /**
> + * @return String
> + */
> + public String getArtifactIdOveride()
> + {
> + return artifactIdOveride;
> + }
> +
> + /**
> + * @param artifact
> + */
> + public void setArtifactIdOveride(String artifactIdOveride)
> + {
> + this.artifactIdOveride = artifactIdOveride;
> + }
> +
> + /**
>   * @return
>   */
>  public Project getProject()
> @@ -131,7 +147,14 @@
>  }
>  if (typeHandler == null)
>  {
> - typeHandler = new DefaultArtifactTypeHandler();
> + //TODO NC - remove debug
> + System.out.println("artifactIdOveride = " + artifactIdOveride);
> +
> + NamedArtifactTypeHandler namedHandler = new NamedArtifactTypeHandler();
> + if (artifactIdOveride != null) {
> + namedHandler.setArtifactId(artifactIdOveride);
> + }
> + typeHandler = namedHandler;
>  }
>  }
>  
> Index: 
> src/main/org/apache/maven/artifact/deployer/NamedArtifactTypeHandler.java
> ===

[jira] Closed: (MEV-243) xmlrpc:xmlrpc:1.2 depends on relocated servlet api

2005-12-02 Thread Edwin Punzalan (JIRA)

 [ http://jira.codehaus.org/browse/MEV-243?page=all ]
 
Edwin Punzalan closed MEV-243:
--

 Assign To: Edwin Punzalan
Resolution: Fixed

Patch applied. Thanks!

> xmlrpc:xmlrpc:1.2 depends on relocated servlet api
> --
>
>  Key: MEV-243
>  URL: http://jira.codehaus.org/browse/MEV-243
>  Project: Maven Evangelism
> Type: Bug
>   Components: Dependencies
> Reporter: Matt Brozowski
> Assignee: Edwin Punzalan
>  Attachments: xmlrpc-1.2.patch, xmlrpc-1.2.patch.correct
>
>
> xmlrpc:xmlrpc:1.2
> depends on servletapi:servletapi:2.2 which has been moved to 
> javax.servlet:servleti-api:2.2
> I will attach the patch

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MPARTIFACT-62) uniqueVersion support for snapshots like m2

 [ http://jira.codehaus.org/browse/MPARTIFACT-62?page=all ]
 
Lukas Theussl closed MPARTIFACT-62:
---

Resolution: Won't Fix

Timestamped artifacts are implemented in m1 since a long time and it has been 
made optional very recently: MPARTIFACT-59

> uniqueVersion support for snapshots like m2
> ---
>
>  Key: MPARTIFACT-62
>  URL: http://jira.codehaus.org/browse/MPARTIFACT-62
>  Project: maven-artifact-plugin
> Type: Wish
> Versions: 1.6
> Reporter: Shinobu Kawai Yoshida
> Priority: Trivial

>
>
> It would be great if the M1 plugin also supported a uniqueVersion-like 
> feature.
> cf. http://maven.apache.org/maven-model/maven.html#class_snapshotRepository

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MNG-1374) Release plugin fails to update SNAPSHOTS in the dependencyManagement section

2005-12-02 Thread John Casey (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1374?page=all ]
 
John Casey closed MNG-1374:
---

 Resolution: Fixed
Fix Version: 2.0.1

applied. thanks, mike

> Release plugin fails to update SNAPSHOTS in the dependencyManagement section
> 
>
>  Key: MNG-1374
>  URL: http://jira.codehaus.org/browse/MNG-1374
>  Project: Maven 2
> Type: Bug
>   Components: maven-release-plugin
> Versions: 2.0
>  Environment: Maven 2.0 (release-plugin version: 2.0-beta3)
> Reporter: Ørjan Austvold
> Assignee: John Casey
>  Fix For: 2.0.1
>  Attachments: prep.txt
>
>
> In a multi project the parent-pom can specify "standard" versions for 
> dependencies within the project group. I have found it convenient to also 
> list group-members with versions in this section so that all child artifact 
> within the group simply specifies inter-group artifact dependencies without 
> versions.
> The release plugin fails to alter SNAPSHOT dependencies within the 
> dependencyMangement section. The tagged version of child poms gets instead 
> the correct version explicitly stated in their dependency section.
> It seems a bit strange that dependencies on artifacts within a group must 
> have dependencies on other artifacts within the group listed with version 
> numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MEV-241) commons-attribute-compiler has direct dependency on tools.jar and fails on MacOSX

2005-12-02 Thread Edwin Punzalan (JIRA)

 [ http://jira.codehaus.org/browse/MEV-241?page=all ]
 
Edwin Punzalan closed MEV-241:
--

Resolution: Fixed

> commons-attribute-compiler has direct dependency on tools.jar and fails on 
> MacOSX
> -
>
>  Key: MEV-241
>  URL: http://jira.codehaus.org/browse/MEV-241
>  Project: Maven Evangelism
> Type: Bug
> Reporter: Matt Brozowski
> Assignee: Edwin Punzalan
>  Attachments: commons-attributes-compiler.patch
>
>
> commons-attributes-compiler-2.1.pom has the following dependency:
> 
>   java
>   tools
>   1.4
>   ${java.home}/../lib/tools.jar
>   system
> 
> This breaks on MacOSX which doesn't have a tools.jar.  After discussing this 
> with brett he pointed me to it0063 in maven-core-it which solved this using 
> profiles as follows:
>   
> 
>   
>   default-tools.jar
>   
> 
>   java.vendor
>   Sun Microsystems Inc.
> 
>   
>   
> 
>   sun.jdk
>   tools
>   1.4.2
>   system
>   ${java.home}/../lib/tools.jar
> 
>   
> 
>   
> I have checked out the repo and make the change and will attach the patch 
> file.  (Is there someway I could have tested this first?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: [vote] Mike Perham as a committer to Maven SCM

+1
 
On 12/2/05, Brett Porter <[EMAIL PROTECTED]> wrote:
+1Emmanuel Venisse wrote:> Hi,>> Mike works on Perforce provider.> This is a vote to make him a committer.
>> +1 from me.>> Emmanuel>

[jira] Created: (MPARTIFACT-62) uniqueVersion support for snapshots like m2

2005-12-02 Thread Shinobu Kawai Yoshida (JIRA)

uniqueVersion support for snapshots like m2
---

 Key: MPARTIFACT-62
 URL: http://jira.codehaus.org/browse/MPARTIFACT-62
 Project: maven-artifact-plugin
Type: Wish
Versions: 1.6
Reporter: Shinobu Kawai Yoshida
Priority: Trivial


It would be great if the M1 plugin also supported a uniqueVersion-like feature.

cf. http://maven.apache.org/maven-model/maven.html#class_snapshotRepository

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - FAILED - update] Fri Dec 2 17:00:00 GMT 2005

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051202.17.txt

[jira] Closed: (CONTINUUM-483) Setting RUN_AS_USER causes startup script to fail.

2005-12-02 Thread Emmanuel Venisse (JIRA)

 [ http://jira.codehaus.org/browse/CONTINUUM-483?page=all ]
 
Emmanuel Venisse closed CONTINUUM-483:
--

 Assign To: Emmanuel Venisse
Resolution: Fixed

Fixed.

> Setting RUN_AS_USER causes startup script to fail.
> --
>
>  Key: CONTINUUM-483
>  URL: http://jira.codehaus.org/browse/CONTINUUM-483
>  Project: Continuum
> Type: Bug
>   Components: Core system
> Versions: 1.0.1
>  Environment: gentoo 2.6.5 kernel, bash 2.05
> Reporter: Corridor Software Developer
> Assignee: Emmanuel Venisse
>  Fix For: 1.0.2

>
>
> If the run.sh script is modified to include a RUN_AS_USER, this line in the 
> script
> su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
> wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE"
> fails with the following error:
> /bin/bash: continuum: No such file or directory
> reducing the line yields the same error right down to the 'su -m user_name'. 
> However, if the -m is moved to beyond the user, everything works out:
> su $RUN_AS_USER -m -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
> wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE"
> note that it occurs twice in the file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (MNG-1735) Ability to pass all prompted information as parameters in release:prepare

Ability to pass all prompted information as parameters in release:prepare
-

 Key: MNG-1735
 URL: http://jira.codehaus.org/browse/MNG-1735
 Project: Maven 2
Type: Wish
  Components: maven-release-plugin  
Versions: 2.0
Reporter: Yann Le Du
Priority: Minor


In release:prepare, it would be nice that all prompted information can also be 
passed as parameters :
* tag name (already available, -Dtag)
* release version
* new development version

It would allow to call the plugin in real non-interactive mode - that is, 
without being forced to accept default values.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MPPDF-53) Title and dates are incorrect when used with Maven 1.0.2

 [ http://jira.codehaus.org/browse/MPPDF-53?page=all ]
 
Lukas Theussl closed MPPDF-53:
--

Resolution: Fixed

> Title and dates are incorrect when used with Maven 1.0.2
> 
>
>  Key: MPPDF-53
>  URL: http://jira.codehaus.org/browse/MPPDF-53
>  Project: maven-pdf-plugin
> Type: Bug
> Versions: 2.5
>  Environment: Maven 1.0.2
> maven-pdf-plugin-2.5-SNAPSHOT
> Reporter: Wendy Smoak
>  Fix For: 2.5

>
>
> See http://struts.apache.org/struts-tiles/struts-tiles.pdf  for an example of 
> a PDF generated with Maven 1.0.2 and the latest development snapshot of the 
> plugin.  The title, current date, and inception date are not correct.
> From Lukas in http://marc.theaimsgroup.com/?t=11316844423&r=1&w=2 :
> "Apparently this is another m1.0 - 1.1 compatibility issue. I reproduce 
> it with m1.0.2 and pdf plugin 2.5-SNAPSHOT, but not with any other 
> combination. Somehow the dummy values in project2fo.xslt are not 
> overridden by the default ones. It doesn't even work if I specify the 
> properties explicitly in project.properties. I have no idea why this 
> happens since it works with pdf plugin 2.4 and I don't see what has 
> changed with this respect since."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MNG-1529) NPE when inheriting report sets

2005-12-02 Thread Joakim Erdfelt (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1529?page=all ]

Joakim Erdfelt updated MNG-1529:


Attachment: MNG-1539-test-case.tar.bz2

I have been experiencing this NPE also.

I have attached a small sample project/test case to demonstrate
this bug.

Note: I still use maven 2.0 final (not 2.0.1).

> NPE when inheriting report sets
> ---
>
>  Key: MNG-1529
>  URL: http://jira.codehaus.org/browse/MNG-1529
>  Project: Maven 2
> Type: Bug
>   Components: Inheritence and Interpolation
> Versions: 2.0
>  Environment: JDK 1.5.0_05, Kubuntu linux 5.1
> Reporter: Arik Kfir
>  Fix For: 2.0.1
>  Attachments: MNG-1539-test-case.tar.bz2
>
>
> I have three POMs:
> A: serves as a template for new projects
> B: Extends A - the root POM of a multi-module project
> C: Extends B - a module in the B project
> One of the things project A defines is the  element. However, when 
> I try to build project B, I get the following exception:
> [EMAIL PROTECTED]:~/projects/swinger$ mvn clean
> [INFO] Scanning for projects...
> [INFO] snapshot org.corleon:parent:1.1-SNAPSHOT: checking for updates from 
> corleon
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] null
> [INFO] 
> 
> [INFO] Trace
> java.lang.NullPointerException
> at java.util.TreeMap.compare(TreeMap.java:1093)
> at java.util.TreeMap.getEntry(TreeMap.java:347)
> at java.util.TreeMap.containsKey(TreeMap.java:204)
> at 
> org.apache.maven.project.ModelUtils.mergeReportPluginDefinitions(ModelUtils.java:324)
> at 
> org.apache.maven.project.ModelUtils.mergeReportPluginLists(ModelUtils.java:156)
> at 
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleReportingInheritance(DefaultModelInheritanceAssembler.java:277)
> at 
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:170)
> at 
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:56)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:605)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509)
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441)
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Sat Nov 12 13:45:14 IST 2005
> [INFO] Final Memory: 1M/2M
> [INFO] 
> 
> I tracked down the problem to the  element in project A, because 
> when I remove it, things work again. I believe there's a problem in the way 
> maven merges reporting info from parent POMs (well..duh).
> Here is the reporting data in project A:
>   
> 
>   
> maven-javadoc-plugin
> 
>   
> 
>   javadoc
> 
>   
> 
>   
>   
> maven-project-info-reports-plugin
> 
>   
> 
>   dependencies
>   project-team
>   license
>   scm
> 
>   
> 
>   
>   
> org.codehaus.mojo
> changes-maven-plugin
> 
>   
> 
>   chang

site-plugin broken

2005-12-02 Thread Mike Perham

It depends on:

org.codehaus.doxia:doxia-site-renderer:1.0-alpha-6-SNAPSHOT:jar

but doxia's groupId has changed:

  
doxia
org.apache.maven.doxia
1.0-alpha-6-SNAPSHOT
  
  doxia-site-renderer


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

Re: Design - Replacing Continuum's Web Framework

I don't know if webwork it's the best framework, but it seems to be simple to use (similar to
Struts) and it will be merge with Struts (http://feeds.feedburner.com/techtarget/tsscom/home?m=285)
Result pages of an action is define in one place (xwork.xml file), so it's simple to add/modify a
feature.

A comparison beetween web frameworks is available
(http://www.opensymphony.com/webwork/wikidocs/Comparison%20to%20other%20web%20frameworks.html, only
struts actually)

Positive points for webwork :
- ognl support
- jsp, velocity, freemarker... web view support

Emmanuel

John Casey a écrit :

Hi everyone,

We've been talking about this for quite awhile in various channels, and
I wanted to take a few minutes and formalize the discussion. I'll
capture the highlights of this discussion in the wiki afterwards. I'll
start by posting my own thoughts, and let you all respond.

Up to this point, Continuum has been built on a web framework called
Summit, which is part of the Plexus project, and using Velocity as the
page rendering technology. Summit is still a very young project, and as
a result has its problems. Given the proliferation of web frameworks out
there, it seems natural to wonder whether we couldn't find something
more mainstream and mature that will fit our needs.

The key goal here is to make the web tier as easy to understand as
possible by the widest possible audience, without sacrificing anything
in the way of quality. To that end, criteria might include:

* tool support
* maturity in the form of multiple final releases (or at least one)
* good integration with JSP (it's the most widely-used rendering
technology out there for java)
* ready availability of good documentation
* integration with a decent security library (think acegi)
* others?

Another big concern is that we need to be able to make this web
framework integrate with Plexus without too much funny business. I don't
expect that to be a big problem, but worth mentioning.

I know that a certain amount of work has been done by Trygve and
Emmanuel to get WebWork running inside Plexus. Is this the best
framework? A quick check of Amazon showed three books, only one of which
is completely concerned with WW. SpringMVC might be another option,
since it has probably the most natural integration with Acegi. There is
a certain amount of overlap between Spring and Plexus that we'd probably
have to map with a custom Spring container or something, but that's
likely to be everywhere, since dependency injection is such a hot topic
(and very useful).

What do you all think?

-john

Re: [jira] Commented: (MPDASHBOARD-34) Cobertura aggregator don't support offline mode

2005-12-02 Thread Lukas Theussl


Arnaud,

I noticed that I have introduced the same incompatibility (util:replace 
a string) at several places in the xdoc plugin.


Would it be a valid workaround to put commons-lang as a dependency and 
use the static StringUtils.replace instead?


Cheers,
-Lukas


Arnaud Heritier (JIRA) wrote:

   [ http://jira.codehaus.org/browse/MPDASHBOARD-34?page=comments#action_52591 ] 


Arnaud Heritier commented on MPDASHBOARD-34:


your patch will make the plugin compatible only with maven 1.1
the jelly tag util:replace bundled in maven 1.0.2 doesn't allow to replace a 
String.
Personnaly I'm not against to create plugins compatible only with maven 1.1 if 
we don't have a workaround.

 


Cobertura aggregator don't support offline mode
---

Key: MPDASHBOARD-34
URL: http://jira.codehaus.org/browse/MPDASHBOARD-34
Project: maven-dashboard-plugin
   Type: Bug
   Versions: 1.9
   Reporter: pkernevez
Attachments: MPDASHBOARD-34.patch


We I throw the goal "dashboard:report-single" I had an error if I am off line:
BUILD FAILED
File.. 
C:\maven\home\.maven\cache\maven-dashboard-plugin-1.9-SNAPSHOT\plugin.jelly
Element... j:import
Line.. 210
Column -1
file:/C:/maven/home/.maven/cache/maven-dashboard-plugin-1.9-SNAPSHOT/plugin-resources/aggregators/coberturaloc.jelly:32:
-1:  Error on line 2 of document : External entity not found: 
"http://cobertura.sourceforge.net/xml/coverage-0
2.dtd". Nested exception: External entity not found: 
"http://cobertura.sourceforge.net/xml/coverage-02.dtd";.
Total time : 2 seconds
Finished at : Wednesday, November 30, 2005 6:25:22 PM CET
This error is due to the DTD declaration into the file 
"target\docs\cobertura\coverage.xml":
http://cobertura.sourceforge.net/xml/coverage-02.dtd";>
If your remove this declaration the target dashboard:report-single succed in.
This is because the plugin need to be on line to be able to download the dtd.
I tried to change the aggretors' jelly script but the jelly attribute 
"validate" doesn't seems to perform:
I replace the part:
   
 
  
   
with :
   
 
  
   
But I don't resolve my issue
   



 




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

Re: release plugin depends on maven 2.0.1

emamuel has made neccessary changes so that release and scm plugins to use
plexus-utils-1.4.

You should be ok now.




On 12/2/05, Mike Perham <[EMAIL PROTECTED]> wrote:
>
> Can someone please deploy the latest plexus-utils SNAPSHOT?
> release:perform with the latest release-plugin does not work for me due
> to this and forcing an upToDate check does not help.
>
> -Original Message-
> From: dan tran [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 02, 2005 12:48 AM
> To: Maven Developers List
> Subject: Re: release plugin depends on maven 2.0.1
>
> maven-scm-plugin is now depending on plexus-utils-1.5-SNAPSHOT as well.
>
> -D
>
>
> On 12/1/05, Brett Porter < [EMAIL PROTECTED]> wrote:
> >
> > I noticed that the release plugin now requires plexus-utils 1.0.5
> > snapshot. This means that it will only work on Maven 2.0.1 (and
> > recently bootstrapped at that).
> >
> > Is there an alternative?
> >
> > Please be vigilant about backwards compatibility. We really need to
> > get plexus-utils out of the core...
> >
> > - Brett
> >
> > -
> > 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]
>
>

[jira] Commented: (MNG-1529) NPE when inheriting report sets

2005-12-02 Thread Joakim Erdfelt (JIRA)

[ http://jira.codehaus.org/browse/MNG-1529?page=comments#action_52663 ] 

Joakim Erdfelt commented on MNG-1529:
-

Pardon the fat-fingered, incorrectly labeled filename.

The attachment is for this jira - MNG-1529.
The filename is wrong in saying (MNG-1539). sorry.


> NPE when inheriting report sets
> ---
>
>  Key: MNG-1529
>  URL: http://jira.codehaus.org/browse/MNG-1529
>  Project: Maven 2
> Type: Bug
>   Components: Inheritence and Interpolation
> Versions: 2.0
>  Environment: JDK 1.5.0_05, Kubuntu linux 5.1
> Reporter: Arik Kfir
>  Fix For: 2.0.1
>  Attachments: MNG-1539-test-case.tar.bz2
>
>
> I have three POMs:
> A: serves as a template for new projects
> B: Extends A - the root POM of a multi-module project
> C: Extends B - a module in the B project
> One of the things project A defines is the  element. However, when 
> I try to build project B, I get the following exception:
> [EMAIL PROTECTED]:~/projects/swinger$ mvn clean
> [INFO] Scanning for projects...
> [INFO] snapshot org.corleon:parent:1.1-SNAPSHOT: checking for updates from 
> corleon
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] null
> [INFO] 
> 
> [INFO] Trace
> java.lang.NullPointerException
> at java.util.TreeMap.compare(TreeMap.java:1093)
> at java.util.TreeMap.getEntry(TreeMap.java:347)
> at java.util.TreeMap.containsKey(TreeMap.java:204)
> at 
> org.apache.maven.project.ModelUtils.mergeReportPluginDefinitions(ModelUtils.java:324)
> at 
> org.apache.maven.project.ModelUtils.mergeReportPluginLists(ModelUtils.java:156)
> at 
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleReportingInheritance(DefaultModelInheritanceAssembler.java:277)
> at 
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:170)
> at 
> org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:56)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:605)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298)
> at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509)
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441)
> at 
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO] 
> 
> [INFO] Total time: < 1 second
> [INFO] Finished at: Sat Nov 12 13:45:14 IST 2005
> [INFO] Final Memory: 1M/2M
> [INFO] 
> 
> I tracked down the problem to the  element in project A, because 
> when I remove it, things work again. I believe there's a problem in the way 
> maven merges reporting info from parent POMs (well..duh).
> Here is the reporting data in project A:
>   
> 
>   
> maven-javadoc-plugin
> 
>   
> 
>   javadoc
> 
>   
> 
>   
>   
> maven-project-info-reports-plugin
> 
>   
> 
>   dependencies
>   project-team
>   license
>   scm
> 
>   
> 
>   
>   
> org.codehaus.mojo
> changes-maven-plugin
> 
>   
> 
>   changes-report
> 
>

Spawning surefire tests

2005-12-02 Thread Alan D. Cabrera

I think that someone mentioned that they were working on this.  I am in 
great need of this feature.  Does anyone know the status of this?



Regards,
Alan




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

Re: release plugin depends on maven 2.0.1


I modified it, so we don't need plexus-1.0.5-SNAPSHOT

Emmanuel

dan tran a écrit :

I think we should reverse the changes and put it back when  maven 2.0.1 is
released.

It is hard for me to ask my user to use 2.0.1 bootstrap, inorder to do
release and maven:scm-bootstrap

-Dan


On 12/2/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


I need it for use MAVEN_TERMINATE_CMD env var and obtain the right exit
code of mvn in release:perform

Alternative will be to duplicate getSystemEnvironment method from
Commandline class

Emmanuel

Brett Porter a écrit :


I noticed that the release plugin now requires plexus-utils 1.0.5
snapshot. This means that it will only work on Maven 2.0.1 (and recently
bootstrapped at that).

Is there an alternative?

Please be vigilant about backwards compatibility. We really need to get
plexus-utils out of the core...

- Brett

-
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]

[jira] Commented: (MPPDF-51) XSLT Error (javax.xml.transform.TransformerException): org.apache.xml.dtm.DTMException: No more DTM IDs are available

[ http://jira.codehaus.org/browse/MPPDF-51?page=comments#action_52670 ] 

Lukas Theussl commented on MPPDF-51:


Does anybody know a reason why we shouldn't upgrade to xalan 2.7.0 (together 
with the corresponding xerces deps)? 

> XSLT Error (javax.xml.transform.TransformerException): 
> org.apache.xml.dtm.DTMException: No more DTM IDs are available
> -
>
>  Key: MPPDF-51
>  URL: http://jira.codehaus.org/browse/MPPDF-51
>  Project: maven-pdf-plugin
> Type: Bug
>  Environment: Win XP
> Reporter: coyt jackson
> Priority: Critical
>  Attachments: Maven error.txt
>
>
> Hello,
> I am building a simple project with about 50 xml docs I have 6 menu's with 8 
> or so docs and I get this error around doc 23:
> XSLT Error (javax.xml.transform.TransformerException): 
> org.apache.xml.dtm.DTMException: No more DTM IDs are available
> I am rebuilding directories and adding the docs one at a time and it is the 
> same- any suggestions??
> Thanks for your help!!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MEV-241) commons-attribute-compiler has direct dependency on tools.jar and fails on MacOSX

2005-12-02 Thread Carlos Sanchez (JIRA)

[ http://jira.codehaus.org/browse/MEV-241?page=comments#action_52684 ] 

Carlos Sanchez commented on MEV-241:


It was updated, but we need to remove this


  java
  tools
  1.4
  ${java.home}/../lib/tools.jar
  system


> commons-attribute-compiler has direct dependency on tools.jar and fails on 
> MacOSX
> -
>
>  Key: MEV-241
>  URL: http://jira.codehaus.org/browse/MEV-241
>  Project: Maven Evangelism
> Type: Bug
> Reporter: Matt Brozowski
> Assignee: Edwin Punzalan
>  Attachments: commons-attributes-compiler.patch
>
>
> commons-attributes-compiler-2.1.pom has the following dependency:
> 
>   java
>   tools
>   1.4
>   ${java.home}/../lib/tools.jar
>   system
> 
> This breaks on MacOSX which doesn't have a tools.jar.  After discussing this 
> with brett he pointed me to it0063 in maven-core-it which solved this using 
> profiles as follows:
>   
> 
>   
>   default-tools.jar
>   
> 
>   java.vendor
>   Sun Microsystems Inc.
> 
>   
>   
> 
>   sun.jdk
>   tools
>   1.4.2
>   system
>   ${java.home}/../lib/tools.jar
> 
>   
> 
>   
> I have checked out the repo and make the change and will attach the patch 
> file.  (Is there someway I could have tested this first?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1740) Error getting dependencies for a pom packaging project

2005-12-02 Thread Vincent Massol (JIRA)

Error getting dependencies for a pom packaging project
--

 Key: MNG-1740
 URL: http://jira.codehaus.org/browse/MNG-1740
 Project: Maven 2
Type: Bug
  Components: Plugin API  
Versions: 2.0
Reporter: Vincent Massol


It seems there might be a bug with Project.getArtifacts() on projects with a 
pom packaging. I get an empty artifact set even though my project has some 
dependencies. It's working for a war packaging project though...

Here's what I get:

org.apache.maven.lifecycle.LifecycleExecutionException: Artifact 
[org.codehaus.cargo:simple-war:war] is not a dependency of the project.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Artifact 
[org.codehaus.cargo:simple-war:war] is not a dependency of the project.
at 
org.codehaus.cargo.maven2.AbstractDeployable.resolveArtifact(AbstractDeployable.java:105)
at 
org.codehaus.cargo.maven2.WarDeployable.createDeployable(WarDeployable.java:62)
at org.codehaus.cargo.maven2.DeployMojo.deploy(DeployMojo.java:91)
at org.codehaus.cargo.maven2.DeployMojo.execute(DeployMojo.java:71)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
... 16 more

And here's my POM:




  4.0.0
  
org.codehaus.cargo
cargo-samples-testAll
0.1-SNAPSHOT
  
  cargo-samples-maven2-testStartAndRemoteDeploy
  pom
  cargo-samples-maven2-testStartAndRemoteDeploy
  testStartAndRemoteDeploy
  

scm:svn:svn://svn.cargo.codehaus.org/cargo/scm/cargo/trunk/samples/extensions/maven2/testStartAndRemoteDeploy
http://svn.cargo.codehaus.org/
  
  

  org.codehaus.cargo
  simple-war
  0.7-SNAPSHOT
  war

  
[...]

Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (DOXIA-41) Java 1.5 specific code

2005-12-02 Thread mike perham (JIRA)

Java 1.5 specific code
--

 Key: DOXIA-41
 URL: http://jira.codehaus.org/browse/DOXIA-41
 Project: doxia
Type: Bug
Reporter: mike perham


[ERROR] BUILD FAILURE
[INFO] 

[INFO] Compilation failure

D:\apache\doxia\doxia-core\src\main\java\org\apache\maven\doxia\module\confluence\parser\list\TreeComponent.java:[89,8]
 cannot resolve symbol
symbol  : class StringBuilder
location: class 
org.apache.maven.doxia.module.confluence.parser.list.TreeComponent

D:\apache\doxia\doxia-core\src\main\java\org\apache\maven\doxia\module\confluence\parser\list\TreeComponent.java:[89,31]
 cannot resolve symbol
symbol  : class StringBuilder
location: class 
org.apache.maven.doxia.module.confluence.parser.list.TreeComponent


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (MAVENUPLOAD-617) Upload request for wsdl4j 1.5.2 (multiple bundles)

2005-12-02 Thread Kevan Miller (JIRA)

Upload request for wsdl4j 1.5.2 (multiple bundles)
--

 Key: MAVENUPLOAD-617
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-617
 Project: maven-upload-requests
Type: Task
Reporter: Kevan Miller


http://www.hogstrom.org/wsdl4j/wsdl4j-1.5.2-bundle.jar
http://www.hogstrom.org/wsdl4j/wsdl4j-qname-1.5.2-bundle.jar

1.5.2 is a service release of wsdl4j. Geronimo V1 will be dependent upon this 
service release.

I am not a wsdl4j developer. One of the project admins, John Kaputin, requested 
that I generate the upload request.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1739) default version for the release, but not the development

2005-12-02 Thread Michael Fiedler (JIRA)

default version for the release, but not the development


 Key: MNG-1739
 URL: http://jira.codehaus.org/browse/MNG-1739
 Project: Maven 2
Type: Bug
  Components: maven-release-plugin  
Versions: 2.0
 Environment: Win XP, sp2
Reporter: Michael Fiedler
Priority: Minor


   When the prepare goal of release is executed, a default exists for the 
release version of each pom.xml.  However, the development version prompt did 
not have a default listed in all cases.  Only one had a default.  Is this 
considered a bug?  If not, I would like to request/suggest having a default for 
all .

   I am using maven2. 

console:
C:\...\modules>mvn release:prepare
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   modules
[INFO]   x
[INFO]   y
[INFO]   z
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO] 

[INFO] Building modules
[INFO]task-segment: [release:prepare] (aggregator-style)
[INFO] 

[INFO] snapshot com.werner:x:1.2-SNAPSHOT: checking for updates from middle tier
[INFO] [release:prepare]
[INFO] What tag name should be used?
QA
[INFO] Verifying there are no local modifications ...
[INFO] Checking lineage for snapshots ...
[INFO] Checking dependencies for snapshots ...
[INFO] Checking plugins for snapshots ...
[INFO] What is the release version for 'com.werner:modules'? [1.0.1]

[INFO] Checking lineage for snapshots ...
[INFO] Checking dependencies for snapshots ...
[INFO] Checking plugins for snapshots ...
[INFO] What is the release version for 'com.werner:x'? [1.2]

[INFO] Checking lineage for snapshots ...
[INFO] Checking dependencies for snapshots ...
[INFO] Checking plugins for snapshots ...
[INFO] What is the release version for 'com.werner:y'? [1.0.1]

[INFO] Checking lineage for snapshots ...
[INFO] Checking dependencies for snapshots ...
[INFO] Checking plugins for snapshots ...
[INFO] What is the release version for 'com.werner:z'? [1.0.1]

[INFO] Checking in modified POMs
[INFO] Tagging release with the label QA.
[INFO] What is the new development version for 'com.werner:modules'? []

[INFO] What is the new development version for 'com.werner:x'? [1.3-SNAPSHOT]

[INFO] What is the new development version for 'com.werner:y'? []

[INFO] What is the new development version for 'com.werner:z'? []

[INFO] Checking in development POMs
[INFO] 

[INFO] BUILD SUCCESSFUL
[INFO] 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: build failure

go to the test code and add throws Exception for now.
 
On 12/2/05, Mike Perham <[EMAIL PROTECTED]> wrote:
[ERROR] BUILD FAILURE[INFO]
[INFO] Compilation failureD:\apache\maven-scm\maven-scm-providers\maven-scm-provider-clearcase\src\test\java\org\apache\maven\scm\provider\clearcase\command\checkin\ClearCaseCheckInCommandTest.java:
[34,75] unreported exceptionorg.apache.maven.scm.ScmException; must be caught or declared to bethrown

[jira] Updated: (MPARTIFACT-61) scpexe is a noop

 [ http://jira.codehaus.org/browse/MPARTIFACT-61?page=all ]

Lukas Theussl updated MPARTIFACT-61:


Description: 
Unfortunatel scpexe protocoll seems a noop in version 1.5.2. The executable is 
not called, but Maven is reporting happily that it has deployed:

jar:deploy:
[echo] Deploying...
Using userBuildPropertiesFile: C:\Dokumente und 
Einstellungen\jos\build.properties
Using projectPropertiesFile: C:\Work\Projects\commons\lang\project.properties
Using projectBuildPropertiesFile: C:\Work\Projects\commons\lang\build.properties
Will deploy to 1 repository(ies): elsag
Deploying to repository: elsag
Uploading to elsag-commons/poms/elsag-lang-1.2-SNAPSHOT.pom: 
 (7K)
Uploading to elsag-commons/poms/elsag-lang-snapshot-version: 
 (0K)
Uploading to elsag-commons/poms/elsag-lang-1.2-20051011.091919.pom: 
 (7K)
Will deploy to 1 repository(ies): elsag
Deploying to repository: elsag
Uploading to elsag-commons/jars/elsag-lang-1.2-SNAPSHOT.jar: 
 (64K)
Uploading to elsag-commons/jars/elsag-lang-snapshot-version: 
 (0K)
Uploading to elsag-commons/jars/elsag-lang-1.2-20051011.091940.jar: 
 (64K)
attaining goal build:end

I can even remove any scp.exe and ssh.exe or set maven.repo.X.scp.executable to 
any not existing file, the output of Maven is the same. Setting the 
scp.executable property to a batch file that writes something into a file 
proves, that the "executable" is definately not called. All this works with 
1.4.1 though delivered with the M102 installation, the artifacts are really 
delpoyed.

This is a real blocker for me, since I am stuck to 1.0.2 because of extensive 
entitiy usage and I wanted to use 1.5.2 to write self-contained POMs into the 
repository to prepare a M2 transition at a later time.

Note, that the scp protocol does not work either for me, I always get despite 
any settings for private key and passphrase:

Root cause
org.apache.maven.MavenException: Unable to deploy to any repositories
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doDeploy(DefaultArtifactDeployer.java:338)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleDeploy(DefaultArtifactDeployer.java:131)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:102)
at 
org.apache.maven.artifact.deployer.DeployBean.deploy(DeployBean.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230)
at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at 
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at 
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)


  was:
Unfortunatel scpexe protocoll seems a noop in version 1.5.2. The executable is 
not called, but Maven is reporting happily that it has deployed:

jar:deploy:
[echo] Deploying...
Using userBuildPropertiesFile: C:\Dokumente und 
Einstellungen\jos\build.properties
Using projectPropertiesFile: C:\Work\Projects\commons\lang\project.properties
Using projectBuildPropertiesFile: C:\Work\Projects\commons\lang\build.properties
Will deploy to 1 repository(ies): elsag
Deploying to repository: elsag
Uploading to elsag-commons/poms/elsag-lang-1.2-SNAPSHOT.pom: 
 (7K)
Uploading to elsag-commons/poms

[jira] Created: (CONTINUUM-497) Ability to download from the Working Copy page.

2005-12-02 Thread Shinobu Kawai Yoshida (JIRA)

Ability to download from the Working Copy page.
---

 Key: CONTINUUM-497
 URL: http://jira.codehaus.org/browse/CONTINUUM-497
 Project: Continuum
Type: Wish
  Components: Web interface  
Reporter: Shinobu Kawai Yoshida
Priority: Trivial


It would be great if there was an interface to download a file from the Working 
Copy page.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[REPOCLEAN] Error(s) occurred while converting repository

Errors occurred while performing maven-1 to maven-2 repository conversion.

For more details, see:

http://test.maven.codehaus.org/reports/repoclean/02-Dec-2005_04.31.11/repository.report.txt

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

[continuum build - FAILED - update] Fri Dec 2 16:30:00 GMT 2005

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051202.163000.txt

[jira] Updated: (MNG-1736) list-style-position: ouside; in maven-base.css

 [ http://jira.codehaus.org/browse/MNG-1736?page=all ]

Yann Le Du updated MNG-1736:


Attachment: MNG-1736-maven-site-plugin.patch

Changed ouside to outside
Correction is harmless since outside is the default value

> list-style-position: ouside; in maven-base.css
> --
>
>  Key: MNG-1736
>  URL: http://jira.codehaus.org/browse/MNG-1736
>  Project: Maven 2
> Type: Bug
>   Components: maven-site-plugin
> Versions: 2.0.1
> Reporter: Yann Le Du
> Priority: Trivial
>  Attachments: MNG-1736-maven-site-plugin.patch
>
>
> maven-base.css contains incorrect property value :
> list-style-position: ouside;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1736) list-style-position: ouside; in maven-base.css

list-style-position: ouside; in maven-base.css
--

 Key: MNG-1736
 URL: http://jira.codehaus.org/browse/MNG-1736
 Project: Maven 2
Type: Bug
  Components: maven-site-plugin  
Versions: 2.0.1
Reporter: Yann Le Du
Priority: Trivial


maven-base.css contains incorrect property value :
list-style-position: ouside;


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: Design - Replacing Continuum's Web Framework

Carlos Sanchez a écrit :

On 12/1/05, Brett Porter <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:

Acegi is based in servlet filters for the protection of urls, so the
web framework used won't impact its use.

That's great. Does it still require spring to be configured though? We
already have a massive download - I'd really like to reduce our
dependency set.

You could be able to configure it in other way. Spring basically just
call getters and setters. However some classes implement Spring
interfaces and makes use of Spring tools. My first though and i think
John agrees with me is let's include first Spring jars, and after
worry about removing unneeded stuff.

I was in a project using JSF and seems that it's adoption is getting
speed, with different implementations and a lot of extensions,
utilities and tools. I've heard very good things about using
Facelets+JSF to create components, and also about Spring MVC, but
seems to me that people using Spring MVC is moving to JSF.

I've heard a lot of negative points about its use without tools support
too. However I haven't done the necessary investigation. I flicked
through some examples and found the pages almost illegible for the
number of tags for a simple form, and haven't really seen an example of
templating (perhaps that is meant to be external?)

Yes, the spec by itself is not a good idea, you should use tools
available. MyFaces provides some cool stuff, new components,... There
are emerging a lot of projects surrounding JSF

I suggest this read http://jroller.com/page/RickHigh

Although I don't have experience with either Spring MVC or WebWork, at
least with an action framework and JSP/velocity its a bit familiar - I'd
be worried about the learning curve of JSF as a barrier to contribution.
I get the feeling WW will be easy to learn for your average struts
veteran :)

I don't find it that difficult, and I think in a year new people will
stop learning Struts, and go for JSF. I'm pretty sure that a high
perecent of people willing to help will be *new* people, from
universities and so, more than *old* people

I never used JSF, but i've heard too some negatives points. I think it's more simple to do the
migration to jsp technology because (if we need some help, tools, components...) lot of resources
are available

Of those, WW seems the best choice to me as it is coming to Apache and
is the more mature solution, and probably most familiar wrt summit.

I'd also endorse the use of sitemesh. That is a servlet filter that sits
in front of the app to "skin" it. It's very fast, and easy to use.

There's really good integration between myfaces and tiles, it composes
tha pages transparently for you.

Cheers,
Brett

[jira] Updated: (MEV-243) xmlrpc:xmlrpc:1.2 depends on relocated servlet api

 [ http://jira.codehaus.org/browse/MEV-243?page=all ]

Matt Brozowski updated MEV-243:
---

Attachment: xmlrpc-1.2.patch

> xmlrpc:xmlrpc:1.2 depends on relocated servlet api
> --
>
>  Key: MEV-243
>  URL: http://jira.codehaus.org/browse/MEV-243
>  Project: Maven Evangelism
> Type: Bug
>   Components: Dependencies
> Reporter: Matt Brozowski
>  Attachments: xmlrpc-1.2.patch
>
>
> xmlrpc:xmlrpc:1.2
> depends on servletapi:servletapi:2.2 which has been moved to 
> javax.servlet:servleti-api:2.2
> I will attach the patch

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1738) Long words in left column overflows

Long words in left column overflows
---

 Key: MNG-1738
 URL: http://jira.codehaus.org/browse/MNG-1738
 Project: Maven 2
Type: Bug
  Components: maven-site-plugin  
Versions: 2.0.1
 Environment: Mozilla Firefox 1.5
Reporter: Yann Le Du
Priority: Minor
 Attachments: before.png

In the left column, if you put text with long words - such as project names - 
text overflows (see before.png)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MEV-243) xmlrpc:xmlrpc:1.2 depends on relocated servlet api

 [ http://jira.codehaus.org/browse/MEV-243?page=all ]

Matt Brozowski updated MEV-243:
---

Attachment: xmlrpc-1.2.patch.correct

sorry somehow the first file get double up.. use this patch instead

> xmlrpc:xmlrpc:1.2 depends on relocated servlet api
> --
>
>  Key: MEV-243
>  URL: http://jira.codehaus.org/browse/MEV-243
>  Project: Maven Evangelism
> Type: Bug
>   Components: Dependencies
> Reporter: Matt Brozowski
>  Attachments: xmlrpc-1.2.patch, xmlrpc-1.2.patch.correct
>
>
> xmlrpc:xmlrpc:1.2
> depends on servletapi:servletapi:2.2 which has been moved to 
> javax.servlet:servleti-api:2.2
> I will attach the patch

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MEV-243) xmlrpc:xmlrpc:1.2 depends on relocated servlet api

xmlrpc:xmlrpc:1.2 depends on relocated servlet api
--

 Key: MEV-243
 URL: http://jira.codehaus.org/browse/MEV-243
 Project: Maven Evangelism
Type: Bug
  Components: Dependencies  
Reporter: Matt Brozowski
 Attachments: xmlrpc-1.2.patch

xmlrpc:xmlrpc:1.2

depends on servletapi:servletapi:2.2 which has been moved to 
javax.servlet:servleti-api:2.2

I will attach the patch

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

RE: release plugin depends on maven 2.0.1

2005-12-02 Thread Mike Perham

Can someone please deploy the latest plexus-utils SNAPSHOT?
release:perform with the latest release-plugin does not work for me due
to this and forcing an upToDate check does not help.

-Original Message-
From: dan tran [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 02, 2005 12:48 AM
To: Maven Developers List
Subject: Re: release plugin depends on maven 2.0.1

maven-scm-plugin is now depending on plexus-utils-1.5-SNAPSHOT as well.

-D


On 12/1/05, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> I noticed that the release plugin now requires plexus-utils 1.0.5 
> snapshot. This means that it will only work on Maven 2.0.1 (and 
> recently bootstrapped at that).
>
> Is there an alternative?
>
> Please be vigilant about backwards compatibility. We really need to 
> get plexus-utils out of the core...
>
> - Brett
>
> -
> 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: release plugin depends on maven 2.0.1

I think we should reverse the changes and put it back when  maven 2.0.1 is
released.

It is hard for me to ask my user to use 2.0.1 bootstrap, inorder to do
release and maven:scm-bootstrap

-Dan


On 12/2/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
>
> I need it for use MAVEN_TERMINATE_CMD env var and obtain the right exit
> code of mvn in release:perform
>
> Alternative will be to duplicate getSystemEnvironment method from
> Commandline class
>
> Emmanuel
>
> Brett Porter a écrit :
> > I noticed that the release plugin now requires plexus-utils 1.0.5
> > snapshot. This means that it will only work on Maven 2.0.1 (and recently
> > bootstrapped at that).
> >
> > Is there an alternative?
> >
> > Please be vigilant about backwards compatibility. We really need to get
> > plexus-utils out of the core...
> >
> > - Brett
> >
> > -
> > 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]
>
>

build failure

2005-12-02 Thread Mike Perham

[ERROR] BUILD FAILURE
[INFO]


[INFO] Compilation failure

D:\apache\maven-scm\maven-scm-providers\maven-scm-provider-clearcase\src
\test\java\org\apache\maven\
scm\provider\clearcase\command\checkin\ClearCaseCheckInCommandTest.java:
[34,75] unreported exception
 org.apache.maven.scm.ScmException; must be caught or declared to be
thrown

Re: Design - Replacing Continuum's Web Framework


https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf

John Casey a écrit :

Hi everyone,

We've been talking about this for quite awhile in various channels, and 
I wanted to take a few minutes and formalize the discussion. I'll 
capture the highlights of this discussion in the wiki afterwards. I'll 
start by posting my own thoughts, and let you all respond.


Up to this point, Continuum has been built on a web framework called 
Summit, which is part of the Plexus project, and using Velocity as the 
page rendering technology. Summit is still a very young project, and as 
a result has its problems. Given the proliferation of web frameworks out 
there, it seems natural to wonder whether we couldn't find something 
more mainstream and mature that will fit our needs.


The key goal here is to make the web tier as easy to understand as 
possible by the widest possible audience, without sacrificing anything 
in the way of quality. To that end, criteria might include:


* tool support
* maturity in the form of multiple final releases (or at least one)
* good integration with JSP (it's the most widely-used rendering
technology out there for java)
* ready availability of good documentation
* integration with a decent security library (think acegi)
* others?

Another big concern is that we need to be able to make this web 
framework integrate with Plexus without too much funny business. I don't 
expect that to be a big problem, but worth mentioning.


I know that a certain amount of work has been done by Trygve and 
Emmanuel to get WebWork running inside Plexus. Is this the best 
framework? A quick check of Amazon showed three books, only one of which 
is completely concerned with WW. SpringMVC might be another option, 
since it has probably the most natural integration with Acegi. There is 
a certain amount of overlap between Spring and Plexus that we'd probably 
have to map with a custom Spring container or something, but that's 
likely to be everywhere, since dependency injection is such a hot topic 
(and very useful).


What do you all think?

-john

[jira] Updated: (MNG-1374) Release plugin fails to update SNAPSHOTS in the dependencyManagement section

2005-12-02 Thread mike perham (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1374?page=all ]

mike perham updated MNG-1374:
-

Attachment: prep.txt

Patch which appears to exhibit the correct (per my writeup) versioning 
behavior.  Apoligies for the "noise" in the patch but I used Eclipse's code 
format to format per the maven spec and it reformatted a lot of the file.

> Release plugin fails to update SNAPSHOTS in the dependencyManagement section
> 
>
>  Key: MNG-1374
>  URL: http://jira.codehaus.org/browse/MNG-1374
>  Project: Maven 2
> Type: Bug
>   Components: maven-release-plugin
> Versions: 2.0
>  Environment: Maven 2.0 (release-plugin version: 2.0-beta3)
> Reporter: Ørjan Austvold
>  Attachments: prep.txt
>
>
> In a multi project the parent-pom can specify "standard" versions for 
> dependencies within the project group. I have found it convenient to also 
> list group-members with versions in this section so that all child artifact 
> within the group simply specifies inter-group artifact dependencies without 
> versions.
> The release plugin fails to alter SNAPSHOT dependencies within the 
> dependencyMangement section. The tagged version of child poms gets instead 
> the correct version explicitly stated in their dependency section.
> It seems a bit strange that dependencies on artifacts within a group must 
> have dependencies on other artifacts within the group listed with version 
> numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MNG-1738) Long words in left column overflows

 [ http://jira.codehaus.org/browse/MNG-1738?page=all ]

Yann Le Du updated MNG-1738:


Attachment: after.png
MNG-1738-maven-site-plugin.patch

In #leftColumn, added :
overflow: auto;

See after.png

> Long words in left column overflows
> ---
>
>  Key: MNG-1738
>  URL: http://jira.codehaus.org/browse/MNG-1738
>  Project: Maven 2
> Type: Bug
>   Components: maven-site-plugin
> Versions: 2.0.1
>  Environment: Mozilla Firefox 1.5
> Reporter: Yann Le Du
> Priority: Minor
>  Attachments: MNG-1738-maven-site-plugin.patch, after.png, before.png
>
>
> In the left column, if you put text with long words - such as project names - 
> text overflows (see before.png)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1374) Release plugin fails to update SNAPSHOTS in the dependencyManagement section

2005-12-02 Thread mike perham (JIRA)

[ http://jira.codehaus.org/browse/MNG-1374?page=comments#action_52666 ] 

mike perham commented on MNG-1374:
--

I'm attempting to fix this issue but I'm finding that POM updating might 
require two passes.  The issue is that the parent POM holds the depMgmt dep 
versions but it is updated FIRST and then the versions of the children are 
updated.  So the parent 's depMgmt dependency version stays at 1.0.0-SNAPSHOT 
but the child project's actual released version is incremented to 1.0.0.

I think the release transform algorithm will need to change to something like 
this:

for each project
  inc version
  update dependencies
end

for each project
  update depMgmt versions
  writePom
end

My only question is whether the development transform should do the same?  I 
would think that it would be a bad idea for all dependency versions to be 
blanket incremented without a real need.  Instead I would think that we should 
NOT do the same for the release transform and instead force the developer to 
increment the depMgmt version when his project ACTUALLY requires an updated 
version.

> Release plugin fails to update SNAPSHOTS in the dependencyManagement section
> 
>
>  Key: MNG-1374
>  URL: http://jira.codehaus.org/browse/MNG-1374
>  Project: Maven 2
> Type: Bug
>   Components: maven-release-plugin
> Versions: 2.0
>  Environment: Maven 2.0 (release-plugin version: 2.0-beta3)
> Reporter: Ørjan Austvold

>
>
> In a multi project the parent-pom can specify "standard" versions for 
> dependencies within the project group. I have found it convenient to also 
> list group-members with versions in this section so that all child artifact 
> within the group simply specifies inter-group artifact dependencies without 
> versions.
> The release plugin fails to alter SNAPSHOT dependencies within the 
> dependencyMangement section. The tagged version of child poms gets instead 
> the correct version explicitly stated in their dependency section.
> It seems a bit strange that dependencies on artifacts within a group must 
> have dependencies on other artifacts within the group listed with version 
> numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - SUCCESS - update] Fri Dec 2 17:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051202.173000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051202.173000.txt

[jira] Created: (MNG-1737) ArrayIndexOutOfBoundsException upon deploy

2005-12-02 Thread Michael Fiedler (JIRA)

ArrayIndexOutOfBoundsException upon deploy
--

 Key: MNG-1737
 URL: http://jira.codehaus.org/browse/MNG-1737
 Project: Maven 2
Type: Bug
  Components: maven-deploy-plugin  
 Environment: Win xp, sp2
Reporter: Michael Fiedler


I am trying to deploy for the first time.  I am using wagon-ftp, 1.0-alpha-4 as 
an extension for a maven 2 deploy goal.  The repository location (on the host) 
is new and empty.

c:\...> .../bin/mvn clean:clean install deploy
...
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from M2_repo_ftp
Uploading: 
ftp://host/com/company/modules/1.0-SNAPSHOT/modules-1.0-20051202.165702-1.pom
4K uploaded
[INFO] Retrieving previous metadata from M2_repo_ftp
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] 0
[INFO] 

[INFO] Trace
java.lang.ArrayIndexOutOfBoundsException: 0
at 
org.apache.maven.wagon.providers.ftp.FtpWagon.fillInputData(FtpWagon.java:326)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:367)
at 
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:295)
at 
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:334)
at 
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:379)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:83)
at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:138)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[REPOCLEAN] Error(s) occurred while converting repository

Errors occurred while performing maven-1 to maven-2 repository conversion.

For more details, see:

http://test.maven.codehaus.org/reports/repoclean/02-Dec-2005_12.30.58/repository.report.txt

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

[jira] Created: (MNG-1734) In a multi-module build, assembly descriptor paths are not project-relative, but erraneously relative to the parent project directory

2005-12-02 Thread Michael B?ckling (JIRA)

In a multi-module build, assembly descriptor paths are not project-relative, 
but erraneously relative to the parent project directory
-

 Key: MNG-1734
 URL: http://jira.codehaus.org/browse/MNG-1734
 Project: Maven 2
Type: Bug
  Components: maven-assembly-plugin  
Versions: 2.0
 Environment: WinXP SP2
Maven 2
Reporter: Michael Böckling


When I try to perform a multi-module build executed in a build-only 
(packaging=pom) parent project ("AAH-1-Genius-Build"), assembly fails. I 
defined an assembly:assembly execution bound to the "install" phase in the 
"AAH-1-Genius-TpmMonitor" sub-project using my own descriptor. Maven finds the 
descriptor, but the (relative) paths in the descriptor are not expanded against 
the "AAH-1-Genius-TpmMonitor" sub-project, but against the "AAH-1-Genius-Build" 
parent-project, which of course stops the build.
The last line of the error log below shouldnt be 
"C:\DEVELOPMENT\Workspaces\Standard\AAH-1-Genius-Build\src\extern", it should 
be "C:\DEVELOPMENT\Workspaces\Standard\AAH-1-Genius-TpmMonitor\src\extern"!
I also tried using ${basedir} and such, but unfortunately those variables don't 
get expanded. I also tried activating "includeBaseDirectory" in the descriptor, 
hoping it would prepend the current project path to the descriptor paths (I had 
to guess since its not documented...), but no luck.
Beside the obvious bug concerning project directory, I really think maven vars 
should be expanded.
Error log:


[INFO] [assembly:assembly {execution: prepare-assembly}]
[INFO] Expanding: C:\DEVELOPMENT\Workspaces\Standard\AAH-1-Genius-Build\..\AAH-1
-Genius-BusinessLib\target\aah-genius-business-lib-1.0-SNAPSHOT.jar into C:\DEVE
LOPMENT\Workspaces\Standard\AAH-1-Genius-Build\..\AAH-1-Genius-TpmMonitor\target
\assembly\work\aah-genius-business-lib-1.0-SNAPSHOT
[INFO] Expanding: C:\DEVELOPMENT\Workspaces\Standard\AAH-1-Genius-Build\..\AAH-1
-Genius-MappingLib\target\aah-genius-mapping-lib-1.0-SNAPSHOT.jar into C:\DEVELO
PMENT\Workspaces\Standard\AAH-1-Genius-Build\..\AAH-1-Genius-TpmMonitor\target\a
ssembly\work\aah-genius-mapping-lib-1.0-SNAPSHOT
[INFO] -
---
[ERROR] BUILD ERROR
[INFO] -
---
[INFO] Error creating assembly

Embedded error: C:\DEVELOPMENT\Workspaces\Standard\AAH-1-Genius-Build\src\extern
 isn't a directory.
[INFO] -

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1733) attaching javadoc jars to eclipse dependencies

2005-12-02 Thread Michal Stochmialek (JIRA)

attaching javadoc jars to eclipse dependencies
--

 Key: MNG-1733
 URL: http://jira.codehaus.org/browse/MNG-1733
 Project: Maven 2
Type: New Feature
  Components: maven-eclipse-plugin  
Versions: 2.0
Reporter: Michal Stochmialek


The downloadSources is great feature of eclipse plugin.

I would like similar feature, that downloads jars with javadocs and also 
attaches them to eclipse dependecies.

best regards, Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[continuum build - SUCCESS - update] Fri Dec 2 14:30:00 GMT 2005

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20051202.143000.tar.gz

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051202.143000.txt

[jira] Commented: (MEV-232) DWR POM should list dependencies as optional

2005-12-02 Thread Julien Dubois (JIRA)

[ http://jira.codehaus.org/browse/MEV-232?page=comments#action_52655 ] 

Julien Dubois commented on MEV-232:
---

With the current Maven 2 version, there is a bug with the optional dependencies 
which prevents us from correcting the pom ATM.
However, the next version of Maven 2 should be out in a couple of weeks 
(according to Carlos), and the pom.xml in CVS is ready for this version. As 
soon as the next version of Maven 2 is released, we will create a new upload 
bundle for ibiblio, with the correct transitive information in the pom.

> DWR POM should list dependencies as optional
> 
>
>  Key: MEV-232
>  URL: http://jira.codehaus.org/browse/MEV-232
>  Project: Maven Evangelism
> Type: Bug
>   Components: Invalid POM
> Reporter: Matt Raible

>
>
> AFAIK, DWR doesn't require any dependencies at runtime, therefore all it's 
> dependencies should be marked optional (except servlet which should be 
> provided).
> Current: http://www.ibiblio.org/maven2/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom
> Updated: 
> http://static.appfuse.org/repository/uk/ltd/getahead/dwr/1.0/dwr-1.0.pom

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (CONTINUUM-496) End Time contains junk value when I forced a build to run

2005-12-02 Thread Emmanuel Venisse (JIRA)

 [ http://jira.codehaus.org/browse/CONTINUUM-496?page=all ]
 
Emmanuel Venisse closed CONTINUUM-496:
--

 Assign To: Emmanuel Venisse
Resolution: Fixed

Fixed.

> End Time contains junk value when I forced a build to run
> -
>
>  Key: CONTINUUM-496
>  URL: http://jira.codehaus.org/browse/CONTINUUM-496
>  Project: Continuum
> Type: Bug
>   Components: Core system
> Versions: 1.0.2
> Reporter: John Sisson
> Assignee: Emmanuel Venisse
> Priority: Minor
>  Fix For: 1.0.2

>
>
> The following is from the build history when it was building.  Note the end 
> time on the first line:
>   Dec 1, 2005 10:23:11 PM Dec 31, 1969 4:00:00 PM 
> BuildingResult
> 22Dec 1, 2005 10:00:18 PM Dec 1, 2005 10:06:51 PM Success 
> Result
> 21Dec 1, 2005 7:00:16 PM  Dec 1, 2005 7:03:57 PM  Success Result
> This occurred on http://ci.gbuild.org/continuum/servlet/continuum running a 
> 1.1-SNAPSHOT.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commenté: (MNG-1558) Manifest generat ion problems caused by valid POM information

2005-12-02 Thread Lilians Auvigne (JIRA)

[ http://jira.codehaus.org/browse/MNG-1558?page=comments#action_52653 ] 

Lilians Auvigne commented on MNG-1558:
--

I have the same problem with description.length < 72 and multi lines description

Test multi 
lines

maven-archiver generate invalid Manifest

Extension-Name: module
Specification-Title: Test multi 
lines
Specification-Vendor...

> Manifest generation problems caused by valid POM information
> 
>
>  Key: MNG-1558
>  URL: http://jira.codehaus.org/browse/MNG-1558
>  Project: Maven 2
> Type: Bug
>   Components: maven-jar-plugin
> Versions: 2.0
> Reporter: Bob Allison
>  Fix For: 2.0.1

>
>
> It looks like we have some problems with the contents of manifests in jar 
> files.
> According to Sun's documentation 
> (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three 
> basic formatting rules which are not always being enforced:
>1) All text must be UTF-8
>2) Lines are limited to 72 characters; longer lines must be continued
>3) Sections are divided by blank lines
> Where are these rules being violated?  The first rule can be violated by any 
> POM which is in a character set other than UTF-8.  The last two rules can be 
> violated by any POM value which spans multiple lines.  Both of these are 
> potential problems since a number of POM values go directly into the manifest 
> without sufficient checking.
>   
>   
> Example:
> The plugin I have been working on suddenly stopped working.  It stopped when 
> I added a two-line description to the POM.  I have been able to determine 
> that converting the second line of the description into a proper manifest 
> continuation line fixed the problem.  As it turns out, the class loader was 
> ignoring the jar; this created an error where the name of the Mojo class was 
> found but the class could not be loaded.
> Workarounds for the present:
>-- Any POM fields which end up in a jar manifest needs to be limited to 
> UTF-8 characters.
>-- Multi-line values should be constructed so that all lines start with a 
> space character (not strictly required for the first line but it doesn't 
> hurt).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (CONTINUUM-494) Unable to create schedule with year

2005-12-02 Thread Emmanuel Venisse (JIRA)

 [ http://jira.codehaus.org/browse/CONTINUUM-494?page=all ]
 
Emmanuel Venisse closed CONTINUUM-494:
--

 Assign To: Emmanuel Venisse
Resolution: Fixed

Fixed.

> Unable to create schedule with year
> ---
>
>  Key: CONTINUUM-494
>  URL: http://jira.codehaus.org/browse/CONTINUUM-494
>  Project: Continuum
> Type: Bug
>   Components: Web interface
> Versions: 1.0.1
> Reporter: Shinobu Kawai Yoshida
> Assignee: Emmanuel Venisse
>  Fix For: 1.0.2

>
>
> The schedule does not allow cron expressions with year.
> eg. 0 15 10 * * ? 2005
> cf. http://www.opensymphony.com/quartz/api/org/quartz/CronTrigger.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (MNG-1732) Improve methods to define the scope and packaging of dependencies

2005-12-02 Thread Bob Allison (JIRA)

Improve methods to define the scope and packaging of dependencies
-

 Key: MNG-1732
 URL: http://jira.codehaus.org/browse/MNG-1732
 Project: Maven 2
Type: Improvement
Versions: 2.0
Reporter: Bob Allison


I have been thinking about the way the dependency scope is being used, and I 
think there may be a need to expand the scope definitions so that more 
flexibility is available for defining what dependencies get packaged into 
artifacts and what dependencies are used in the various classpaths.  My thought 
is to create a new tag on the dependency XML tree called "usage"; it would look 
something like this:

  junit
  junit
  3.8.1
  
  
true
true
false
false
/usr/local/lib
  


I see two classes of items within the  tag:
--  classpath items (compile, test, execute above) which split out the current 
meaning of the scope value and would have the value of "true" or "false" to 
identify if the dependency should appear on the classpath; the default value 
for these would be "true"
-- packaging items (jar, rpm above) which control the packaging of the 
dependency into the specified type of artifact and would have the value "false" 
to omit the dependency, "true" to package the dependency in a package-specific 
default location (e.g., wars would default to "WEB-INF/lib"), or a path to 
package the dependency in a specific place in the artifact; the default value 
for these would be "false"

My expectation is that both  and  would be accepted and that 
 would be configured as a Map.  If possible, it would be easier for 
mojos to use this arrangement if specifying  would cause a 
pre-configured  map to be placed in the usage variable so that mojos 
only have to look at the usage map and not interpolate the scope value as well.

I think this may also help with people who have a hard time remembering that a 
scope of "compile" means that the dependency is also available at runtime and 
which scopes make the dependency get packaged into the artifact.  It would also 
address some of the "how do I keep my war dependencies from appearing in my ear 
file" type of questions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[REPOCLEAN] Error(s) occurred while converting repository

Errors occurred while performing maven-1 to maven-2 repository conversion.

For more details, see:

http://test.maven.codehaus.org/reports/repoclean/02-Dec-2005_08.31.09/repository.report.txt

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

[jira] Reopened: (MEV-241) commons-attribute-compiler has direct dependency on tools.jar and fails on MacOSX

 [ http://jira.codehaus.org/browse/MEV-241?page=all ]
 
Matt Brozowski reopened MEV-241:



It's been two days and these updates have not made it to the central repo.  I 
don't know the process of how that works so I'm going to reopen in case someone 
missed that this is failing.

Is there someplace I can look to see how this is supposed to work?

> commons-attribute-compiler has direct dependency on tools.jar and fails on 
> MacOSX
> -
>
>  Key: MEV-241
>  URL: http://jira.codehaus.org/browse/MEV-241
>  Project: Maven Evangelism
> Type: Bug
> Reporter: Matt Brozowski
> Assignee: Edwin Punzalan
>  Attachments: commons-attributes-compiler.patch
>
>
> commons-attributes-compiler-2.1.pom has the following dependency:
> 
>   java
>   tools
>   1.4
>   ${java.home}/../lib/tools.jar
>   system
> 
> This breaks on MacOSX which doesn't have a tools.jar.  After discussing this 
> with brett he pointed me to it0063 in maven-core-it which solved this using 
> profiles as follows:
>   
> 
>   
>   default-tools.jar
>   
> 
>   java.vendor
>   Sun Microsystems Inc.
> 
>   
>   
> 
>   sun.jdk
>   tools
>   1.4.2
>   system
>   ${java.home}/../lib/tools.jar
> 
>   
> 
>   
> I have checked out the repo and make the change and will attach the patch 
> file.  (Is there someway I could have tested this first?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MNG-1572) Locale problem in Clover plugin

2005-12-02 Thread Vincent Siveton (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1572?page=all ]
 
Vincent Siveton closed MNG-1572:


 Assign To: Vincent Siveton
Resolution: Fixed

Fix has been committed in rev 326881
http://svn.apache.org/viewcvs.cgi?rev=326881&view=rev

> Locale problem in Clover plugin
> ---
>
>  Key: MNG-1572
>  URL: http://jira.codehaus.org/browse/MNG-1572
>  Project: Maven 2
> Type: Bug
>   Components: maven-clover-plugin
> Versions: 2.0
> Reporter: Wim Deblauwe
> Assignee: Vincent Siveton

>
>
> I get the following error with the clover plugin
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Can't find bundle for base name clover-report, locale nl_NL
> [INFO] 
> 
> [INFO] Trace
> java.util.MissingResourceException: Can't find bundle for base name 
> clover-report, locale nl_NL
> at 
> java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:700)
> at 
> org.apache.maven.plugin.clover.CloverReportMojo.getBundle(CloverReportMojo.java:104)
> at 
> org.apache.maven.plugin.clover.CloverReportMojo.getName(CloverReportMojo.java:136)
> at 
> org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40)
> at java.util.Arrays.mergeSort(Arrays.java:1284)
> at java.util.Arrays.sort(Arrays.java:1223)
> at java.util.Collections.sort(Collections.java:159)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> regards,
> Wim

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-661) In parent site, automatically create link to modules sites and vice-versa

2005-12-02 Thread John Allen (JIRA)

[ http://jira.codehaus.org/browse/MNG-661?page=comments#action_52647 ] 

John Allen commented on MNG-661:


Hi Vincent,

Yeah i think this is a more approrpiate approach, especially as its only 
intended for testing. 

So the key to the the simulate mode is that all projects referenced by the 
reactor env. will be expected to share a common URL root and this root will be 
set by a plugin config rather than try and use the main POM. 

This would be great and would solve another problem i have with my CI based 
builds - In CI builds i still wnat to build the sites to allow project teams to 
access the latest SNAPSHOT javadocs, review code coverage etc without me having 
to deploy the site to the 'offical' location (a task I associate with a project 
deployment, not just CI builds)

I think we should also support the deployment of this 'simulated' site to a 
remote site which leads me to thinking that all this link URL business is 
pretty much dependent on where we're intending to deploy things to (staged or 
deployed/published location) so should we make the settings of these URLs 
something that the deploy operation does as a preparatory action?

site:site - generate site for deployment but create placeholders for links

site:stage - set parent and module links to file:// URLs based upon the 
project's distributionManagement.site details (i.e. exactly as you proposed) 
and then deploy the site to the location defined by the Mojo config (this 
supports us scp'ing the staged site to a remote host  and implicitly supports 
the stagingDirectory you proposed)

site:deploy - set parent and module links to URLs defined the project's real 
URL details (i.e. as my patch currently assumes) and then deploy the sites as 
defined by their distributionManagement settings (which must be related to 
their project.URLs otherwise the POM writer has screwed up:) )

We're definately getting their :- WDYT ...

ps. in regards to naming, staging is a common term for review/testing of a web 
site. Do we want to just call this site:stage rather than simulate? I know to 
us its simulating the real site deployment but in terms of business process the 
user is staging it for testing or local review. Not gonna get religous over 
about it though :)




> In parent site, automatically create link to modules sites and vice-versa
> -
>
>  Key: MNG-661
>  URL: http://jira.codehaus.org/browse/MNG-661
>  Project: Maven 2
> Type: Improvement
>   Components: maven-site-plugin
> Versions: 2.0-alpha-3
> Reporter: Yann Le Du
> Assignee: Vincent Siveton
> Priority: Minor
>  Fix For: 2.0.1
>  Attachments: SiteMojoPatch.txt, SiteMojoPatch.txt, SiteMojoPatch.txt
>
>
> Say we have the following project structure :
> A
> +-- B
> +-- C
> +-- D
> It would be nice to have the following links in the left menu of the 
> generated sites :
> A :
> Modules : B, D
> B :
> Parent : A
> Modules : C
> C :
> Parent : B
> D :
> Parent : A

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1731) I18n issues with report generation

2005-12-02 Thread Anuerin Diaz (JIRA)

I18n issues with report generation
--

 Key: MNG-1731
 URL: http://jira.codehaus.org/browse/MNG-1731
 Project: Maven 2
Type: Wish
Versions: 2.0
Reporter: Anuerin Diaz


The issue wherein report generation of certain plugins (or mix) causes the 
site/build phase to fail has already been logged before (see 
http://jira.codehaus.org/browse/MNG-1572). It might be better for the report 
component to have a way of falling back to a default  locale especially when 
the locale was not explicitly defined in the project descriptor. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-983) add staging site capabilities

2005-12-02 Thread Anuerin Diaz (JIRA)

[ http://jira.codehaus.org/browse/MNG-983?page=comments#action_52646 ] 

Anuerin Diaz commented on MNG-983:
--

Does staging means that there is a separate directory for the assembly of all 
site documentation? I have a need for a way to configure an alternate site 
directory since the site:deploy goal scatters all the pages on the distribution 
site.

Thanks.

ciao!

> add staging site capabilities
> -
>
>  Key: MNG-983
>  URL: http://jira.codehaus.org/browse/MNG-983
>  Project: Maven 2
> Type: Improvement
>   Components: maven-site-plugin
> Reporter: Brett Porter

>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Wagon-scm


Hi,

In wagon, we have a provider that use maven-scm (wagon-scm).
Someone is volunteers to modify/fix it with latest maven-scm code? So users will can use it to 
deploy artifacts in a scm repository instead of a directory in a server.


Emmanuel

[jira] Updated: (MNG-1158) PMD should use "sensible" default rulesets

2005-12-02 Thread Mark J. Titorenko (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1158?page=all ]

Mark J. Titorenko updated MNG-1158:
---

Attachment: MNG-1158-maven-pmd-plugin.patch

Sorry, I didn't read the patch guidelines before attaching.  It's the same 
patch, but the diff is now performed from the correct place and it's following 
the naming scheme.

Apologies for the confusion.

> PMD should use "sensible" default rulesets
> --
>
>  Key: MNG-1158
>  URL: http://jira.codehaus.org/browse/MNG-1158
>  Project: Maven 2
> Type: Task
>   Components: maven-pmd-plugin
> Versions: 2.0-beta-3
> Reporter: Dave Sag
>  Attachments: Locator.java, MNG-1158-maven-pmd-plugin.patch, 
> PmdReport.java.diff
>
>
> When I add a PMD report to my pom.xml the PMD report claims that my class 
> 'Address' should have a constructor.
> this is crazy talk - Address.java is an interface class.
> i guess this is really a PMD bug but i find it hard to believe that such a 
> well established tool as PMD would still be throwing up bugs like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MNG-1158) PMD should use "sensible" default rulesets

2005-12-02 Thread Mark J. Titorenko (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1158?page=all ]

Mark J. Titorenko updated MNG-1158:
---

Attachment: Locator.java
PmdReport.java.diff

I've attached a diff for the PmdReport class which requires the report to be 
supplied with a rulesetLocation configuration parameter.

Also attached is a duplicated version of the Locator class from the checkstyle 
plugin, which allows the ruleset to be stored either in the filesystem, as a 
classpath resource or on a web server. I imagine this kind of common 
functionality needs to be pushed up into the maven codebase somewhere, but 
don't have enough knowledge to suggest where!

This should be enough to fix the issue for this ticket - I don't believe there 
is a de facto "sensible" default ruleset and, instead, I think that anybody 
using this plugin should be choosing which rulesets to be using in their 
environment.

I think the XML output is a seperate issue for which an additional ticket 
should be opened.

I don't have developer access to the maven repository, so I'm hoping somebody 
can take this patch and apply it appropriately!


> PMD should use "sensible" default rulesets
> --
>
>  Key: MNG-1158
>  URL: http://jira.codehaus.org/browse/MNG-1158
>  Project: Maven 2
> Type: Task
>   Components: maven-pmd-plugin
> Versions: 2.0-beta-3
> Reporter: Dave Sag
>  Attachments: Locator.java, PmdReport.java.diff
>
>
> When I add a PMD report to my pom.xml the PMD report claims that my class 
> 'Address' should have a constructor.
> this is crazy talk - Address.java is an interface class.
> i guess this is really a PMD bug but i find it hard to believe that such a 
> well established tool as PMD would still be throwing up bugs like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: release plugin depends on maven 2.0.1


I need it for use MAVEN_TERMINATE_CMD env var and obtain the right exit code of 
mvn in release:perform

Alternative will be to duplicate getSystemEnvironment method from Commandline 
class

Emmanuel

Brett Porter a écrit :

I noticed that the release plugin now requires plexus-utils 1.0.5
snapshot. This means that it will only work on Maven 2.0.1 (and recently
bootstrapped at that).

Is there an alternative?

Please be vigilant about backwards compatibility. We really need to get
plexus-utils out of the core...

- Brett

-
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]

[CLEARCASE] Re: [jira] Commented: (SCM-88) Add transparent support for locking providers


Wim,

can you patch your clearcase provider?

Emmanuel

mike perham (JIRA) a écrit :
[ http://jira.codehaus.org/browse/SCM-88?page=comments#action_52577 ] 


mike perham commented on SCM-88:


I would suggest also adding the override to the ClearCase provider but I did 
not do it.  I verified it works as expected with the Peforce provider.



Add transparent support for locking providers
-

Key: SCM-88
URL: http://jira.codehaus.org/browse/SCM-88
Project: Maven SCM
   Type: Improvement
 Components: maven-scm-api
   Versions: 1.0-beta-2
   Reporter: mike perham
Fix For: 1.0-beta-2
Attachments: release-plugin.txt, scm.txt


Currently the release plugin requires a command line parameter "useEditMode" to 
work with the Clearcase and Perforce providers.  Please integrate the notion of locking 
vs non-locking providers into the SCM API so this does not need to be passed on the 
command line.

Re: Final things for checkout and update in ClearCase