[jira] Created: (ARCHETYPE-113) examples/webapp.html documentation is incorrect
examples/webapp.html documentation is incorrect - Key: ARCHETYPE-113 URL: http://jira.codehaus.org/browse/ARCHETYPE-113 Project: Maven Archetype Issue Type: Bug Reporter: Scott Cytacki The documentation up here: http://maven.apache.org/plugins/maven-archetype-plugin/examples/webapp.html shows the directory structure: . |-- src | `-- main | `-- java | |-- resources | |-- webapp | | `-- WEB-INF | | `-- web.xml | `-- index.jsp `-- pom.xml That is incorrect it should be: . |-- src | `-- main | |-- webapp | | |-- WEB-INF | | | `-- web.xml | | `-- index.jsp | `-- resources `-- pom.xml Sorry I don't have the tool installed to generate those ascii trees automatically so I might not have formated it correctly. -- 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: (MJAR-14) pom.xml information automatically included in META-INF during jar
[ http://jira.codehaus.org/browse/MJAR-14?page=comments#action_77596 ]
Scott Cytacki commented on MJAR-14:
---
Another consequence of putting the exporte-pom.xml in the jar is that any
properties defined in the settings.xml end up in the jar. This includes
passwords used for signing the jars.
> pom.xml information automatically included in META-INF during jar
> --
>
> Key: MJAR-14
> URL: http://jira.codehaus.org/browse/MJAR-14
> Project: Maven 2.x Jar Plugin
> Issue Type: Improvement
>Reporter: Jorg Heymans
> Assigned To: John Casey
> Fix For: 2.1
>
> Attachments: MNG-1543-maven-archiver.patch
>
>
> The jar plugin automatically adds a pom.xml in META-INF, which makes sense.
> But this pom.xml also contains local paths ie
>
>
> d:\src\excalibur-trunk\framework\api\src\java
> src/main/scripts
>
> d:\src\excalibur-trunk\framework\api\src\test
>
> d:\src\excalibur-trunk\framework\api\target\classes
>
> d:\src\excalibur-trunk\framework\api\target\test-classes
>
>
> META-INF
> d:\src\excalibur-trunk\framework\api\..\..
>
> LICENSE.txt
> NOTICE.txt
>
>
>
>
>
>
> d:\src\excalibur-trunk\framework\api\src\test\resources
> I don't see how this information could be useful to anyone else, and i'ld
> rather not have my local paths in distribution jars - call me paranoid :)
> Conversation log from IRC :
> jorgis there a way to tell maven not to include the pom.xml in
> META-INF when creating jars ?
> jesse hm, not that I know of
> jesse might be a boolean to control it in there somewhere
> jorgi looked at the jar plugin config .. didn't seem like it
> jorgit's not a real problem, just funny that this is done by default
> jesse I don't know, it makes it easier down the road to have
> automated things interrogate the jar for dependencies of the things inside
> trygvis yeah, you're right there jesse
> jorgmmm well yes that makes sense ...
> jorgthanks !
> trygvis jorg: it's useful for the application itself
> trygvis like reading out the version number from pom.properties
> jorgtrygvis: yes, but the pom also had my local paths in it for
> and stuff, that's why i found it a bit strange
> trygvis makes it easier making versioning-aware application and gives a
> thigh integration with your project management tool (aka maven)
> trygvis hm
> trygvis that should possibly be changed indeed
> trygvis File properties should be made relative to ${basedir} again
> trygvis when writing out the pom that is
> jorgi can understand about the dependencies , but the build
> configuration probably shouldn't be in there
> jorg
> d:\src\excalibur-trunk\framework\api\..\..
> trygvis jorg: file an issue, it should be relative to ${basedir} if
> there at all
> trygvis IMO the parts of a pom could be stripped from the repo
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72701 ] Scott Cytacki commented on MNGECLIPSE-59: - I created a sub-task to work on the patch for initializing the artifact map: MNGECLIPSE-182 I've posted a patch there that takes care of it for me. Without this initialization there will be many broken dependencies especially if projects are only available in the ecipse workspace. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-182) Initialization of the artifact map, and initialization after cleaning.
[ http://jira.codehaus.org/browse/MNGECLIPSE-182?page=all ] Scott Cytacki updated MNGECLIPSE-182: - Attachment: model-mananger-init-20060818-0.patch This patch takes care of the problems for me. It schedules a job for collecting all the poms in the workspace. It doesn't address the cleaning issue. It goes recursively into modules of the project poms. > Initialization of the artifact map, and initialization after cleaning. > -- > > Key: MNGECLIPSE-182 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-182 > Project: Maven 2.x Extension for Eclipse > Issue Type: Sub-task > Components: Dependency Resolver >Reporter: Scott Cytacki > Assigned To: Eugene Kuleshov > Attachments: model-mananger-init-20060818-0.patch > > > I started on the initialization of the artifact map in the MaveModelManager. > But it is getting a bit more complicated than I thought, and it seems > different than what Euguene suggested. So I wanted to describe it before I > go too much further. > Here is the current design: > MavenModelManager has an initialize() method that: > * checks if it has been initialized before, if so it does nothing > * traverses the projects in the workspace and a calls updateMavenModel for > each pom it finds. > the Job created in Maven2ClassContainerInitializer initialize() method calls > initialize on the mavenModelManager > Additionally there is the issue of when the workspace is cleaned. Here is > the case: > - project A depends on groupB:artifactB > - the workspace becomes inconsistant, or the automatic building is turned off > - project B is added to the workspace and its maven key is groupB:artifactB > - now the workspace is cleaned > The building process appears to decide the order of processing projects based > on the dependency graph between the projects. In this case project A doesn't > know it depends on B yet, so the builder might build project A first. In > this case the poms in B won't be in the artifact map yet. So A won't add the > project B as a dependency. I'm curious again how the PDE handles cases like > this. > Perhaps the best is to listen for the clean event and re-create the artifact > map in the modelManager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-184) invalid relativePath references in pom causes an incorrectly handled NPE
invalid relativePath references in pom causes an incorrectly handled NPE Key: MNGECLIPSE-184 URL: http://jira.codehaus.org/browse/MNGECLIPSE-184 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Reporter: Scott Cytacki Assigned To: Eugene Kuleshov If the project.parent.relativePath is not valid the following NPE is thrown. The m2eclispe plugin currently handles this by displaying an error on the pom with a descrption of NullPointerException. It seems this is a bug in the maven embedder, but in the meantime the m2eclipse plugin could at least log the exception better. java.lang.NullPointerException at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1075) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:676) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:418) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:194) at org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:305) at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:330) at org.maven.ide.eclipse.Maven2Plugin$ReadProjectTask.run(Maven2Plugin.java:577) at org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:185) at org.maven.ide.eclipse.Maven2Plugin.resolveClasspathEntries(Maven2Plugin.java:388) at org.maven.ide.eclipse.Maven2Plugin.resolveClasspathEntries(Maven2Plugin.java:461) at org.maven.ide.eclipse.container.Maven2ClasspathContainerInitializer$1.run(Maven2ClasspathContainerInitializer.java:83) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-182) Initialization of the artifact map, and initialization after cleaning.
Initialization of the artifact map, and initialization after cleaning. -- Key: MNGECLIPSE-182 URL: http://jira.codehaus.org/browse/MNGECLIPSE-182 Project: Maven 2.x Extension for Eclipse Issue Type: Sub-task Components: Dependency Resolver Reporter: Scott Cytacki Assigned To: Eugene Kuleshov I started on the initialization of the artifact map in the MaveModelManager. But it is getting a bit more complicated than I thought, and it seems different than what Euguene suggested. So I wanted to describe it before I go too much further. Here is the current design: MavenModelManager has an initialize() method that: * checks if it has been initialized before, if so it does nothing * traverses the projects in the workspace and a calls updateMavenModel for each pom it finds. the Job created in Maven2ClassContainerInitializer initialize() method calls initialize on the mavenModelManager Additionally there is the issue of when the workspace is cleaned. Here is the case: - project A depends on groupB:artifactB - the workspace becomes inconsistant, or the automatic building is turned off - project B is added to the workspace and its maven key is groupB:artifactB - now the workspace is cleaned The building process appears to decide the order of processing projects based on the dependency graph between the projects. In this case project A doesn't know it depends on B yet, so the builder might build project A first. In this case the poms in B won't be in the artifact map yet. So A won't add the project B as a dependency. I'm curious again how the PDE handles cases like this. Perhaps the best is to listen for the clean event and re-create the artifact map in the modelManager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72627 ] Scott Cytacki commented on MNGECLIPSE-59: - I think I tracked down the source of my problems. The artifacts map in the MavenModelManager is not be initialized correctly. When eclipse is started this map is empty, and it is only populated when pom is opened and changed. So at some point when the plugin is starting up it needs to search through the projects and build up that map. Or the map needs to be serialized, but it seems a lot safer to build the map at the beginning of each startup. I also see that the model manager is using the embedder to read the poms. This makes sense, but it is tricky, because it is easy to create infinite recursions. If the artifact resolver causes the model manager to read a pom then the embedder will ask the artifact resolver to do some resolving which then asks the model manager to read a pom I'm not sure yet what the best way to prevent that. In my original patch I was avoiding the use of the emedder, but that meant the code had to reimpliment the logic for figuring out the version, goupId and artifactId from the raw pom. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72565 ] Scott Cytacki commented on MNGECLIPSE-59: - I just checked it out. The refactoring looks good, and thanks for updating the eclipse formater settings. But... It only worked for a few seconds, and then all the eclipse project dependencies disappeared from the classpath container and were replaced with maven jar dependencies. I'll try to figure out what is going on. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-179) Use eclipse artifact resolver for forked maven builds
[ http://jira.codehaus.org/browse/MNGECLIPSE-179?page=comments#action_72483 ] Scott Cytacki commented on MNGECLIPSE-179: -- That use case definately trumps any complications in the local repository. One part of the solution could be to have the MavenModelManager marshall its map of eclipse projects and then unmarshaled them in the forked process. I believe that artifact resolvers can be added to the plexus container, and then the forked maven build will use them. But I don't know how this done. > Use eclipse artifact resolver for forked maven builds > - > > Key: MNGECLIPSE-179 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-179 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature >Reporter: Scott Cytacki > Assigned To: Eugene Kuleshov >Priority: Minor > > We should examine if the eclipse artifact resolver, which was created to > address this issue: MNGECLIPSE-59 > Should be used in forked maven builds. This would mean that artifacts would > not need to be installed into the local repository, before they could be used > by forked maven builds. > Doing this though, might have some complicated consequences. For example it > might be possible to install a project without installing a dependency. How > does the reactor handle this: if sub project A depends on subproject B can A > be installed without installing B? > That seems like a good way to think of this: the Eclipse workspace is like a > parent project that has sub projects one for each eclipse project. Just like > in a traditional multi-project, those sub projects can reference > dependencies that are not installed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72482 ] Scott Cytacki commented on MNGECLIPSE-59: - created MNGECLIPSE-179 to dicuss this option of using the resolver in forked maven builds. created MNGECLIPSE-180 to track handling of multi-module projects by the eclipse artifact resolver. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-180) Eclipse artifact resolver doesn't handle multi-module projects
Eclipse artifact resolver doesn't handle multi-module projects -- Key: MNGECLIPSE-180 URL: http://jira.codehaus.org/browse/MNGECLIPSE-180 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Reporter: Scott Cytacki Assigned To: Eugene Kuleshov The solution to MNGECLIPSE-59 does not handle multi-module projects.I can add this functionally once the cleaned up and refactored patch is commited. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-179) Use eclipse artifact resolver for forked maven builds
Use eclipse artifact resolver for forked maven builds - Key: MNGECLIPSE-179 URL: http://jira.codehaus.org/browse/MNGECLIPSE-179 Project: Maven 2.x Extension for Eclipse Issue Type: New Feature Reporter: Scott Cytacki Assigned To: Eugene Kuleshov Priority: Minor We should examine if the eclipse artifact resolver, which was created to address this issue: MNGECLIPSE-59 Should be used in forked maven builds. This would mean that artifacts would not need to be installed into the local repository, before they could be used by forked maven builds. Doing this though, might have some complicated consequences. For example it might be possible to install a project without installing a dependency. How does the reactor handle this: if sub project A depends on subproject B can A be installed without installing B? That seems like a good way to think of this: the Eclipse workspace is like a parent project that has sub projects one for each eclipse project. Just like in a traditional multi-project, those sub projects can reference dependencies that are not installed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72473 ] Scott Cytacki commented on MNGECLIPSE-59: - Dimitry, some testing would be great. Robert, Regarding the duplicate project dependencies. I would expect the JDT to handle this, I'd be curious how this is handled by the eclipse plugin classpath container. On the second point, I agree, A should update as soon as B's pom is saved. Since m2eclipse is already listening to pom changes this should be straight forward. To optimize, each maven eclipse project can listen to all of its dependencies which are maven eclipse projects. We might need a new event for this, but hopefully there is an existing event we can use. Performance is something that needs to be tested. There is a lot of room for improvement, but I didn't want to do it without reason. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72391 ] Scott Cytacki commented on MNGECLIPSE-59: - The embedder has been updated already to include the changes: MNG-1937 The embedder checked into the m2eclipse svn includes these changes. The latest version of my patch project-artifacts-2006062900.patch, applies to Trunk correctly. I had to set the fuzz factor to 3. And I had to manually select all the patch items that have red exclaimation points. More details on those red marks are here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=143354 All the patches really only take 2 approaches: those that add an eclipse artifact resolver to the embedder and the one that does not. * With the eclipse artifact resolver, the embedder uses the eclipse maven projects when it is looking for artifacts. In this case the eclipse maven projects do not be to installed into a maven repository, before they can references by other poms. This is useful when checking out a collection of interdependent eclipse maven projects that haven't been installed or deployed. See below for a use case. * Without the eclipse artifact resolver, when maven tries to find a pom or dependency it will not use the eclipse maven projects. So the artifacts must be available through the normal maven artifact resolution process: installed/deployed into a maven repository. This causes strange behavior, m2eclipse will use the pom from the maven repository, but will use the classes from eclipse project. So for example if A depends on B and B depends on C. A and B are eclipse maven projects. Then the pom of B is changed to add D as a dependency so B no depends on C and D. B is not installed or deployed. The dependencies of A will not include D. This is because m2eclipse is asking the embedder for the dependencies of A, and the embedder is using the pom for B from the maven repository not the pom from the eclipse project. So the 4 patchers are: Mark - ArtifactResolver-try3.patch Kenney - MNGECLIPSE-59 Drew - mngeclipse-59-drew-hack.txt Scott (me) - project-artifacts*.patch * Drew's patch does not add the eclipse artifact resolver to the embedder. * Mark's patch did add the eclipse artifact resolver to the embedder, but at the time he wrote the patch the embedder did not allow adding new artifact resolvers. So Mark also had to supply a patch to the embedder to make his patch work. Since then the embedder has added this functionality in a slighty different way. * Kenney made Mark's patch compile with the Trunk and with the embedder in the Trunk. But it accidentally removed the call that added the eclipse artifact resolver. * My patch is an update of Kenney's patch making it work with the Trunk and added back in the eclipse artifact resolver. It was then modified to be more modular so it would touch less of the m2eclipse code. So in conlusion, you need to decide if you want to use the eclipse artifact resolver. I believe using it will give the most consistant user experience. If you do use the eclipse artifact resolver, then my patch is the most up-to-date. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-811) Documentation of Deployment Repository Directory
Documentation of Deployment Repository Directory Key: CONTINUUM-811 URL: http://jira.codehaus.org/browse/CONTINUUM-811 Project: Continuum Issue Type: Bug Components: Documentation Affects Versions: 1.0.3 Reporter: Scott Cytacki I can't find any good documenation on how the deployment repository directory works. As far as I can tell continuum magically runs a special mvn deploy goal after any sucess build. But I can't find this in the log. Also it isn't clear how this relates to an explicit mvn deploy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_71776 ] Scott Cytacki commented on MNGECLIPSE-59: - I just checked the attachements and it seems they are back. I see that this issue has been marked unassigned. Can someone who has commit access, describe what needs to be done to get this into checked in? Do we need a few people to test it? Is there something wrong with the code that is keeping it out? Do I need to address the performace issue mentioned above: - add a cache to maintain a list of maven eclipse projects instead of rebuilding it on each use of the classpath container. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MJAR-51) handle signing jars which are not project artifacts and not "in place" signing
handle signing jars which are not project artifacts and not "in place" signing
--
Key: MJAR-51
URL: http://jira.codehaus.org/browse/MJAR-51
Project: Maven 2.x Jar Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Scott Cytacki
It seems the SignJarMojo is intended to be used both as a way to sign a jar
artifact, and as a utitlity to sign jars for other plugins in maven.
The jnlp plugin uses it in the latter mode. However currently it can only sign
jars "inplace" when the jar being signed isn't a artifact of a project.
More specifically if the signedJar field is not null, and the project of the
SingJarMojo is null, then SignJarMojo fails. Changing:
else
{
project.getArtifact().setFile( signedjar );
}
to
else if ( project != null)
{
project.getArtifact().setFile( signedjar );
}
Would fix this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Scott Cytacki updated MNGECLIPSE-59: Attachment: project-artifacts-2006062900.patch > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Scott Cytacki updated MNGECLIPSE-59: Attachment: project-artifacts-2006062701.patch > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_68386 ] Scott Cytacki commented on MNGECLIPSE-59: - After looking more closely at the two patches: Mark's and Kenney's. I realized they are not the same. Kenney did add the eclipse artfiact resolver to the plexus container. However, Mark's approach for adding it no longer works. The way that Milos implemented it was different than Mark's original approach. You can see that discussed here: http://jira.codehaus.org/browse/MNG-1937 I figured out how to add the eclipse artifact resolver to the container using the version of the embedder currently checked in to the org.maven.ide.eclipse project. I'm cleaning up a patch with that in it now, and I'll post it soon. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_68375 ] Scott Cytacki commented on MNGECLIPSE-59: - Hi Dimitry and Eugene, I'm sorry for any confusion that I caused, but I assumed that Kenney's patch was the most uptodate. Based on Kenney's comments Mark's patch would not apply to the trunk, so Kenney patch was just updating Mark's patch for the trunk. It was my belief that the best way to help Eugene was to make sure that the patch would be easy to apply to the trunk. Continuing with that approach I noticed that my last patch no longer applies cleanly to the trunk, so now I'm updating it. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-145) dependencyManagement in parent poms broken in eclipse on linux
dependencyManagement in parent poms broken in eclipse on linux
--
Key: MNGECLIPSE-145
URL: http://jira.codehaus.org/browse/MNGECLIPSE-145
Project: Maven 2.x Extension for Eclipse
Type: Bug
Components: Dependency Resolver
Versions: 0.0.9
Reporter: Scott Cytacki
Assigned to: Eugene Kuleshov
Attachments: pom.xml
This is a weird one. I don't know if it is a maven embedder bug or an eclipse
plugin bug. I attached a test pom.
This pom has a single dependency on org.codehaus.xfire:xfire-java5
>From the command line I can run mvn compile and it downloads the correct xfire
>artifacts. I tried it both with maven 2.0.2 and 2.0.4
When I enable maven on the project in eclipse using 0.0.9 maven plugin,
eclipse 3.2RC5, linux. It fails saying it cant find:
org.codehaus.xfire:xfire-core:jar:2.4.1
org.codehaus.xfire:xfire-aegis:jar:2.4.1
org.codehaus.xfire:xfire-annotations:jar:2.4.1
When I try the same thing on maven plugin 0.0.9, eclipse 3.2RC7, intel mac.
It works fine.
I looked into the xfire poms, and they are using a fancy dependency setup.
xfire-java5 dependends on xfire-core but it doesn't specifiy a version number.
The version is supposed to be pulled from the dependency management in the
parent pom: xfire-parent. Actually the dependency management section of the
xfire-parent doesn't have the version for each dependency instead it uses:
${version}. Which I assume pulles the version from xfire-parent itself. So
some how this double indirection of version number is confusing only linux. It
could also be the version of eclipse.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-106) Dependency Resolver and PDE conflicts
[ http://jira.codehaus.org/browse/MNGECLIPSE-106?page=comments#action_67837 ] Scott Cytacki commented on MNGECLIPSE-106: -- I've found a way to have a maven project double as a eclipse plugin. I don't know if this solves your particular problem but it is mostly working for me. My main problem is that I have two types of dependencies: 1. Those that are available as both maven artifacts and plugins. 2. Those that are only available as maven artifacts. If a project has dependencies of type 1. Then it is easy, simply choose between the maven classpath container and the plugin classpath container. Remove one of them. Even if you remove the plugin classpath container, the plugin project can still be used by other plugin projects and it can still be used in a testing eclipse application. If a project has dependencies of type 2, then make a second plugin project that contains those maven dependencies. So lets say the project you are working with is called: MyPlugin. It has maven deps on jug and xstream. If you add jug and xtream to the MyPlugin plugin classpath you will get conflicts. So instead make a new plugin project called MyPluginDeps, and add jug and xstream to this project. Now change the MyPlugin manifest.mf so it depends on MyPluginDeps. Now the MyPlugin project will build with either the maven classpath container or the plugin classpath container. This isn't the perfect solution: 1. the dependencies need to be updated in two places. 2. if the dependencies are not the same you might have different jars at runtime than at compile time. The way I'm managing the dependencies right now is to use the maven assembly:assembly goal with the descriptorId set to "jar-with-dependencies" This creates a single jar that contains all dependencies combined into one jar. I then copy this jar into the MyPluginDeps project. > Dependency Resolver and PDE conflicts > - > > Key: MNGECLIPSE-106 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-106 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Components: Dependency Resolver > Environment: Eclipse PDE > Reporter: Dimitry Voytenko > Assignee: Eugene Kuleshov > Attachments: sample-plugins.zip > > > All tests have been done using the solution provided in the > http://jira.codehaus.org/browse/MNGECLIPSE-59. This solution works very well, > but there're specifics when using it in the PDE (Plugin Development) > environment. > Attached are sample plugins that demonstrate the issue (tested under Eclipse > 3.1.2). Unpack sample-plugins.zip and import projects in the workspace. Patch > from MNGECLIPSE-59 should be applied. Rebuild both projects. Build of > "com.example.plugins.main" should fail with an error: >"Build path contains duplicate entry: 'com.example.plugins.component' for > project com.example.plugins.main" > The problem occures b/c of conflict b/w PDE classpath container and Maven2 > classpath container. They both contain "com.example.plugins.component" > project. > PDE's classpath container is defined in the org.eclipse.pde.core plugin as an > org.eclipse.pde.core.requiredPlugins extension. It uses META-INF/MANIFEST.MF > file as a source. MANIFEST.MF is basically an OSGI manifest that lists all > dependent bundles in the form: >Require-Bundle: org.eclipse.core.runtime, ... > with optionally specified version and transiting information. > Both manifest and PDE container are very essential for the PDE work. It's not > clear if they can be properly extended to avoid conflicts. > If such a way can be found, it is important to keep in mind the similarities > and differences b/w Maven and PDE dependency management: > a) PDE dependencies have flags "optional" and "re-exported". By default > dependencies are required and non-transient. The "optional" property can be > modeled via Maven'2 optional dependency. The re-exported property basically > makes the dependency transient. I'm not sure if all of these states can be > modelled via Maven's scope. > b) Version management is different. PDE allows to specify dependency on the > latest found version of a plugin (if version parameters is specified then it > should be greater or equal). In Eclipse 3.2 it's actually possible to specify > both borders, i.e. version no earlier than 2.0.0 and no later than 3.0.0. > c) MANIFEST.MF is a deployable file. It's used at runtime to build the > classloader graph. > If it's not possible to extend PDE to source it from the Maven's > configuration a temporary solution could be to exclude a dependent project > from the Maven container if it can be found elsewhere in the classpath. The > possible issue here: if it's possible to get the access from Maven container > to the content of the other containers. > Cooperation with Eclipse team would probably help here as this would al
[jira] Updated: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Scott Cytacki updated MNGECLIPSE-59: Attachment: project-artifacts.patch > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-134) wizard for creating java project from existing pom.xml
[ http://jira.codehaus.org/browse/MNGECLIPSE-134?page=comments#action_66980 ] Scott Cytacki commented on MNGECLIPSE-134: -- Here are the steps I have to do when checking out a simple maven project: - give it a name: there is no default name suggested by the New Java Project wizard - specify the jre - set the src/main/java and src/test/java folders as source folders - change the output folder: I prefer to separate it from target/classes so the too compilers don't collide - use Maven2->Enable Maven I think those steps are worth a wizard. Really they are just setting up the defaults for the new java project wizard. Hopefully it is easy to set those defaults. > wizard for creating java project from existing pom.xml > -- > > Key: MNGECLIPSE-134 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-134 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Wizards > Reporter: Scott Cytacki > Assignee: Eugene Kuleshov > > > When checking out a maven project from an scm that doesn't include .project > .classpath files. It would be nice if the maven plugin gave the option to > create the eclipse java project as it is being checked out. This is appears > to be handled by making a new project wizard. > An example of similar functionality is when checking out a ant based project > you can create an eclipse project from it. > The current solution is to check it out and then fix it up after the fact, by > adding the maven library, or instead runing the eclipse:eclipse goal. > The wizard could detect things like multimodule projects and at least give > some advice to the user, or better it might beable to give the user different > options for handling them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2355) Documentation of the @component javadoc tag
Documentation of the @component javadoc tag --- Key: MNG-2355 URL: http://jira.codehaus.org/browse/MNG-2355 Project: Maven 2 Type: Improvement Components: Documentation: General Reporter: Scott Cytacki While trying to figure out how the AbstractCompilerMojo worked, I found the @component tag for the compilerManager field. There is a reference page for the mojo-api-spec, but this page doesn't talk about the "component" tag. That page seems like a logical place to put this documentation, or at least a reference to it if it is already somewhere else. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-134) wizard for creating java project from existing pom.xml
wizard for creating java project from existing pom.xml -- Key: MNGECLIPSE-134 URL: http://jira.codehaus.org/browse/MNGECLIPSE-134 Project: Maven 2.x Extension for Eclipse Type: New Feature Components: Wizards Reporter: Scott Cytacki Assigned to: Eugene Kuleshov When checking out a maven project from an scm that doesn't include .project .classpath files. It would be nice if the maven plugin gave the option to create the eclipse java project as it is being checked out. This is appears to be handled by making a new project wizard. An example of similar functionality is when checking out a ant based project you can create an eclipse project from it. The current solution is to check it out and then fix it up after the fact, by adding the maven library, or instead runing the eclipse:eclipse goal. The wizard could detect things like multimodule projects and at least give some advice to the user, or better it might beable to give the user different options for handling them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNGECLIPSE-103) Multiple projects launch configuration name collision
[ http://jira.codehaus.org/browse/MNGECLIPSE-103?page=all ] Scott Cytacki updated MNGECLIPSE-103: - Attachment: maven-plugin-launch-bug.zip > Multiple projects launch configuration name collision > -- > > Key: MNGECLIPSE-103 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-103 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.5 > Environment: eclipse 3.2M5a > Reporter: Scott Cytacki > Assignee: Eugene Kuleshov > Priority: Minor > Attachments: maven-plugin-launch-bug.zip > > > Context: > I have three eclipse projects with depencencies: A -> B -> C > Each project depends on several jars declared in a pom.xml. > Using the maven2 plugin there is a "Maven2 Dependencies" library in each > project. > From the poms, I've removed the B depency from A, and the C dependency from > B. And I've added these dependencies in the eclipse project. > Problem: > When I try to run a class in project A from eclipse it is very difficult to > construct the runtime classpath. This is setup in the "Classpath" tab of the > Run dialog. > If the "Maven2 Dependencies" is exported from projects B and C. Then adding > those projects to this classpath should also add the Maven2 Dependencies > library. What actually happens is that only one Maven2 library is added. > I was able to make this work by saving the a launch configuration I was > configuring and modifying the launcit by hand. The launch file can be saved > though the "shared file" option in the common tab. > My guess is that Run Classpath dialog requires the name of libraries to be > unique. > One solution: > It seems that if the the name of the Maven2 Depedencies library had the name > of the project appended or prepended then creating launch configurations > would be possible through the gui instead of editing the launch configuration > file directly. -- 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
