[jira] Updated: (MNGECLIPSE-107) Dependency Resolver and Eclipse Web Tools Platform (WTP)
[ http://jira.codehaus.org/browse/MNGECLIPSE-107?page=all ] Robert Elliot updated MNGECLIPSE-107: - Attachment: m2eclipse-patch.txt This patch causes M2Eclipse to add a classpath attribute org.eclipse.jst.j2ee.deployableArtifact=true to all items it adds to a project's classpath that ought to be packaged up with it if the project should be packaged as a war or ear. At present this will do nothing useful, but it is possible that future releases of the WTP will recognise this attribute and act accordingly when deploying to a server. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=154251 Dependency Resolver and Eclipse Web Tools Platform (WTP) Key: MNGECLIPSE-107 URL: http://jira.codehaus.org/browse/MNGECLIPSE-107 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Components: Dependency Resolver Environment: Eclipse WTP Reporter: Dimitry Voytenko Attachments: m2eclipse-patch.txt, wtp-samples.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 with WebTools. Attached are sample projects that demonstrate the issue (tested under Eclipse 3.1.2). Unpack wtp-samples.zip and import projects in the workspace. Patch from MNGECLIPSE-59 should be applied. Rebuild both projects. Build of web-main should fail with an error: Build path contains duplicate entry: 'web-component' for project web-main The problem occures b/c of conflict b/w Java classpath (in the Java Build Path Projects) and Maven2 classpath container. They both contain web-component project. If go to Properties Java Build Path Projects and remove web-component project manually everything will compile fine, but WTP will not include web-component in the runtime classpath when running the web-main project in the servlet container (e.g. Tomcat). To fix that, you have to include web-component in the J2EE Module Dependencies for web-main (see Properties J2EE Module Dependencies). When you try to save J2EE Module Dependencies changes, you get the same duplicate classpath entry error. J2EE Module Dependencies use regular Java classpath for a project and thus Maven's container should work just fine (theoretically). The problem occures exactly when WTP tries to save J2EE Module Dependencies and synchronize them with Java classpath. It most probably tries to add a project marked in the module dependencies to the list of dependent java projects and fails. One solution here could be to source J2EE Module Dependencies from the Maven's configuration for a project. J2EE Module Dependencies are stored within the project in the .settings/.component and looks something like the following: dependent-module deploy-path=/WEB-INF/lib handle=module:/resource/web-component/web-component dependency-typeuses/dependency-type /dependent-module This information is present in the POM with dependency scope other than provided and system. If it's not possible to extend WTP to read module dependencies from Maven's POM this issue can be redirected to WTP itself, as there's nothing illegal with the way Maven2 extends classpath (as specified in MNGECLIPSE-59). It's only the synchronization procedure of WTP configuration that fails in this case. -- 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_72440 ] Robert Elliot commented on MNGECLIPSE-59: - I applied the patch to a clean check out from Trunk last night, built and upgraded to the 0.0.10 plugin. It appears to work fine in terms of doing what it's meant to; however, I had dual entries in the classpath of many of my projects because I had previously put the project in the POM and added it as a project in the Eclipse classpath. Particularly in the case of a WTP project that made the whole workspace unstable - in fact the only way I was able to remove the duplicate entries from the WTP project was to close the workspace, go into the .settings folder via Windows Explorer and remove the WTP dependencies manually. Which makes me wonder if having a dual entry on the classpath results in some kind of infinite loop? I'm fairly sure that vanilla Eclipse lets you recover errors like that without needing to alter files in notepad. 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_72444 ] Robert Elliot commented on MNGECLIPSE-59: - Very minor point - if you have project A in the workspace specifying version 0.1 of project B in its POM and project B version 0.1 in the workspace, it is correctly resolved as a project. If you then change project B's POM to version 0.2, project A should immediately break (or resolve to the repository if you installed B0.1 at some point). In fact it carries on merrily resolving to Project B in the workspace until you make an edit to Project A's POM, at which point it resolves the reference to B0.1, realises it isn't in the workspace and acts appropriately. It would be nice if the plugin did a resolve of all Maven2 projects in the workspace when any POM is updated, to avoid this issue. Not sure how expensive that might be, or whether you could do a targetted resolve of only references to the project whose POM had changed. I'll have a look at the code. 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-178) Type ahead for all elements in the POM
Type ahead for all elements in the POM -- Key: MNGECLIPSE-178 URL: http://jira.codehaus.org/browse/MNGECLIPSE-178 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Components: POM Editor Affects Versions: 0.0.9 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Priority: Minor The standard POM added when clicking Maven2 - Enable should have the project tag look like this: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; The XML editor will then allow type ahead help in adding elements in the right place. Saves people going looking for the schema location and putting it in manually. -- 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-178) Type ahead for all elements in the POM
[ http://jira.codehaus.org/browse/MNGECLIPSE-178?page=comments#action_72447 ] Robert Elliot commented on MNGECLIPSE-178: -- Just had a look in the code - it appears this is something the MavenEmbedder class does, so not really something this pugin can fix. Type ahead for all elements in the POM -- Key: MNGECLIPSE-178 URL: http://jira.codehaus.org/browse/MNGECLIPSE-178 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Components: POM Editor Affects Versions: 0.0.9 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Priority: Minor The standard POM added when clicking Maven2 - Enable should have the project tag look like this: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; The XML editor will then allow type ahead help in adding elements in the right place. Saves people going looking for the schema location and putting it in manually. -- 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-105) Add maven-managed dependencies as project J2EE Module Dependencies
[ http://jira.codehaus.org/browse/MNGECLIPSE-105?page=comments#action_72466 ] Robert Elliot commented on MNGECLIPSE-105: -- Has anyone made any attempt at a more elegant solution? I'm trying to work out whether the org.eclipse.wst.server.core.publishTasks extension point might be a viable way to get in and tell the publish operation to include the appropriate jars/projects from the Maven2 library. Unfortunately I can't check WTP out for some reason. Add maven-managed dependencies as project J2EE Module Dependencies -- Key: MNGECLIPSE-105 URL: http://jira.codehaus.org/browse/MNGECLIPSE-105 Project: Maven 2.x Extension for Eclipse Issue Type: Wish Components: Dependency Resolver Affects Versions: 0.0.5 Environment: Eclipse 3.1.2 with WTP 1.0, using Tomcat 5.5 for running webapp projects. Maven 2.x Extension for Eclipse Reporter: Daniel Fernández Attachments: mngeclipse-test.zip When creating a WTP's Dynamic Web project with eclipse, following a maven2 directory structure and creating a pom.xml file for it using the Maven 2.x Extension for Eclipse, everything works ok with dependencies as these are added to the project build path (under the Maven 2 Dependencies folder) as soon as they are added to the pom.xml But, when this project is being run in a Tomcat Server from eclipse, these dependencies are not being added to the WEB-INF/lib directory. This could be done by adding, for each newly added dependency and its transitive dependencies (not having scope provided or test) an entry into the .settings/.component file like these: dependent-module deploy-path=/WEB-INF/lib handle=module:/classpath/var/M2_REPO/commons-collections/commons-collections/2.1/commons-collections-2.1.jar dependency-typeuses/dependency-type /dependent-module (this one was written by the maven-eclipse-plugin, which creates these entries) This way webapps created from eclipse and managed by maven could be automatically run in Tomcat from Eclipse. Regards, Daniel. -- 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-181) Update the eclipse artifact resolver so that projects react to a change in one of their dependencies POMs
Update the eclipse artifact resolver so that projects react to a change in one of their dependencies POMs - Key: MNGECLIPSE-181 URL: http://jira.codehaus.org/browse/MNGECLIPSE-181 Project: Maven 2.x Extension for Eclipse Issue Type: Task Components: Dependency Resolver Affects Versions: 0.0.10 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Priority: Minor Using patch project-artifacts-2006062900.patch in http://jira.codehaus.org/browse/MNGECLIPSE-59 if you have project A in the workspace specifying version 0.1 of project B in its POM and project B version 0.1 in the workspace, this dependency of A is correctly resolved to the workspace. If you then change project B's POM to version 0.2, project A should immediately break (or resolve to the repository if you installed B0.1 at some point). In fact it carries on merrily resolving to Project B in the workspace until you make an edit to Project A's POM, at which point it resolves the reference to B0.1, realises it isn't in the workspace and acts appropriately. It would be nice if the plugin did a resolve of all Maven2 projects in the workspace when any POM is updated, to avoid this issue. Not sure how expensive that might be, or whether you could do a targetted resolve of only references to the project whose POM had changed. Scott Cytacki's comment: 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. -- 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_72485 ] Robert Elliot commented on MNGECLIPSE-59: - created http://jira.codehaus.org/browse/MNGECLIPSE-181 to discuss updating projects that depend on the changed project on POM saving 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-105) Add maven-managed dependencies as project J2EE Module Dependencies
[ http://jira.codehaus.org/browse/MNGECLIPSE-105?page=comments#action_72511 ] Robert Elliot commented on MNGECLIPSE-105: -- I've been stepping through the WTP code, and have as a result raised this improvement request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=154165 I wonder if someone who is much more familiar with the Eclipse extensibility framework could have a look and see whether there is anything that can be done without an alteration to WTP. Questions I immediately have are: * What happens if two plugins use the org.eclipse.wst.server.core.moduleFactories extension point, both declaring they are for the same type of project? Is there any way for a plugin to specify use me, not that other one? * Can the Maven plugin use this extension point without making the whole plugin dependent on the WTP project at runtime? As obviously this extension point would only get used if you had already installed WTP. I'm afraid I'm very green when it comes to the Eclipse plugin framework. Add maven-managed dependencies as project J2EE Module Dependencies -- Key: MNGECLIPSE-105 URL: http://jira.codehaus.org/browse/MNGECLIPSE-105 Project: Maven 2.x Extension for Eclipse Issue Type: Wish Components: Dependency Resolver Affects Versions: 0.0.5 Environment: Eclipse 3.1.2 with WTP 1.0, using Tomcat 5.5 for running webapp projects. Maven 2.x Extension for Eclipse Reporter: Daniel Fernández Attachments: mngeclipse-test.zip When creating a WTP's Dynamic Web project with eclipse, following a maven2 directory structure and creating a pom.xml file for it using the Maven 2.x Extension for Eclipse, everything works ok with dependencies as these are added to the project build path (under the Maven 2 Dependencies folder) as soon as they are added to the pom.xml But, when this project is being run in a Tomcat Server from eclipse, these dependencies are not being added to the WEB-INF/lib directory. This could be done by adding, for each newly added dependency and its transitive dependencies (not having scope provided or test) an entry into the .settings/.component file like these: dependent-module deploy-path=/WEB-INF/lib handle=module:/classpath/var/M2_REPO/commons-collections/commons-collections/2.1/commons-collections-2.1.jar dependency-typeuses/dependency-type /dependent-module (this one was written by the maven-eclipse-plugin, which creates these entries) This way webapps created from eclipse and managed by maven could be automatically run in Tomcat from Eclipse. Regards, Daniel. -- 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-177) Compiler Plugin Fails
Compiler Plugin Fails - Key: MNGECLIPSE-177 URL: http://jira.codehaus.org/browse/MNGECLIPSE-177 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Maven Launcher Affects Versions: 0.0.9 Environment: Eclipse 3.2, Windows XP, Java 1.5.0-06 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Attachments: lidalia-test-message.zip Choosing Run as on a very simple maven enabled project and specifying as goals clean install results in a compiler error as so: [INFO] compiler:compile Compiling 1 source file to C:\Documents and Settings\Rob\Eclipse Workspaces\Experimentation Workspace\lidalia-test-remoting\target\classes [ERROR] mojo-execute : compiler:compile Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project [ERROR] project-execute : uk.org.lidalia:lidalia-test-remoting:jar:0.0.1 ( task-segment: [clean, install] ) Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 8 more Running mvn clean install from the command line works fine. -- 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-177) Compiler Plugin Fails
[ http://jira.codehaus.org/browse/MNGECLIPSE-177?page=comments#action_72315 ] Robert Elliot commented on MNGECLIPSE-177: -- That was it. Sorry for bothering you. Compiler Plugin Fails - Key: MNGECLIPSE-177 URL: http://jira.codehaus.org/browse/MNGECLIPSE-177 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Maven Launcher Affects Versions: 0.0.9 Environment: Eclipse 3.2, Windows XP, Java 1.5.0-06 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Attachments: lidalia-test-message.zip Choosing Run as on a very simple maven enabled project and specifying as goals clean install results in a compiler error as so: [INFO] compiler:compile Compiling 1 source file to C:\Documents and Settings\Rob\Eclipse Workspaces\Experimentation Workspace\lidalia-test-remoting\target\classes [ERROR] mojo-execute : compiler:compile Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project [ERROR] project-execute : uk.org.lidalia:lidalia-test-remoting:jar:0.0.1 ( task-segment: [clean, install] ) Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 8 more Running mvn clean install from the command line works fine. -- 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-165) URLs for source code on the project site are wrong
URLs for source code on the project site are wrong -- Key: MNGECLIPSE-165 URL: http://jira.codehaus.org/browse/MNGECLIPSE-165 Project: Maven 2.x Extension for Eclipse Issue Type: Task Affects Versions: 0.0.9 Environment: Site Reporter: Robert Elliot Assigned To: Eugene Kuleshov Priority: Trivial Fix For: 0.0.9 On the main page of the site (http://m2eclipse.codehaus.org/) the URLs are incorrect. They are given as: http://svn.codehaus.org/trunk/?root=m2eclipse and svn co https://svn.codehaus.org/m2eclipse/trunk m2eclipse they should be: http://svn.codehaus.org/m2eclipse/trunk/?root=m2eclipse and svn co http://svn.codehaus.org/m2eclipse/trunk m2eclipse -- 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-87) Enabling Maven on a project does not change the context sensitive menu
[ http://jira.codehaus.org/browse/MNGECLIPSE-87?page=comments#action_61408 ] Robert Elliot commented on MNGECLIPSE-87: - Narrowed it down - it's J2EE Standard Tools (JST) 1.0.1 that causes the problem. And it definitely does it to the Spring plugin, too - incorrect visibility context menus appearing. I'll look for/raise a bug over at Eclipse. Enabling Maven on a project does not change the context sensitive menu -- Key: MNGECLIPSE-87 URL: http://jira.codehaus.org/browse/MNGECLIPSE-87 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.5 Environment: Eclipse 3.2 M5a Reporter: Robert Elliot Assignee: Eugene Kuleshov 1) Create a new Java project in Eclipse 3.2 M5a 2) Right click on the project, and in the resulting context sensitive menu go to Maven2 - Enable 3) Complete the wizard, making this a Maven enabled project 4) Notice that the Maven nature builder is correctly added to the .project file 5) Notice that the Maven icon is not added to the Project 6) Right click on the project, and in the resulting context sensitive menu go to Maven2. Notice that the only available option is still Enable - you cannot disable or add dependencies. 7) Notice that you can right-click on the pom and add dependencies. No errors in the m2 console, nor anything immediately obvious in the debug output. Don't currently understand Eclipse plugins well enough to work it out from the code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-87) Enabling Maven on a project does not change the context sensitive menu
[ http://jira.codehaus.org/browse/MNGECLIPSE-87?page=comments#action_61411 ] Robert Elliot commented on MNGECLIPSE-87: - Eclipse bug here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=132419 Enabling Maven on a project does not change the context sensitive menu -- Key: MNGECLIPSE-87 URL: http://jira.codehaus.org/browse/MNGECLIPSE-87 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.5 Environment: Eclipse 3.2 M5a Reporter: Robert Elliot Assignee: Eugene Kuleshov 1) Create a new Java project in Eclipse 3.2 M5a 2) Right click on the project, and in the resulting context sensitive menu go to Maven2 - Enable 3) Complete the wizard, making this a Maven enabled project 4) Notice that the Maven nature builder is correctly added to the .project file 5) Notice that the Maven icon is not added to the Project 6) Right click on the project, and in the resulting context sensitive menu go to Maven2. Notice that the only available option is still Enable - you cannot disable or add dependencies. 7) Notice that you can right-click on the pom and add dependencies. No errors in the m2 console, nor anything immediately obvious in the debug output. Don't currently understand Eclipse plugins well enough to work it out from the code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-87) Enabling Maven on a project does not change the context sensitive menu
Enabling Maven on a project does not change the context sensitive menu -- Key: MNGECLIPSE-87 URL: http://jira.codehaus.org/browse/MNGECLIPSE-87 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.5 Environment: Eclipse 3.2 M5a Reporter: Robert Elliot Assigned to: Eugene Kuleshov 1) Create a new Java project in Eclipse 3.2 M5a 2) Right click on the project, and in the resulting context sensitive menu go to Maven2 - Enable 3) Complete the wizard, making this a Maven enabled project 4) Notice that the Maven nature builder is correctly added to the .project file 5) Notice that the Maven icon is not added to the Project 6) Right click on the project, and in the resulting context sensitive menu go to Maven2. Notice that the only available option is still Enable - you cannot disable or add dependencies. 7) Notice that you can right-click on the pom and add dependencies. No errors in the m2 console, nor anything immediately obvious in the debug output. Don't currently understand Eclipse plugins well enough to work it out from the code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
