[jira] Closed: (MNGECLIPSE-66) unable to find artifacts from attached tests
[ http://jira.codehaus.org/browse/MNGECLIPSE-66?page=all ] Eugene Kuleshov closed MNGECLIPSE-66: - Resolution: Fixed Fix Version: 0.0.10 Thanks Ovidio. I verified it with trunk (0.0.10) version and seems working ok here too. > unable to find artifacts from attached tests > > > Key: MNGECLIPSE-66 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-66 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Dependency Resolver > Versions: 0.0.3 > Reporter: Jesper Zedlitz > Assignee: Eugene Kuleshov > Fix For: 0.0.10 > Attachments: mngeclipse_66_install.tar.gz, mngeclipse_66_use.tar.gz > > > I am using attached tests as described here: > http://maven.apache.org/guides/mini/guide-attached-tests.html > Although the test jar is already installed the plugin states it is "Unable to > download the artifact from any repository: > com.myco.app:foo-1.0-SNAPSHOT.test-jar" (using the same name as in the docu > here as example). > In the repository the name of the jar file is > "com.myco.app:foo-1.0-SNAPSHOT-tests.jar". > Maybe just '-' and '.' are mixed up...? -- 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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=all ] Per Olesen updated MSUREFIRE-129: - Attachment: OutOfMemoryError.log > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Priority: Minor > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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: (MNGECLIPSE-71) install goal for multiproject does not discover and act upon submodules
[ http://jira.codehaus.org/browse/MNGECLIPSE-71?page=all ] Eugene Kuleshov closed MNGECLIPSE-71: - Resolution: Fixed Fix Version: 0.0.10 Verifieed in trunk (0.0.10) version. Reactor is working for Maven launched from Eclipse. > install goal for multiproject does not discover and act upon submodules > --- > > Key: MNGECLIPSE-71 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-71 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.4 > Environment: XP sp1, eclipse 3.1.1, plugin from > http://m2eclipse.codehaus.org/ v0.0.4, maven 2.0.2 on my desktop > Reporter: Tom Perry > Assignee: Eugene Kuleshov > Fix For: 0.0.10 > Attachments: MNGECLIPSE-75.patch, spring-acegi-poc.zip > > > first, sorry if this is seen as a double post (I also posted this to the > maven user list). I didn't check this site until recently. > I've built an "M2" task with eclipse External Tools. This task runs install > on a selected project. > when I run this install on a multiproject, none of the subprojects are > discovered, they are not compiled and jars are not installed to my local > repo. The only result is the pom from the parent project is installed to my > local repo. > if I run this "M2" install task on a simple project, it is compiled and it's > jar is installed. > if I run mvn install from a commandline from the eclipse > workspace/multi-project, the subprojects are discovered and compiled and > their jars are installed. so it doesn't appear to be a problem with the > parent and child poms, at least for the installed maven 202. > so I'm turning to this group for help. I tried to subscribe to the user > list, but my email was returned. > thanks in advance > Tom -- 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-2333) Plugins need to offer up all information without executing
[ http://jira.codehaus.org/browse/MNG-2333?page=comments#action_66901 ] Eugene Kuleshov commented on MNG-2333: -- Jason, in a mean time (for short term) it would be enough to get back all the resources and source generated by plugins during Maven execution cycle. So, I can call generate-sources and capture source folders registered by plugins. See sample project mngeclipse-75-xmlbeans-testcase.zip in http://jira.codehaus.org/browse/MNGECLIPSE-75 > Plugins need to offer up all information without executing > -- > > Key: MNG-2333 > URL: http://jira.codehaus.org/browse/MNG-2333 > Project: Maven 2 > Type: New Feature > Components: Embedding > Versions: 2.0.5 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > > > In an IDE environment, you want to know what will be generated by a plugin > without having it execute. For example, if you have a plugin that generates a > source directory you want to know that without having actually execute the > plugin because it can take a long time if you have a lot of plugins. > Another issue will probably have to be created to outline changes to the > plugin api so that external tools can call this method to get all the > information up-front. I couldn't find any related issues. > This should also work when reactor projects are run. > Another example is any plugin that produces resources that need to be added > to the UI. -- 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: (MNGECLIPSE-85) MavenLauncher should be externalized
[ http://jira.codehaus.org/browse/MNGECLIPSE-85?page=all ] Eugene Kuleshov closed MNGECLIPSE-85: - Resolution: Won't Fix > MavenLauncher should be externalized > > > Key: MNGECLIPSE-85 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-85 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Components: Maven Launcher > Versions: 0.0.5 > Reporter: Thorsten Kamann > Assignee: Eugene Kuleshov > Attachments: AbstractMavenLauncher.java, DefaultMavenLauncher.java, > ExecutePomAction.java.patch, IMavenLauncher.java, launcher.patch, > screenshot-1.jpg > > > The MavenLauncher is included in the ExecutePomAction. To allow other views > to use this launcher I want to extract the code in a seperate class. -- 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: (MNGECLIPSE-89) Compile goal fails with exception
[ http://jira.codehaus.org/browse/MNGECLIPSE-89?page=all ] Eugene Kuleshov closed MNGECLIPSE-89: - Resolution: Won't Fix As already mentioned in comments this is because maven expect to find tools.jar to when compiling java code. Launcher should be using JDK and not JRE. > Compile goal fails with exception > - > > Key: MNGECLIPSE-89 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-89 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Maven Launcher > Versions: 0.0.5 > Environment: Windows XP, Eclipse 3.1.2 > Reporter: Dale King > Assignee: Eugene Kuleshov > > > Used archetype to generate project as specified in Maven documentation and > use that generated folder as Eclipse project. Enable Maven for the project. > Can build from the command line, but trying to compile from Maven in Eclipse > fails: > [INFO] > > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [clean, compile] > [INFO] > > [INFO] clean:clean > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\classes > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\test-classes > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > Compiling 1 source file to C:\EclipseWorkspace\my-app\target\classes > [ERROR] mojo-execute : compiler:compile > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : com.mycompany.app:my-app:jar:1.0-SNAPSHOT ( > task-segment: [clean, compile] ) > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 8 more > Here is the command line output from doing the same thing: > C:\EclipseWorkspace\my-app>mvn clean compile > [INFO] Scanning for projects... > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [clean, compile] > [INFO] > - > --- > [INFO] [clean:clean] > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\classes > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > Compiling 1 source file to C:\EclipseWorkspace\my-app\target\classes > [INFO] > - > --- > [INFO] BUILD SUCCESSFUL > [INFO] > - > --- > [INFO] Total time: 7 seconds > [INFO] Finished at: Tue Mar 21 20:38:54 EST 2006 > [INFO] Final Memory: 2M/8M > [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/jir
[jira] Commented: (MNG-2350) tag is ignored for plugins in the section of the POM
[ http://jira.codehaus.org/browse/MNG-2350?page=comments#action_66903 ] Gunther Popp commented on MNG-2350: --- I moved the site plugin from / to / and now it works as expected. However, the example in the guide (http://maven.apache.org/plugins/maven-site-plugin/howto.html) places the plugin explicitly in the / section of the pom. This should be changed, IMO. And please note that the site-plugin works perfectly when it is configured in the section (e.g. changing the outputEncoding works fine). Only the tag is ignored in this case. IMO, Maven should report an error or at least a warning when the site-plugin is placed in the wrong section of the POM. > tag is ignored for plugins in the section of the POM > -- > > Key: MNG-2350 > URL: http://jira.codehaus.org/browse/MNG-2350 > Project: Maven 2 > Type: Bug > Components: Sites & Reporting > Versions: 2.0.4 > Environment: Windows XP > Reporter: Gunther Popp > > > A version defined for a plugin in the section of the POM is > ignored. For example, I would expect that the following definition in a POM > forces the usage of version 2.0-beta-4 of the site-plugin: > > ... > > > > org.apache.maven.plugins > maven-site-plugin > 2.0-beta-4 > > ... > However, Maven always uses the newer version 2.0-beta-5: > >mvn site -X > + Error stacktraces are turned on. > Maven version: 2.0.4 > ... > [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for > updates from central > [DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository > central > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.pom > 2/2K > 2K downloaded > [DEBUG] Artifact resolved > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for > project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: > org.apache.maven.plugins:maven-plugins:pom:1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.maven:maven-parent:pom:1 from the repository. > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.jar > 52K downloaded > [DEBUG] Artifact resolved > ... > It doesn´t matter, if the plugin already exists in the local repostitory or > not. -- 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: (MNGECLIPSE-92) Build path for resource directories should be 'exclude all'
[ http://jira.codehaus.org/browse/MNGECLIPSE-92?page=comments#action_66904 ] Eugene Kuleshov commented on MNGECLIPSE-92: --- Brad, if you want to take this and implement suggested approach for adding resources folders as class folders I would be able to take patch. See Java Buld Path -> Libraries -> Add Class Folder (that is in Eclipse 3.2 UI, in 3.1 it could be slightlu different, though structure of .classpath is the same). BTW, personally I like that folders for resources appear as packages, so they are flatened by Eclipse in Package Explorer... > Build path for resource directories should be 'exclude all' > --- > > Key: MNGECLIPSE-92 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-92 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Reporter: Brad Davis > Assignee: Eugene Kuleshov > Priority: Minor > Attachments: mvn2ide.patch > > > when you update the source folders in eclipse, resource folders are placed on > the build path in a naive manner. While they should be on the build path so > that running and debugging in eclipse places them in the class path, they > should have an exclude pattern of exclude all, so that any java files within > them will not be compiled and so that directories within the resources > folders will not appear as packages. > Attached is a patch that corrects 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
[jira] Closed: (MNGECLIPSE-109) dependencies order
[ http://jira.codehaus.org/browse/MNGECLIPSE-109?page=all ] Eugene Kuleshov closed MNGECLIPSE-109: -- Resolution: Won't Fix Dependencies appear in the same order as being resolved by Maven. Reordering then will have impact on classpath (e.g. which classes/jars to use first). > dependencies order > -- > > Key: MNGECLIPSE-109 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-109 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Environment: Eclipse 3.1.2, m2eclipse 0.0.5, maven 2.0.4, Windows 2000 and > Ubuntu 5.10, JDK 1.5 > Reporter: David Rabinowitz > Assignee: Eugene Kuleshov > Priority: Trivial > > > Is it possible to order the dependecies in the .classpath by alphabetic > order? It will make finding dependecies in the project much easier. -- 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: (MNGECLIPSE-108) Exception is thrown when enabling the m2eclipse nature to the project
[ http://jira.codehaus.org/browse/MNGECLIPSE-108?page=comments#action_66906 ] Eugene Kuleshov commented on MNGECLIPSE-108: Do you mind to attach complete eclipse project that would allow to reproduce issue? Otherwise I would have to close issue as not reproduceable... > Exception is thrown when enabling the m2eclipse nature to the project > - > > Key: MNGECLIPSE-108 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-108 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.5 > Environment: Eclipse 3.1.2, m2eclipse 0.0.5, maven 2.0.4, Windows 2000 and > Ubuntu 5.10, JDK 1.5 > Reporter: David Rabinowitz > Assignee: Eugene Kuleshov > > > When enabling the Maven 2 nature on the project, the log (in teh console) > ends with the line "Can't enable nature Java Model Exception: Java Model > Status [Build path contains duplicate entry: 'C:Documents and > Settings/david/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar' > for project xxx]" > Same problem happened on ubuntu, that time it was the junit 3.8.1 who > triggered the error. > The nature is enabled, but all the dependecies can be seen directly under the > project (and not under "Maven 2 dependecies"). > My dependencies: > > > org.springframework > spring-webmvc > 1.2.6 > > > org.springframework > spring-mock > 1.2.6 > > > opensymphony > sitemesh > 2.2.1 > > > javax.servlet > servlet-api > 2.3 > > > log4j > log4j > 1.2.13 > > > c3p0 > c3p0 > 0.9.0.2 > > -- 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: (MNGECLIPSE-110) Documentation in general
[ http://jira.codehaus.org/browse/MNGECLIPSE-110?page=all ] Eugene Kuleshov updated MNGECLIPSE-110: --- Version: (was: 1.0.0) There are couple flash demos available on plugin site at http://m2eclipse.codehaus.org/ > Documentation in general > > > Key: MNGECLIPSE-110 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-110 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Documentation > Reporter: jeremie granat > Assignee: Eugene Kuleshov > Priority: Minor > > > I couldn't find any real documentation on what the plug in could do and what > it could not. I think some documentation should be created before the release > of 1.0.0. > - How to's > - What functions are in the plug in > - What functions are not in the plug in -- 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: (MRM-100) Make ProxyConfiguration into a plexus configuration object
[ http://jira.codehaus.org/browse/MRM-100?page=all ] Edwin Punzalan updated MRM-100: --- Assign To: Edwin Punzalan Remaining Estimate: 6 hours Original Estimate: 6 hours > Make ProxyConfiguration into a plexus configuration object > -- > > Key: MRM-100 > URL: http://jira.codehaus.org/browse/MRM-100 > Project: Maven Repository Manager > Type: Improvement > Components: remote proxy > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > Original Estimate: 6 hours > Remaining: 6 hours > -- 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: (MRM-66) Repository configuration
[ http://jira.codehaus.org/browse/MRM-66?page=all ] Brett Porter updated MRM-66: Fix Version: 1.0-beta-1 Remaining Estimate: (was: 1 day) Original Estimate: (was: 1 day) the configuration items are in the maven-repository-configuration modello model now > Repository configuration > > > Key: MRM-66 > URL: http://jira.codehaus.org/browse/MRM-66 > Project: Maven Repository Manager > Type: Task > Reporter: Maria Odea Ching > Fix For: 1.0-beta-1 > > > A configuration file will be retrieved and read by the Administration module. > Then the values will be set on the specific class(es) that will use this > configuration. Configurable fields: repositories, location of local cache and > if repositories are browsable. -- 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: (MNGECLIPSE-124) Unable to view use Maven2 using Eclipse 3.2RC4
[ http://jira.codehaus.org/browse/MNGECLIPSE-124?page=comments#action_66911 ] Eugene Kuleshov commented on MNGECLIPSE-124: Please try with version 0.0.9. If it won't work please check default m2 repository folder "Documents and Settings//.m2 make sure that this directory exist and settings.xml (if it is there) is a valid xml. > Unable to view use Maven2 using Eclipse 3.2RC4 > -- > > Key: MNGECLIPSE-124 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-124 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.7 > Environment: Windows XP Professional SP2 > JSE v1.5.0-06 > Eclipse 3.2RC4 > Reporter: Douglas WF Acheson > Assignee: Eugene Kuleshov > Attachments: .log > > > This is this error when I try to go to the Maven2 preferences : > Plug-in org.maven.ide.eclipse was unable to load class > org.maven.ide.eclipse.preferences.Maven2PreferencePage. > As well, I an not able to associate a project with maven2 when using the RMB > context menu for a project . I get a popup window with the following > The chosen operation is not currently available -- 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: (MNGECLIPSE-129) dependency type from parent pom
[ http://jira.codehaus.org/browse/MNGECLIPSE-129?page=comments#action_66912 ] Eugene Kuleshov commented on MNGECLIPSE-129: Version stuff is working in the trunk code (0.0.10). For pom types please attach Eclipse project and all the poms needed to reproduce issue. Also specify when exactly error occurs (when resolving dependencies or when launching maven goals from within Eclipse). > dependency type from parent pom > --- > > Key: MNGECLIPSE-129 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-129 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Dependency Resolver > Versions: 0.0.9 > Environment: Eclipse: 3.1.1 > Reporter: Marek Bieganski > Assignee: Eugene Kuleshov > Priority: Minor > > > My pom contains dependencies like: > > xxx-parent > com.xxx > HEAD-SNAPSHOT > > ... > > com.xxx > yyy > > xxx-parent pom contains full yyy dependency info: > > com.xxx > yyy > HEAD-SNAPSHOT > ejb > > Problem occurs when ejb is declared in parent pom, and no > is declared in child pom. > Only error message i got is: > 06-05-30 15:32:49 CEST: Project build error Failed to validate POM > Workaround is to redeclare ejb in child pom, but AFAIK if no > type is declared, it should be inherited from parent -- 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: (MSUREFIRE-130) Setting forkMode changes user.dir for multimodule projects
[ http://jira.codehaus.org/browse/MSUREFIRE-130?page=comments#action_66913 ] Richard van der Hoff commented on MSUREFIRE-130: > if we were to do this, then the tests would behave differently based on > whether it were in a multi-module or run from the individual project. They do already, if forkMode==never. > The way it is, the individual project is always consistent, it's only the > fork modes which aren't. I'm not sure that's the case. Anyway, it's certainly true that you can't have it be intuitive both ways. I happen to think that leaving user.dir alone would be the lesser of two evils, but I'm not really that worried about it. > Setting forkMode changes user.dir for multimodule projects > -- > > Key: MSUREFIRE-130 > URL: http://jira.codehaus.org/browse/MSUREFIRE-130 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Richard van der Hoff > Priority: Minor > > > The working directory of tests on a submodule in a multimodule project is > different dependeng on whether forkMode is enabled or not. > When forkMode==never, the working directory is that of the top-level module; > otherwise, it is set to the directory of the submodule. > I know this is defined behaviour - but it has been suggested that it is > unintuitive. -- 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: (ARCHETYPE-41) Parameter 'version' not correctly recognized
Parameter 'version' not correctly recognized
Key: ARCHETYPE-41
URL: http://jira.codehaus.org/browse/ARCHETYPE-41
Project: Maven Archetype
Type: Bug
Components: Plugin
Versions: 1.0-alpha-4
Reporter: Vitaly Berdinskikh
Parameter 'version' used instead of 'archetypeVersion' or
Call:
mvn archetype:create -DgroupId=** -DartifactId=*
-Dversion=0.1.0-alpha-1 -DpackageName=
Error log:
===
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment: [archetype:create] (aggregator-style)
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-core/0.1.0-alpha-1/maven-archetype-core-0.1.0-alpha-1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-creator/0.1.0-alpha-1/maven-archetype-creator-0.1.0-alpha-1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-creator/0.1.0-alpha-1/maven-archetype-creator-0.1.0-alpha-1.jar
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-core/0.1.0-alpha-1/maven-archetype-core-0.1.0-alpha-1.jar
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.maven.archetype:maven-archetype-creator:jar:0.1.0-alpha-1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.archetype
-DartifactId=maven-archetype-creator \
-Dversion=0.1.0-alpha-1 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1)
org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:1.0-alpha-4
2) org.apache.maven.archetype:maven-archetype-creator:jar:0.1.0-alpha-1
2) org.apache.maven.archetype:maven-archetype-core:jar:0.1.0-alpha-1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.archetype
-DartifactId=maven-archetype-core \
-Dversion=0.1.0-alpha-1 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1)
org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:1.0-alpha-4
2) org.apache.maven.archetype:maven-archetype-core:jar:0.1.0-alpha-1
--
2 required artifacts are missing.
for artifact:
org.apache.maven.plugins:maven-archetype-plugin:maven-plugin:1.0-alpha-4
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://svn.apache.org/maven-snapshot-repository)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 8 seconds
[INFO] Finished at: Thu Jun 08 11:42:24 EEST 2006
[INFO] Final Memory: 2M/4M
[INFO]
===
See plugin parameters description for goal 'create'
http://maven.apache.org/plugins/maven-archetype-plugin/create-mojo.html
...
version String ${version} 1.0-SNAPSHOT
...
Also if call with out parameter 'version'? project succesfully created with
version number '1.0-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] Commented: (MNG-2293) maven-plugin-descriptor: Not possible to define a default implementation for a field defined by its interface
[ http://jira.codehaus.org/browse/MNG-2293?page=comments#action_66915 ] Jerome Lacoste commented on MNG-2293: - The issue related to plexus-containers-default was that M2_HOME/core ships alpha-9. I am rebuilding with forcing this to be alpha-10. Hope that will solve it. > maven-plugin-descriptor: Not possible to define a default implementation for > a field defined by its interface > - > > Key: MNG-2293 > URL: http://jira.codehaus.org/browse/MNG-2293 > Project: Maven 2 > Type: New Feature > Components: Plugin Creation Tools > Versions: 2.0.4 > Reporter: Jerome Lacoste > Priority: Critical > Attachments: MNG-2293-plugins.diff, MNG-2293.diff, dependency-mistery.log, > it0106.tar.bz2, patch-MNG-2293-source2.tar.bz2, patch-MNG-2293.diff > > > MOJO-393 is about letting the user define an alternate configuration element, > thus changing the way the webstart plugin works. > For that the idea was to make the mojo field an interface, provide a default > implementation in the plugin and let the user use plexus to instanciate a new > implemenation. > so for most users we would have: > > > > > and for some: > > > > > Unfortunately, today I am forced to specify the implementation in both cases. > There's no way to inform the plugin to use the default implementation. > The plugin.xml contains: > > bla > ...BlaInterface >... > > I tried to use > /[EMAIL PROTECTED] implementation="...BlaImplementation"*/ > BlaInterface bla; > but that fails as well. > Marking critical because it doesn't allow me add new features to the plugin > without breaking the config.xml. -- 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-2352) Upgrade to plexus-container-default-alpha-10
Upgrade to plexus-container-default-alpha-10 Key: MNG-2352 URL: http://jira.codehaus.org/browse/MNG-2352 Project: Maven 2 Type: Improvement Reporter: Jerome Lacoste Priority: Blocker This is required for MNG-2201 in particular. -- 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] Reopened: (MNG-2350) tag is ignored for plugins in the section of the POM
[ http://jira.codehaus.org/browse/MNG-2350?page=all ] Carlos Sanchez reopened MNG-2350: - Reopen to fix docs. Mike, you should have assigned the issue to ourself when closing it > tag is ignored for plugins in the section of the POM > -- > > Key: MNG-2350 > URL: http://jira.codehaus.org/browse/MNG-2350 > Project: Maven 2 > Type: Bug > Components: Sites & Reporting > Versions: 2.0.4 > Environment: Windows XP > Reporter: Gunther Popp > > > A version defined for a plugin in the section of the POM is > ignored. For example, I would expect that the following definition in a POM > forces the usage of version 2.0-beta-4 of the site-plugin: > > ... > > > > org.apache.maven.plugins > maven-site-plugin > 2.0-beta-4 > > ... > However, Maven always uses the newer version 2.0-beta-5: > >mvn site -X > + Error stacktraces are turned on. > Maven version: 2.0.4 > ... > [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for > updates from central > [DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository > central > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.pom > 2/2K > 2K downloaded > [DEBUG] Artifact resolved > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for > project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: > org.apache.maven.plugins:maven-plugins:pom:1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.maven:maven-parent:pom:1 from the repository. > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.jar > 52K downloaded > [DEBUG] Artifact resolved > ... > It doesn´t matter, if the plugin already exists in the local repostitory or > not. -- 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-2350) tag is ignored for plugins in the section of the POM
[ http://jira.codehaus.org/browse/MNG-2350?page=all ] Carlos Sanchez updated MNG-2350: Version: (was: 2.0.4) documentation Fix Version: documentation > tag is ignored for plugins in the section of the POM > -- > > Key: MNG-2350 > URL: http://jira.codehaus.org/browse/MNG-2350 > Project: Maven 2 > Type: Bug > Components: Sites & Reporting > Versions: documentation > Environment: Windows XP > Reporter: Gunther Popp > Fix For: documentation > > > A version defined for a plugin in the section of the POM is > ignored. For example, I would expect that the following definition in a POM > forces the usage of version 2.0-beta-4 of the site-plugin: > > ... > > > > org.apache.maven.plugins > maven-site-plugin > 2.0-beta-4 > > ... > However, Maven always uses the newer version 2.0-beta-5: > >mvn site -X > + Error stacktraces are turned on. > Maven version: 2.0.4 > ... > [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for > updates from central > [DEBUG] maven-site-plugin: resolved to version 2.0-beta-5 from repository > central > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.pom > 2/2K > 2K downloaded > [DEBUG] Artifact resolved > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for > project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: > org.apache.maven.plugins:maven-plugins:pom:1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.maven:maven-parent:pom:1 from the repository. > [DEBUG] Trying repository central > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-5/maven-site-plugin-2.0-beta-5.jar > 52K downloaded > [DEBUG] Artifact resolved > ... > It doesn´t matter, if the plugin already exists in the local repostitory or > not. -- 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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=comments#action_66918 ] Carlos Sanchez commented on MSUREFIRE-129: -- >From the output I see that it's not forking > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Priority: Minor > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=comments#action_66919 ] Joerg Schaible commented on MSUREFIRE-129: -- forkModes have changed again to "never", "once", "always", so replace "pertest" with "always". > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Priority: Minor > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=comments#action_66920 ] Brett Porter commented on MSUREFIRE-129: pertest, etc still work, however > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Priority: Minor > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=comments#action_66921 ] Per Olesen commented on MSUREFIRE-129: -- Tried it with fork mode "always" which did NOT work. In the debug output I observed: [DEBUG] (f) forkMode = always But it did not fork (I saw no java cmdline). Tried it with "once", which works fine. So am using that now. Can we conclude, that "always" does not work then? BTW: The current online docs say: "Option to specify the forking mode. Can be "never" (default), "once" or "always". "none" and "pertest" are also accepted for backwards compatibility." > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Priority: Minor > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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: (MWAR-45) add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/
[ http://jira.codehaus.org/browse/MWAR-45?page=comments#action_66923 ] Torgeir Lorange Østby commented on MWAR-45: --- This feature makes it easier to overlay war files if you have files with the same name and path in the war projects you want to merge (e.g. in src/main/resources). With this, these files will end up in their respective jars instead of replacing each other during the overlay process (take the application context descriptor as an example). > add config prop to specify webapp classes should be zipped and placed into > WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ > - > > Key: MWAR-45 > URL: http://jira.codehaus.org/browse/MWAR-45 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Ian Springer > Attachments: mwar-45.patch > > > I think this is a common enough practice that there should be an option > provided for it. -- 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-939) Simple Log 1.7 upload bundle request
Simple Log 1.7 upload bundle request
Key: MAVENUPLOAD-939
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-939
Project: maven-upload-requests
Type: Task
Reporter: Gwyn Evans
http://www.javaguy.co.uk/log/simple-log-1.7-dist.jar
http://www.javaguy.co.uk/log/simple-log-clog-1.7-dist.jar
http://www.javaguy.co.uk/log/simple-log-sl4j-1.7-dist.jar
https://simple-log.dev.java.net/
{I'm not a developer, just a user of the API.}
Simple Log is a small library that does logging very simply and requires you to
do almost nothing (other than actually logging) to get log output happening. It
is much simpler to use than a logging framework, especially in terms of
configuration.
It doesn't attempt to solve every logging problem in one package, but contains
enough features to be a viable alternative for most applications that need
logging.
--
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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=all ] Carlos Sanchez updated MSUREFIRE-129: - Priority: Major (was: Minor) Fix Version: 2.3 This needs to be checked > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.2 > Reporter: Per Olesen > Fix For: 2.3 > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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-2297) plugin definitions not merged correctly
[ http://jira.codehaus.org/browse/MNG-2297?page=all ] Carlos Sanchez closed MNG-2297: --- Assign To: Carlos Sanchez Resolution: Duplicate > plugin definitions not merged correctly > --- > > Key: MNG-2297 > URL: http://jira.codehaus.org/browse/MNG-2297 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0.4 > Reporter: Richard van der Hoff > Assignee: Carlos Sanchez > Priority: Minor > Attachments: maven-project-plugins.patch, maven-project-plugins.patch > > > If both a parent, and a child plugin reference a plugin, the plugin > configuration is not merged correctly; instead, the child build ends up with > two copies of the plugin (with separate configuration and separate > executions). > The attachment contains a testcase demonstrating the problem, and fixes to > ModelUtils.java (against current trunk) to fix it. -- 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: (CONTINUUM-696) Bunch of stack traces when company logo is wrong and relative
[ http://jira.codehaus.org/browse/CONTINUUM-696?page=all ] Carlos Sanchez updated CONTINUUM-696: - Fix Version: 1.1-alpha-1 > Bunch of stack traces when company logo is wrong and relative > - > > Key: CONTINUUM-696 > URL: http://jira.codehaus.org/browse/CONTINUUM-696 > Project: Continuum > Type: Improvement > Components: Web interface > Versions: 1.0.3 > Reporter: Carlos Sanchez > Priority: Minor > Fix For: 1.1-alpha-1 > > > When setting company logo to "s" continuum hits > http://localhost:8080/continuum/servlet/s, causing a bunch of stack traces > It'd be better to have the continuum servlet explicitly setup in the web.xml > and turn of the auto mapping of servlets > 14:57:22.468 WARN!! Exception for /continuum/servlet/s > javax.servlet.UnavailableException: java.lang.ClassNotFoundException: s > at org.mortbay.jetty.servlet.Invoker.service(Invoker.java:154) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.String.substring(String.java:1768) > at > org.apache.maven.continuum.web.pipeline.valve.ContinuumViewContextPopulatorValve.populateViewContext(ContinuumViewContextPopulatorValve.java:48) > at > org.codehaus.plexus.summit.pipeline.valve.CreateViewContextValve.invoke(CreateViewContextValve.java:50) > at > org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) > at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) > 2006-05-12 14:57:26,875 [SocketListener0-0] WARN VelocityComponent >- org.apache.velocity.runtime.exception.ReferenceException: reference : > template = screens/Error.vm [line 10,column 8] : $stackTrace is not a valid > reference. > 2006-05-12 14:57:38,875 [SocketListener0-0] INFO Action:login >- Trying to log in 'carlos'. > username: carlos > 14:57:39.468 WARN!! Exception for /continuum/servlet/s > javax.servlet.UnavailableException: java.lang.ClassNotFoundException: s > at org.mortbay.jetty.servlet.Invoker.service(Invoker.java:154) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at
[jira] Created: (MNG-2353) mvn site:site fails generating the dependencies if the MNG-806 fix is present
mvn site:site fails generating the dependencies if the MNG-806 fix is present
-
Key: MNG-2353
URL: http://jira.codehaus.org/browse/MNG-2353
Project: Maven 2
Type: Sub-task
Components: Sites & Reporting, Dependencies
Versions: 2.0.4
Environment: Windows XP SP2
Reporter: Alejandro Scandroli
Priority: Minor
mvn site:site fails generating the dependencies when the MNG-806 fix is present.
I'm using this in my pom.xml
sun.jdk
tools
1.5
system
${java.home}/../lib/tools.jar
Here is the error log:
(...)
[INFO] Generate "Dependencies" report.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:467)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225)
at
org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.getMavenProjectFromRepository(DependenciesReport.java:456)
at
org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.printDescriptionsAndURLs(DependenciesReport.java:392)
at
org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.printDescriptionsAndURLs(DependenciesReport.java:429)
at
org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:277)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:97)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
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:256)
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]
If I delete (or comment) this dependency it works perfectly.
--
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:
[jira] Commented: (MNG-2221) Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times
[ http://jira.codehaus.org/browse/MNG-2221?page=comments#action_66934 ] Carlos Sanchez commented on MNG-2221: - See patch from MNG-2297 > Multiple Executions of Plugin at Difference Inhertiance levels causes plugin > executions to run multiple times > - > > Key: MNG-2221 > URL: http://jira.codehaus.org/browse/MNG-2221 > Project: Maven 2 > Type: Bug > Components: Inheritence and Interpolation > Versions: 2.0.4 > Reporter: Stephen Duncan Jr > Priority: Critical > Fix For: 2.0.5 > Attachments: repeat-test.zip > > > Can occur in a variety of ways, but the attached test case shows a parent pom > defining an antrun-execution, and then a child specifying another execution > with a different id. Both executions run twice when running from the child. > I believe this is the same as Kenney Westerhof's comment: > http://jira.codehaus.org/browse/MNG-2054#action_62477 -- 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-2237) Inherited plugin executed twice if child pom merges configuration
[ http://jira.codehaus.org/browse/MNG-2237?page=all ]
Carlos Sanchez closed MNG-2237:
---
Assign To: Carlos Sanchez
Resolution: Duplicate
Fix Version: (was: 2.0.5)
> Inherited plugin executed twice if child pom merges configuration
> -
>
> Key: MNG-2237
> URL: http://jira.codehaus.org/browse/MNG-2237
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.4
> Reporter: Joerg Schaible
> Assignee: Carlos Sanchez
>
>
> According the docs the configuration of a plugin is merged, when the plugin
> is inherited. This actually hapens, but the plugin with the merged
> configuration is added twice in the effective-pom and therefore executed
> twice.
> Setup a parent pom with a plugin configuration to attach the javadocs:
> {noformat}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> attach-javadocs
>
> jar
>
>
>
> true
>
> true
>
>
> {noformat}
> and a child pom that adds additional elements in the configuration:
> {noformat}
>
> maven-javadoc-plugin
>
>
> http://java.sun.com/j2se/1.4.2/docs/api/
>
> http://jakarta.apache.org/commons/logging/commons-logging-1.0.4/docs/apidocs/
> http://jmock.codehaus.org/docs/javadoc/
> http://www.junit.org/junit/javadoc/3.8.1/
>
>
>
> {noformat}
> In this case the javadoc is generated twice, the goal help:effective-pom
> reveals, that the plugin was merged, but added twice.
--
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-2353) mvn site:site fails generating the dependencies if the MNG-806 fix is present
[ http://jira.codehaus.org/browse/MNG-2353?page=all ]
Carlos Sanchez closed MNG-2353:
---
Assign To: Carlos Sanchez
Resolution: Duplicate
> mvn site:site fails generating the dependencies if the MNG-806 fix is present
> -
>
> Key: MNG-2353
> URL: http://jira.codehaus.org/browse/MNG-2353
> Project: Maven 2
> Type: Sub-task
> Components: Sites & Reporting, Dependencies
> Versions: 2.0.4
> Environment: Windows XP SP2
> Reporter: Alejandro Scandroli
> Assignee: Carlos Sanchez
> Priority: Minor
>
>
> mvn site:site fails generating the dependencies when the MNG-806 fix is
> present.
> I'm using this in my pom.xml
>
>
> sun.jdk
> tools
> 1.5
> system
> ${java.home}/../lib/tools.jar
>
> Here is the error log:
> (...)
> [INFO] Generate "Dependencies" report.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:82)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:467)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225)
> at
> org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.getMavenProjectFromRepository(DependenciesReport.java:456)
> at
> org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.printDescriptionsAndURLs(DependenciesReport.java:392)
> at
> org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.printDescriptionsAndURLs(DependenciesReport.java:429)
> at
> org.apache.maven.report.projectinfo.DependenciesReport$DependenciesRenderer.renderBody(DependenciesReport.java:277)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
> at
> org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:97)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> 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:256)
> 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.m
[jira] Created: (MNG-2354) exclusion of a dependency prevents the dependency being added normally
exclusion of a dependency prevents the dependency being added normally -- Key: MNG-2354 URL: http://jira.codehaus.org/browse/MNG-2354 Project: Maven 2 Type: Bug Components: Dependencies Reporter: Jorg Heymans Consider following usecase: commons-beanutils commons-beanutils-core 1.7.0 commons-configuration commons-configuration 1.2 commons-beanutils-core commons-beanutils Above pom configuration to me says: ignore the transitive dependency on commons-beanutils-core brought in by commons-configurations because i would like to define and use my own. However this configuration excludes commons-beanutils-core completely, eg in a war build it's not included as a dependency anymore. -- 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: (SCM-184) PerforceScmProvider.createClientspec should use the working dir's canonical path for the clientspec root
[ http://jira.codehaus.org/browse/SCM-184?page=all ]
Mike Perham closed SCM-184:
---
Resolution: Fixed
Thanks John.
> PerforceScmProvider.createClientspec should use the working dir's canonical
> path for the clientspec root
>
>
> Key: SCM-184
> URL: http://jira.codehaus.org/browse/SCM-184
> Project: Maven SCM
> Type: Bug
> Components: maven-scm-provider-perforce
> Versions: 1.0
> Reporter: John Didion
> Assignee: Mike Perham
> Fix For: 1.0
>
>
> createClientspec should look like this:
> {noformat}
> public static String createClientspec( PerforceScmProviderRepository
> repo, String specname, File workDir )
> {
> String clientspecName = getClientspecName( repo, workDir );
> String userName = getUsername( repo );
> String rootDir = null;
> try {
> rootDir = workDir.getCanonicalPath();
> } catch (IOException ex) {
> //getLogger().error("Error getting canonical path for working
> directory: " + workDir, ex);
> rootDir = workDir.getAbsolutePath();
> }
> StringBuffer buf = new StringBuffer();
> buf.append( "Client: " ).append( clientspecName ).append( NEWLINE );
> buf.append( "Root: " ).append( rootDir ).append( NEWLINE );
> buf.append( "Owner: " ).append( userName ).append( NEWLINE );
> buf.append( "View:" ).append( NEWLINE );
> buf.append( "\t" ).append( PerforceScmProvider.getCanonicalRepoPath(
> repo.getPath() ) );
> buf.append( " //" ).append( clientspecName ).append( "/..." ).append(
> NEWLINE );
> buf.append( "Description:" ).append( NEWLINE );
> buf.append( "\t" ).append( "Created by maven-scm-provider-perforce"
> ).append( NEWLINE );
> return buf.toString();
> }
> {noformat}
> Otherwise, when used with continuum, the changelog command will never work.
> The continuum working directory always looks like
> CONTINUUM_HOME/bin/win32/../../apps/depot/69 when creating the clientspec,
> and perforce seems not to know how to deal with non-canonical paths, so
> perforce always just spits out an error message and returns no changes. This
> sucks because then build complete notifications never get sent.
--
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: (SCM-184) PerforceScmProvider.createClientspec should use the working dir's canonical path for the clientspec root
[ http://jira.codehaus.org/browse/SCM-184?page=all ]
Mike Perham updated SCM-184:
Version: 1.0
Fix Version: 1.0
> PerforceScmProvider.createClientspec should use the working dir's canonical
> path for the clientspec root
>
>
> Key: SCM-184
> URL: http://jira.codehaus.org/browse/SCM-184
> Project: Maven SCM
> Type: Bug
> Components: maven-scm-provider-perforce
> Versions: 1.0
> Reporter: John Didion
> Assignee: Mike Perham
> Fix For: 1.0
>
>
> createClientspec should look like this:
> {noformat}
> public static String createClientspec( PerforceScmProviderRepository
> repo, String specname, File workDir )
> {
> String clientspecName = getClientspecName( repo, workDir );
> String userName = getUsername( repo );
> String rootDir = null;
> try {
> rootDir = workDir.getCanonicalPath();
> } catch (IOException ex) {
> //getLogger().error("Error getting canonical path for working
> directory: " + workDir, ex);
> rootDir = workDir.getAbsolutePath();
> }
> StringBuffer buf = new StringBuffer();
> buf.append( "Client: " ).append( clientspecName ).append( NEWLINE );
> buf.append( "Root: " ).append( rootDir ).append( NEWLINE );
> buf.append( "Owner: " ).append( userName ).append( NEWLINE );
> buf.append( "View:" ).append( NEWLINE );
> buf.append( "\t" ).append( PerforceScmProvider.getCanonicalRepoPath(
> repo.getPath() ) );
> buf.append( " //" ).append( clientspecName ).append( "/..." ).append(
> NEWLINE );
> buf.append( "Description:" ).append( NEWLINE );
> buf.append( "\t" ).append( "Created by maven-scm-provider-perforce"
> ).append( NEWLINE );
> return buf.toString();
> }
> {noformat}
> Otherwise, when used with continuum, the changelog command will never work.
> The continuum working directory always looks like
> CONTINUUM_HOME/bin/win32/../../apps/depot/69 when creating the clientspec,
> and perforce seems not to know how to deal with non-canonical paths, so
> perforce always just spits out an error message and returns no changes. This
> sucks because then build complete notifications never get sent.
--
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-2354) exclusion of a dependency prevents the dependency being added normally
[ http://jira.codehaus.org/browse/MNG-2354?page=all ] Carlos Sanchez closed MNG-2354: --- Assign To: Carlos Sanchez Resolution: Duplicate > exclusion of a dependency prevents the dependency being added normally > -- > > Key: MNG-2354 > URL: http://jira.codehaus.org/browse/MNG-2354 > Project: Maven 2 > Type: Bug > Components: Dependencies > Reporter: Jorg Heymans > Assignee: Carlos Sanchez > > > Consider following usecase: > > commons-beanutils > commons-beanutils-core > 1.7.0 > > > commons-configuration > commons-configuration > 1.2 > > > commons-beanutils-core > commons-beanutils > > > Above pom configuration to me says: ignore the transitive dependency on > commons-beanutils-core brought in by commons-configurations because i would > like to define and use my own. However this configuration excludes > commons-beanutils-core completely, eg in a war build it's not included as a > dependency anymore. -- 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-46) EJB-client libraries are added with wrong extension
EJB-client libraries are added with wrong extension --- Key: MWAR-46 URL: http://jira.codehaus.org/browse/MWAR-46 Project: Maven 2.x War Plugin Type: Bug Versions: 2.0 Reporter: Joerg Schaible Priority: Blocker If a war has a dependency to an ejb client library, this library is added to META-INF/lib as artifactId.ejb-client. Such artifacts are not added to the classpath by all app servers e.g. like WebLogic 8.1. The dependency must be added as artifactId-ejb-client.jar. -- 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: (WAGONHTTP-8) wagon-http does not MKCOL for missing parent resources during deploy
[ http://jira.codehaus.org/browse/WAGONHTTP-8?page=comments#action_66938 ]
Carlos Sanchez commented on WAGONHTTP-8:
Like what is at http://maven.apache.org/wagon/wagon-providers/wagon-http/ ?
> wagon-http does not MKCOL for missing parent resources during deploy
>
>
> Key: WAGONHTTP-8
> URL: http://jira.codehaus.org/browse/WAGONHTTP-8
> Project: wagon-http
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, against
> Apache/2.0.54 (Fedora) DAV/2
> Reporter: Matthew Daniel
> Priority: Blocker
>
>
> Please see MNG-1580 and
> When trying to deploy using wagon-http, it does not understand the concept of
> parent directories and just issues a blind PUT with the resource URI. Further
> to the user's confusion, it does not report a helpful message but "Access
> denided" which is 100% not true.
> {quote}
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifactat
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> 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: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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying
> artifact
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:160)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Authorization failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
> ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Authorization
> failed: Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:215)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77)
> ... 19 more
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denided to:
> http://servername/path/to/a/non-existant/1.5-SNAPSHOT/artifactid-1.5-20060209.202937-1.jar
> at
> org.apache.maven.wagon.providers.http.HttpWagon.put(HttpWagon.java:202)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180)
> ... 21 more
> {quote}
--
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: (MDEPLOY-28) Deployment should delete remote files and create new ones instead of modifying them
[ http://jira.codehaus.org/browse/MDEPLOY-28?page=comments#action_66939 ] Carlos Sanchez commented on MDEPLOY-28: --- no problem > Deployment should delete remote files and create new ones instead of > modifying them > --- > > Key: MDEPLOY-28 > URL: http://jira.codehaus.org/browse/MDEPLOY-28 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.3 > Reporter: Carlos Sanchez > Priority: Critical > Fix For: 2.3 > > > Remote files usually are non group writable while the directory is to prevent > changes in the files without knowing who changed it (eg. apache repository > policy) > So deployment should delete metadata files and create new ones instead of > editing 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] Commented: (SCM-209) Specifying working directory for Runtime.exec() on linux has no effect
[ http://jira.codehaus.org/browse/SCM-209?page=comments#action_66940 ]
Mike Perham commented on SCM-209:
-
I can't make this change easily as it breaks pretty much every test. Please
submit a patch with everything fixed, if possible. Otherwise this will have to
wait until the big refactoring I have planned for next month.
> Specifying working directory for Runtime.exec() on linux has no effect
> --
>
> Key: SCM-209
> URL: http://jira.codehaus.org/browse/SCM-209
> Project: Maven SCM
> Type: Bug
> Components: maven-scm-provider-perforce
> Versions: 1.0-beta-3
> Reporter: John Didion
>
>
> Passing the working directory as an argument to Runtime.exec seems to have no
> effect on linux...perforce still goes with whatever the VM's initial working
> directory was. You need to set -d to make it use the correct one.
> In PerforceScmProvider.createP4Command():
> command.createArgument().setValue("-d");
> command.createArgument().setValue(workingDir.getAbsolutePath());
--
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: (MNGECLIPSE-134) wizard for creating java project from existing pom.xml
wizard for creating java project from existing pom.xml -- Key: MNGECLIPSE-134 URL: http://jira.codehaus.org/browse/MNGECLIPSE-134 Project: Maven 2.x Extension for Eclipse Type: New Feature Components: Wizards Reporter: Scott Cytacki Assigned to: Eugene Kuleshov When checking out a maven project from an scm that doesn't include .project .classpath files. It would be nice if the maven plugin gave the option to create the eclipse java project as it is being checked out. This is appears to be handled by making a new project wizard. An example of similar functionality is when checking out a ant based project you can create an eclipse project from it. The current solution is to check it out and then fix it up after the fact, by adding the maven library, or instead runing the eclipse:eclipse goal. The wizard could detect things like multimodule projects and at least give some advice to the user, or better it might beable to give the user different options for handling 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] Commented: (MNGECLIPSE-134) wizard for creating java project from existing pom.xml
[ http://jira.codehaus.org/browse/MNGECLIPSE-134?page=comments#action_66943 ] Eugene Kuleshov commented on MNGECLIPSE-134: I don't know if it worth a wizard. You can checkout and use regular Eclipse wizards and then use Maven2 -> Enable Maven from the project popup menu. > wizard for creating java project from existing pom.xml > -- > > Key: MNGECLIPSE-134 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-134 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Wizards > Reporter: Scott Cytacki > Assignee: Eugene Kuleshov > > > When checking out a maven project from an scm that doesn't include .project > .classpath files. It would be nice if the maven plugin gave the option to > create the eclipse java project as it is being checked out. This is appears > to be handled by making a new project wizard. > An example of similar functionality is when checking out a ant based project > you can create an eclipse project from it. > The current solution is to check it out and then fix it up after the fact, by > adding the maven library, or instead runing the eclipse:eclipse goal. > The wizard could detect things like multimodule projects and at least give > some advice to the user, or better it might beable to give the user different > options for handling 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] Closed: (WAGON-4) Publish site for 0.9
[ http://jira.codehaus.org/browse/WAGON-4?page=all ] Carlos Sanchez closed WAGON-4: -- Assign To: Carlos Sanchez Resolution: Won't Fix outdated > Publish site for 0.9 > > > Key: WAGON-4 > URL: http://jira.codehaus.org/browse/WAGON-4 > Project: wagon > Type: Task > Versions: 1.0-alpha-2 > Reporter: Jason van Zyl > Assignee: Carlos Sanchez > > > Publish the site for 0.9. -- 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] Moved: (WAGONFTP-13) scp-external-wagen and ssh using ProxyCommand blacklist repository
[ http://jira.codehaus.org/browse/WAGONFTP-13?page=all ]
Carlos Sanchez moved WAGON-39 to WAGONFTP-13:
-
Version: (was: 1.0-alpha-6)
1.0-alpha-6
Fix Version: (was: 1.0-beta-1)
Component: (was: wagon-ssh-external)
Key: WAGONFTP-13 (was: WAGON-39)
Project: wagon-ftp (was: wagon)
> scp-external-wagen and ssh using ProxyCommand blacklist repository
> -
>
> Key: WAGONFTP-13
> URL: http://jira.codehaus.org/browse/WAGONFTP-13
> Project: wagon-ftp
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: linux 2.6.15-1.2054_FC5
> client ssh: OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
> server in the middle ssh:OpenSSH_4.2, OpenSSL 0.9.7d 17 Mar 2004
>
> Reporter: M. van der Plas
> Attachments: EndsWith.patch
>
>
> I use my laptop to work at the office and at home. The office has a
> repository for inhouse developed projects.
> ssh channles are used to connect with the office repository from home.
> I configured ssh using with a ProcyCommand to tunnel to the subversion
> respository.
> I configured mvn using a home specific settings.xml to use scp-external-ssh
> as the standard ssh wagon cannot handle the ProxyCommand.
> This fails when external 3rd party artifacts and plugins are checked in the
> company repositories.
> Since they are located in the ibiblio central repository the scp command
> fails.
> This is normally not a problem because the Wagons check if the output of the
> copy command is "No such file or directory".
> If so, the artifact is searched in another repository.
> With the introduction of the ProxyCommand this mechanism does not work any
> more.
> ProxyCommand prints "Killed by signal 1" to stderr when the scp command fails.
> See also http://lists.debian.org/debian-ssh/2005/06/msg00074.html for the ssh
> bug.
> The problem is that both
> wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/ScpWagon.java
> (revision 388735)
> and
> wagon-providers/wagon-ssh-external/src/main/java/org/apache/maven/wagon/providers/sshext/ScpExternalWagon.java
> (revision 388735)
> use stderr.endsWith("No such file or directory") while stderr in my case ends
> with "Killed by sgnal 1."
> The problem can be fixed by using indexOf( "No such file or directory") != -1
> instead of the endsWith() call.
> I've implemented this fix and verified that the problem did not occur. The
> patch is attached.
--
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] Moved: (WAGONHTTP-12) An exception is throwed when the http response code is 201
[ http://jira.codehaus.org/browse/WAGONHTTP-12?page=all ]
Carlos Sanchez moved WAGON-36 to WAGONHTTP-12:
--
Version: (was: 1.0-alpha-6)
Fix Version: (was: 1.0-beta-1)
Component: (was: wagon-http-lightweight)
Key: WAGONHTTP-12 (was: WAGON-36)
Project: wagon-http (was: wagon)
> An exception is throwed when the http response code is 201
> --
>
> Key: WAGONHTTP-12
> URL: http://jira.codehaus.org/browse/WAGONHTTP-12
> Project: wagon-http
> Type: Bug
> Reporter: Alexandre Poitras
> Priority: Minor
>
>
> The put method of the LightweightHttpWagon class throw an exception whener
> the http response code is 201. The 201 code indicate the PUT method has
> completed successfully in a WebDav environment.
> The problem comes from here :
> if ( putConnection.getResponseCode() != HttpURLConnection.HTTP_OK
> )
> {
> throw new TransferFailedException(
> "Unable to transfer file. HttpURLConnection returned the
> response code: " +
> putConnection.getResponseCode() );
> }
>
> An exception is thrown whenever the Http code is different from 200 wich is
> not good.
--
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] Moved: (WAGONHTTP-11) Wagon http fails when remote repo is not accessible
[ http://jira.codehaus.org/browse/WAGONHTTP-11?page=all ] Carlos Sanchez moved WAGON-46 to WAGONHTTP-11: -- Version: (was: 1.0-alpha-7) Fix Version: (was: 1.0-beta-1) Component: (was: wagon-http-lightweight) Key: WAGONHTTP-11 (was: WAGON-46) Project: wagon-http (was: wagon) > Wagon http fails when remote repo is not accessible > --- > > Key: WAGONHTTP-11 > URL: http://jira.codehaus.org/browse/WAGONHTTP-11 > Project: wagon-http > Type: Bug > Reporter: Carlos Sanchez > > > Seems that maven understands error codes from the http server, but not > exceptions like "host doesn't exist" or "connection timeout", which make the > build fail instead of going to the next one -- 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] Moved: (WAGONFTP-15) wagon-ftp sometimes does not build due to socket errors in tests
[ http://jira.codehaus.org/browse/WAGONFTP-15?page=all ] Carlos Sanchez moved WAGON-43 to WAGONFTP-15: - Version: (was: 1.0-beta-1) Fix Version: (was: 1.0-beta-1) Component: (was: wagon-ftp) Key: WAGONFTP-15 (was: WAGON-43) Project: wagon-ftp (was: wagon) > wagon-ftp sometimes does not build due to socket errors in tests > > > Key: WAGONFTP-15 > URL: http://jira.codehaus.org/browse/WAGONFTP-15 > Project: wagon-ftp > Type: Bug > Environment: linux, maven 2.0.4 > Reporter: Henry S. Isidro > Priority: Minor > > > The wagon-ftp provider build sometimes do not continue due to a > SocketException in the unit test. This message is displayed several times: > [ERROR] Exception accepting connection > java.net.SocketException: Socket is closed > at java.net.ServerSocket.accept(ServerSocket.java:417) > at > org.apache.avalon.cornerstone.blocks.connection.Connection.run(Connection.java:134) > at > org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:90) > at > org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:136) > There are times though that the build will succeed so this seems to be an > inconsistent occurrence. -- 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] Moved: (WAGONSSH-48) scp-external-wagen and ssh using ProxyCommand blacklist repository
[ http://jira.codehaus.org/browse/WAGONSSH-48?page=all ]
Carlos Sanchez moved WAGONFTP-13 to WAGONSSH-48:
Key: WAGONSSH-48 (was: WAGONFTP-13)
Project: wagon-ssh (was: wagon-ftp)
> scp-external-wagen and ssh using ProxyCommand blacklist repository
> -
>
> Key: WAGONSSH-48
> URL: http://jira.codehaus.org/browse/WAGONSSH-48
> Project: wagon-ssh
> Type: Bug
> Versions: 1.0-alpha-6
> Environment: linux 2.6.15-1.2054_FC5
> client ssh: OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
> server in the middle ssh:OpenSSH_4.2, OpenSSL 0.9.7d 17 Mar 2004
>
> Reporter: M. van der Plas
> Attachments: EndsWith.patch
>
>
> I use my laptop to work at the office and at home. The office has a
> repository for inhouse developed projects.
> ssh channles are used to connect with the office repository from home.
> I configured ssh using with a ProcyCommand to tunnel to the subversion
> respository.
> I configured mvn using a home specific settings.xml to use scp-external-ssh
> as the standard ssh wagon cannot handle the ProxyCommand.
> This fails when external 3rd party artifacts and plugins are checked in the
> company repositories.
> Since they are located in the ibiblio central repository the scp command
> fails.
> This is normally not a problem because the Wagons check if the output of the
> copy command is "No such file or directory".
> If so, the artifact is searched in another repository.
> With the introduction of the ProxyCommand this mechanism does not work any
> more.
> ProxyCommand prints "Killed by signal 1" to stderr when the scp command fails.
> See also http://lists.debian.org/debian-ssh/2005/06/msg00074.html for the ssh
> bug.
> The problem is that both
> wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/ScpWagon.java
> (revision 388735)
> and
> wagon-providers/wagon-ssh-external/src/main/java/org/apache/maven/wagon/providers/sshext/ScpExternalWagon.java
> (revision 388735)
> use stderr.endsWith("No such file or directory") while stderr in my case ends
> with "Killed by sgnal 1."
> The problem can be fixed by using indexOf( "No such file or directory") != -1
> instead of the endsWith() call.
> I've implemented this fix and verified that the problem did not occur. The
> patch is attached.
--
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: (WAGONFTP-12) Null-Pointer Exception when password tag missing or empty in maven2 settings.xml
[ http://jira.codehaus.org/browse/WAGONFTP-12?page=all ] Carlos Sanchez closed WAGONFTP-12: -- Assign To: Carlos Sanchez Resolution: Duplicate > Null-Pointer Exception when password tag missing or empty in maven2 > settings.xml > > > Key: WAGONFTP-12 > URL: http://jira.codehaus.org/browse/WAGONFTP-12 > Project: wagon-ftp > Type: Bug > Versions: 1.0-alpha-6 > Environment: Windows-XP, Maven 2.0.2 > Reporter: Alex Rueegg > Assignee: Carlos Sanchez > > > A Null-Pointer Exception is thrown when the password tag in settings.xml is > not given or kept blank. I guess it is this line > if ( !ftp.login( username.trim(), password.trim() ) ) > where the trim() method is invoked on a null object. -- 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: (MPSITE-51) site:war creates incomplete war with many files missing
site:war creates incomplete war with many files missing --- Key: MPSITE-51 URL: http://jira.codehaus.org/browse/MPSITE-51 Project: maven-site-plugin Type: Bug Components: plugin Versions: 1.6.1, 1.7 Environment: beta3 Reporter: Jeff Jensen Problem first appeared when upgraded to 1.7. Downgrading to 1.6.1 caused the problem to go away. Now, a month or two later, 1.6.1 exhibits the problem too. Perhaps because the size of our codebase continues to grow it now shows in 1.6.1. How we create the war: 1) clean all 2) run site on each component 3) run multiproject on the parent to get the dashboard report, its html pages generated, and all subprojects copied into place 4) run site:war to create the war The war is missing files, including files in the root that are part of the parent (e.g. FAQs) and most content of some subprojects. Yes, these files exist in the target dir. Interestingly, the -X output shows one of the missing files identified as needed and added on a site:war run that doesn't delete the war first: [war] [VERBOSE] perforcefaq.html added as perforcefaq.html is outdated. [war] [VERBOSE] adding entry perforcefaq.html Yet the resulting war does not have that file (and others). Hmm, perhaps this suggests a problem somewhere else... The site and war is large, runs about 10 hours to generate and the war as-is is around 360M. I moved the site deploy process to the war approach from the file copy approach, as it was cleaner and a bit faster. I think the workaround is to go back to the file copy deploy approach. -- 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-44) Inner class inclusion too powerful
[ http://jira.codehaus.org/browse/SUREFIRE-44?page=comments#action_66951 ]
Ken Arnold commented on SUREFIRE-44:
My mistake, this is not a 2.0 issue (that was a typo). It's a 1.5.3 issue.
I am going to have to add no-arg constructors to all nested classes right now.
This is just wrong.
> Inner class inclusion too powerful
> --
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: surefire
> Type: Bug
> Versions: 2.0
> Reporter: Ken Arnold
>
>
> When inner classes were included, it was done in a way that was too powerful.
> I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included
> class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for
> other reasons (simple mock objects, for example). Inner classes do not have
> no-arg constructors, and so including them includes classes that pretty much
> by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test
> case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else,
> nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of
> top-level classes is much more selective. I would prefer if the default
> inclusion of nested classes followed the same default naming pattern. But at
> the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException:
> com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at
> org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at
> org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at
> org.apache.maven.surefire.battery.JUnitBattery.(JUnitBattery.java:81)
> at
> org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at
> org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> 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.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
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: (MEAR-30) EAR plugin generates meta-inf rather than META-INF
EAR plugin generates meta-inf rather than META-INF -- Key: MEAR-30 URL: http://jira.codehaus.org/browse/MEAR-30 Project: Maven 2.x Ear Plugin Type: Bug Versions: 2.2 Reporter: Andreas Schildbach When I run "mvn package" on my ear module, I get both "application.xml" and "Manifest.mf" in a directory called "meta-inf" rather than the standard-conform "META-INF". JBoss consequently cannot find application.xml in the EAR when trying to deploy. Here is my plugin config: org.apache.maven.plugins maven-ear-plugin name description 1.4 group artifact true Maven-ear-plugin is resolved to version 2.2. -- 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-2355) Documentation of the @component javadoc tag
Documentation of the @component javadoc tag --- Key: MNG-2355 URL: http://jira.codehaus.org/browse/MNG-2355 Project: Maven 2 Type: Improvement Components: Documentation: General Reporter: Scott Cytacki While trying to figure out how the AbstractCompilerMojo worked, I found the @component tag for the compilerManager field. There is a reference page for the mojo-api-spec, but this page doesn't talk about the "component" tag. That page seems like a logical place to put this documentation, or at least a reference to it if it is already somewhere else. -- 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: (MPSITE-51) site:war creates incomplete war with many files missing
[ http://jira.codehaus.org/browse/MPSITE-51?page=comments#action_66957 ] Lukas Theussl commented on MPSITE-51: - The site:war goal is a simple wrapper for ant's war task. Could you try to run an equivalent ant task to see if you get the same effect? > site:war creates incomplete war with many files missing > --- > > Key: MPSITE-51 > URL: http://jira.codehaus.org/browse/MPSITE-51 > Project: maven-site-plugin > Type: Bug > Components: plugin > Versions: 1.6.1, 1.7 > Environment: beta3 > Reporter: Jeff Jensen > > > Problem first appeared when upgraded to 1.7. Downgrading to 1.6.1 caused the > problem to go away. Now, a month or two later, 1.6.1 exhibits the problem > too. Perhaps because the size of our codebase continues to grow it now shows > in 1.6.1. > How we create the war: > 1) clean all > 2) run site on each component > 3) run multiproject on the parent to get the dashboard report, its html pages > generated, and all subprojects copied into place > 4) run site:war to create the war > The war is missing files, including files in the root that are part of the > parent (e.g. FAQs) and most content of some subprojects. Yes, these files > exist in the target dir. > Interestingly, the -X output shows one of the missing files identified as > needed and added on a site:war run that doesn't delete the war first: > [war] [VERBOSE] perforcefaq.html added as perforcefaq.html is outdated. > > [war] [VERBOSE] adding entry perforcefaq.html > Yet the resulting war does not have that file (and others). Hmm, perhaps > this suggests a problem somewhere else... > The site and war is large, runs about 10 hours to generate and the war as-is > is around 360M. > I moved the site deploy process to the war approach from the file copy > approach, as it was cleaner and a bit faster. I think the workaround is to > go back to the file copy deploy approach. -- 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: (MNGECLIPSE-89) Compile goal fails with exception
[ http://jira.codehaus.org/browse/MNGECLIPSE-89?page=comments#action_66961 ] Dale King commented on MNGECLIPSE-89: - I understand why the problem happens. But I think there is still the issue that this is very likely to occur with other users and there is nothing in build errors to tell you why you are unable to build. I think the Maven Eclipse plug-in should do a check when it starts a build to check to see if the user has inadvertantly set up their JRE to point to a JRE instead of a JDK and give them an alert telling them that they will not be able to build Java unless they correct this. > Compile goal fails with exception > - > > Key: MNGECLIPSE-89 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-89 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Maven Launcher > Versions: 0.0.5 > Environment: Windows XP, Eclipse 3.1.2 > Reporter: Dale King > Assignee: Eugene Kuleshov > > > Used archetype to generate project as specified in Maven documentation and > use that generated folder as Eclipse project. Enable Maven for the project. > Can build from the command line, but trying to compile from Maven in Eclipse > fails: > [INFO] > > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [clean, compile] > [INFO] > > [INFO] clean:clean > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\classes > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\test-classes > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > Compiling 1 source file to C:\EclipseWorkspace\my-app\target\classes > [ERROR] mojo-execute : compiler:compile > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : com.mycompany.app:my-app:jar:1.0-SNAPSHOT ( > task-segment: [clean, compile] ) > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 8 more > Here is the command line output from doing the same thing: > C:\EclipseWorkspace\my-app>mvn clean compile > [INFO] Scanning for projects... > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [clean, compile] > [INFO] > - > --- > [INFO] [clean:clean] > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\classes > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > Compiling 1 source file to C:\EclipseWorkspace\my-app\target\classes > [INFO] > - > --- > [INFO] BUILD SUCCESSFUL > [INFO] > - > --- > [INFO] Total time: 7 seconds > [INFO] Finished at: Tue Mar 21 20:38:54 EST 2006 > [INFO] Final Memory: 2M/8M > [INFO] > ---
[jira] Commented: (MNGECLIPSE-89) Compile goal fails with exception
[ http://jira.codehaus.org/browse/MNGECLIPSE-89?page=comments#action_66962 ] Eugene Kuleshov commented on MNGECLIPSE-89: --- Dale, since there are whole bunch of cases when JDK is not needed at all, I would suggest you to raise issue for Maven compiler plugin to provide more humane error. So, this warning will be done in a single place as oppose to do it for every tool that is integrating Maven. BTW, you can probably configure compiler plugin to use eclipse compiler or even external javac command which will run just fine on JRE... > Compile goal fails with exception > - > > Key: MNGECLIPSE-89 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-89 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Maven Launcher > Versions: 0.0.5 > Environment: Windows XP, Eclipse 3.1.2 > Reporter: Dale King > Assignee: Eugene Kuleshov > > > Used archetype to generate project as specified in Maven documentation and > use that generated folder as Eclipse project. Enable Maven for the project. > Can build from the command line, but trying to compile from Maven in Eclipse > fails: > [INFO] > > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [clean, compile] > [INFO] > > [INFO] clean:clean > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\classes > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\test-classes > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > Compiling 1 source file to C:\EclipseWorkspace\my-app\target\classes > [ERROR] mojo-execute : compiler:compile > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : com.mycompany.app:my-app:jar:1.0-SNAPSHOT ( > task-segment: [clean, compile] ) > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 8 more > Here is the command line output from doing the same thing: > C:\EclipseWorkspace\my-app>mvn clean compile > [INFO] Scanning for projects... > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [clean, compile] > [INFO] > - > --- > [INFO] [clean:clean] > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\classes > [INFO] Deleting directory C:\EclipseWorkspace\my-app\target\test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > Compiling 1 source file to C:\EclipseWorkspace\my-app\target\classes > [INFO] > - > --- > [INFO] BUILD SUCCESSFUL > [INFO] > - > --- > [INFO] Total time: 7 seconds > [INFO] Finished at: Tue Mar 21 20:38:54 EST 2006 > [INFO] Final Memory: 2M/8M > [INFO] > - >
[jira] Closed: (MAVENUPLOAD-931) Echomine Feridian Version 1.0b2 Maven Uploads
[ http://jira.codehaus.org/browse/MAVENUPLOAD-931?page=all ] Chris Chen closed MAVENUPLOAD-931: -- Resolution: Incomplete I am closing my own issue as incomplete because I am making Feridian fully maven-ready in the next update version. Thus, this request is no longer necessary. Thanks, Chris > Echomine Feridian Version 1.0b2 Maven Uploads > - > > Key: MAVENUPLOAD-931 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-931 > Project: maven-upload-requests > Type: Task > Reporter: Chris Chen > > > Feridian xmpp module > http://open.echomine.org/feridian/feridian-xmpp-1.0b2-bundle.jar > http://open.echomine.org/confluence/display/FERIDIAN > http://open.echomine.org/confluence/display/EM/General+News > > Feridian jabber module > http://open.echomine.org/feridian/feridian-jabber-1.0b2-bundle.jar > http://open.echomine.org/confluence/display/FERIDIAN > http://open.echomine.org/confluence/display/EM/General+News > > Feridian jabber-compat module > http://open.echomine.org/feridian/feridian-jabber-compat-1.0b2-bundle.jar > http://open.echomine.org/confluence/display/FERIDIAN > http://open.echomine.org/confluence/display/EM/General+News -- 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: (MNGECLIPSE-135) "Password Required" dialog requires user/password to be re-enter for each project
"Password Required" dialog requires user/password to be re-enter for each
project
-
Key: MNGECLIPSE-135
URL: http://jira.codehaus.org/browse/MNGECLIPSE-135
Project: Maven 2.x Extension for Eclipse
Type: Improvement
Versions: 0.0.9
Environment: Maven (2.0.4)
m2eclipse 0.0.9
Eclipse 3.1.2
Reporter: Jimisola Laursen
Assigned to: Eugene Kuleshov
Priority: Minor
Have an internal Maven repository that I use https to connect to.
I have multi-module Maven project and hence a project in Eclipse for each
module - with dependencies between them.
When I start up Eclipse I am kindly asked for the username and password. But,
not once. It is requested for each project even do the site ("Connect to") is
the same for all projects.
It would be nice if the m2eclipse plugin could somewhat remember this without
the need for me to reenter it for each project. Perhaps even an option to
"Remember this login information.".
I originally filed this enhancement request towards Eclipse Platform
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=145999) as I thought it was
included in the platform, but according to the Eclipse guys this is a Maven
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] Commented: (MRELEASE-123) release plugin does not take commandline parameters into account
[ http://jira.codehaus.org/browse/MRELEASE-123?page=comments#action_66966 ] Jorg Heymans commented on MRELEASE-123: --- toying around with this, it seems that mvn release:prepare -N -Darguments=-N does seem to work for releasing a top-level pom only. It's a bit counter-intuitive at first but makes sense when you think about it. The first -N kicks in at the command line directly and the second one when the integration run is forked. > release plugin does not take commandline parameters into account > > > Key: MRELEASE-123 > URL: http://jira.codehaus.org/browse/MRELEASE-123 > Project: Maven 2.x Release Plugin > Type: Bug > Versions: 2.0-beta-4 > Reporter: Jorg Heymans > > > i would like to do a release of a top-level pom only : intuitively i do "mvn > -N release:prepare". During release preparation the -N parameter is left out > however and maven does a full integration on all child modules and > subsequently includes them in the release process. -- 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-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=comments#action_66968 ] Balaji Ravi commented on SUREFIRE-46: - I have attached a test case for this bug. The problem is that the URL's being put in to the URLClassLoader have spaces in them & when the RMIClassLoader or something else uses a StringTokenizer to get the URL's, it splits them because of the spaces in to 2 urls... Ideally, when putting the URL's in the classloader, we should properly escape it. It is a bug in File.toURL method & sun has recognized that & because of some compatibility issues, they have provided a workaround to use File.toURI().toURL(); Hope this helps... > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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: (MNGECLIPSE-135) "Password Required" dialog requires user/password to be re-enter for each project
[ http://jira.codehaus.org/browse/MNGECLIPSE-135?page=comments#action_66969
]
Eugene Kuleshov commented on MNGECLIPSE-135:
We don't have any code for asking user and password in the plugin. Can you
attach a screenshot of that dialog you getting?
I suspect that eclipse register own java.net.Authenticator that handle all the
passwords and embedder just don't know anything about it...
Anyways, since we don't have any repository with auth and can't easily
reproduce it will be really low priority. unless somebody will investigate it
and provide patches.
> "Password Required" dialog requires user/password to be re-enter for each
> project
> -
>
> Key: MNGECLIPSE-135
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-135
> Project: Maven 2.x Extension for Eclipse
> Type: Improvement
> Versions: 0.0.9
> Environment: Maven (2.0.4)
> m2eclipse 0.0.9
> Eclipse 3.1.2
> Reporter: Jimisola Laursen
> Assignee: Eugene Kuleshov
> Priority: Minor
>
>
> Have an internal Maven repository that I use https to connect to.
> I have multi-module Maven project and hence a project in Eclipse for each
> module - with dependencies between them.
> When I start up Eclipse I am kindly asked for the username and password. But,
> not once. It is requested for each project even do the site ("Connect to") is
> the same for all projects.
> It would be nice if the m2eclipse plugin could somewhat remember this without
> the need for me to reenter it for each project. Perhaps even an option to
> "Remember this login information.".
> I originally filed this enhancement request towards Eclipse Platform
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=145999) as I thought it was
> included in the platform, but according to the Eclipse guys this is a Maven
> 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] Updated: (SUREFIRE-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=all ] Balaji Ravi updated SUREFIRE-46: Attachment: pom.xml > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: SurefirebugTest.java, pom.xml, pom.xml, surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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: (SUREFIRE-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=all ] Balaji Ravi updated SUREFIRE-46: Attachment: SurefirebugTest.java pom.xml > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: SurefirebugTest.java, pom.xml, pom.xml, surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_66973 ]
Prasad Kashyap commented on MNG-624:
The Geronimo project has about 145 pom.xmls layered in 3 to 4 tiers.
Ideally, we would like to set the version in one single place and use it
repeatedly everywhere. This would include the version for the and for
the . Example :
org.apache.geronimo
geronimo-parent
${geronimoVersion}
4.0.0
org.apache.geronimo.applications
applications-parent
${geronimoVersion}
...
Such a thing is not possible.
If we want to do a top level build with 1 single 'mvn' command, then we cannot
use ${geronimoVersion} while declaring the project's and
parent's version. We will have to explicitly define the version. That would
mean changing every single pom.xml every time the release
changes.
Setting the version in -D doesn't work either.
> automatic parent versioning
> ---
>
> Key: MNG-624
> URL: http://jira.codehaus.org/browse/MNG-624
> Project: Maven 2
> Type: Improvement
> Components: Inheritence and Interpolation
> Reporter: Brett Porter
> Assignee: Brett Porter
> Priority: Blocker
> Fix For: 2.1
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
> MNG-521)
> currently, you have to specify the parent version when extending which makes
> a project stand alone very easily, but has the drawback of being a
> maintainance problem when you start development on a new version. Tools can
> help, but it would be nice not to have to rely on them.
> One alternative is to allow the parent version to be omitted, and when it is
> it is assumed you want the latest. The parent is used from the reactor or the
> universal source directory. IT may also be read from a LATEST in the
> repository though this is contentious - it may be better to simply fail in
> that environment and require builds be in a known checkout structure for
> building individual projects.
> This also introduces the need for tool support to populate the version on
> release and deployment for reproducibility.
--
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: (CONTINUUM-725) CLONE -Cannot reference POM via http link with authentication
CLONE -Cannot reference POM via http link with authentication - Key: CONTINUUM-725 URL: http://jira.codehaus.org/browse/CONTINUUM-725 Project: Continuum Type: Bug Reporter: Scott McLachlan Assigned to: Emmanuel Venisse Fix For: 1.0.3 Continuum is not able to download a POM from a URL like http://user:[EMAIL PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this issue, but they've been closed almost 6 months ago. Has this feature been left out of the 1.0.2 release? -- 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: (CONTINUUM-726) CLONE -Cannot reference POM via http link with authentication
CLONE -Cannot reference POM via http link with authentication - Key: CONTINUUM-726 URL: http://jira.codehaus.org/browse/CONTINUUM-726 Project: Continuum Type: Bug Reporter: Scott McLachlan Assigned to: Emmanuel Venisse Fix For: 1.0.3 Continuum is not able to download a POM from a URL like http://user:[EMAIL PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this issue, but they've been closed almost 6 months ago. Has this feature been left out of the 1.0.2 release? -- 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: (CONTINUUM-725) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-725?page=comments#action_66974 ] Scott McLachlan commented on CONTINUUM-725: --- This issue is not resolved. I get the following error message in my log: jvm 1| 2006-06-08 15:23:01,054 [SocketListener0-0] INFO ContinuumProjectBuilder:maven-two-builder - Downloading https://scc.cerebit.com/svn/sample/trunk/proficio/pom.xml jvm 1| 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - Created 0 projects. jvm 1| 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - Created 0 project groups. jvm 1| 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - 1 warnings. jvm 1| 2006-06-08 15:23:01,156 [SocketListener0-0] INFO Continuum - Could not download https://my.server.com/svn/sample/trunk/proficio/pom.xml: Server returned HTTP response code: 401 for URL: https://my.server.com/svn/sample/trunk/proficio/pom.xml The URL is good and the username:password are good. If I use the same parameters in the Ant project setup i can connect fine to subversion. > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-725 > URL: http://jira.codehaus.org/browse/CONTINUUM-725 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 release? -- 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: (MRELEASE-114) ${project.artifactId} was replaced with it's value during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-114?page=comments#action_66975 ]
Richard van der Hoff commented on MRELEASE-114:
---
Yes it is, and it's very annoying.
Sounds like a duplicate of MRELEASE-16 to me.
> ${project.artifactId} was replaced with it's value during release:perform
> -
>
> Key: MRELEASE-114
> URL: http://jira.codehaus.org/browse/MRELEASE-114
> Project: Maven 2.x Release Plugin
> Type: Bug
> Environment: Windows XP, Java 1.4.2
> Reporter: Paul Spencer
>
>
> In release:perform, the variable ${project.artifactId} was replaced with it's
> value in the connection and developerConnection tags in the pom. This did NOT
> happen in other place in the pom!
> Before release:
> scm:cvs:pserver:[EMAIL
> PROTECTED]:/bar:${project.artifactId}
> After release:
> scm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom
> BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
> related to the above problem.
--
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-1408) filesetId does not contain all dependencies when artifact was not yet locally installed
[ http://jira.codehaus.org/browse/MNG-1408?page=comments#action_66977 ] Chris Hilton commented on MNG-1408: --- Did anyone verify or not if the patch is the "right" way to fix this? It seems to fix the path issues I've been having, but I'm wondering if I'm trading one set of problems for another. I'm also a bit concerned that this bug had its fix version removed; does that mean there's something wrong with the patch? As stated above, this is quite a blocker for those of trying to migrate from Ant. > filesetId does not contain all dependencies when artifact was not yet locally > installed > --- > > Key: MNG-1408 > URL: http://jira.codehaus.org/browse/MNG-1408 > Project: Maven 2 > Type: Bug > Components: Ant tasks > Versions: 2.0 > Environment: java version "1.4.2_04", Linux 2.6.11.12, Apache Ant version > 1.6.5 > Reporter: Ingo Weichsel > Attachments: patch.txt > > > In the artifact:dependencies task the filesetId is only correctly set, when > the artifact was installed locally before running ant. > After deletion of the local repository the dependant artifacts will be > downloaded to the local repository, but only one of two dependant files will > be included in the ant fileset. The classpath is set correctly. > After running "mvn install" locally for the "as-base-launcher" maven project, > ant computes the correct filesetId. > The ant-project depends on the artifact "as-base-launcher" which itselfs > depends only on classworlds. Snippets from ant buildfiles, poms and ant > output follows: > From the ant buildfile: > > > > pathId="as-launcher.classpath" verbose="true"> > > > > > > > > > > > > > > > > > The referenced POM defining the ant dependencies: > > 4.0.0 > actis > ant-as-base > 1.0-SNAPSHOT > > > actis > as-base-launcher > 1.0-SNAPSHOT > > > > > actisRepository > actisRepository > http://company.com:/repository/ > > > > Output of the ant run: > launcherJAR: > actis:ant-as-base:jar:1.0-SNAPSHOT (selected) > actis:as-base-launcher:jar:1.0-SNAPSHOT (selected) > classworlds:classworlds:jar:1.1-alpha-1 (selected) > [echo] CLASSPATH: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar:/home/iwe/.m2/repository/actis/as-base-launcher/1.0-20051103.102305-8/as-base-launcher-1.0-20051103.102305-8.jar > [echo] FILESET: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar -- 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-46) Proper escape of classpath entries esp. in windows
[ http://jira.codehaus.org/browse/SUREFIRE-46?page=comments#action_66979 ] Olivier Lamy commented on SUREFIRE-46: -- Hi, There is a lot of bugs in http://bugs.sun.com/bugdatabase concerning this. You have some workarounds : - no more using windows ;-) - adding an element in your settings -- Olivier > Proper escape of classpath entries esp. in windows > -- > > Key: SUREFIRE-46 > URL: http://jira.codehaus.org/browse/SUREFIRE-46 > Project: surefire > Type: Bug > Versions: 2.0 > Environment: Windows > Reporter: Balaji Ravi > Attachments: SurefirebugTest.java, pom.xml, pom.xml, surefire-booter.patch > > > When a classpath entry has a directory with spaces, surefire booter class > doesn't properly create the URL. i.e. it doesn't escape the url's added. > I have attached a patch that would fix this problem. -- 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: (MNGECLIPSE-135) "Password Required" dialog requires user/password to be re-enter for each project
[ http://jira.codehaus.org/browse/MNGECLIPSE-135?page=comments#action_66981
]
Jimisola Laursen commented on MNGECLIPSE-135:
-
Eugene,
I think you are right about it being an Eclipse issue with
java.net.Authenticator after all.
If you you check bug #145999 at eclipse.org (see link in original description),
you'll see that after the bug was closed someone seem to have come to the same
conclusion with it being java.net.Authenticator after all.
Perhaps you could take a glance?
I want be able to provide a screenshot until tomorrow.
> "Password Required" dialog requires user/password to be re-enter for each
> project
> -
>
> Key: MNGECLIPSE-135
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-135
> Project: Maven 2.x Extension for Eclipse
> Type: Improvement
> Versions: 0.0.9
> Environment: Maven (2.0.4)
> m2eclipse 0.0.9
> Eclipse 3.1.2
> Reporter: Jimisola Laursen
> Assignee: Eugene Kuleshov
> Priority: Minor
>
>
> Have an internal Maven repository that I use https to connect to.
> I have multi-module Maven project and hence a project in Eclipse for each
> module - with dependencies between them.
> When I start up Eclipse I am kindly asked for the username and password. But,
> not once. It is requested for each project even do the site ("Connect to") is
> the same for all projects.
> It would be nice if the m2eclipse plugin could somewhat remember this without
> the need for me to reenter it for each project. Perhaps even an option to
> "Remember this login information.".
> I originally filed this enhancement request towards Eclipse Platform
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=145999) as I thought it was
> included in the platform, but according to the Eclipse guys this is a Maven
> 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] Commented: (MNGECLIPSE-134) wizard for creating java project from existing pom.xml
[ http://jira.codehaus.org/browse/MNGECLIPSE-134?page=comments#action_66980 ] Scott Cytacki commented on MNGECLIPSE-134: -- Here are the steps I have to do when checking out a simple maven project: - give it a name: there is no default name suggested by the New Java Project wizard - specify the jre - set the src/main/java and src/test/java folders as source folders - change the output folder: I prefer to separate it from target/classes so the too compilers don't collide - use Maven2->Enable Maven I think those steps are worth a wizard. Really they are just setting up the defaults for the new java project wizard. Hopefully it is easy to set those defaults. > wizard for creating java project from existing pom.xml > -- > > Key: MNGECLIPSE-134 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-134 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Wizards > Reporter: Scott Cytacki > Assignee: Eugene Kuleshov > > > When checking out a maven project from an scm that doesn't include .project > .classpath files. It would be nice if the maven plugin gave the option to > create the eclipse java project as it is being checked out. This is appears > to be handled by making a new project wizard. > An example of similar functionality is when checking out a ant based project > you can create an eclipse project from it. > The current solution is to check it out and then fix it up after the fact, by > adding the maven library, or instead runing the eclipse:eclipse goal. > The wizard could detect things like multimodule projects and at least give > some advice to the user, or better it might beable to give the user different > options for handling 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: (MNGECLIPSE-135) "Password Required" dialog requires user/password to be re-enter for each project
[ http://jira.codehaus.org/browse/MNGECLIPSE-135?page=all ]
Eugene Kuleshov updated MNGECLIPSE-135:
---
Comment: was deleted
> "Password Required" dialog requires user/password to be re-enter for each
> project
> -
>
> Key: MNGECLIPSE-135
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-135
> Project: Maven 2.x Extension for Eclipse
> Type: Improvement
> Versions: 0.0.9
> Environment: Maven (2.0.4)
> m2eclipse 0.0.9
> Eclipse 3.1.2
> Reporter: Jimisola Laursen
> Assignee: Eugene Kuleshov
> Priority: Minor
>
>
> Have an internal Maven repository that I use https to connect to.
> I have multi-module Maven project and hence a project in Eclipse for each
> module - with dependencies between them.
> When I start up Eclipse I am kindly asked for the username and password. But,
> not once. It is requested for each project even do the site ("Connect to") is
> the same for all projects.
> It would be nice if the m2eclipse plugin could somewhat remember this without
> the need for me to reenter it for each project. Perhaps even an option to
> "Remember this login information.".
> I originally filed this enhancement request towards Eclipse Platform
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=145999) as I thought it was
> included in the platform, but according to the Eclipse guys this is a Maven
> 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] Commented: (MSUREFIRE-131) Surefire-JUnit does not recognize "suite"-methods
[ http://jira.codehaus.org/browse/MSUREFIRE-131?page=comments#action_66985
]
Bryce Nordgren commented on MSUREFIRE-131:
--
I think I just ran into this as well but didn't know how to phrase the
question. I'm trying to make a maven2 POM for the jakarta commons-events
project (which is dormant.) Their naming convention is a little askew, so I
tried to add an {{}} element to explicitly specify the
"AllTestsSuite.java" which constructs a gigantic TestSuite. {{mvn test}} just
results in a "No tests to run" complaint. Removing the includes element and
renaming the file to end in "Test.java" makes maven find the test and complete
without error. I'll try this patch and see if it cures my ills, then report
back.
> Surefire-JUnit does not recognize "suite"-methods
> -
>
> Key: MSUREFIRE-131
> URL: http://jira.codehaus.org/browse/MSUREFIRE-131
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.2
> Reporter: Philip Gerlach
> Attachments: maven-surefire-junit-trunk-412516.patch
>
>
> Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
> "suite"-method like
> --
> public static junit.framework.Test suite() {
>return new junit.framework.JUnit4TestAdapter(Foo.class);
> }
> -
> to run it, but Surefire-JUnit did not recognize these methods and treated
> them like PojoTests what obviously lead to TestFailures.
> So I fetched the source code from the repository and searched for the
> problem. I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite
> that did not test for the "suite"-mechanism, so I wrote a new static method
> to test for this situation and integrated it in the if-conditions.
> Now the "suite"-methods work for my JUnit4 Tests and should do also for
> others ;-)
> The patch is attached.
> P.S. Since this it is the first time, I'm trying to bugfix something for an
> open source-project, please just let me know, if I have done something wrong
> with this process.
--
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: (MSUREFIRE-131) Surefire-JUnit does not recognize "suite"-methods
[ http://jira.codehaus.org/browse/MSUREFIRE-131?page=comments#action_66986
]
Bryce Nordgren commented on MSUREFIRE-131:
--
No joy. This does not appear to be my solution. I'll keep looking...
> Surefire-JUnit does not recognize "suite"-methods
> -
>
> Key: MSUREFIRE-131
> URL: http://jira.codehaus.org/browse/MSUREFIRE-131
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.2
> Reporter: Philip Gerlach
> Attachments: maven-surefire-junit-trunk-412516.patch
>
>
> Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
> "suite"-method like
> --
> public static junit.framework.Test suite() {
>return new junit.framework.JUnit4TestAdapter(Foo.class);
> }
> -
> to run it, but Surefire-JUnit did not recognize these methods and treated
> them like PojoTests what obviously lead to TestFailures.
> So I fetched the source code from the repository and searched for the
> problem. I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite
> that did not test for the "suite"-mechanism, so I wrote a new static method
> to test for this situation and integrated it in the if-conditions.
> Now the "suite"-methods work for my JUnit4 Tests and should do also for
> others ;-)
> The patch is attached.
> P.S. Since this it is the first time, I'm trying to bugfix something for an
> open source-project, please just let me know, if I have done something wrong
> with this process.
--
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: (MNGECLIPSE-80) Project information
[ http://jira.codehaus.org/browse/MNGECLIPSE-80?page=comments#action_66987 ] Jimisola Laursen commented on MNGECLIPSE-80: It seems (by the look) as if the current project site on http://m2eclipse.codehaus.org/ uses Maven site. I also noticed that the main Maven page has an "Eclipse plugin" section: http://maven.apache.org/eclipse-plugin.html Wouldn't it be better if they linked directly to the project site on codehaus? > Project information > --- > > Key: MNGECLIPSE-80 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-80 > Project: Maven 2.x Extension for Eclipse > Type: Wish > Components: Documentation > Reporter: Jimisola Laursen > Assignee: Eugene Kuleshov > Priority: Minor > > > Have been looking around for project information, but can seem to find any. > Filing an issue was my last resort. Hope it does not cause any inconveniance. > Can't seem to find a project page with project information such as road map, > status/news (about releases etc) ,developers, contact information, link to > Jira issue tracker. > Such a project page would be highly appreciated. The closest I've come to > find is www.codehaus.org/Projects, but are the mailing lists used? > There is no activity appearently - at least there does not seem to be any > posts > in [EMAIL PROTECTED] mailing list - is the plugin discussed elsewhere? > Jimisola -- 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] Deleted: (CONTINUUM-726) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-726?page=all ] Brett Porter deleted CONTINUUM-726: --- > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-726 > URL: http://jira.codehaus.org/browse/CONTINUUM-726 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 release? -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_66990 ]
Brett Porter commented on MNG-624:
--
you never need a ${geronimoVersion} property. version is inherited. And you'll
have to specify the parent version until this new feature is implemented (you
can't get the version of the parent to use from the parent :)
You can use the release plugin to automatically update these for you in the
mean time.
> automatic parent versioning
> ---
>
> Key: MNG-624
> URL: http://jira.codehaus.org/browse/MNG-624
> Project: Maven 2
> Type: Improvement
> Components: Inheritence and Interpolation
> Reporter: Brett Porter
> Assignee: Brett Porter
> Priority: Blocker
> Fix For: 2.1
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
> MNG-521)
> currently, you have to specify the parent version when extending which makes
> a project stand alone very easily, but has the drawback of being a
> maintainance problem when you start development on a new version. Tools can
> help, but it would be nice not to have to rely on them.
> One alternative is to allow the parent version to be omitted, and when it is
> it is assumed you want the latest. The parent is used from the reactor or the
> universal source directory. IT may also be read from a LATEST in the
> repository though this is contentious - it may be better to simply fail in
> that environment and require builds be in a known checkout structure for
> building individual projects.
> This also introduces the need for tool support to populate the version on
> release and deployment for reproducibility.
--
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: (CONTINUUM-725) CLONE -Cannot reference POM via http link with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-725?page=comments#action_66992 ] Brett Porter commented on CONTINUUM-725: what issue did you clone? > CLONE -Cannot reference POM via http link with authentication > - > > Key: CONTINUUM-725 > URL: http://jira.codehaus.org/browse/CONTINUUM-725 > Project: Continuum > Type: Bug > Reporter: Scott McLachlan > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > Continuum is not able to download a POM from a URL like http://user:[EMAIL > PROTECTED]/trunk/pom.xml. I've seen a number of bugs posted relating to this > issue, but they've been closed almost 6 months ago. Has this feature been > left out of the 1.0.2 release? -- 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: (MNGECLIPSE-134) wizard for creating java project from existing pom.xml
[ http://jira.codehaus.org/browse/MNGECLIPSE-134?page=all ] Eugene Kuleshov updated MNGECLIPSE-134: --- Priority: Minor (was: Major) Instead of your steps 2, 3 and 4 you can use Maven2->Update Source Folders action. It suppose to do exactly that. We have an open issu in regards to the target folder and as I suggested there you can set your preferred defaults for project target folder in global Eclipse properties. Anyways, I am changing priority to minor. There is already stub for Maven project in the code so if somebody would like to finish it we will be glad to apply patch. > wizard for creating java project from existing pom.xml > -- > > Key: MNGECLIPSE-134 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-134 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Wizards > Reporter: Scott Cytacki > Assignee: Eugene Kuleshov > Priority: Minor > > > When checking out a maven project from an scm that doesn't include .project > .classpath files. It would be nice if the maven plugin gave the option to > create the eclipse java project as it is being checked out. This is appears > to be handled by making a new project wizard. > An example of similar functionality is when checking out a ant based project > you can create an eclipse project from it. > The current solution is to check it out and then fix it up after the fact, by > adding the maven library, or instead runing the eclipse:eclipse goal. > The wizard could detect things like multimodule projects and at least give > some advice to the user, or better it might beable to give the user different > options for handling 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: (MRM-66) Repository configuration
[ http://jira.codehaus.org/browse/MRM-66?page=all ] John Tolentino updated MRM-66: -- Remaining Estimate: 16 hours Original Estimate: 16 hours > Repository configuration > > > Key: MRM-66 > URL: http://jira.codehaus.org/browse/MRM-66 > Project: Maven Repository Manager > Type: Task > Reporter: Maria Odea Ching > Assignee: John Tolentino > Fix For: 1.0-beta-1 > > Original Estimate: 16 hours > Remaining: 16 hours > > A configuration file will be retrieved and read by the Administration module. > Then the values will be set on the specific class(es) that will use this > configuration. Configurable fields: repositories, location of local cache and > if repositories are browsable. -- 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: (MSUREFIRE-132) Odd Filename/inner class dependant behavior (and some junit tests)
Odd Filename/inner class dependant behavior (and some junit tests)
--
Key: MSUREFIRE-132
URL: http://jira.codehaus.org/browse/MSUREFIRE-132
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.2
Reporter: Bryce Nordgren
Priority: Minor
Attachments: surefire-junit-tests.patch
I started this because I couldn't get maven 2 to recognize the tests which came
with Jakarta commons-events. The problem boils down to the fact that there are
many files/classes which implement tests, but they are all collated by a single
TestSuite, called AllTestSuite.java, which extends TestCase. I am able to make
maven run the tests merely by renaming this file to AllSuiteTest.java, and no
other changes.
I tried adding an {{}} element with the original name, but this did
not pick up the tests. Surefire reliably reports that there are no tests to
run.
I did some remedial testing with junit tests (coded against the surefire-junit
trunk). I was unable to reproduce this behavior, but I did uncover wierd
behavior with TestCases as inner classes. The patch against surefire-junit
trunk is included and includes only minor changes to the POM and the tests I
wrote.
--
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
