[jira] Issue Comment Edited: (MPIR-107) Add configuration for the Project Dependency Graph / Dependency Tree
[
http://jira.codehaus.org/browse/MPIR-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140918#action_140918
]
fdk edited comment on MPIR-107 at 7/8/08 2:23 AM:
-
But these report is very light, juste show :
{code}
Used and declared dependencies
...
Used but undeclared dependencies
...
Unused but declared dependencies
...
{code}
Like we can see here :
http://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html,
the tree is not a report.
was (Author: fdk):
But these report is very light, juste show :
Used and declared dependencies
...
Used but undeclared dependencies
...
Unused but declared dependencies
...
Like we can see here :
http://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html,
the tree is not a report.
> Add configuration for the Project Dependency Graph / Dependency Tree
>
>
> Key: MPIR-107
> URL: http://jira.codehaus.org/browse/MPIR-107
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Improvement
> Components: dependencies
>Reporter: Arnaud
>
> Like we can configure the tree in the maven-dependency-plugin
> (http://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html),
> Why we can't configure the tree in this plugin ?
> In my project, i 'd like show only module of my compagny in the tree, and if
> there are conflict.
> so i 'd like use this configuration (it works with the commande : mvn
> dependency:tree )
> {code}
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> ${versionDependency}
>
> net.mycompany.*
> true
>
>
>
>
> {code}
> thank you
--
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] Commented: (MECLIPSE-459) missing artifact references with pde mode enabled
[
http://jira.codehaus.org/browse/MECLIPSE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141015#action_141015
]
Gopalakrishnan U commented on MECLIPSE-459:
---
I am also hit by this problem. As Benjamin pointed out I also think the problem
is on line 415. It should have been
if ( config.isPde() && dep.isProvided() && dep.isOsgiBundle() )
i.e, don't add the dependency to the classpath if the dependency is provided
AND it is a bundle AND the project is a PDE project.
It needs to be added to the class path if the dependency was not provided or it
is not a OSGi bundle. Here is the patch
Index:
src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java
===
---
src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java
(revision 674713)
+++
src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseClasspathWriter.java
(working copy)
@@ -412,7 +412,7 @@
// if the dependency is not provided and the plugin runs in
"pde mode", the dependency is
// added to the Bundle-Classpath:
-if ( config.isPde() && ( dep.isProvided() ||
dep.isOsgiBundle() ) )
+if ( config.isPde() && dep.isProvided() && dep.isOsgiBundle() )
{
return;
}
Gopal
> missing artifact references with pde mode enabled
> -
>
> Key: MECLIPSE-459
> URL: http://jira.codehaus.org/browse/MECLIPSE-459
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path, PDE
> support
>Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_11
> OS name: "linux" version: "2.6.15-51-686" arch: "i386" Family: "unix"
>Reporter: Benjamin Voigt
>Priority: Critical
> Attachments: pde_dep_missing.zip
>
>
> Some artifacts are not referenced after executing mvn eclipse:eclipse and
> having pde mode enabled. The strange thing is, that this does only happen for
> particluar versions of an artifact.
> Two artifacts that I found with this problem are jetty (org.mortbay.jetty)
> and slf4j-log4j12 (org.slf4j-log4j12). Jetty versions beyond 6.1.5 work with
> pde enabled, higher versions do not. Same for slf4j-log4j12 versions =< 1.1.0.
> Attached is an example project demonstrating the problem. Turn pde mode
> on/off in the pom and execute mvn eclipse:eclipse.
--
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] Commented: (MNG-3647) Maven performance needs improvement
[
http://jira.codehaus.org/browse/MNG-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141017#action_141017
]
Milos Kleint commented on MNG-3647:
---
your suggestions goes against the pluggability and out-of-the box principles
that maven is built on. You can't know if resources-plugin will do anything
before you run it. Your suggestion about configuring each plugin might work for
you, but it's not a good general option. You can do that even now. Define a
custom packaging ("void" for example) that has no mojos associated with
lifecycle phases and the configuration on your own for each plugin. However I'm
not convinced it's worth the effort. I believe it's the maven core that needs
to be optimized first.
> Maven performance needs improvement
> ---
>
> Key: MNG-3647
> URL: http://jira.codehaus.org/browse/MNG-3647
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.8
>Reporter: Ittay Dror
>
> I have a multi-module project with 40 modules. Running 'install' with no
> compilation takes 30 seconds. Running 'compile' takes 18 seconds. This is
> very high IMHO. Buildr (written in Ruby - a scripted language) takes 1
> second). In 'compile', adding time measurements to the mojo executions showed
> a cumulative time of 4.8 seconds. (Note that I ran maven several times, so
> all files are in the buffer cache)
> I've profiled the code to find obvious bottlenecks. Here is what I could
> easily fix:
> a. reading component configuration: in maven-uber jar there are 9
> configurations that maven read and parsed 2394 times. I added a simple
> HashMap cache to return the already parsed configuration. Note that this
> suggest a lot of inefficiency in the maven code itself.
> b. ComponentValueSetter is used to set values in Mojos. It is created per
> field and always tries to find the field again. This showed high during
> profiling. I implemented a cache but I'm not sure whether this matters much
> c. in plexus, component discovery is done a lot of times - every time a jar
> is added to the container after it is started. this does a lot of xml
> parsing. I added code to disable component discovery temporarily and start it
> again. I call it from DefaultLifecycleExecutor.findExtensions at the start
> and end of the method. Also from
> DefaultPluginManager.ensurePluginContainerIsComplete.
> d. in DefaultRepositoryMetadataManager the function readMetadata always loads
> the metadata file and parses it. I have added a cache (although without
> paying attention to timestamps)
> Also, I ran java with the flags -client -dsa -da -Xnoclassgc -Xbatch -Xincgc.
> This shaved 3 seconds.
> All the above steps caused the time to drop to 8 seconds. Meaning 3 seconds
> due to JVM flags and 7 seconds of actions that could easily be avoided.
> There are other issues which are harder to tackle:
> 1. profiling shows that Xpp3DomBuilder is called a lot of times. Since it is
> called with a Reader/InputStream I can't easily implement a cache here.
> 2. jar files are always created and always installed. unlike the above
> actions, where the files were in the buffer cache, here actual IO occurs.
--
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] Commented: (MNG-3586) jaxws mojo wsgen failure with maven 2.1
[
http://jira.codehaus.org/browse/MNG-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141020#action_141020
]
Henri Gomez commented on MNG-3586:
--
Hi to all,
I take a look at the jaxws-maven-plugin and found this in its pom :
default-tools.jar
java.vendor
Sun Microsystems Inc.
com.sun
tools
1.5.0
system
${java.home}/../lib/tools.jar
System scope and path are deprecated in maven 2.1 ?
Regards
> jaxws mojo wsgen failure with maven 2.1
>
>
> Key: MNG-3586
> URL: http://jira.codehaus.org/browse/MNG-3586
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
>Affects Versions: 2.1
> Environment: Windows XP / Java 5 or 6
>Reporter: Henri Gomez
>Assignee: Brett Porter
> Fix For: 2.1-alpha-1
>
> Attachments: pom.xml, sample-wsgen-fixed.zip, sample-wsgen.zip
>
>
> I can build jar projects using the jaxws wsgen mojo (1.9) under maven
> 2.0.x but it failed under m2eclipse (0.9.3) when using maven 2.1
> embedded (it works if I switch m2eclipse to use the maven 2.0.9 on my
> system).
> I tried with various JVM (Sun and IBM 5 and 6) but still got the
> problem with maven 2.1 embedded (maven 2.1-620417 and 2.1-655675):
> error is :
> From file: C:\workspace\xxx-er-go\pom.xml
> Reason: Failed to execute wsgen
> java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174)
> at
> org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
> at
> org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:91)
> at org.codehaus.mojo.jaxws.MainWsGenMojo.execute(MainWsGenMojo.java:14)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:577)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
> at
> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> at
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:903)
> at
> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
> at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:52)
> Any idea or fixes ?
> my pom.xml wsgen is standard :
>
>
>
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
> compile
>
> compile
>
> initialize
>
[jira] Commented: (MNG-3647) Maven performance needs improvement
[ http://jira.codehaus.org/browse/MNG-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141022#action_141022 ] Ittay Dror commented on MNG-3647: - Note: I don't want this issue to become a discussion about a suggestion I made in a comment and not the concrete improvements I wrote in the main description. About the plugins. Think of a scenario where I write a pom.xml for a module where I know there isn't any src/main/resources folder, and hence nothing for the resources plugin to do. What I would want to be able to do is to write in pom.xml something like: org.apache.maven.plugins maven-resources-plugin true maven will then remove this plugin from the lifecycle, and with it the overhead of initializing all objects and data just so the 'execute' doesn't do anything. i fail to see how it goes against pluggability or out-of-the-box. if i do nothing, the plugin runs (maybe print a warning that it has nothing to do and suggest it will be disabled?) > Maven performance needs improvement > --- > > Key: MNG-3647 > URL: http://jira.codehaus.org/browse/MNG-3647 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.8 >Reporter: Ittay Dror > > I have a multi-module project with 40 modules. Running 'install' with no > compilation takes 30 seconds. Running 'compile' takes 18 seconds. This is > very high IMHO. Buildr (written in Ruby - a scripted language) takes 1 > second). In 'compile', adding time measurements to the mojo executions showed > a cumulative time of 4.8 seconds. (Note that I ran maven several times, so > all files are in the buffer cache) > I've profiled the code to find obvious bottlenecks. Here is what I could > easily fix: > a. reading component configuration: in maven-uber jar there are 9 > configurations that maven read and parsed 2394 times. I added a simple > HashMap cache to return the already parsed configuration. Note that this > suggest a lot of inefficiency in the maven code itself. > b. ComponentValueSetter is used to set values in Mojos. It is created per > field and always tries to find the field again. This showed high during > profiling. I implemented a cache but I'm not sure whether this matters much > c. in plexus, component discovery is done a lot of times - every time a jar > is added to the container after it is started. this does a lot of xml > parsing. I added code to disable component discovery temporarily and start it > again. I call it from DefaultLifecycleExecutor.findExtensions at the start > and end of the method. Also from > DefaultPluginManager.ensurePluginContainerIsComplete. > d. in DefaultRepositoryMetadataManager the function readMetadata always loads > the metadata file and parses it. I have added a cache (although without > paying attention to timestamps) > Also, I ran java with the flags -client -dsa -da -Xnoclassgc -Xbatch -Xincgc. > This shaved 3 seconds. > All the above steps caused the time to drop to 8 seconds. Meaning 3 seconds > due to JVM flags and 7 seconds of actions that could easily be avoided. > There are other issues which are harder to tackle: > 1. profiling shows that Xpp3DomBuilder is called a lot of times. Since it is > called with a Reader/InputStream I can't easily implement a cache here. > 2. jar files are always created and always installed. unlike the above > actions, where the files were in the buffer cache, here actual IO occurs. -- 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] Updated: (MAVENUPLOAD-2124) javaparser-1.0.0-bundle.jar
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Liahushevich updated MAVENUPLOAD-2124: --- Attachment: javaparser-1.0.1-bundle.jar 08/Jul/2008: upload javaparser-1.0.1-bundle.jar version only > javaparser-1.0.0-bundle.jar > --- > > Key: MAVENUPLOAD-2124 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2124 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Alexandr Liahushevich > Attachments: javaparser-1.0.0-bundle.jar, > javaparser-1.0.0-bundle.jar, javaparser-1.0.1-bundle.jar > > > From: Julio Gesser [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 2:38 PM > To: Alexandr Liahushevich > Subject: Re: Java 1.5 Parser - request to put sources into the maven > repository > > Helo Alexandr, > yes, you can put this distribution there, but I think you need to put the > license too. > best regards, > Júlio Vilmar Gesser > 2008/6/24 Alexandr Liahushevich <[EMAIL PROTECTED]>: > One more question please. > We are using Maven technology for our projects. > Is it ok for you and your team that we want to put your > javaparser_2008-06-19.jar file in the http://repo1.maven.org/maven2/ central > maven repository? -- 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: (MWAR-162) Building to SMB-directory fails
Building to SMB-directory fails --- Key: MWAR-162 URL: http://jira.codehaus.org/browse/MWAR-162 Project: Maven 2.x War Plugin Issue Type: Bug Environment: XP Reporter: Eero Anttila mvn war:exploded with a pom.xml configuration wich has a build directory on smb share won't work anymore. \\mySmbshare\deploy ... This feature is handy when deploying directly to tomcat over a smb-share. It used to work in previous version. Here's the stack trace: [INFO] Exploding webapp [INFO] Assembling webapp[XXX] in [\\XXX\XXX] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) at org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) at org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:4 8) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:443) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:371) at org.apache.maven.plugin.war.WarExplodedMojo.execute(WarExplodedMojo.java:41) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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
[jira] Updated: (MPIR-111) Make Classifier and Optional column in dependencies report "optional" in the renderer
[ http://jira.codehaus.org/browse/MPIR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MPIR-111: - Summary: Make Classifier and Optional column in dependencies report "optional" in the renderer (was: Make Classifier and Optional column in dependies report "optional" in the renderer) > Make Classifier and Optional column in dependencies report "optional" in the > renderer > - > > Key: MPIR-111 > URL: http://jira.codehaus.org/browse/MPIR-111 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Vincent Siveton > Fix For: 2.1 > > > Actually, Classifier and Optional columns are always presents. It should be > better to add them only if they have different 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
[jira] Created: (DOXIA-247) unable to parse document when the last character is '}'
unable to parse document when the last character is '}'
---
Key: DOXIA-247
URL: http://jira.codehaus.org/browse/DOXIA-247
Project: Maven Doxia
Issue Type: Bug
Affects Versions: 1.0-alpha-11
Reporter: David Delbecq
When last character of a document is '}', maven doxia issues a, array out of
bound exception. It tries to get next character to find out if we found a '}}'
pair, but doesn't check bounds of document:
{code}
org.apache.maven.doxia.parser.ParseException: String index out of range: 14
at
org.apache.maven.doxia.module.confluence.ConfluenceParser.parse(ConfluenceParser.java:139)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
range: 14
at java.lang.String.charAt(String.java:558)
at
org.apache.maven.doxia.module.confluence.parser.ParagraphBlockParser.visit(ParagraphBlockParser.java:134)
at
org.apache.maven.doxia.module.confluence.ConfluenceParser.parse(ConfluenceParser.java:103)
at
org.apache.maven.doxia.module.confluence.ConfluenceParser.parse(ConfluenceParser.java:131)
{code}
testcase:
{code:title=AppTest.java|borderStyle=solid}
package org.apache.doxia.test.BUGTestCase;
import java.io.StringReader;
/**
* Unit test for simple App.
*/
public class AppTest
extends TestCase
{
/**
* Create the test case
*
* @param testName name of the test case
*/
public AppTest( String testName )
{
super( testName );
}
/**
* @return the suite of tests being tested
*/
public static Test suite()
{
return new TestSuite( AppTest.class );
}
/**
* Rigourous Test :-)
* @throws ParseException
*/
public void testEndBracket() throws ParseException
{
String document = "Test" +
"\n\n* list1"+
"\n\n* list2"+
"\n\n* list2"+
"\n{pre}123{/pre}";
StringWriter writer = new StringWriter();
ConfluenceParser parser = new ConfluenceParser();
XhtmlSink sink = new XhtmlSink(writer);
/* parsing with additional space at end works*/
parser.parse(new StringReader(document+" "), sink);
assertTrue("generated document should have a size
>0",writer.toString().length()>0);
/* parsing with document ending in } fails*/
try{
parser.parse(new StringReader(document), sink);
} catch (Exception e){
e.printStackTrace();
fail("parsing with document ending in } should not
fails");
}
assertTrue("generated document should have a size
>0",writer.toString().length()>0);
}
/**
* Rigourous Test :-)
* @throws ParseException
*/
public void testEndBracketInList() throws ParseException
{
String document1 = "Test" +
"\n\n* list1"+
"\n\n* list2"+
"\n\n* list2{pre}123{/pre} "+
"\n123";
String document2 = "Test" +
"\n\n* list1"+
"\n\n* list2"+
"\n\n* list2{pre}123{/pre}"+
"\n123";
StringWriter writer = new StringWriter();
ConfluenceParser parser = new ConfluenceParser();
XhtmlSink sink = new XhtmlSink(writer);
/* parsing with additional space at end of list item works*/
parser.parse(new StringReader(document1), sink);
assertTrue("generated document should have a size
>0",writer.toString().length()>0);
/* parsing with end of list item ending in } fails*/
try{
parser.parse(new StringReader(document2), sink);
} catch (Exception e){
e.printStackTrace();
fail("parsing with end of list item ending in } should
not fails");
}
assertTrue("generated document should have a size
>0",writer.toString().length()>0);
}
}
{code}
--
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] Commented: (MECLIPSE-459) missing artifact references with pde mode enabled
[ http://jira.codehaus.org/browse/MECLIPSE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141038#action_141038 ] Gopalakrishnan U commented on MECLIPSE-459: --- Oops! Just figured out that the patch doesn't work. needs more work. > missing artifact references with pde mode enabled > - > > Key: MECLIPSE-459 > URL: http://jira.codehaus.org/browse/MECLIPSE-459 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path, PDE > support >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1 > Environment: Maven version: 2.0.9 > Java version: 1.5.0_11 > OS name: "linux" version: "2.6.15-51-686" arch: "i386" Family: "unix" >Reporter: Benjamin Voigt >Priority: Critical > Attachments: pde_dep_missing.zip > > > Some artifacts are not referenced after executing mvn eclipse:eclipse and > having pde mode enabled. The strange thing is, that this does only happen for > particluar versions of an artifact. > Two artifacts that I found with this problem are jetty (org.mortbay.jetty) > and slf4j-log4j12 (org.slf4j-log4j12). Jetty versions beyond 6.1.5 work with > pde enabled, higher versions do not. Same for slf4j-log4j12 versions =< 1.1.0. > Attached is an example project demonstrating the problem. Turn pde mode > on/off in the pom and execute mvn eclipse:eclipse. -- 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] Closed: (MPIR-111) Make Classifier and Optional column in dependencies report "optional" in the renderer
[ http://jira.codehaus.org/browse/MPIR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-111. Assignee: Vincent Siveton Resolution: Fixed fixed in r674775, snapshot deployed > Make Classifier and Optional column in dependencies report "optional" in the > renderer > - > > Key: MPIR-111 > URL: http://jira.codehaus.org/browse/MPIR-111 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.1 > > > Actually, Classifier and Optional columns are always presents. It should be > better to add them only if they have different 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
[jira] Created: (MPIR-112) Dependency Listings is too big
Dependency Listings is too big -- Key: MPIR-112 URL: http://jira.codehaus.org/browse/MPIR-112 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependencies Affects Versions: 2.1 Reporter: Vincent Siveton Fix For: 2.1 We need to reduce the size of the Dependency Listings. -- 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] Updated: (MPIR-112) Dependency Listings is too big
[ http://jira.codehaus.org/browse/MPIR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MPIR-112: - Fix Version/s: 2.1 > Dependency Listings is too big > -- > > Key: MPIR-112 > URL: http://jira.codehaus.org/browse/MPIR-112 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement > Components: dependencies >Affects Versions: 2.1 >Reporter: Vincent Siveton > Fix For: 2.1 > > > We need to reduce the size of the Dependency Listings. -- 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-2141) Updated version of JSON Java code from www.json.org
Updated version of JSON Java code from www.json.org --- Key: MAVENUPLOAD-2141 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2141 Project: Maven Upload Requests Issue Type: Wish Reporter: Michael Tamm There have been some changes since the last release: http://repo1.maven.org/maven2/org/json/json/20070829 -- 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] Commented: (MNG-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141086#action_141086 ] Alexandre Sauve commented on MNG-2205: -- I think that 'provided' transitive dependencies are important! The case that comes to my mind is OSGi and Eclipse development. You need a certain class/package in order to compile your code; however that same package will be available on the runtime environment as a bundle. You don't want to start adding this jar as an embed library into your bundle! You want to embed only those that are runtime/compile dependencies. However since 'provided' is NOT transitive you would have to list all the dependencies this bundle you depend on has in your POM! Not exactly a step forward from Maven 1. You would like to pull in these bundle dependencies just for the need of compilation (and actually you would what them in the manifest file too). So in the end for OSGi and Eclipse transitive provided dependencies would be a really nice thing to have! > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 2.1 > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- 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] Updated: (MNG-2873) Unable to find transitive dependencies when they have been relocated.
[ http://jira.codehaus.org/browse/MNG-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-2873: Fix Version/s: (was: 2.0.10) 2.0.11 pushing this until we can get a test to reliably reproduce it. > Unable to find transitive dependencies when they have been relocated. > - > > Key: MNG-2873 > URL: http://jira.codehaus.org/browse/MNG-2873 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre > Fix For: 2.0.11 > > > I have two projects A and B. Project A is dependent on B. Project B has > compile time on project C which is deployed to a repository, repository1. > The newest version, 2.0, of project C has since been relocated from > oldGroupId to newGroupId. The relocation POMs are working correctly and > Project B is able to be built successfully. Project A is not dependent on > anything from repository1 it does not list that repository in its own > section. When building project A, it tries to resolve the > dependencies of B which includes C. However I am currently getting errors > when it tries to resolve the C. Below is an example of this error occurring. > As you can see the list of remote repositories does not display repository1 > as one of the repositories that was checked despite the fact that Project B > listed it in its POM. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > No versions are present in the repository for the artifact with a range [1,) > oldGroupId:projectC:jar:null > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > repo2 (http://repo.some-repo.com/repo) > If I change project B to not use a range but to instead depend on a > non-relocated version of project C everything works fine and I do not get > this issue at all. The other and more correct solution to this issue is to > update project B to use the new groupIds however it forces me to release > project B immediately since all older released versions of B are broken by > using the old groupIds an this issue. -- 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] Work started: (MNG-3654) [regression] unable to build ServiceMix 3 - IndexOutOfBoundsException in mergeDeterministicBuildElements
[ http://jira.codehaus.org/browse/MNG-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3654 started by John Casey. > [regression] unable to build ServiceMix 3 - IndexOutOfBoundsException in > mergeDeterministicBuildElements > > > Key: MNG-3654 > URL: http://jira.codehaus.org/browse/MNG-3654 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10, 2.1-alpha-1 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.0.10, 2.1-alpha-1 > > > in https://svn.apache.org/repos/asf/servicemix/smx3/trunk, run mvn compile. > Result (before build begins): > java.lang.IndexOutOfBoundsException: Index: 3, Size: 3 > at java.util.ArrayList.RangeCheck(ArrayList.java:546) > at java.util.ArrayList.get(ArrayList.java:321) > at > org.apache.maven.project.DefaultMavenProjectBuilder.mergeDeterministicBuildElements(DefaultMavenProjectBuilder.java:1112) > at > org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:998) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:879) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:507) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:199) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:576) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:459) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:532) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:532) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:363) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:127) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) -- 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] Commented: (MDOCCK-12) @Override let QDOX fail for this plugin
[ http://jira.codehaus.org/browse/MDOCCK-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141093#action_141093 ] Dennis Lundberg commented on MDOCCK-12: --- Can you give us a sample file that we can use for testing? > @Override let QDOX fail for this plugin > --- > > Key: MDOCCK-12 > URL: http://jira.codehaus.org/browse/MDOCCK-12 > Project: Maven 2.x Documentation Checker Plugin > Issue Type: Bug >Affects Versions: 1.0-beta-2 > Environment: Win XP >Reporter: MTStorm >Priority: Minor > > The plugin fails when QDox hit @Override. Here is the stacktrace: > [INFO] Trace > com.thoughtworks.qdox.parser.ParseException: syntax error @[33,5] in ...my > java file > at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) > at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) > at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) > at > com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:296) > at > com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:312) > at > com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:308) > at > com.thoughtworks.qdox.JavaDocBuilder$1.visitFile(JavaDocBuilder.java:365) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) > at > com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52) > at > com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:362) > at > org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:477) > at > org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) > at > org.apache.maven.plugin.docck.CheckPluginDocumentationMojo.checkPackagingSpecificDocumentation(CheckPluginDocumentationMojo.java:67) > at > org.apache.maven.plugin.docck.AbstractCheckDocumentationMojo.checkProject(AbstractCheckDocumentationMojo.java:319) > at > org.apache.maven.plugin.docck.AbstractCheckDocumentationMojo.execute(AbstractCheckDocumentationMojo.java:149) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > 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: 12 seconds > [INFO] Finished at: Wed Jun 04 10:40:35 CEST 2008 > [INFO] Final Memory: 10M/19M > [INFO] > -
[jira] Created: (MAVENUPLOAD-2142) Rsync XCluder repo
Rsync XCluder repo -- Key: MAVENUPLOAD-2142 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2142 Project: Maven Upload Requests Issue Type: Wish Reporter: Manos Batsis Attachments: gr.abiss.xcluder.sh Attached an sh script to rsync the xcluder release repo to maven central. Thanks! Manos -- 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] Closed: (MNG-3654) [regression] unable to build ServiceMix 3 - IndexOutOfBoundsException in mergeDeterministicBuildElements
[ http://jira.codehaus.org/browse/MNG-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3654. --- Resolution: Fixed > [regression] unable to build ServiceMix 3 - IndexOutOfBoundsException in > mergeDeterministicBuildElements > > > Key: MNG-3654 > URL: http://jira.codehaus.org/browse/MNG-3654 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10, 2.1-alpha-1 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.0.10, 2.1-alpha-1 > > > in https://svn.apache.org/repos/asf/servicemix/smx3/trunk, run mvn compile. > Result (before build begins): > java.lang.IndexOutOfBoundsException: Index: 3, Size: 3 > at java.util.ArrayList.RangeCheck(ArrayList.java:546) > at java.util.ArrayList.get(ArrayList.java:321) > at > org.apache.maven.project.DefaultMavenProjectBuilder.mergeDeterministicBuildElements(DefaultMavenProjectBuilder.java:1112) > at > org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:998) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:879) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:507) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:199) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:576) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:459) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:532) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:532) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:363) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:127) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) -- 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] Work started: (MNG-3511) Review fix for MNG-2166
[
http://jira.codehaus.org/browse/MNG-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-3511 started by John Casey.
> Review fix for MNG-2166
> ---
>
> Key: MNG-3511
> URL: http://jira.codehaus.org/browse/MNG-3511
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
>Priority: Minor
> Fix For: 2.0.10
>
> Attachments: no-goal-help.patch
>
>
> As requested by Brett in MNG-3276, here a new issue. My relevant comment over
> at the other issue:
> I still consider the output from Maven quite unhelpful in this case. Please
> consider that Maven is just a tool/utility for developers and hence not
> everybody out there will spend time to get through the documentation. Some
> peoply simply want to "use" Maven, not understand how it works.
> The Ant scripts that I am trying to replace in our organization all provided
> some help about the current project and the available targets using the echo
> task when the default target was executed. This allowed newbies to quickly
> figure out how to perform build steps without ever reading the Ant manual.
> Surely, once you know Maven's lifecycle you never need such help targets but
> especially old Ant geeks need some easy way of migrating into Maven land.
> The attached patch should provide the following console output:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO]
> You must specify at least one goal or lifecycle phase to perform build steps.
> The following list illustrates some commonly used build commands:
> mvn clean
> Deletes any build output (e.g. class files or JARs).
> mvn test
> Runs the unit tests for the project.
> mvn install
> Copies the project artifacts into your local repository.
> mvn deploy
> Copies the project artifacts into the remote repository.
> mvn site
> Creates project documentation (e.g. reports or Javadoc).
> Please see
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> for a complete description of available lifecycle phases.
> Use "mvn -?" to show general usage information about Maven's command line.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Oct 22 20:48:42 EDT 2007
> [INFO] Final Memory: 1M/4M
> [INFO]
>
> {noformat}
> This output is intended to show further comon use-cases than just "install".
> Besides, the user is pointed to a concrete URL with helpful information for
> his actual need (personally, I consider pointing people at home pages as
> helpful as telling to use Google... information should be found, not searched)
--
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] Closed: (MNG-3511) Review fix for MNG-2166
[
http://jira.codehaus.org/browse/MNG-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3511.
---
Resolution: Fixed
Fix Version/s: 2.1-alpha-1
> Review fix for MNG-2166
> ---
>
> Key: MNG-3511
> URL: http://jira.codehaus.org/browse/MNG-3511
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
> Attachments: no-goal-help.patch
>
>
> As requested by Brett in MNG-3276, here a new issue. My relevant comment over
> at the other issue:
> I still consider the output from Maven quite unhelpful in this case. Please
> consider that Maven is just a tool/utility for developers and hence not
> everybody out there will spend time to get through the documentation. Some
> peoply simply want to "use" Maven, not understand how it works.
> The Ant scripts that I am trying to replace in our organization all provided
> some help about the current project and the available targets using the echo
> task when the default target was executed. This allowed newbies to quickly
> figure out how to perform build steps without ever reading the Ant manual.
> Surely, once you know Maven's lifecycle you never need such help targets but
> especially old Ant geeks need some easy way of migrating into Maven land.
> The attached patch should provide the following console output:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO]
> You must specify at least one goal or lifecycle phase to perform build steps.
> The following list illustrates some commonly used build commands:
> mvn clean
> Deletes any build output (e.g. class files or JARs).
> mvn test
> Runs the unit tests for the project.
> mvn install
> Copies the project artifacts into your local repository.
> mvn deploy
> Copies the project artifacts into the remote repository.
> mvn site
> Creates project documentation (e.g. reports or Javadoc).
> Please see
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> for a complete description of available lifecycle phases.
> Use "mvn -?" to show general usage information about Maven's command line.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Oct 22 20:48:42 EDT 2007
> [INFO] Final Memory: 1M/4M
> [INFO]
>
> {noformat}
> This output is intended to show further comon use-cases than just "install".
> Besides, the user is pointed to a concrete URL with helpful information for
> his actual need (personally, I consider pointing people at home pages as
> helpful as telling to use Google... information should be found, not searched)
--
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] Commented: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141113#action_141113 ] M. Rohrmoser commented on MSITE-159: Workaround: replace one of the characters of the external/absolute URL with it's url-encoded form, e.g. a . (dot) within the servername with %2e. This seems to prevent substitution. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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] Commented: (MASSEMBLY-144) wont put files in top level directory
[
http://jira.codehaus.org/browse/MASSEMBLY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141116#action_141116
]
Basil James Whitehouse III commented on MASSEMBLY-144:
--
I think this has to do with includeBaseDirectory being false and the output
directory being / .
A workaround that I discovered is to set the output directory to . (dot):
{code:xml}
bug-example
zip
false
TODO.txt
.
{code}
> wont put files in top level directory
> -
>
> Key: MASSEMBLY-144
> URL: http://jira.codehaus.org/browse/MASSEMBLY-144
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP using maven 2.0.4. I think I am using
> assembly 2.1 as that is the only version I could find in my ~/.m2 directory.
>Reporter: Alan Kent
>Assignee: John Casey
>Priority: Minor
> Fix For: 2.2-beta-1
>
>
> I am relatively new to Maven so hopefully this is not a silly mistake, but
> the following assembly XML file will NOT include the TODO.txt file. If you
> put the file into a subdirectory (using
> a/b/c or by setting
> true) then the file will appear
> in the ZIP file. This is at least non-intuitive, but feels like a bug to me.
>
> bug-example
>
> zip
>
> false
>
>
> TODO.txt
> /
>
>
>
--
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: (MARTIFACT-29) DefaultWagonManager checks all remote repositories
DefaultWagonManager checks all remote repositories -- Key: MARTIFACT-29 URL: http://jira.codehaus.org/browse/MARTIFACT-29 Project: Maven Artifact Issue Type: Bug Affects Versions: 3.0-alpha-1 Reporter: Igor Fedorenko Attachments: martifact-unecessary-remote-lookup.diif DefaultWagonManager will attempt to download artifact from all remote repositories even if the artifact is available from the first repository. -- 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] Updated: (MARTIFACT-29) DefaultWagonManager checks all remote repositories
[ http://jira.codehaus.org/browse/MARTIFACT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MARTIFACT-29: --- Fix Version/s: 3.0-alpha-1 > DefaultWagonManager checks all remote repositories > -- > > Key: MARTIFACT-29 > URL: http://jira.codehaus.org/browse/MARTIFACT-29 > Project: Maven Artifact > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Igor Fedorenko >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > Attachments: martifact-unecessary-remote-lookup.diif > > > DefaultWagonManager will attempt to download artifact from all remote > repositories even if the artifact is available from the first repository. -- 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] Closed: (MARTIFACT-29) DefaultWagonManager checks all remote repositories
[ http://jira.codehaus.org/browse/MARTIFACT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MARTIFACT-29. -- Resolution: Fixed > DefaultWagonManager checks all remote repositories > -- > > Key: MARTIFACT-29 > URL: http://jira.codehaus.org/browse/MARTIFACT-29 > Project: Maven Artifact > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Igor Fedorenko >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > Attachments: martifact-unecessary-remote-lookup.diif > > > DefaultWagonManager will attempt to download artifact from all remote > repositories even if the artifact is available from the first repository. -- 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] Commented: (MARTIFACT-29) DefaultWagonManager checks all remote repositories
[ http://jira.codehaus.org/browse/MARTIFACT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141132#action_141132 ] Jason van Zyl commented on MARTIFACT-29: Patch applied. > DefaultWagonManager checks all remote repositories > -- > > Key: MARTIFACT-29 > URL: http://jira.codehaus.org/browse/MARTIFACT-29 > Project: Maven Artifact > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Igor Fedorenko >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > Attachments: martifact-unecessary-remote-lookup.diif > > > DefaultWagonManager will attempt to download artifact from all remote > repositories even if the artifact is available from the first repository. -- 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] Work started: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3380 started by John Casey. > MavenMetadataSource retrieves ResolutionGroup without consulting > ManagedVersionMap, is problem when relocation > -- > > Key: MNG-3380 > URL: http://jira.codehaus.org/browse/MNG-3380 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: luke w patterson >Assignee: John Casey > Fix For: 2.0.10 > > Attachments: MNG-3380-integration-test.zip, > MNG-3380-maven-artifact.patch, patch.txt, repo.zip > > > Consider the following scenario: > > 4.0.0 > root-groupId > root-artifactId > 1 > > > direct-dependency-groupId > direct-dependency-artifactId > 1 > > > > > > transitive-dependency-new-groupId > transitive-dependency-artifactId > 2 > > > > > > 4.0.0 > direct-dependency-groupId > direct-dependency-artifactId > 1 > > > transitive-dependency-old-groupId > transitive-dependency-artifactId > 1 > > > > > > 4.0.0 > transitive-dependency-old-groupId > transitive-dependency-artifactId > 1 > > > transitive-dependency-new-groupId > > > > > 4.0.0 > transitive-dependency-new-groupId > transitive-dependency-artifactId > 1 > > > other-groupId > other-artifactId-a > 1 > > > > > 4.0.0 > transitive-dependency-new-groupId > transitive-dependency-artifactId > 2 > > > other-groupId > other-artifactId-a > 1 > > > other-groupId > other-artifactId-b > 1 > > > > > -- > actual dependency:tree > > root-groupId:root-artifactId:jar:1 > \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile > \- > transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile > (version managed from 1) >\- other-groupId:other-artifactId-a:jar:1:compile > -- > expected dependency:tree > > root-groupId:root-artifactId:jar:1 > \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile > \- > transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile > (version managed from 1) >\- other-groupId:other-artifactId-a:jar:1:compile >\- other-groupId:other-artifactId-b:jar:1:compile <-- missing from > actual result > -- > > As you can see from the listing above, > other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency > list. > I have attached the zipped repo which was used when generating the > dependency:tree listings shown above. I also attached a crude temporary > patch which my team is currently using to resolve this issue. After ignoring > whitespace changes, it is about 10 lines different. > Thanks, > Luke -- 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] Closed: (MAVENUPLOAD-2105) Uploading proguard 4.2 to The Central Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2105. --- Assignee: Carlos Sanchez Resolution: Fixed > Uploading proguard 4.2 to The Central Repository > > > Key: MAVENUPLOAD-2105 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2105 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Vlad Skarzhevskyy >Assignee: Carlos Sanchez > > Please Upload the latest version to Repository. The last version (posted by > me) in repository is 4.1 > http://pyx4j.com/downloads/proguard-4.2-bundle.jar > http://proguard.sourceforge.net/ > ProGuard is a free Java class file shrinker, optimizer, and obfuscator. It > removes unused classes, fields, methods, and attributes. It then optimizes > the bytecode. It then renames the remaining classes, fields, and methods > using short meaningless names. Finally, it preverifies the processed code for > Java 6 or for Java Micro Edition. > Changes in 4.2: > * Refined data flow analysis in optimization step. > * Fixed handling of exceptions when inlining subroutines. > * Fixed inlining of incompatible code constructs between different java > versions. > * Fixed computation of local variable frame size. > * Fixed optimization of infinite loops. > * Fixed optimization of subroutine invocations. > * Fixed optimization of floating point remainder computations. > * Fixed removal of unused parameters in method descriptors containing > arrays of longs or doubles. > * Added undocumented java system properties maximum.inlined.code.length > (default is 8) and maximum.resulting.code.length (defaults are 8000 for JSE > and 2000 for JME), for expert users who read release notes. > * Fixed processing of generic types in Signature attributes in shrinking > and optimization steps. > * Fixed processing of inner class names in Signature attributes in > obfuscation step. > * Improved adapting resource file names following obfuscated class names. > * Fixed interpretation of package names in GUI. > * Fixed default settings for Xlets in GUI. > * Updated documentation and examples. -- 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] Closed: (MAVENUPLOAD-2133) Please add jpp to repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2133. --- Assignee: Carlos Sanchez Resolution: Fixed > Please add jpp to repository > > > Key: MAVENUPLOAD-2133 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2133 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Ivan Szkiba >Assignee: Carlos Sanchez > > "net.sourceforge.jpp","[EMAIL > PROTECTED]:/home/groups/j/jp/jpp/repository/release","rsync_ssh","Ivan > Szkiba","[EMAIL PROTECTED]",, -- 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] Closed: (MAVENUPLOAD-2116) Please add MigLayout to the auto rsynced list.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2116. --- Assignee: Carlos Sanchez Resolution: Fixed > Please add MigLayout to the auto rsynced list. > -- > > Key: MAVENUPLOAD-2116 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2116 > Project: Maven Upload Requests > Issue Type: New Feature >Reporter: Mikael Grev >Assignee: Carlos Sanchez > > "miglayout","rsync://[EMAIL PROTECTED]/maven/releases","rsync",Mikael > Grev,[EMAIL PROTECTED],, > The password is "maven". > MigLayout is a LayoutManager for Swing & SWT. It is the #1 RFE for being > added to SWT and #10 RFE for being added to the Java SDK. > I own MiGInfoCom AB which owns MigLayout. > Cheers, > Mikael Grev -- 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] Commented: (MAVENUPLOAD-2142) Rsync XCluder repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141157#action_141157 ] Carlos Sanchez commented on MAVENUPLOAD-2142: - please check updated instructions at http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Rsync XCluder repo > -- > > Key: MAVENUPLOAD-2142 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2142 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Manos Batsis > Attachments: gr.abiss.xcluder.sh > > > Attached an sh script to rsync the xcluder release repo to maven central. > Thanks! > Manos -- 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] Closed: (MAVENUPLOAD-2108) Uploading antenna 1.0.2 to The Central Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2108. --- Assignee: Carlos Sanchez Resolution: Fixed > Uploading antenna 1.0.2 to The Central Repository > - > > Key: MAVENUPLOAD-2108 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2108 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Vlad Skarzhevskyy >Assignee: Carlos Sanchez > > Please Upload the latest version to Repository. The last version (posted by > me) in repository is 0.9.14 > The antenna project provides a set of Ant tasks for developing J2ME/MIDP > applications based on the J2ME Wireless Toolkit. > Maven plugin exists (j2me-maven-plugin) to use this library in maven build. -- 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] Closed: (MAVENUPLOAD-2113) maven-license-plugin-1.3.1 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2113. --- Assignee: Carlos Sanchez Resolution: Fixed > maven-license-plugin-1.3.1 upload request > - > > Key: MAVENUPLOAD-2113 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2113 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Mathieu Carbou >Assignee: Carlos Sanchez > Attachments: maven-license-plugin-1.3.1-bundle.jar > > > http://maven-license-plugin.googlecode.com/files/maven-license-plugin-1.3.1-bundle.jar > http://code.google.com/p/maven-license-plugin/ > I'm the developer of the maven license plugin, please upload! > Mathieu Carbou. -- 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] Commented: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141159#action_141159 ] John Casey commented on MNG-3380: - This is fixed on the 2.0.x branch, and I've incorporated an integration test based on the MNG-3380-integration-test.zip (I changed it to fail compilation and unit testing, rather than requiring a separate plugin to verify things). The only thing that I need to finish up is the fix for trunk (2.1) before I close this issue. > MavenMetadataSource retrieves ResolutionGroup without consulting > ManagedVersionMap, is problem when relocation > -- > > Key: MNG-3380 > URL: http://jira.codehaus.org/browse/MNG-3380 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.8 >Reporter: luke w patterson >Assignee: John Casey > Fix For: 2.0.10 > > Attachments: MNG-3380-integration-test.zip, > MNG-3380-maven-artifact.patch, patch.txt, repo.zip > > > Consider the following scenario: > > 4.0.0 > root-groupId > root-artifactId > 1 > > > direct-dependency-groupId > direct-dependency-artifactId > 1 > > > > > > transitive-dependency-new-groupId > transitive-dependency-artifactId > 2 > > > > > > 4.0.0 > direct-dependency-groupId > direct-dependency-artifactId > 1 > > > transitive-dependency-old-groupId > transitive-dependency-artifactId > 1 > > > > > > 4.0.0 > transitive-dependency-old-groupId > transitive-dependency-artifactId > 1 > > > transitive-dependency-new-groupId > > > > > 4.0.0 > transitive-dependency-new-groupId > transitive-dependency-artifactId > 1 > > > other-groupId > other-artifactId-a > 1 > > > > > 4.0.0 > transitive-dependency-new-groupId > transitive-dependency-artifactId > 2 > > > other-groupId > other-artifactId-a > 1 > > > other-groupId > other-artifactId-b > 1 > > > > > -- > actual dependency:tree > > root-groupId:root-artifactId:jar:1 > \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile > \- > transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile > (version managed from 1) >\- other-groupId:other-artifactId-a:jar:1:compile > -- > expected dependency:tree > > root-groupId:root-artifactId:jar:1 > \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile > \- > transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile > (version managed from 1) >\- other-groupId:other-artifactId-a:jar:1:compile >\- other-groupId:other-artifactId-b:jar:1:compile <-- missing from > actual result > -- > > As you can see from the listing above, > other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency > list. > I have attached the zipped repo which was used when generating the > dependency:tree listings shown above. I also attached a crude temporary > patch which my team is currently using to resolve this issue. After ignoring > whitespace changes, it is about 10 lines different. > Thanks, > Luke -- 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] Commented: (MNG-3511) Review fix for MNG-2166
[
http://jira.codehaus.org/browse/MNG-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141161#action_141161
]
Paul Benedict commented on MNG-3511:
Is the output in a message resource so it can be localized?
> Review fix for MNG-2166
> ---
>
> Key: MNG-3511
> URL: http://jira.codehaus.org/browse/MNG-3511
> Project: Maven 2
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Assignee: John Casey
>Priority: Minor
> Fix For: 2.0.10, 2.1-alpha-1
>
> Attachments: no-goal-help.patch
>
>
> As requested by Brett in MNG-3276, here a new issue. My relevant comment over
> at the other issue:
> I still consider the output from Maven quite unhelpful in this case. Please
> consider that Maven is just a tool/utility for developers and hence not
> everybody out there will spend time to get through the documentation. Some
> peoply simply want to "use" Maven, not understand how it works.
> The Ant scripts that I am trying to replace in our organization all provided
> some help about the current project and the available targets using the echo
> task when the default target was executed. This allowed newbies to quickly
> figure out how to perform build steps without ever reading the Ant manual.
> Surely, once you know Maven's lifecycle you never need such help targets but
> especially old Ant geeks need some easy way of migrating into Maven land.
> The attached patch should provide the following console output:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO]
> You must specify at least one goal or lifecycle phase to perform build steps.
> The following list illustrates some commonly used build commands:
> mvn clean
> Deletes any build output (e.g. class files or JARs).
> mvn test
> Runs the unit tests for the project.
> mvn install
> Copies the project artifacts into your local repository.
> mvn deploy
> Copies the project artifacts into the remote repository.
> mvn site
> Creates project documentation (e.g. reports or Javadoc).
> Please see
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> for a complete description of available lifecycle phases.
> Use "mvn -?" to show general usage information about Maven's command line.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Oct 22 20:48:42 EDT 2007
> [INFO] Final Memory: 1M/4M
> [INFO]
>
> {noformat}
> This output is intended to show further comon use-cases than just "install".
> Besides, the user is pointed to a concrete URL with helpful information for
> his actual need (personally, I consider pointing people at home pages as
> helpful as telling to use Google... information should be found, not searched)
--
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] Commented: (SUREFIRE-382) TestNG parameterized test failures don't specify parameterized values
[ http://jira.codehaus.org/browse/SUREFIRE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141163#action_141163 ] Dave Meibusch commented on SUREFIRE-382: +1. This is a particular problem when using the @DataProvider annotation with TestNG for generate test data. The generated testng-results.xml file (resolved by SUREFIRE-384) does contain details of the parameters used for each test, just not used in the Surefire HTML report. > TestNG parameterized test failures don't specify parameterized values > - > > Key: SUREFIRE-382 > URL: http://jira.codehaus.org/browse/SUREFIRE-382 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Reporter: Dan Fabulich > Fix For: 2.x > > Attachments: testng-dataProviderFailure.zip > > > TestNG allows tests to accept variable parameters; the test is run multiple > times with multiple parameter values. > http://testng.org/doc/documentation-main.html#parameters > But the parameter values aren't stored in the surefire-reports directory > either in the txt or xml versions, and so they can't show up in the final > report. -- 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
