maven kodo plugin
Hi All, Could anybody tell me that is there any new plugin released for enhancing the persistent classes by kodo enhancer like maven-kodo-plugin-4.0.0-EA3 - this one is compatible with KODO 4.0.1 but we need it for KODO 4.1.4 or KODO 4.2. Please note, we are using maven 1.0.2. Warm Regards, Chandramohan Sawant Infosys Technologies Ltd PUNE, INDIA Direct : +91 20 4023 5756 Mobile: +91 9923330445 CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
[jira] Commented: (MCOMPILER-30) Compiler fork executable fails when the path has spaces
[
http://jira.codehaus.org/browse/MCOMPILER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182221#action_182221
]
Hilal Ram commented on MCOMPILER-30:
HOW TO FIX THIS ISSUE
This is how you can Quick Fix this issue...
Go to your compile plugin -- Remove the true Element ; the build
works fine.
maven-compiler-plugin
${JAVA_HOME_1.5}/bin/javac.exe
1.5
1.5
1.5
> Compiler fork executable fails when the path has spaces
> ---
>
> Key: MCOMPILER-30
> URL: http://jira.codehaus.org/browse/MCOMPILER-30
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Carlos Sanchez
>
> JAVA_1_3_HOME=C:\Program Files\Java\jdk1.3.1_18
>
> maven-compiler-plugin
>
> true
> 1.3
> ${JAVA_1_3_HOME}/bin/javac
>
>
> Fails with
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-201) Copy zip file in WEB-INF/lib
Copy zip file in WEB-INF/lib Key: MWAR-201 URL: http://jira.codehaus.org/browse/MWAR-201 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.0.1 Environment: I have a composant zip file, but it isn't copy into my war Reporter: adrien ruffie Attachments: pom.xml I have a zip file, and I need to copy it in WEB-INF/lib of my war (the zip file, not all content). I try with adding andfiltering external web resources and overlay, but not successful. I can see this row, during debug : [DEBUG] Skipping artifact of type zip for WEB-INF/lib I attached the pom.xml within this issue -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2491) XQParser Upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Abos closed MAVENUPLOAD-2491. Resolution: Won't Fix Package is not stable > XQParser Upload request > --- > > Key: MAVENUPLOAD-2491 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2491 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Damien Abos > > I'm the developer of xqparser sourceforge project, please upload! > Thanks you :) > leejin (Damien Abos) -- 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: (MCOMPILER-74) build failure when executable path contains spaces
[
http://jira.codehaus.org/browse/MCOMPILER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182239#action_182239
]
Vincent Siveton commented on MCOMPILER-74:
--
Hilal, you need to use the compiler plugin 2.1-SNAPSHOT
I just deployed a new snapshot and you need to add the following in your pom:
{noformat}
apache.snapshots
http://repository.apache.org/snapshots
false
{noformat}
> build failure when executable path contains spaces
> --
>
> Key: MCOMPILER-74
> URL: http://jira.codehaus.org/browse/MCOMPILER-74
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2, 2.1
> Environment: windows xp, maven 2.0.9
>Reporter: Greg Hengeli
>Assignee: Vincent Siveton
> Fix For: 2.1
>
>
> When compiling a project with an executable that has spaces in its path, a
> build failure is encountered. This can be reproduced by following the exact
> example given on the Maven Compiler Plugin home page
> (http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html)
> This seems to be already mentioned in MCOMPILER-30 (which is closed) but
> there is a comment after it was closed stating it still doesn't work.
> One potential solution I have found is to use version 1.5.1 of plexus-utils -
> should this be updated in the maven-compiler-plugin's pom or is there a
> better solution?
> [INFO] -
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.BuildFailureException: Compilation failure
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
> at java.lang.reflect.Method.invoke(Method.java:391)
> 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.CompilationFailureException: Compilation
> failure
> Failure executing javac, but could not parse the error:
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
> at
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:562)
> at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:115)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> ... 17 more
> [INFO]
>
> [INFO] To
[jira] Created: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
Synchronize dnsjava-osgi Maven Repository - Key: MAVENUPLOAD-2503 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 Project: Maven Upload Requests Issue Type: Wish Reporter: Robert Burrell Donkin This project was created to package an upstream dependency for Apache James (and probably other projects too) suitably for Maven (and OSGi). The upstream maintainer is not interested in maintaining meta-data for Maven so it was agreed that a separate downstream project made more sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182241#action_182241 ] Robert Burrell Donkin commented on MAVENUPLOAD-2503: "net.sf.dnsjavaosgi","mavens...@web.sourceforge.net:/home/groups/d/dn/dnsjava-osgi/htdocs/m2","rsync_ssh","Robert Burrell Donkin","rdon...@apache.org",, > Synchronize dnsjava-osgi Maven Repository > - > > Key: MAVENUPLOAD-2503 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Robert Burrell Donkin > > This project was created to package an upstream dependency for Apache James > (and probably other projects too) suitably for Maven (and OSGi). The upstream > maintainer is not interested in maintaining meta-data for Maven so it was > agreed that a separate downstream project made more sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2503) Synchronize dnsjava-osgi Maven Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182242#action_182242 ] Robert Burrell Donkin commented on MAVENUPLOAD-2503: This is the first time I've tried to setup something like this at SourceForge so appologies in advance for any mistakes I've made > Synchronize dnsjava-osgi Maven Repository > - > > Key: MAVENUPLOAD-2503 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2503 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Robert Burrell Donkin > > This project was created to package an upstream dependency for Apache James > (and probably other projects too) suitably for Maven (and OSGi). The upstream > maintainer is not interested in maintaining meta-data for Maven so it was > agreed that a separate downstream project made more sense. -- 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-2504) Authomatical Repository Synchronization
Authomatical Repository Synchronization --- Key: MAVENUPLOAD-2504 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2504 Project: Maven Upload Requests Issue Type: Wish Reporter: Dmitry Buzdin "net.sf.dozer","mavens...@web.sourceforge.net:/home/groups/d/do/dozer/htdocs/m2repo","rsync_ssh","Dmitry Buzdin","buz...@gmail.com",, -- 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: (SUREFIRE-555) Support junit core for parallel running of tests
Support junit core for parallel running of tests Key: SUREFIRE-555 URL: http://jira.codehaus.org/browse/SUREFIRE-555 Project: Maven Surefire Issue Type: New Feature Environment: All Reporter: Kristian Rosenvold Attachments: surefire.patch The enclosed patch adds junitcore support to surefire. The patch requires junit 4.6 (the latest released version) to compile, but is only activated when running with the 4.7 snapshot or higher (due to some bugs in 4.6). The patch adds one extra setting to the surefire plugin. More details at http://incodewetrustinc.blogspot.com/ The new plugin also requires an external library which can be found at http://github.com/krosenvold/configurable-parallel-computer/tree/master, which will be bumped to 1.0 when/if you decide to accept the patch. I am requesting that the junit project actually accept the features of the configurable-parallel-computer as a standard feature in junit 4.7, but that's not decided yet. I do not have a public maven repo that is hosting configurable-parallel-computer, but was hoping maybe you could publish 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] Commented: (MSITE-409) Incorrect URLs in multi-module project
[ http://jira.codehaus.org/browse/MSITE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182259#action_182259 ] Benson Margulies commented on MSITE-409: I'm not on Linux and this problem happens with plain old site:deploy. The site plugin is assuming that the tree hierarchy and the parent hierarchy are the same. This is not necessarily the state of affairs. Some of us have additional levels of parent that are used to share configuration with a different topology than our tree of relationships. The parent relationship is not necessarily simply a backpointer to the module relationship. > Incorrect URLs in multi-module project > -- > > Key: MSITE-409 > URL: http://jira.codehaus.org/browse/MSITE-409 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: Benson Margulies > > I have a top-level pom and some modules. One of the modules serves as a > parent for most, but not all, of the rest. > Thus, for most, the parent is ../parent, and for that the parent is the > top-level project itself. > I ran: > mvn site:stage -DstagingDirectory=/Users/benson/stage > It takes a very long time. > All of my child links came out incorrectly: e.g: > href="../../Users/benson/x/trunk/greenhouse/etrog/../../../../hudson.basistech.net/home/projects/etrog">RLPJ > Buildtools > There aren't distinct subdirectories in the staged dir for those of my > modules that use the parent. Actually, now that I look, I see that the ones > that parent into ../parent are subdirectories of 'parent' instead of > subdirectories of the top-level. But the links are still all wrong. -- 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-249) Add Apache Camel WAR archetype to internal catalog
Add Apache Camel WAR archetype to internal catalog -- Key: ARCHETYPE-249 URL: http://jira.codehaus.org/browse/ARCHETYPE-249 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Reporter: Jonathan Anstey Attachments: camel-archetype-war.patch Could someone apply this patch to add camel-archetype-war to the internal catalog? I'd like to get it in before the next release of the archetype plugin. -- 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: (MCHECKSTYLE-105) Update to Checkstyle 5.0
[ http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182268#action_182268 ] francisdb commented on MCHECKSTYLE-105: --- Maven 2.2.0 was released today which drops Java 1.4 support... > Update to Checkstyle 5.0 > > > Key: MCHECKSTYLE-105 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Felix Röthenbacher >Assignee: nicolas de loof > Fix For: 2.4 > > Attachments: patch.diff, update-to-5.0beta2.patch > > > Checkstyle 5.0-beta01 adds support for generics, etc. > See > http://checkstyle.sourceforge.net/5.x/releasenotes.html > for a list of new features. > Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is > available from a public Maven repository. > Patch updates plugin to changed API / implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-469) CLONE -mark contents of "target" directory as derived
[ http://jira.codehaus.org/browse/MECLIPSE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182284#action_182284 ] Vladimir Nicolici commented on MECLIPSE-469: I was very surprised to find this bug marked as "won't fix". I can't even vote for it. If there isn't an easy solution, you should at least notify the Eclipse user that he/she should set the flag himself/herself, to avoid problems with searches and commits. It took me some time before I discovered how to set the derived flag from the UI. For an explanation on how to set this flag with the API, look here: http://www.pushing-pixels.org/?p=847 I also think the flag should set in the project, not in the workspace, but the Eclipse guys seem to have a different philosophy regarding the nature of the derived flag. > CLONE -mark contents of "target" directory as derived > - > > Key: MECLIPSE-469 > URL: http://jira.codehaus.org/browse/MECLIPSE-469 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Andreas Schildbach > > Eclipse has the notion of "derived resources", which are normally excluded > from many dialogs like the "Open Resource" dialog (Ctrl-Shift-R). Without > this marker, all those dialogs would be cluttered with unrelevant files > (which can't be edited anyway because they will be overwritten on the next > build). > Unfortunately, unlike Eclipse itself, "mvn eclipse:eclipse" does not mark > generated files as derived. A good candidate would be the entire contents of > the "target" directory. -- 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-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182296#action_182296 ] Ovidiu Feodorov commented on SCM-368: - Just an observation, I found cases when cygwin svn fails with absolute cygwin paths, if those paths are specified in a --targets file. More details about these cases here: http://mail-archives.apache.org/mod_mbox/maven-users/200907.mbox/%3c4a4cd0fb.7070...@novaordis.com%3e I'd suggest making using relative paths configurable from pom. > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- 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-4227) DefaultArtifactVersion equals implementation does not handle null
DefaultArtifactVersion equals implementation does not handle null - Key: MNG-4227 URL: http://jira.codehaus.org/browse/MNG-4227 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.2.0, 2.1.0, 2.0.10, 2.0.9, 2.0.8 Environment: Windows Vista w/ JDK 1.5.0_18 Reporter: Sean Griffin Priority: Minor A NullPointerException is possible in org.apache.maven.artifact.versioning.DefaultArtifactVersion because it simply delegates to the compareTo() method as its implementation. The compareTo method need not handle objects of a different type or null objects (and in fact does not), but the equals() method is supposed to handle these two situations. In certain cases (although I have not been able to track down the exact cause of null argument) a NPE is thrown for this reason. It's fine to call compareTo() as the equals implementation, but it should first be wrapped in an instanceof check: Change "return compareTo( other ) == 0;" to if !(other instanceof DefaultArtifactVersion) return false; return compareTo(other) == 0; This bug is exposed when using the new NetBeans 6.7 "Show Dependency Graph" functionality on certain projects. Here is the full stack trace: java.lang.NullPointerException at org.apache.maven.artifact.versioning.DefaultArtifactVersion.compareTo(DefaultArtifactVersion.java:65) at org.apache.maven.artifact.versioning.DefaultArtifactVersion.equals(DefaultArtifactVersion.java:59) at org.apache.maven.artifact.versioning.Restriction.equals(Restriction.java:164) at java.util.AbstractList.equals(AbstractList.java:507) at org.apache.maven.artifact.versioning.VersionRange.equals(VersionRange.java:568) at org.apache.maven.shared.dependency.tree.DependencyNode.nullEquals(DependencyNode.java:890) at org.apache.maven.shared.dependency.tree.DependencyNode.equals(DependencyNode.java:825) at org.netbeans.modules.maven.graph.ArtifactGraphNode.represents(ArtifactGraphNode.java:116) at org.netbeans.modules.maven.graph.DependencyGraphScene.getGraphNodeRepresentant(DependencyGraphScene.java:173) at org.netbeans.modules.maven.graph.EdgeWidget.getConflictType(EdgeWidget.java:210) at org.netbeans.modules.maven.graph.EdgeWidget.(EdgeWidget.java:85) at org.netbeans.modules.maven.graph.DependencyGraphScene.attachEdgeWidget(DependencyGraphScene.java:202) at org.netbeans.modules.maven.graph.DependencyGraphScene.attachEdgeWidget(DependencyGraphScene.java:95) at org.netbeans.api.visual.graph.GraphScene.addEdge(GraphScene.java:152) at org.netbeans.modules.maven.graph.GraphConstructor.endVisit(GraphConstructor.java:133) at org.apache.maven.shared.dependency.tree.DependencyNode.accept(DependencyNode.java:317) at org.netbeans.modules.maven.graph.DependencyGraphTopComponent$8.run(DependencyGraphTopComponent.java:416) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:577) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1030) -- 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: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182308#action_182308 ] jesse crossley commented on MINSTALL-40: This problem still occurs with mvn 2.0.10 and war plugins 2.1-alpha-2 and 2.1-beta-1. I've employed the work around using an empty /src/main/resources/placeHolder.txt, but that's not a very satisfying solution. Is there any fix forthcoming? I see that the duplicate issue http://jira.codehaus.org/browse/MINSTALL-18";>MINSTALL-18 has been closed, but this version of the issue is ongoing. > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Assignee: Benjamin Bentmann >Priority: Minor > Attachments: clean-install-with-war-2.0.2.log, clean-install.log, > MINSTALL40-sample2.zip, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 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] Commented: (MNG-2562) expose current time as a property for POM interpolation
[
http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182313#action_182313
]
Benjamin Bentmann commented on MNG-2562:
Matthew, I believe there is probably a misunderstanding. We have to distinguish
what gets interpolated (and by whom). The Maven core is only responsible for
interpolating the POM, not the resources or any other project source files. The
latter is the job for plugins, usually the Maven Resources Plugin. So you
should fill the issue at the plugin which needs to be updated to support the
timestamp as a new interpolation source. The plugin can fetch the value from
the {{MavenSession}}.
BTW, I updated the site some time ago so that the feature in now documented,
see [Available
Variable|http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Available_Variables].
> expose current time as a property for POM interpolation
> ---
>
> Key: MNG-2562
> URL: http://jira.codehaus.org/browse/MNG-2562
> Project: Maven 2
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Reporter: Brett Porter
>Assignee: John Casey
> Fix For: 2.1.0-M1
>
>
> it is useful to have the current time, for example to write out a manifest
> entry for the build time or to filter into another file.
> I'm not sure of the best way to make the format of the time configurable -
> perhaps another POM element/property.
> See the related issue for a current example of how this can be done, but it
> would be nice to have a built-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
Re: [jira] Created: (MCHECKSTYLE-112) Error when using custom Checkstyle configuration
Have you found a solution to this issue, I am getting the same error when
trying to configure a custom config file in a multi-module maven project.
JIRA j...@codehaus.org wrote:
>
> Error when using custom Checkstyle configuration
> -
>
> Key: MCHECKSTYLE-112
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-112
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
> Affects Versions: 2.2
> Environment: Windows Vista and cygwin
> Reporter: Flavio Pompermaier
> Attachments: checkstyle.xml
>
> If trying to use a custom configuration it seem that Maven cannot
> instantiate properly available checks.
> When I try to run it with a predefined Checkstyle configuration instead,
> everything works well.
> This is how is set up the plugin in the pom.xml:
>
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
>
>
> ${basedir}/src/main/config/checkstyle/checkstyle.xml
>
> ${basedir}/src/main/config/checkstyle/suppressions.xml
>
>
>
>..
>
> And in attachment there's the checkstyle.xml file.
> This is the output of Maven:
>
> Embedded error: Error rendering Maven report: Failed during checkstyle
> configuration
> Unable to instantiate JavadocPackageCheck (OR WHATEVER ELSE CHECK...)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
> generation
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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 during
> page generation
> at
> org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:101)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> ... 16 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> rendering Maven report: Failed during checkstyle configuration
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:149)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
> at
> org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> ... 18 more
> Caused by: org.apache.maven.reporting.MavenReportException: Failed during
> checkstyle configuration
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:648)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> ... 22 more
> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot
> initialize module JavadocPackage - Unable t
[jira] Created: (MAVENUPLOAD-2505) Uploading into Maven repository
Uploading into Maven repository --- Key: MAVENUPLOAD-2505 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2505 Project: Maven Upload Requests Issue Type: Task Reporter: Pavel Ponec Thanks Paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-576) Merge resource dirs shall pass gracefully
[
http://jira.codehaus.org/browse/MECLIPSE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182315#action_182315
]
Daniel Siegmann commented on MECLIPSE-576:
--
I have encountered the same problem on a number of my projects. This will block
us from using any version of this plugin newer than 2.6 until it is fixed.
> Merge resource dirs shall pass gracefully
> -
>
> Key: MECLIPSE-576
> URL: http://jira.codehaus.org/browse/MECLIPSE-576
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : .project
>Affects Versions: 2.7
>Reporter: Yuen-Chi Lian
> Attachments: DIFF.txt
>
>
> .project generation is failing for folks in our team that have updated to the
> 2.7 release. It's due to {{EclipseSourceDir#merge()}} added in this version.
> The reason why it is failing at our end because we use resource filtering on
> resources appearing on the same path, i.e.
> {noformat}
>
>
> src/main/resources
>
> **/*
>
>
>
> src/main/resources
>
> **/*.properties
>
> true
>
>
> {noformat}
> {noformat}
> [INFO] Request to merge when 'filtering' is not identical. Original=resource
> src/main/resources: output=target/classes, include=[**/*],
> exclude=[**/*.java], test=false, filtering=false, merging with=resource
> src/main/resources: output=target/classes, include=[**/*.properties],
> exclude=[**/*.java], test=false, filtering=true
> {noforrmat}
> I don't think fixing the POM to fit the plugin is a feasible solution. We
> have Spring XML files and other documents that use ant style properties and
> we don't wish Maven to perform filtering for us on them (see first
> {{}} tag). It should just pass it like what it used to be in
> previous versions.
--
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: (MASSEMBLY-428) regression: duplicate files added to the assembly
regression: duplicate files added to the assembly - Key: MASSEMBLY-428 URL: http://jira.codehaus.org/browse/MASSEMBLY-428 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Reporter: Tim Myer Priority: Blocker This issue needs to be re-opened for Beta-4: http://jira.codehaus.org/browse/MASSEMBLY-285 Could not re-open it myself. Needed to create a new bug. Sorry about that :(. -- 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-51) release:perform could update the date attribute in the changes.xml
[ http://jira.codehaus.org/browse/MRELEASE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182317#action_182317 ] Michael Osipov commented on MRELEASE-51: funny, just found your ticket. I believe this belongs to changes plugin in conjunction with site plugin. I filed a ticket few days ago MCHANGES-161 > release:perform could update the date attribute in the changes.xml > --- > > Key: MRELEASE-51 > URL: http://jira.codehaus.org/browse/MRELEASE-51 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Reporter: Olivier Lamy >Priority: Minor > > Could the release:perform made a simple update with the date in changes.xml > as maven do. -- 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: (MASSEMBLY-428) regression: duplicate files added to the assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Myer closed MASSEMBLY-428. -- Resolution: Fixed My mistake. Something strange seems to have been going on with my version. This does not re-appear in 2.2-beta-4. Sorry for the spam. > regression: duplicate files added to the assembly > - > > Key: MASSEMBLY-428 > URL: http://jira.codehaus.org/browse/MASSEMBLY-428 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 >Reporter: Tim Myer >Priority: Blocker > > This issue needs to be re-opened for Beta-4: > http://jira.codehaus.org/browse/MASSEMBLY-285 > Could not re-open it myself. Needed to create a new bug. Sorry about that > :(. -- 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: (MECLIPSE-581) Test source directories appear before Main source directories
[ http://jira.codehaus.org/browse/MECLIPSE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MECLIPSE-581: --- Affects Version/s: (was: 2.7) 2.6 I had my team verify this issue occurs starting 2.6. Using 2.5.1 works just fine. > Test source directories appear before Main source directories > - > > Key: MECLIPSE-581 > URL: http://jira.codehaus.org/browse/MECLIPSE-581 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : .project >Affects Versions: 2.6 > Environment: Maven 2.0.10 >Reporter: Paul Benedict > > This is either a bug or a questionable feature. When I run eclipse:eclipse on > a project that has siblings in its parent POM, two things happen: > (1) the sibling projects become a dependent project, not jar dependencies > (2) src/test appears before src/main in the package explorer. > I can handle #1, but #2 really is a tough adjustment. -- 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-4227) DefaultArtifactVersion equals implementation does not handle null
[
http://jira.codehaus.org/browse/MNG-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4227:
---
Affects Version/s: (was: 2.2.0)
(was: 2.1.0)
(was: 2.0.10)
(was: 2.0.9)
(was: 2.0.8)
3.0-alpha-2
I checked the code, the {{equals()}} impl looks good for all of the recent 2.x
versions. This actually affects 3.x, as expected from the relation to embedded
usage in an IDE.
> DefaultArtifactVersion equals implementation does not handle null
> -
>
> Key: MNG-4227
> URL: http://jira.codehaus.org/browse/MNG-4227
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0-alpha-2
> Environment: Windows Vista w/ JDK 1.5.0_18
>Reporter: Sean Griffin
>Priority: Minor
>
> A NullPointerException is possible in
> org.apache.maven.artifact.versioning.DefaultArtifactVersion because it simply
> delegates to the compareTo() method as its implementation. The compareTo
> method need not handle objects of a different type or null objects (and in
> fact does not), but the equals() method is supposed to handle these two
> situations. In certain cases (although I have not been able to track down
> the exact cause of null argument) a NPE is thrown for this reason.
> It's fine to call compareTo() as the equals implementation, but it should
> first be wrapped in an instanceof check:
> Change "return compareTo( other ) == 0;"
> to
> if !(other instanceof DefaultArtifactVersion) return false;
> return compareTo(other) == 0;
> This bug is exposed when using the new NetBeans 6.7 "Show Dependency Graph"
> functionality on certain projects. Here is the full stack trace:
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.versioning.DefaultArtifactVersion.compareTo(DefaultArtifactVersion.java:65)
> at
> org.apache.maven.artifact.versioning.DefaultArtifactVersion.equals(DefaultArtifactVersion.java:59)
> at
> org.apache.maven.artifact.versioning.Restriction.equals(Restriction.java:164)
> at java.util.AbstractList.equals(AbstractList.java:507)
> at
> org.apache.maven.artifact.versioning.VersionRange.equals(VersionRange.java:568)
> at
> org.apache.maven.shared.dependency.tree.DependencyNode.nullEquals(DependencyNode.java:890)
> at
> org.apache.maven.shared.dependency.tree.DependencyNode.equals(DependencyNode.java:825)
> at
> org.netbeans.modules.maven.graph.ArtifactGraphNode.represents(ArtifactGraphNode.java:116)
> at
> org.netbeans.modules.maven.graph.DependencyGraphScene.getGraphNodeRepresentant(DependencyGraphScene.java:173)
> at
> org.netbeans.modules.maven.graph.EdgeWidget.getConflictType(EdgeWidget.java:210)
> at org.netbeans.modules.maven.graph.EdgeWidget.(EdgeWidget.java:85)
> at
> org.netbeans.modules.maven.graph.DependencyGraphScene.attachEdgeWidget(DependencyGraphScene.java:202)
> at
> org.netbeans.modules.maven.graph.DependencyGraphScene.attachEdgeWidget(DependencyGraphScene.java:95)
> at
> org.netbeans.api.visual.graph.GraphScene.addEdge(GraphScene.java:152)
> at
> org.netbeans.modules.maven.graph.GraphConstructor.endVisit(GraphConstructor.java:133)
> at
> org.apache.maven.shared.dependency.tree.DependencyNode.accept(DependencyNode.java:317)
> at
> org.netbeans.modules.maven.graph.DependencyGraphTopComponent$8.run(DependencyGraphTopComponent.java:416)
> at
> org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:577)
> at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1030)
--
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: (MPLUGINTESTING-11) plugin-testing-mvn-3.x branch does not compile/work with latest maven 3.0-SNAPSHOT
plugin-testing-mvn-3.x branch does not compile/work with latest maven 3.0-SNAPSHOT -- Key: MPLUGINTESTING-11 URL: http://jira.codehaus.org/browse/MPLUGINTESTING-11 Project: Maven 2.x Plugin Testing Issue Type: Bug Reporter: Igor Fedorenko Attachments: maven-plugin-testing.diff Attached patch allows use of maven-plugin-testing with current maven 3.0-SNAPSHOT (svnrev 790428) -- 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-4227) DefaultArtifactVersion equals implementation does not handle null
[ http://jira.codehaus.org/browse/MNG-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4227. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 3.0-alpha-3 Fixed in [r790712|http://svn.apache.org/viewvc?view=rev&revision=790712]. > DefaultArtifactVersion equals implementation does not handle null > - > > Key: MNG-4227 > URL: http://jira.codehaus.org/browse/MNG-4227 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-2 > Environment: Windows Vista w/ JDK 1.5.0_18 >Reporter: Sean Griffin >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 3.0-alpha-3 > > > A NullPointerException is possible in > org.apache.maven.artifact.versioning.DefaultArtifactVersion because it simply > delegates to the compareTo() method as its implementation. The compareTo > method need not handle objects of a different type or null objects (and in > fact does not), but the equals() method is supposed to handle these two > situations. In certain cases (although I have not been able to track down > the exact cause of null argument) a NPE is thrown for this reason. > It's fine to call compareTo() as the equals implementation, but it should > first be wrapped in an instanceof check: > Change "return compareTo( other ) == 0;" > to > if !(other instanceof DefaultArtifactVersion) return false; > return compareTo(other) == 0; > This bug is exposed when using the new NetBeans 6.7 "Show Dependency Graph" > functionality on certain projects. Here is the full stack trace: > java.lang.NullPointerException > at > org.apache.maven.artifact.versioning.DefaultArtifactVersion.compareTo(DefaultArtifactVersion.java:65) > at > org.apache.maven.artifact.versioning.DefaultArtifactVersion.equals(DefaultArtifactVersion.java:59) > at > org.apache.maven.artifact.versioning.Restriction.equals(Restriction.java:164) > at java.util.AbstractList.equals(AbstractList.java:507) > at > org.apache.maven.artifact.versioning.VersionRange.equals(VersionRange.java:568) > at > org.apache.maven.shared.dependency.tree.DependencyNode.nullEquals(DependencyNode.java:890) > at > org.apache.maven.shared.dependency.tree.DependencyNode.equals(DependencyNode.java:825) > at > org.netbeans.modules.maven.graph.ArtifactGraphNode.represents(ArtifactGraphNode.java:116) > at > org.netbeans.modules.maven.graph.DependencyGraphScene.getGraphNodeRepresentant(DependencyGraphScene.java:173) > at > org.netbeans.modules.maven.graph.EdgeWidget.getConflictType(EdgeWidget.java:210) > at org.netbeans.modules.maven.graph.EdgeWidget.(EdgeWidget.java:85) > at > org.netbeans.modules.maven.graph.DependencyGraphScene.attachEdgeWidget(DependencyGraphScene.java:202) > at > org.netbeans.modules.maven.graph.DependencyGraphScene.attachEdgeWidget(DependencyGraphScene.java:95) > at > org.netbeans.api.visual.graph.GraphScene.addEdge(GraphScene.java:152) > at > org.netbeans.modules.maven.graph.GraphConstructor.endVisit(GraphConstructor.java:133) > at > org.apache.maven.shared.dependency.tree.DependencyNode.accept(DependencyNode.java:317) > at > org.netbeans.modules.maven.graph.DependencyGraphTopComponent$8.run(DependencyGraphTopComponent.java:416) > at > org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:577) > at > org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1030) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-409) Incorrect URLs in multi-module project
[ http://jira.codehaus.org/browse/MSITE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182327#action_182327 ] Jason Smith commented on MSITE-409: --- The problem appears to be the following code in SiteStageMojo. String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( outputRelativePath + "/" + structureProject ); If the staging folder is: C:\ws\target\staging and the output-directory dummy file is: C:\ws\target\staging\base-parent-pom\utils-core\dummy.html then the relative path is ../.. For each additional inherited parent POM, you get an additional '..' The desired path is actually just ".." So for staging, at least, this works for my case: //String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( //outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( "../" + structureProject ); You have to replace outputRelativePath in a couple of places. I am hoping that someone can take a look at this and verify whether or not this is a fix, and maybe roll it out to the plugin. > Incorrect URLs in multi-module project > -- > > Key: MSITE-409 > URL: http://jira.codehaus.org/browse/MSITE-409 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: Benson Margulies > > I have a top-level pom and some modules. One of the modules serves as a > parent for most, but not all, of the rest. > Thus, for most, the parent is ../parent, and for that the parent is the > top-level project itself. > I ran: > mvn site:stage -DstagingDirectory=/Users/benson/stage > It takes a very long time. > All of my child links came out incorrectly: e.g: > href="../../Users/benson/x/trunk/greenhouse/etrog/../../../../hudson.basistech.net/home/projects/etrog">RLPJ > Buildtools > There aren't distinct subdirectories in the staged dir for those of my > modules that use the parent. Actually, now that I look, I see that the ones > that parent into ../parent are subdirectories of 'parent' instead of > subdirectories of the top-level. But the links are still all wrong. -- 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: (MPLUGINTESTING-11) plugin-testing-mvn-3.x branch does not compile/work with latest maven 3.0-SNAPSHOT
[ http://jira.codehaus.org/browse/MPLUGINTESTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MPLUGINTESTING-11. --- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.0 Applied in [r790716|http://svn.apache.org/viewvc?view=rev&revision=790716], thanks Igor. > plugin-testing-mvn-3.x branch does not compile/work with latest maven > 3.0-SNAPSHOT > -- > > Key: MPLUGINTESTING-11 > URL: http://jira.codehaus.org/browse/MPLUGINTESTING-11 > Project: Maven 2.x Plugin Testing > Issue Type: Bug >Reporter: Igor Fedorenko >Assignee: Benjamin Bentmann > Fix For: 2.0 > > Attachments: maven-plugin-testing.diff > > > Attached patch allows use of maven-plugin-testing with current maven > 3.0-SNAPSHOT (svnrev 790428) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-395) Maven site multi module url problem
[ http://jira.codehaus.org/browse/MSITE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182332#action_182332 ] Jason Smith commented on MSITE-395: --- See MSITE-409 comments. > Maven site multi module url problem > --- > > Key: MSITE-395 > URL: http://jira.codehaus.org/browse/MSITE-395 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: valsho >Priority: Blocker > Attachments: genesis-2.0-SNAPSHOT-source-release.tar.gz, > genesis-2.0-SNAPSHOT-source-release.tar.gz > > > The generated maven (2.0.10) site for a multi module project is different on > windows and linux. > The difference is the relative url for the modules. > -- > Here's the project structure : > myProject/ >trunk/ > pom.xml > module1/ > pom.xml > src/ > module2/ > pom.xml > src/ > -- > Here's myProject/trunk/pom.xml definition : > com.myProject > modulepom > pom > POM myProject > 1.0-SNAPSHOT > > > module1 > module2 > > > > site > Maven site > file:// > > > > > org.apache.maven.plugins > maven-site-plugin > 2.0 > > > -- > On module1 and module2 pom, I didn't declare any > information. > I've "only" declared the parent > > com.myProject > modulepom > 1.0-SNAPSHOT > > > com.myProject > module1 > jar > 1.0-SNAPSHOT > module1 name > -- > Here are the index.html files generated on windows and linux in > myProject/trunk/target/staging/localhost/ after launching mvn site:stage in > directory myProject/trunk/ > --> Site deployed on Windows which is correct > > Modules > > module1 name > > > > module2 name > > ... > --> Site deployed on Linux which isn't correct > ... > Modules > >href="../../tmp/testProject/myProject/trunk/../localhost">module1 name > > > >href="../../tmp/testProject/myProject/trunk/../localhost">module2 name > >... > where /tmp/testProject/ is the absolute path where is stored myProject/ on > linux > -- > Any idea ? > Maybe i should use something different in than > file:// > Thanks for your help -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-409) Incorrect URLs in multi-module project
[ http://jira.codehaus.org/browse/MSITE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182327#action_182327 ] Jason Smith edited comment on MSITE-409 at 7/2/09 2:28 PM: --- The problem appears to be the following code in SiteStageMojo. String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( outputRelativePath + "/" + structureProject ); If the staging folder is: C:\ws\target\staging and the output-directory dummy file is: C:\ws\target\staging\base-parent-pom\utils-core\dummy.html then the relative path is ../.. For each additional inherited parent POM, you get an additional '..' The desired relative path is actually just "..", and I think this is always the case. But I could be wrong. But it works for me in all cases, and I am running many projects against this modification. So for staging, at least, this works for my case: //String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( //outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( "../" + structureProject ); You have to replace outputRelativePath in a couple of places. I am hoping that someone can take a look at this and verify whether or not this is a fix, and maybe roll it out to the plugin. was (Author: jasonsmith): The problem appears to be the following code in SiteStageMojo. String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( outputRelativePath + "/" + structureProject ); If the staging folder is: C:\ws\target\staging and the output-directory dummy file is: C:\ws\target\staging\base-parent-pom\utils-core\dummy.html then the relative path is ../.. For each additional inherited parent POM, you get an additional '..' The desired path is actually just ".." So for staging, at least, this works for my case: //String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( //outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( "../" + structureProject ); You have to replace outputRelativePath in a couple of places. I am hoping that someone can take a look at this and verify whether or not this is a fix, and maybe roll it out to the plugin. > Incorrect URLs in multi-module project > -- > > Key: MSITE-409 > URL: http://jira.codehaus.org/browse/MSITE-409 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: Benson Margulies > > I have a top-level pom and some modules. One of the modules serves as a > parent for most, but not all, of the rest. > Thus, for most, the parent is ../parent, and for that the parent is the > top-level project itself. > I ran: > mvn site:stage -DstagingDirectory=/Users/benson/stage > It takes a very long time. > All of my child links came out incorrectly: e.g: > href="../../Users/benson/x/trunk/greenhouse/etrog/../../../../hudson.basistech.net/home/projects/etrog">RLPJ > Buildtools > There aren't distinct subdirectories in the staged dir for those of my > modules that use the parent. Actually, now that I look, I see that the ones > that parent into ../parent are subdirectories of 'parent' instead of > subdirectories of the top-level. But the links are still all wrong. -- 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-2971) Variables are not replaced into installed pom file
[
http://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182333#action_182333
]
Sheldon Daigle commented on MNG-2971:
-
We have a fairly complex maven environment and without Christian's workaround,
we would have been dead in the water. I also agree that installing poms with
unexpanded properties is useless.
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: http://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
>Assignee: Ralph Goers
> Fix For: 2.2.x
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
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-3832) Allow wildcards in dependency exclusions
[
http://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182334#action_182334
]
Tomek Bujok commented on MNG-3832:
--
I have been using and popularizing Maven since many yeras. This week I am on
some kind vacations so I decided to spend a day coding and contribute a little
bit. I wanted to implement a "wildcard dependency exclusions feature"
(MNG-3832). I have never browsed the Maven source code before, but after
getting acquinted with the project structure, running and debugging it from
eclipse I found the potential class to change. It was ExcludesArtifactFilter in
the maven-artifact project.
The fix version of the feature was 2.x -> so I have checked out the code from
the newest 2.2.x branch, since the trunk folder contains 3.x version.
I wanted the modification to be self-contained thus I have only changed the
ExcludesArtifactFilter class. I have also created a test case
(ExcludesArtifactFilterTest) encompassing 21 unit tests which proves the
correctnes of the implemented approach.
I have extended the requested functionality a little bit. Right now, filter
constructs literal java regular expression for every pattern which is contained
by the list passed to the filter constructor. Include method matches given
artifact against all patterns. Since it is an exlcusion filter - if artifact is
matched at least once it will not be included. Filter defines "\*" (star) as a
wild-card character - a character that may be substituted for any other
character(s). It is implemented in such a way, that every occurrence of a "\*"
(star) in the exclusion pattern is replaced with the ".*" expression during the
construction of the literal java regex. Exclusion pattern can contain wild-card
character zero or more times in any place in the groupId or artifactId;
Patch file is included as an external file to this issue.
Examples:
{code:xml}
DEFINITION:
*
SEMANTICS: All artifacts are excluded.
LITERAL_JAVA_REGEX: .*:.* (optimized by excludeAll flag)
DEFINITION:
*
SEMANTICS: All artifacts are excluded.
LITERAL_JAVA_REGEX: .*:.* (optimized by excludeAll flag)
DEFINITION:
*
*
SEMANTICS: All artifacts are excluded.
LITERAL_JAVA_REGEX: .*:.* (optimized by excludeAll flag)
DEFINITION:
*
commons-lang
SEMANTICS: Artifacts with any groupId and with the artifactId equal to
"commons-lang" will be excluded.
LITERAL_JAVA_REGEX: .*:commons-lang
DEFINITION:
org.springframework
*
SEMANTICS: Artifacts with groupId "org.springframework" will be excluded.
LITERAL_JAVA_REGEX: org\.springframework:.*
MATCHING_ARTIFACT_EXAMPLES: org.springframework:spring-ws
NOT_MATCHING_ARTIFACT_EXAMPLES: org.springframework.snapshot:spring-ws
DEFINITION:
org.springframework.*
*
SEMANTICS: Artifacts with groupId beginning with "org.springframework." will be
excluded.
LITERAL_JAVA_REGEX: org\.springframework\..*:.*
MATCHING_ARTIFACT_EXAMPLES: org.springframework.snapshot:spring-ws
NOT_MATCHING_ARTIFACT_EXAMPLES: org.springframeworksnapshot:spring-ws
DEFINITION:
org.springframework*
*
SEMANTICS: Artifacts with groupId beginning with "org.springframework" will be
excluded.
LITERAL_JAVA_REGEX: org\.springframework.*:.*
MATCHING_ARTIFACT_EXAMPLES: org.springframework.snapshot:spring-ws,
org.springframeworksnapshot:spring-ws
NOT_MATCHING_ARTIFACT_EXAMPLES: org.spring.snapshot:spring-ws
DEFINITION:
org.*.test
*
SEMANTICS: Artifacts with groupId beginning with "org." and ending with ".test"
will be excluded.
LITERAL_JAVA_REGEX: org\..*\.test*:.*
MATCHING_ARTIFACT_EXAMPLES: org.apache.test:test-library,
org.apache.snapshot.test:test-library
NOT_MATCHING_ARTIFACT_EXAMPLES: orgapachetest:test-library
{code}
> Allow wildcards in dependency exclusions
>
>
> Key: MNG-3832
> URL: http://jira.codehaus.org/browse/MNG-3832
> Project: Maven 2
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Paul Gier
> Fix For: 2.x
>
>
> I would like to be able to exclude all transitive dependencies from a certain
> dependencies. This is especially useful when depending on an artifact with a
> classifier that may not have the same dependencies as the main artifact.
> Currently the only way to do this is by excluding each dependency
> individually which requires significant effort and is prone to becoming out
> of date. The following syntax is one possibility.
> Exclude all transitive dependencies
> {code}
>
> *
>
> {code}
> Exclude transitive dependencies with the groupId "org.company"
> {code}
>
> org.company
> *
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://w
[jira] Updated: (MNG-3832) Allow wildcards in dependency exclusions
[
http://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Bujok updated MNG-3832:
-
Attachment: MNG-3832-maven-artifact.patch
Patch which solves MNG-3832 issue (also including test case)
> Allow wildcards in dependency exclusions
>
>
> Key: MNG-3832
> URL: http://jira.codehaus.org/browse/MNG-3832
> Project: Maven 2
> Issue Type: New Feature
> Components: Dependencies
>Reporter: Paul Gier
> Fix For: 2.x
>
> Attachments: MNG-3832-maven-artifact.patch
>
>
> I would like to be able to exclude all transitive dependencies from a certain
> dependencies. This is especially useful when depending on an artifact with a
> classifier that may not have the same dependencies as the main artifact.
> Currently the only way to do this is by excluding each dependency
> individually which requires significant effort and is prone to becoming out
> of date. The following syntax is one possibility.
> Exclude all transitive dependencies
> {code}
>
> *
>
> {code}
> Exclude transitive dependencies with the groupId "org.company"
> {code}
>
> org.company
> *
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MINSTALL-40: -- Attachment: MINSTALL-40-fixed.zip MINSTALL-40-fixed.zip is an updated version of the example provided by Michele. This version locks down the version for the maven-install-plugin to 2.3 and shows this issue is fixed in version 2.3. So Jesse, be sure to use version 2.3 of the maven-install-plugin. If the issue really persists for, you will need to provide an example project to reproduce it for further analysis. > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Assignee: Benjamin Bentmann >Priority: Minor > Attachments: clean-install-with-war-2.0.2.log, clean-install.log, > MINSTALL-40-fixed.zip, MINSTALL40-sample2.zip, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 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] Issue Comment Edited: (MSITE-409) Incorrect URLs in multi-module project
[ http://jira.codehaus.org/browse/MSITE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182327#action_182327 ] Jason Smith edited comment on MSITE-409 at 7/2/09 6:27 PM: --- The problem appears to be the following code in SiteStageMojo. It is not specific to Linux, and occurs on both Windows and Linux. String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( outputRelativePath + "/" + structureProject ); If the staging folder is: C:\ws\target\staging and the output-directory dummy file is: C:\ws\target\staging\base-parent-pom\utils-core\dummy.html then the relative path is ../.. For each additional inherited parent POM, you get an additional '..' The desired relative path is actually just "..", and I think this is always the case. But I could be wrong. But it works for me in all cases, and I am running many projects against this modification. So for staging, at least, this works for my case: //String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( //outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( "../" + structureProject ); You have to replace outputRelativePath in a couple of places. I am hoping that someone can take a look at this and verify whether or not this is a fix, and maybe roll it out to the plugin. was (Author: jasonsmith): The problem appears to be the following code in SiteStageMojo. String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( outputRelativePath + "/" + structureProject ); If the staging folder is: C:\ws\target\staging and the output-directory dummy file is: C:\ws\target\staging\base-parent-pom\utils-core\dummy.html then the relative path is ../.. For each additional inherited parent POM, you get an additional '..' The desired relative path is actually just "..", and I think this is always the case. But I could be wrong. But it works for me in all cases, and I am running many projects against this modification. So for staging, at least, this works for my case: //String outputRelativePath = PathTool.getRelativePath( stagingDirectory.getAbsolutePath(), new File( //outputDirectory, "dummy.html" ).getAbsolutePath() ); project.setUrl( "../" + structureProject ); You have to replace outputRelativePath in a couple of places. I am hoping that someone can take a look at this and verify whether or not this is a fix, and maybe roll it out to the plugin. > Incorrect URLs in multi-module project > -- > > Key: MSITE-409 > URL: http://jira.codehaus.org/browse/MSITE-409 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: Benson Margulies > > I have a top-level pom and some modules. One of the modules serves as a > parent for most, but not all, of the rest. > Thus, for most, the parent is ../parent, and for that the parent is the > top-level project itself. > I ran: > mvn site:stage -DstagingDirectory=/Users/benson/stage > It takes a very long time. > All of my child links came out incorrectly: e.g: > href="../../Users/benson/x/trunk/greenhouse/etrog/../../../../hudson.basistech.net/home/projects/etrog">RLPJ > Buildtools > There aren't distinct subdirectories in the staged dir for those of my > modules that use the parent. Actually, now that I look, I see that the ones > that parent into ../parent are subdirectories of 'parent' instead of > subdirectories of the top-level. But the links are still all wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-409) Incorrect URLs in multi-module project
[ http://jira.codehaus.org/browse/MSITE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182352#action_182352 ] Jason Smith commented on MSITE-409: --- See the comments on MSITE-409. I think this might be related. > Incorrect URLs in multi-module project > -- > > Key: MSITE-409 > URL: http://jira.codehaus.org/browse/MSITE-409 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: Benson Margulies > > I have a top-level pom and some modules. One of the modules serves as a > parent for most, but not all, of the rest. > Thus, for most, the parent is ../parent, and for that the parent is the > top-level project itself. > I ran: > mvn site:stage -DstagingDirectory=/Users/benson/stage > It takes a very long time. > All of my child links came out incorrectly: e.g: > href="../../Users/benson/x/trunk/greenhouse/etrog/../../../../hudson.basistech.net/home/projects/etrog">RLPJ > Buildtools > There aren't distinct subdirectories in the staged dir for those of my > modules that use the parent. Actually, now that I look, I see that the ones > that parent into ../parent are subdirectories of 'parent' instead of > subdirectories of the top-level. But the links are still all wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-409) Incorrect URLs in multi-module project
[ http://jira.codehaus.org/browse/MSITE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=182356#action_182356 ] Benson Margulies commented on MSITE-409: DId you mean to put that comment here? > Incorrect URLs in multi-module project > -- > > Key: MSITE-409 > URL: http://jira.codehaus.org/browse/MSITE-409 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: Benson Margulies > > I have a top-level pom and some modules. One of the modules serves as a > parent for most, but not all, of the rest. > Thus, for most, the parent is ../parent, and for that the parent is the > top-level project itself. > I ran: > mvn site:stage -DstagingDirectory=/Users/benson/stage > It takes a very long time. > All of my child links came out incorrectly: e.g: > href="../../Users/benson/x/trunk/greenhouse/etrog/../../../../hudson.basistech.net/home/projects/etrog">RLPJ > Buildtools > There aren't distinct subdirectories in the staged dir for those of my > modules that use the parent. Actually, now that I look, I see that the ones > that parent into ../parent are subdirectories of 'parent' instead of > subdirectories of the top-level. But the links are still all wrong. -- 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
