[jira] Updated: (MNG-2196) Fails when parent module is not located a level above
[ http://jira.codehaus.org/browse/MNG-2196?page=all ]
Brett Porter updated MNG-2196:
--
Fix Version: 2.0.4
> Fails when parent module is not located a level above
> -
>
> Key: MNG-2196
> URL: http://jira.codehaus.org/browse/MNG-2196
> Project: Maven 2
> Type: Bug
> Components: Dependencies
> Versions: 2.0.4
> Reporter: Vincent Massol
> Priority: Blocker
> Fix For: 2.0.4
>
>
> Cargo is now failing to build with v2.0.4-SNAPSHOT as shown below. I believe
> the problem is because we have the following structure
> {noformat}
> trunk/
> |_ samples/
> |_ testdata/
> {noformat}
> where {{testdata}}'s POM refers to the POM in {{trunk}}.
> Error log:
> {noformat}
> C:\dev\cargo\trunk>mvn clean install
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: org.codehaus.cargo
> ArtifactId: cargo
> Version: 0.9-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> org.codehaus.cargo:cargo:pom:0.9-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> org.codehaus.cargo:cargo for p
> roject: org.codehaus.cargo:cargo-samples-testdata:pom:null
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
> 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:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find
> parent: org.codehaus.cargo
> :cargo for project: org.codehaus.cargo:cargo-samples-testdata:pom:null
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBu
> ilder.java:1132)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuil
> der.java:672)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMa
> venProjectBuilder.java:414)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java
> :190)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
> ... 11 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM
> 'org.codehaus.cargo:cargo' not fou
> nd in repository: Unable to download the artifact from any repository
> org.codehaus.cargo:cargo:pom:0.9-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenP
> rojectBuilder.java:511)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBu
> ilder.java:1128)
> ... 18 more
> Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
> Unable to download the arti
> fact from any repository
> org.codehaus.cargo:cargo:pom:0.9-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolve
> r.java:136)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolve
> r.java:63)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenP
> rojectBuilder.java:465)
> ... 19 more
> Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to
> download the artifact fro
> m any repository
> at
> o
[jira] Created: (MPXDOC-192) Add a public DTD identifier for XDOC
Add a public DTD identifier for XDOC Key: MPXDOC-192 URL: http://jira.codehaus.org/browse/MPXDOC-192 Project: maven-xdoc-plugin Type: Improvement Reporter: Henning Schmiedehausen Fix For: 1.10 To be able to automatically select the DTD for XDOC (which will be first released with the maven xdoc plugin), it would be good to define and add a public DTD identifier for the XDOC format. As discussed, I'd like to propose http://www.apache.org/dtds/xdoc_1_0.dtd";> for the XDOC format. It would be great if you could also adopt this for the xdoc plugin (and change the name of the xdoc DTD file from the current 1.10 version to match the xdoc_1_0.dtd name. Once the plugin is released, we can coordinate with the infra people to get the file in the referenced location. -- 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-2197) Add a MavenProject.addArtifact() method
Add a MavenProject.addArtifact() method --- Key: MNG-2197 URL: http://jira.codehaus.org/browse/MNG-2197 Project: Maven 2 Type: Improvement Components: Plugin API Versions: 2.0.4 Reporter: Vincent Massol Priority: Minor See http://www.nabble.com/MavenProject.addArtifact%28%29-t1369889.html#a3700811 -- 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: (MCLOVER-26) dependencies omitted from classpath during clover compile
[ http://jira.codehaus.org/browse/MCLOVER-26?page=comments#action_62532 ] Vincent Massol commented on MCLOVER-26: --- Hi Jake I think I've found the problem. I've committed a fix. Could you try the version in SVN if it works for you? > dependencies omitted from classpath during clover compile > - > > Key: MCLOVER-26 > URL: http://jira.codehaus.org/browse/MCLOVER-26 > Project: Maven 2.x Clover Plugin > Type: Bug > Versions: 2.0 > Environment: java 1.4.2_05, solaris os, anthill pro 2.5 > Reporter: jake pezaro > Assignee: Vincent Massol > Fix For: 2.1 > Attachments: anthill_RiskCacheServer-Deploy-Builder_log.txt, pom.xml, > pom.xml, pom.xml > > > my project builds & tests sucessfully using when using the normal lifecycle > (compiler:compile), however when clover runs the compile task (as part of mvn > site) the compile fails. i have attached a debug log from such a build to > this bug. from this i can see that the classpath used by the clover compile > is missing a dependency (com.vcint:VcCommons:jar:2.2.1-SNAPSHOT). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MSUREFIRE-53) Make forked mode console output look the same as non-forked mode console output
[ http://jira.codehaus.org/browse/MSUREFIRE-53?page=all ] Kenney Westerhof reopened MSUREFIRE-53: --- Assign To: Kenney Westerhof (was: Jason van Zyl) The System.out/System.err is NOT correctly printed to standard out when using fork mode. This is because it still uses plexus-utils 1.0.5. > Make forked mode console output look the same as non-forked mode console > output > --- > > Key: MSUREFIRE-53 > URL: http://jira.codehaus.org/browse/MSUREFIRE-53 > Project: Maven 2.x Surefire Plugin > Type: Bug > Reporter: Jason van Zyl > Assignee: Kenney Westerhof > Fix For: 2.1.3 > > > Right now nothing comes out on the console which is confusing to users. -- 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: (MSUREFIRE-53) Make forked mode console output look the same as non-forked mode console output
[ http://jira.codehaus.org/browse/MSUREFIRE-53?page=all ] Kenney Westerhof closed MSUREFIRE-53: - Resolution: Fixed Fixed in revision 390651. > Make forked mode console output look the same as non-forked mode console > output > --- > > Key: MSUREFIRE-53 > URL: http://jira.codehaus.org/browse/MSUREFIRE-53 > Project: Maven 2.x Surefire Plugin > Type: Bug > Reporter: Jason van Zyl > Assignee: Kenney Westerhof > Fix For: 2.1.3 > > > Right now nothing comes out on the console which is confusing to users. -- 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: (MCLOVER-7) "mvn clover:report" generates errors in tests that execute properly in "mvn test"
[ http://jira.codehaus.org/browse/MCLOVER-7?page=all ]
Vincent Massol closed MCLOVER-7:
Assign To: Vincent Massol
Resolution: Cannot Reproduce
Not enough details to reproduce. Chris, please reopen or create a new issue if
you still have the problem.
> "mvn clover:report" generates errors in tests that execute properly in "mvn
> test"
> -
>
> Key: MCLOVER-7
> URL: http://jira.codehaus.org/browse/MCLOVER-7
> Project: Maven 2.x Clover Plugin
> Type: Bug
> Versions: 2.0-alpha-1
> Reporter: Chris Gray
> Assignee: Vincent Massol
> Fix For: 2.1
>
>
> Some of our java code opens data files, which have been stored in the
> ${PROJECT_ROOT} directory. When we execute "mvn test", the code compiles
> fine, and all unit tests pass. However, when we add the clover plugin to the
> pom.xml file, all tests fail during the clover run. As far as I can tell, it
> looks like clover when executes the tests, they look for the data files in
> the ${PROJECT_ROOT}/target/clover directory instead of the ${PROJECT_ROOT}
> 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] Created: (MAVENUPLOAD-810) Upload jcaptcha
Upload jcaptcha --- Key: MAVENUPLOAD-810 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-810 Project: maven-upload-requests Type: Task Reporter: Vincent Siveton JCAPTCHA, for Java Completely Automated Public Test to tell Computers and Humans Apart Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPXDOC-192) Add a public DTD identifier for XDOC
[ http://jira.codehaus.org/browse/MPXDOC-192?page=comments#action_62543 ] Henning Schmiedehausen commented on MPXDOC-192: --- To ensure that XML Editors like XMLMind are able to preserve the whitespace in the .. blocks, please apply the attached patch to the DTD. > Add a public DTD identifier for XDOC > > > Key: MPXDOC-192 > URL: http://jira.codehaus.org/browse/MPXDOC-192 > Project: maven-xdoc-plugin > Type: Improvement > Reporter: Henning Schmiedehausen > Fix For: 1.10 > > > To be able to automatically select the DTD for XDOC (which will be first > released with the maven xdoc plugin), it would be good to define and add a > public DTD identifier for the XDOC format. As discussed, I'd like to propose > > "http://www.apache.org/dtds/xdoc_1_0.dtd";> > for the XDOC format. It would be great if you could also adopt this for the > xdoc plugin (and change the name of the xdoc DTD file from the current 1.10 > version to match the xdoc_1_0.dtd name. > Once the plugin is released, we can coordinate with the infra people to get > the file in the referenced location. -- 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: (MPXDOC-192) Add a public DTD identifier for XDOC
[ http://jira.codehaus.org/browse/MPXDOC-192?page=all ] Henning Schmiedehausen updated MPXDOC-192: -- Attachment: xml-space.patch > Add a public DTD identifier for XDOC > > > Key: MPXDOC-192 > URL: http://jira.codehaus.org/browse/MPXDOC-192 > Project: maven-xdoc-plugin > Type: Improvement > Reporter: Henning Schmiedehausen > Fix For: 1.10 > Attachments: xml-space.patch > > > To be able to automatically select the DTD for XDOC (which will be first > released with the maven xdoc plugin), it would be good to define and add a > public DTD identifier for the XDOC format. As discussed, I'd like to propose > > "http://www.apache.org/dtds/xdoc_1_0.dtd";> > for the XDOC format. It would be great if you could also adopt this for the > xdoc plugin (and change the name of the xdoc DTD file from the current 1.10 > version to match the xdoc_1_0.dtd name. > Once the plugin is released, we can coordinate with the infra people to get > the file in the referenced location. -- 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-2198) Add and to plugin metadata
Add and to plugin metadata --- Key: MNG-2198 URL: http://jira.codehaus.org/browse/MNG-2198 Project: Maven 2 Type: New Feature Components: Plugin API, Dependencies Reporter: Johann Reyes Add to the plugin metadata and support so related source/javadoc are resolved as well along the dependency itself. -- 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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
Site plugin should convert .fml files when working from xdocDirectory
-
Key: MSITE-109
URL: http://jira.codehaus.org/browse/MSITE-109
Project: Maven 2.x Site Plugin
Type: Improvement
Versions: 2.0
Reporter: Wendy Smoak
In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
http://maven.apache.org/maven-1.x/plugins/faq/properties.html
If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
'xdocDirectory'), it should convert any .fml files it finds there.
http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
Optional toggle switch to revert MIDEA-35 - Key: MIDEA-44 URL: http://jira.codehaus.org/browse/MIDEA-44 Project: Maven 2.x Idea Plugin Type: Improvement Reporter: Patrick Lightbody Attachments: useShortDependencyNames.patch I never had any problems with the short names that were removed when MIDEA-35 was fixed, but I believe the reporter that it can cause problems. However, I think that it is a useful enough feature that users should be able to turn it on if they want to. So here is a patch that does 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] Closed: (MPMD-18) set linkXRef to true by default, and only link if JXR report is included to make it automatic
[ http://jira.codehaus.org/browse/MPMD-18?page=all ] Brett Porter closed MPMD-18: Resolution: Fixed I ended up going a little differently, to be consistent with the other plugins, but they were mostly inspired by this patch in the first place. Thanks Jesse! > set linkXRef to true by default, and only link if JXR report is included to > make it automatic > - > > Key: MPMD-18 > URL: http://jira.codehaus.org/browse/MPMD-18 > Project: Maven 2.x Pmd Plugin > Type: Improvement > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0-beta-2 > Attachments: mpmd-18.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-45) Problems with exclude logic
Problems with exclude logic --- Key: MIDEA-45 URL: http://jira.codehaus.org/browse/MIDEA-45 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Patrick Lightbody Attachments: excludeBugFix.patch The latest exclude logic has a couple problems: 1) an add() instead of an addAll() method causes some very funky IDEA behavior 2) a bug from my previous patch - the project's base dir was not used to build up the resource dir, breaking reactor builds 3) the smart logic in getExcludedDirectories() is nice an all, but if the dirs don't exist it does nothing. I provided a simpler implementation that may make most of that method moot, but it doesn't hurt to keep it there either. By comparing the simple strings (after having been sorted), you can achieve almost all the same optimizations. Patch supplied. -- 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: (MIDEA-46) Macros in reactor projects aren't added to the IDEA project
Macros in reactor projects aren't added to the IDEA project --- Key: MIDEA-46 URL: http://jira.codehaus.org/browse/MIDEA-46 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Patrick Lightbody This is a bug in a previous patch I supplied. Basically, the feature that lets you define a Library source dir works great for single-project maven builds, but for reactor builds there is a small bug. Basically, there is a Set that is passed in to the IdeaModuleMojo that gets populated with names of path mappings when any source dir contains the pattern $foo$. That Set is then used to populate the ipr file like so: The problem with my implementation is multiple macro Sets are created, one for each module that gets build. Except for the root maven project, that Set is immediately discarded since the project file is only built once. I don't have a patch for this because I don't have a good suggested fix. On the plus side, it's not a critical issue. The only problem is that IDEA won't prompt the user to provide path mappings for those macros. Instead, you have to do them by hand. -- 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: (MIDEA-46) Macros in reactor projects aren't added to the IDEA project
[ http://jira.codehaus.org/browse/MIDEA-46?page=comments#action_62557 ] Patrick Lightbody commented on MIDEA-46: Whoops, forgot to set the priority of this down - it's far from Major. Very low priority. > Macros in reactor projects aren't added to the IDEA project > --- > > Key: MIDEA-46 > URL: http://jira.codehaus.org/browse/MIDEA-46 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Patrick Lightbody > > > This is a bug in a previous patch I supplied. Basically, the feature that > lets you define a Library source dir works great for single-project maven > builds, but for reactor builds there is a small bug. > Basically, there is a Set that is passed in to the IdeaModuleMojo that gets > populated with names of path mappings when any source dir contains the > pattern $foo$. That Set is then used to populate the ipr file like so: > > > > The problem with my implementation is multiple macro Sets are created, one > for each module that gets build. Except for the root maven project, that Set > is immediately discarded since the project file is only built once. I don't > have a patch for this because I don't have a good suggested fix. > On the plus side, it's not a critical issue. The only problem is that IDEA > won't prompt the user to provide path mappings for those macros. Instead, you > have to do them by hand. -- 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: (MPMD-14) create pmd:cpd-check goal
[ http://jira.codehaus.org/browse/MPMD-14?page=all ] Brett Porter closed MPMD-14: Resolution: Fixed > create pmd:cpd-check goal > - > > Key: MPMD-14 > URL: http://jira.codehaus.org/browse/MPMD-14 > Project: Maven 2.x Pmd Plugin > Type: New Feature > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-806) Upload PMD 3.6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-806?page=all ] Brett Porter updated MAVENUPLOAD-806: - Attachment: pmd-3.6-bundle.jar > Upload PMD 3.6 > -- > > Key: MAVENUPLOAD-806 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-806 > Project: maven-upload-requests > Type: Improvement > Reporter: Mike Perham > Attachments: pmd-3.6-bundle.jar > > > Required for MPMD-23. > http://pmd.sourceforge.net/ -- 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-806) Upload PMD 3.6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-806?page=all ] Brett Porter closed MAVENUPLOAD-806: Assign To: Brett Porter Resolution: Fixed > Upload PMD 3.6 > -- > > Key: MAVENUPLOAD-806 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-806 > Project: maven-upload-requests > Type: Improvement > Reporter: Mike Perham > Assignee: Brett Porter > Attachments: pmd-3.6-bundle.jar > > > Required for MPMD-23. > http://pmd.sourceforge.net/ -- 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: (MPMD-23) Use PMD 3.6
[ http://jira.codehaus.org/browse/MPMD-23?page=all ] Brett Porter closed MPMD-23: Resolution: Fixed > Use PMD 3.6 > --- > > Key: MPMD-23 > URL: http://jira.codehaus.org/browse/MPMD-23 > Project: Maven 2.x Pmd Plugin > Type: Improvement > Versions: 2.0 > Reporter: Christopher G. Stach II > Fix For: 2.0 > > > PMD 3.6 just came out with some important JDK 1.5 and memory fixes. -- 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: (MRESOURCES-17) Filtering of property values containing backslashes for properties files does not escape them
Filtering of property values containing backslashes for properties files does
not escape them
-
Key: MRESOURCES-17
URL: http://jira.codehaus.org/browse/MRESOURCES-17
Project: Maven 2.x Resources Plugin
Type: Bug
Versions: 2.1
Environment: Windows XP
Reporter: Dale King
For example consider this in a filtered property file (which I needed to use
for some tests):
targetDirectory=${pom.build.directory}
which generates after filtering:
targetDirectory=C:\ProjectDirectory\target
When the property file is read that will be read as C:ProjectDirectoryarget
--
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-811) Upload JAXB 2.0 jars
Upload JAXB 2.0 jars Key: MAVENUPLOAD-811 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-811 Project: maven-upload-requests Type: Task Reporter: Jeff Genender http://people.apache.org/~jgenender/jaxb-api-2.0EA3-bundle.jar http://people.apache.org/~jgenender/jaxb-impl-2.0EA3-bundle.jar http://people.apache.org/~jgenender/jaxb-xjc-2.0EA3-bundle.jar Requested by Brett so that the mutliple versions can be removed from various projects. -- 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-811) Upload JAXB 2.0 jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-811?page=all ] Brett Porter closed MAVENUPLOAD-811: Assign To: Brett Porter Resolution: Fixed done. Forfuture uploads, it might be better to have aversion of 2.0-EA3, or such, and include the URL and description of the artifact in the POM. I also wonder if xjc should depend on impl and api, and if impl should depend on api? > Upload JAXB 2.0 jars > > > Key: MAVENUPLOAD-811 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-811 > Project: maven-upload-requests > Type: Task > Reporter: Jeff Genender > Assignee: Brett Porter > > > http://people.apache.org/~jgenender/jaxb-api-2.0EA3-bundle.jar > http://people.apache.org/~jgenender/jaxb-impl-2.0EA3-bundle.jar > http://people.apache.org/~jgenender/jaxb-xjc-2.0EA3-bundle.jar > Requested by Brett so that the mutliple versions can be removed from various > projects. -- 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-40) don't generate doc file if it is unchanged
[ http://jira.codehaus.org/browse/MSITE-40?page=comments#action_62561 ] Brett Porter commented on MSITE-40: --- I'm happy with the generated-site stuff being reprocessed each time if they are newer, and leaving it up to the reports to only update if their sources have changed. I'm not yet applying these patches to give Jesse a chance to revisit to use the document map to test source against out, rather than needing to maintain the site-timestamp directory. > don't generate doc file if it is unchanged > -- > > Key: MSITE-40 > URL: http://jira.codehaus.org/browse/MSITE-40 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0 > Attachments: msite-40-doxia.patch, msite-40-site-plugin.patch > > > this would help make rsync more effecient not to mention faster site gen -- 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: (MSITE-109) Site plugin should convert .fml files when working from xdocDirectory
[ http://jira.codehaus.org/browse/MSITE-109?page=all ]
Brett Porter updated MSITE-109:
---
Fix Version: 2.0
> Site plugin should convert .fml files when working from xdocDirectory
> -
>
> Key: MSITE-109
> URL: http://jira.codehaus.org/browse/MSITE-109
> Project: Maven 2.x Site Plugin
> Type: Improvement
> Versions: 2.0
> Reporter: Wendy Smoak
> Fix For: 2.0
>
>
> In m1, by default the .fml files are found anywhere under ${basedir}/xdocs.
> http://maven.apache.org/maven-1.x/plugins/faq/properties.html
> If the m2 site plugin is working from ${basedir}/xdocs, (or a configured
> 'xdocDirectory'), it should convert any .fml files it finds there.
> http://www.nabble.com/-m2-latest-site-plugin-with-m1-format-project%2C-and-skins--t1379592.html#a3708717
--
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: (MCLEAN-8) conversion of the existing unit tests to use the AbstractMojoTestCase from the plugin testing harness
[ http://jira.codehaus.org/browse/MCLEAN-8?page=comments#action_62562 ] Brett Porter commented on MCLEAN-8: --- Jesse, with the -2 patch I get 3 tests fail: testEmptyDirectories testFilesets testInvalidDirectory Just me, or do you encounter them too? This happens whether run as a normal project or in the reactor, or in IDEA. > conversion of the existing unit tests to use the AbstractMojoTestCase from > the plugin testing harness > - > > Key: MCLEAN-8 > URL: http://jira.codehaus.org/browse/MCLEAN-8 > Project: Maven 2.x Clean Plugin > Type: Improvement > Reporter: Jesse McConnell > Attachments: maven-clean-harness-2.patch, maven-clean-harness.patch > > > This is the patch for that I am hoping are best practices in using the plugin > testing harness as mentioned in MNG-32 -- 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: (MSITE-105) No line number for Doxia barfs makes using APT to write site documentation all but impossible
[ http://jira.codehaus.org/browse/MSITE-105?page=all ] Brett Porter closed MSITE-105: -- Assign To: Jesse McConnell (was: Brett Porter) Resolution: Fixed applied > No line number for Doxia barfs makes using APT to write site documentation > all but impossible > - > > Key: MSITE-105 > URL: http://jira.codehaus.org/browse/MSITE-105 > Project: Maven 2.x Site Plugin > Type: New Feature > Versions: 2.0-beta-4 > Environment: all > Reporter: Greg Luck > Assignee: Jesse McConnell > Priority: Critical > Fix For: 2.0 > Attachments: msite-105-site-render.patch, msite-105.patch > > > The following is a typical error message complaining about the lack of a > closing > tag. Also happens regularly with missing } tags when you are doing > links. Getting a message like that in a 1000 line document is impossible to > debug. > It should specify the line number. and ideally the column number. > [ERROR] Error rendering > /Users/gluck/work/ehcache/src/site/apt/documentation/logging.apt: missing '>' > org.codehaus.doxia.module.apt.AptParseException: missing '>' > at > org.codehaus.doxia.module.apt.AptParser.doTraverseText(AptParser.java:1011) > at > org.codehaus.doxia.module.apt.AptParser.access$500(AptParser.java:27) > at > org.codehaus.doxia.module.apt.AptParser$Block.traverseText(AptParser.java:1211) > at > org.codehaus.doxia.module.apt.AptParser$Block.traverseText(AptParser.java:1206) > at > org.codehaus.doxia.module.apt.AptParser$Paragraph.traverse(AptParser.java:1484) > at > org.codehaus.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:238) > at > org.codehaus.doxia.module.apt.AptParser.traverseBody(AptParser.java:148) > at org.codehaus.doxia.module.apt.AptParser.parse(AptParser.java:110) > at org.codehaus.doxia.DefaultDoxia.parse(DefaultDoxia.java:65) > at > org.codehaus.plexus.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:221) > at > org.codehaus.plexus.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:173) > at > org.codehaus.plexus.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:152) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:340) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > 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) > Try parsing the following snippet to get the above error: > +--+ >class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" > properties="peerDiscovery=manual, > rmiUrls=//server2:40001/sampleCache11|//server2:40001/sampleCache12"/> > +--+ -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=all ] Brett Porter closed MIDEA-44: - Assign To: Brett Porter Resolution: Fixed Fix Version: 2.0 applied, with some changes: - I renamed it "dependenciesAsLibraries", which I think is more accurate about what it does - I defaulted it to true. I've never encountered problems, even with web modules, and I'd like it to remain consistent with prior versions and the M1 plugin. Perhaps if we get specific cases where it is a problem (eg web modules), we can disable it for those. Interesting about it being undocumented. I'm pretty sure that earlier in 4.x you used to be able to add a library from this dialog, but that setting certainly seems to have disappeared from the GUI. > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does 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] Closed: (MIDEA-45) Problems with exclude logic
[ http://jira.codehaus.org/browse/MIDEA-45?page=all ] Brett Porter closed MIDEA-45: - Assign To: Brett Porter Resolution: Fixed Fix Version: 2.0 applied, thanks. > Problems with exclude logic > --- > > Key: MIDEA-45 > URL: http://jira.codehaus.org/browse/MIDEA-45 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: excludeBugFix.patch > > > The latest exclude logic has a couple problems: > 1) an add() instead of an addAll() method causes some very funky IDEA behavior > 2) a bug from my previous patch - the project's base dir was not used to > build up the resource dir, breaking reactor builds > 3) the smart logic in getExcludedDirectories() is nice an all, but if the > dirs don't exist it does nothing. I provided a simpler implementation that > may make most of that method moot, but it doesn't hurt to keep it there > either. By comparing the simple strings (after having been sorted), you can > achieve almost all the same optimizations. > Patch supplied. -- 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: (MIDEA-34) Add resources to source folders instead of module libraries
[ http://jira.codehaus.org/browse/MIDEA-34?page=all ] Brett Porter closed MIDEA-34: - Assign To: Brett Porter Resolution: Fixed > Add resources to source folders instead of module libraries > --- > > Key: MIDEA-34 > URL: http://jira.codehaus.org/browse/MIDEA-34 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Assignee: Brett Porter > Priority: Critical > Fix For: 2.0 > Attachments: idea-1.patch > > > Having the resources as module libraries does not make much sense. > Instead the resources dir(s) should be added as normal idea source folders, > so that editing of properties files, xml files, etc. is possible. > see applied patch > Regards, > Manfred -- 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: (MIDEA-34) Add resources to source folders instead of module libraries
[ http://jira.codehaus.org/browse/MIDEA-34?page=comments#action_62567 ] Brett Porter commented on MIDEA-34: --- skipping resources with filtering or target paths > Add resources to source folders instead of module libraries > --- > > Key: MIDEA-34 > URL: http://jira.codehaus.org/browse/MIDEA-34 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Assignee: Brett Porter > Priority: Critical > Fix For: 2.0 > Attachments: idea-1.patch > > > Having the resources as module libraries does not make much sense. > Instead the resources dir(s) should be added as normal idea source folders, > so that editing of properties files, xml files, etc. is possible. > see applied patch > Regards, > Manfred -- 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: (MIDEA-24) Resources should be in the classpath, not sources
[ http://jira.codehaus.org/browse/MIDEA-24?page=all ]
Brett Porter reopened MIDEA-24:
---
> Resources should be in the classpath, not sources
> -
>
> Key: MIDEA-24
> URL: http://jira.codehaus.org/browse/MIDEA-24
> Project: Maven 2.x Idea Plugin
> Type: Improvement
> Reporter: Patrick Lightbody
> Assignee: Edwin Punzalan
> Fix For: 2.0
> Attachments: idea.resources.diff
>
>
> I think resources should be marked in the classpath, not in the sources
> directory. Although sources can be copied, but defalt some files aren't (like
> .gif, .js, etc). Brett agreed this would be a fine change, so I am attaching
> a patch. Note: this patch is a bit ghetto since I didn't know how to tell if
> a java Resource is of the "resources" type or the "java source" type. Feel
> free to tweak the endsWith("resources") check as needed :)
--
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: (MIDEA-24) Resources should be in the classpath, not sources
[ http://jira.codehaus.org/browse/MIDEA-24?page=all ]
Brett Porter closed MIDEA-24:
-
Assign To: Brett Porter (was: Edwin Punzalan)
Resolution: Won't Fix
Fix Version: (was: 2.0)
rolled back, see MIDEA-34
> Resources should be in the classpath, not sources
> -
>
> Key: MIDEA-24
> URL: http://jira.codehaus.org/browse/MIDEA-24
> Project: Maven 2.x Idea Plugin
> Type: Improvement
> Reporter: Patrick Lightbody
> Assignee: Brett Porter
> Attachments: idea.resources.diff
>
>
> I think resources should be marked in the classpath, not in the sources
> directory. Although sources can be copied, but defalt some files aren't (like
> .gif, .js, etc). Brett agreed this would be a fine change, so I am attaching
> a patch. Note: this patch is a bit ghetto since I didn't know how to tell if
> a java Resource is of the "resources" type or the "java source" type. Feel
> free to tweak the endsWith("resources") check as needed :)
--
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-37) eclipse:eclipse should execute in a later phase than "generate-sources"
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=comments#action_62569 ] fabrizio giustina commented on MECLIPSE-37: --- the change has been reverted in version 2.2, so that now the plugin doesn't need projects to compile. The original issue tracked here (being able to add source folders in a later phase) is so reopened, and we will continue to discuss it in order to design a better solution. A snapshot with this change has been deployed at: http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.2-SNAPSHOT/maven-eclipse-plugin-2.2-20060402.070500-1.jar > eclipse:eclipse should execute in a later phase than "generate-sources" > --- > > Key: MECLIPSE-37 > URL: http://jira.codehaus.org/browse/MECLIPSE-37 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.0 > Reporter: Mark Donszelmann > Assignee: fabrizio giustina > > > the eclipse:eclipse goal should run in a later phase than it currently does > (generate-sources) > as user defined plugins may add to the compileSourceRoots and > testCompileSourceRoots. > If it runs later, added paths will be written correctly to the .classpath. > Suggested phase is "test" -- 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: (MECLIPSE-3) Generation of eclipse projects requires that reactor projects have installed jars
[ http://jira.codehaus.org/browse/MECLIPSE-3?page=all ] fabrizio giustina closed MECLIPSE-3: Resolution: Fixed fix in svn for 2.2. The plugin now does a manual artifact resolution and doesn't require reactor projects to be installed anymore. A snapshot with this change can be found at: http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.2-SNAPSHOT/maven-eclipse-plugin-2.2-20060402.070500-1.jar > Generation of eclipse projects requires that reactor projects have installed > jars > - > > Key: MECLIPSE-3 > URL: http://jira.codehaus.org/browse/MECLIPSE-3 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.0 > Reporter: Barry Kaplan > Assignee: fabrizio giustina > Fix For: 2.2 > > > Most reactor actions work without requiring projects in the hierachy to have > installed jars. eg, You can compile and test the hierarchy using only the > project target directories. However, when generating eclipse projects, the > plugin will fail if a dependent project in the hierarchy does not have its > jar installed. (Note, that if the jar /is/ installed, a direct project > reference /will/ be defined in the .classpath -- ie, the project installed > jar is never actually used.) -- 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: (MECLIPSE-87) Eclipse plugin should not try to download sources of system dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-87?page=all ] fabrizio giustina closed MECLIPSE-87: - Resolution: Fixed fix in svn for 2.2 > Eclipse plugin should not try to download sources of system dependencies > > > Key: MECLIPSE-87 > URL: http://jira.codehaus.org/browse/MECLIPSE-87 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Renaud Julienne > Assignee: fabrizio giustina > Fix For: 2.2 > > > When eclipse.downloadSources is set to true, eclipse plugin try to download > sources of system dependencies, whereas the notion of system dependencies is > that they are not in any repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-81) Instructions for add-maven-repo incorrect.
[ http://jira.codehaus.org/browse/MECLIPSE-81?page=all ] fabrizio giustina closed MECLIPSE-81: - Assign To: fabrizio giustina Resolution: Fixed Fix Version: 2.1 According to the last comment, this is working in 2.1 > Instructions for add-maven-repo incorrect. > -- > > Key: MECLIPSE-81 > URL: http://jira.codehaus.org/browse/MECLIPSE-81 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Environment: > http://maven.apache.org/plugins/maven-eclipse-plugin/overview.html > Reporter: Archimedes Trajano > Assignee: fabrizio giustina > Fix For: 2.1 > > > In http://maven.apache.org/plugins/maven-eclipse-plugin/overview.html it says > to add the maven repository use the following command: > mvn -Declipse.workspace= eclipse:add-maven-repo > when executing this however, I get > --- > [INFO] One or more required plugin parameters are invalid/missing for > 'eclipse:a > dd-maven-repo' > [0] inside the definition for plugin: 'maven-eclipse-plugin'specify the > followin > g: > > ... > VALUE > . -- 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: (MECLIPSE-85) Maven eclipse plugin generates duplicate entries in .project file
[ http://jira.codehaus.org/browse/MECLIPSE-85?page=all ] fabrizio giustina closed MECLIPSE-85: - Assign To: fabrizio giustina Resolution: Duplicate Fix Version: 2.2 looks like a duplicate of MECLIPSE-86 (reactor modules gets added twice if a different type is specified in dependency) > Maven eclipse plugin generates duplicate entries in .project file > - > > Key: MECLIPSE-85 > URL: http://jira.codehaus.org/browse/MECLIPSE-85 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Shashikala Shamarao > Assignee: fabrizio giustina > Fix For: 2.2 > > > Hi, > I have written a pom.xml for my project which has lot of sub-modules and each > of these modules contain pom.xml file. > main project > - arch project > - servs project (this project is an ejb module) > - client project > In the main pom.file, I have defined the dependency for these other modules. > When I generate .project and .classpath file, it puts duplicate entry for the > ejb modules due to which when I load them into eclipse, it does not build > properly. > Can anyone help me with this. > Thanks in advance, > Shashi -- 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: (MECLIPSE-86) Dependencies of type test-jar get added twice
[ http://jira.codehaus.org/browse/MECLIPSE-86?page=all ]
fabrizio giustina closed MECLIPSE-86:
-
Resolution: Fixed
fix in svn for 2.2
> Dependencies of type test-jar get added twice
> -
>
> Key: MECLIPSE-86
> URL: http://jira.codehaus.org/browse/MECLIPSE-86
> Project: Maven 2.x Eclipse Plugin
> Type: Bug
> Versions: 2.1
> Reporter: Geoffrey De Smet
> Assignee: fabrizio giustina
> Fix For: 2.2
> Attachments: meclipse-86-maven-eclipse-plugin.patch, meclipse-86-patch.txt
>
>
> Consider a project with these dependencies:
>
> org.springframework.richclient
> spring-richclient-core
> ${pom.version}
>
>
> org.springframework.richclient
> spring-richclient-core
> test-jar
> ${pom.version}
> test
>
> From Larry Streepy:
> "When the eclipse plugin processes this pom, it processes both dependency
> entries and adds each of them to the classpath as type "src". It
> doesn't appear to be doing any kind of handling for duplicate entries,
> and I see nothing in the plugin code that seems to deal with the "type"
> of a dependency."
--
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
