[RESULT] [VOTE] Retire Maven Eclipse Plugin / Donation to Mojohaus
Hi, The vote has passed with the following result: +1 (binding): Barrie Treloar, Arnaud Héritier, Tamás Cservenák, Dennis Lundberg, Hervé BOUTEMY, Olivier Lamy, Karl Heinz Marbaise, Kristian Rosenvold, Jason van Zyl, Robert Scholte +1 (non binding): Tibor Digana, Anders Hammar, Michael Osipov, Andreas Gudian +0.5 (non binding): Baptiste Mathus thanks for the huge number of votes!! I will continue with the steps required to retire this plugin. Robert Op Sun, 04 Oct 2015 11:18:55 +0200 schreef Robert Scholte <rfscho...@apache.org>: Hi, during the latest upgrade of the plugin-parent I faced several issues with the maven-eclipse-plugin. It will take quite some time to fix these issues, but is it worth maintaining it here? Nowadays the Maven support for Eclipse is good and stable. The maven-eclipse-plugin has a lot of integration tests which should be rewritten, because it always launches a new Maven fork and it takes ages to complete. This simply blocks good continuous integration of the plugins. I know there are still some projects with can't use the Maven Integration of Eclipse and depend on this plugin, so the sources need to stay available for users so the can extend it for their own usage. I therefor propose that we retire maven-eclipse-plugin for the Apache Maven project and donate it to the Mojohaus project If this vote is successful I will make one final release of the plugin, making it clear on the plugin site that it has been retired. After that the source code will be moved into the "retired" area in Subversion. The process for retiring a plugin is described here: http://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Eclipse Plugin 2.10 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Eclipse Plugin, version 2.10 This plugin is used to generate Eclipse IDE files (*.classpath, *.project, *.wtpmodules and the .settings folder) for use with a project - if the M2E Eclipse-Plugin does not fit you. This release is the last one supporting Maven 2. http://maven.apache.org/plugins/maven-eclipse-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.10/version /plugin Release Notes - Maven Eclipse Plugin - Version 2.10 ** Bug * [MECLIPSE-731] - eclipse:clean not deleting ./settings folder that it creates * [MECLIPSE-738] - NullPointerException in LinkedResource if locationURI is present in .project ** Improvement * [MECLIPSE-697] - Delete deprecated code * [MECLIPSE-721] - Improve documentation to explain why Eclipse sometimes does not import projects with correct project names. * [MECLIPSE-754] - UPdate plexus-archiver to 2.9,plexus-utils to 3.0.18 and maven-archiver to 2.5 * [MECLIPSE-756] - Fix RAT Report * [MECLIPSE-757] - Add proper classpath entry names for Java 7 / 8 * [MECLIPSE-758] - Use mojo annotations ** New Feature * [MECLIPSE-759] - Add goal to resolve dependencies in .classpath files of a workspace Enjoy, -The Apache Maven team
Re: M2Eclipse vs. maven-eclipse-plugin: which is preferred?
If you just use the Eclipse/STS delivered by the Spring team, you get everything that you need to use Maven without worrying about plug-ins. Ron On 15/05/2014 7:50 PM, Barrie Treloar wrote: On 9 May 2014 18:49, Thomas Broyer t.bro...@gmail.com wrote: Hi all, Does the Apache Maven Project/Community has an official stance about whether M2Eclipse or maven-eclipse-plugin is preferred way of importing Maven projects into Eclipse? I thought M2Eclipse was the blessed way, but I cannot find anything official online. Only that the maven-eclipse-plugin hasn't been updated for a while, but that could also be a sign that it has no issue and Eclipse offers backwards compatibility. Note: this is not a poll about what you as a developer prefers, I'm looking for whether there's an official position and which one it is. Background: I'm in a argument in a code review for an archetype about whether to include maven-eclipse-plugin configuration within the POM or not; and any official choice would help us avoid bikeshedding. There isn't anything really official. The maven-eclipse-plugin doesn't get much love any more these days, but still works fine for some people. However you will probably find the m2eclipse experience better. Other alternatives to consider are other editors. I've never used NetBeans or IntelliJ but others report good experiences. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: M2Eclipse vs. maven-eclipse-plugin: which is preferred?
On 9 May 2014 18:49, Thomas Broyer t.bro...@gmail.com wrote: Hi all, Does the Apache Maven Project/Community has an official stance about whether M2Eclipse or maven-eclipse-plugin is preferred way of importing Maven projects into Eclipse? I thought M2Eclipse was the blessed way, but I cannot find anything official online. Only that the maven-eclipse-plugin hasn't been updated for a while, but that could also be a sign that it has no issue and Eclipse offers backwards compatibility. Note: this is not a poll about what you as a developer prefers, I'm looking for whether there's an official position and which one it is. Background: I'm in a argument in a code review for an archetype about whether to include maven-eclipse-plugin configuration within the POM or not; and any official choice would help us avoid bikeshedding. There isn't anything really official. The maven-eclipse-plugin doesn't get much love any more these days, but still works fine for some people. However you will probably find the m2eclipse experience better. Other alternatives to consider are other editors. I've never used NetBeans or IntelliJ but others report good experiences.
Re: M2Eclipse vs. maven-eclipse-plugin: which is preferred?
There is nothing official from the Maven itself. There used to be competing Maven Eclipse integration from different people here, and there has always been the command line generation vs IDE integration. So there is no officially blessed integration from the Maven project proper. Also note that M2Eclipse and the maven-eclipse-plugin are not compatible. In M2E it specifically looks for project files created with the maven-eclipse-plugin and disables them. On May 9, 2014, at 2:19 AM, Thomas Broyer t.bro...@gmail.com wrote: Hi all, Does the Apache Maven Project/Community has an official stance about whether M2Eclipse or maven-eclipse-plugin is preferred way of importing Maven projects into Eclipse? I thought M2Eclipse was the blessed way, but I cannot find anything official online. Only that the maven-eclipse-plugin hasn't been updated for a while, but that could also be a sign that it has no issue and Eclipse offers backwards compatibility. Note: this is not a poll about what you as a developer prefers, I'm looking for whether there's an official position and which one it is. Background: I'm in a argument in a code review for an archetype about whether to include maven-eclipse-plugin configuration within the POM or not; and any official choice would help us avoid bikeshedding. -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We all have problems. How we deal with them is a measure of our worth. -- Unknown
M2Eclipse vs. maven-eclipse-plugin: which is preferred?
Hi all, Does the Apache Maven Project/Community has an official stance about whether M2Eclipse or maven-eclipse-plugin is preferred way of importing Maven projects into Eclipse? I thought M2Eclipse was the blessed way, but I cannot find anything official online. Only that the maven-eclipse-plugin hasn't been updated for a while, but that could also be a sign that it has no issue and Eclipse offers backwards compatibility. Note: this is not a poll about what you as a developer prefers, I'm looking for whether there's an official position and which one it is. Background: I'm in a argument in a code review for an archetype about whether to include maven-eclipse-plugin configuration within the POM or not; and any official choice would help us avoid bikeshedding. -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/
Re: maven-eclipse-plugin - configure source and output-folders
Hi Andreas, Andreas Dolk wrote: Hi all, we have a rather complex project structure with a lot of projects and a couple of code generators that produce java classes for production and test. The challenge now is to configure the build files so that a mvn eclipse:eclipse run will create all required source folders and set the correct output folders, for example: src folder: src/main/code-gen out folder: (default) - target/classes src folder: src/test/code-gen out folder: target/test-classes Currently we use the maven build helper to set the source folders but I still don't know how to set the out dirs - now it creates a project config that compiles production and test classes into the same out folder which actually causes conflicts. Isn't that automatically done using build-helper:add-source vs. build- helper:add-test-source? Is there any way to fine-tune the .classpath file programmatically? - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin - configure source and output-folders
On Oct 4, 2013, at 5:18 PM, Andreas Dolk andreas.dolk.mo...@googlemail.com wrote: Hi all, we have a rather complex project structure with a lot of projects and a couple of code generators that produce java classes for production and test. The challenge now is to configure the build files so that a mvn eclipse:eclipse run will create all required source folders and set the correct output folders, for example: What happens if you run: mvn test-compile eclipse:eclipse instead of just mvn eclipse:eclipse By default, eclipse:eclipse just runs far enough to get the source directories, not all the test directories. If you force maven to run to the test-compile phase, then it should be able to pick everything up. Dan src folder: src/main/code-gen out folder: (default) - target/classes src folder: src/test/code-gen out folder: target/test-classes Currently we use the maven build helper to set the source folders but I still don't know how to set the out dirs - now it creates a project config that compiles production and test classes into the same out folder which actually causes conflicts. Is there any way to fine-tune the .classpath file programmatically? Cheers, Andreas -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin - configure source and output-folders
test. The challenge now is to configure the build files so that a mvn eclipse:eclipse run will create all required source folders and set the correct output folders, for example: Are you aware of m2e and other options for using Maven in Eclipse? I'm just not convinced you will get what you want from m-e-p in any reasonable timeframe without adjusting the code yourself and donating changes back. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-eclipse-plugin - configure source and output-folders
Hi all, we have a rather complex project structure with a lot of projects and a couple of code generators that produce java classes for production and test. The challenge now is to configure the build files so that a mvn eclipse:eclipse run will create all required source folders and set the correct output folders, for example: src folder: src/main/code-gen out folder: (default) - target/classes src folder: src/test/code-gen out folder: target/test-classes Currently we use the maven build helper to set the source folders but I still don't know how to set the out dirs - now it creates a project config that compiles production and test classes into the same out folder which actually causes conflicts. Is there any way to fine-tune the .classpath file programmatically? Cheers, Andreas
maven-eclipse-plugin generates wrong eclipse project
Hi! I have a source directory structure like below (1). I have maven project that compiles uses include in the pom.xml and all builds OK. When I run mvn eclipse:eclipse in same directory I do not get a usable Eclipse project. The classes dir after compilation looks like (2). I suggest that in general maven-eclipse-pluging would like to accept any maven project that is accepted by maven. Is there anyone who can advice about it? 1) +---gen | \---com | \---HybridJava | \---Sample | A.java +---src | \---com | \---HybridJava | \---Sample | B.java 2) +---classes | +---gen | | \---com | | \---HybridJava | | \---Sample | | A.class | +---src | | \---com | | \---HybridJava | | \---Sample | | B.class Nikolay - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: JDT compiler compliance level as a parameter for eclipse:eclipse target of maven-eclipse-plugin
Thanks for suggestions, Barrie and Wayne! I will have a look at maven-eclipse-plugin source code later. To clarify, source1.5/source corresponds to javac -source option and to ECJ org.eclipse.jdt.core.compiler.source setting target1.6/target corresponds to javac -target option and to ECJ org.eclipse.jdt.core.compiler.codegen.targetPlatform setting org.eclipse.jdt.core.compiler.compliance is an ECJ setting, which doesn't have a direct counterpart either in javac options or in maven-compiler-plugin settings. I've really tried hard to figure out what exactly it means but Eclipse documentation [1] is vague about the meaning of this option. According to the JDT settings compatibility table [2], codegen.targetPlatform specifies the target VM version, and should never be less then the source version, whereas the source version and compliance settings are quite similar, but the former seems to be a refinement of the latter. After reading [3], [4] and [5] my best guess is that - compliance corresponds to Java language version, - source corresponds to Java class library version (see -bootclasspath option for javac), - target corresponds to Java VM version, - and Execution Environment setting would correspond to Java runtime version (see [6]). At least, this explanation clarifies why I was able to use Java6 syntax sugar (@Override on interface implementation) with compliance set to 1.6, whereas source and target were set to 1.5. Still I may be wrong and the only way to get an authoritative answer is to ask on the JDT DEV mailing list. I'll ask them and hopefully come back later with an answer. As for Sun's javac, it seems that compliance is always set to the jdk level, e.g. javac -source 1.5 -target 1.5 with javac from jdk6u27 allows using @Override annotation on interface implementation. [1] http://help.eclipse.org/juno/topic/org.eclipse.jdt.doc.user/reference/preferences/java/ref-preferences-compiler.htm [2] Open http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%2Fguide%2Fjdt_api_options.htm , scroll down to JDT Core options descriptions, click on Builder options and scroll a bit up to see the compatibility table [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=323633#c23 [4] http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse.jdt/core/3.7.0/org/eclipse/jdt/internal/compiler/batch/Main.java#Main.validateOptions%28boolean%29 [5] http://wiki.eclipse.org/index.php/Execution_Environment [6] http://wiki.eclipse.org/PDE/Resources/Execution_Environments Regards, Mikhail - Original Message - From: Barrie Treloar baerr...@gmail.com To: Maven Users List users@maven.apache.org Sent: Friday, July 27, 2012 12:29:04 AM Subject: Re: JDT compiler compliance level as a parameter for eclipse:eclipse target of maven-eclipse-plugin On Fri, Jul 27, 2012 at 7:57 AM, Barrie Treloar baerr...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:13 AM, Wayne Fay wayne...@gmail.com wrote: Long story short, I tried to modify eclipse project generation so that in the .settings/org.eclipse.jdt.core.prefs instead of this: org.eclipse.jdt.core.compiler.compliance=1.5 I get this (look at the compliance): org.eclipse.jdt.core.compiler.compliance=1.6 but didn't find a way to configure maven-eclipse-plugin. Most likely you are the first person to want this specific configuration of the plugin, thus it does not currently exist. You'll probably need to scratch your own itch. Pull down the source code for maven-eclipse-plugin, tweak it somehow to add this feature, and contribute the code back for (possible) inclusion in a future release. Here's a hint: you're going to want to adjust EclipseSettingsWriter and probably some Eclipse plugin Mojo code too since this should be an extra configuration item in the plugin... http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/writers/workspace/EclipseSettingsWriter.html Also remember, that the maven-eclipse-plugin reads the configuration of the maven-compiler-plugin. See http://maven.apache.org/plugins/maven-eclipse-plugin/trouble-shooting/jdk-being-used-is-different-than-expected.html So you ideally need to configure that the way you want. I'm not sure what org.eclipse.jdt.core.compiler.compliance=1.6 actually does. Is this equivalent to plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.6/target /configuration /plugin Alternatively, you can fix your problem with the overrides and mark it as something to worry about manually. The time invested to fix this automatically may not be worth the effort. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
JDT compiler compliance level as a parameter for eclipse:eclipse target of maven-eclipse-plugin
Hi, I've tried to checkout Jenkins CI source code and generate an Eclipse project for it (see instructions in [1]). Unfortunately generated Eclipse projects seemed to contain errors, which I first reported as a Jenkins bug [2]. Further investigation revealed that even though Jenkins is build with javac -source 1.5 -target 1.5 parameters, they use javac from JDK6u18 or later and rely on animal-sniffer plug-in to ensure that their code is java5-compliant. Unfortunately, it seems that neither Sun's javac nor Animal Sniffer noticed the presence of @Override annotations on methods implementing interfaces, which is not allowed in Java 5 and is ok in Java 6 [3]. On the other hand, Eclipse Java Compiler does notice them and mark each one as error. Long story short, I tried to modify eclipse project generation so that in the .settings/org.eclipse.jdt.core.prefs instead of this: org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5 eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.source=1.5 org.eclipse.jdt.core.compiler.compliance=1.5 I get this (look at the compliance): org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5 eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.source=1.5 org.eclipse.jdt.core.compiler.compliance=1.6 but didn't find a way to configure maven-eclipse-plugin. Has anybody else experienced this problem? Can you suggest any ideas? [1] https://wiki.jenkins-ci.org/display/JENKINS/Building+Jenkins [2] https://issues.jenkins-ci.org/browse/JENKINS-14579 [3] http://stackoverflow.com/questions/8220786/java-eclipse-override-error Kind regards, Mikhail Kalkov Purple Scout AB Software Developer Address: Östra Hamngatan 31, SE- 41110 Gothenburg, Sweden Phone: +46 (0) 732 - 051405 E-mail: mikhail.kal...@purplescout.se Web: www.purplescout.se - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: JDT compiler compliance level as a parameter for eclipse:eclipse target of maven-eclipse-plugin
Long story short, I tried to modify eclipse project generation so that in the .settings/org.eclipse.jdt.core.prefs instead of this: org.eclipse.jdt.core.compiler.compliance=1.5 I get this (look at the compliance): org.eclipse.jdt.core.compiler.compliance=1.6 but didn't find a way to configure maven-eclipse-plugin. Most likely you are the first person to want this specific configuration of the plugin, thus it does not currently exist. You'll probably need to scratch your own itch. Pull down the source code for maven-eclipse-plugin, tweak it somehow to add this feature, and contribute the code back for (possible) inclusion in a future release. Here's a hint: you're going to want to adjust EclipseSettingsWriter and probably some Eclipse plugin Mojo code too since this should be an extra configuration item in the plugin... http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/writers/workspace/EclipseSettingsWriter.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: JDT compiler compliance level as a parameter for eclipse:eclipse target of maven-eclipse-plugin
On Fri, Jul 27, 2012 at 7:13 AM, Wayne Fay wayne...@gmail.com wrote: Long story short, I tried to modify eclipse project generation so that in the .settings/org.eclipse.jdt.core.prefs instead of this: org.eclipse.jdt.core.compiler.compliance=1.5 I get this (look at the compliance): org.eclipse.jdt.core.compiler.compliance=1.6 but didn't find a way to configure maven-eclipse-plugin. Most likely you are the first person to want this specific configuration of the plugin, thus it does not currently exist. You'll probably need to scratch your own itch. Pull down the source code for maven-eclipse-plugin, tweak it somehow to add this feature, and contribute the code back for (possible) inclusion in a future release. Here's a hint: you're going to want to adjust EclipseSettingsWriter and probably some Eclipse plugin Mojo code too since this should be an extra configuration item in the plugin... http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/writers/workspace/EclipseSettingsWriter.html Also remember, that the maven-eclipse-plugin reads the configuration of the maven-compiler-plugin. See http://maven.apache.org/plugins/maven-eclipse-plugin/trouble-shooting/jdk-being-used-is-different-than-expected.html So you ideally need to configure that the way you want. I'm not sure what org.eclipse.jdt.core.compiler.compliance=1.6 actually does. Is this equivalent to plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.6/target /configuration /plugin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: JDT compiler compliance level as a parameter for eclipse:eclipse target of maven-eclipse-plugin
On Fri, Jul 27, 2012 at 7:57 AM, Barrie Treloar baerr...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:13 AM, Wayne Fay wayne...@gmail.com wrote: Long story short, I tried to modify eclipse project generation so that in the .settings/org.eclipse.jdt.core.prefs instead of this: org.eclipse.jdt.core.compiler.compliance=1.5 I get this (look at the compliance): org.eclipse.jdt.core.compiler.compliance=1.6 but didn't find a way to configure maven-eclipse-plugin. Most likely you are the first person to want this specific configuration of the plugin, thus it does not currently exist. You'll probably need to scratch your own itch. Pull down the source code for maven-eclipse-plugin, tweak it somehow to add this feature, and contribute the code back for (possible) inclusion in a future release. Here's a hint: you're going to want to adjust EclipseSettingsWriter and probably some Eclipse plugin Mojo code too since this should be an extra configuration item in the plugin... http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/writers/workspace/EclipseSettingsWriter.html Also remember, that the maven-eclipse-plugin reads the configuration of the maven-compiler-plugin. See http://maven.apache.org/plugins/maven-eclipse-plugin/trouble-shooting/jdk-being-used-is-different-than-expected.html So you ideally need to configure that the way you want. I'm not sure what org.eclipse.jdt.core.compiler.compliance=1.6 actually does. Is this equivalent to plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.5/source target1.6/target /configuration /plugin Alternatively, you can fix your problem with the overrides and mark it as something to worry about manually. The time invested to fix this automatically may not be worth the effort. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
My day job company is associate member of Eclipse so of course Eclipse is tool to use. Markku On 2.3.2012 18:14, Wayne Fay wrote: You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that ... Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Help me understand this line of thinking... Product A is demonstrably broken for what we need and has been since 2008. Products B and C support our needs perfectly well. One is free, one is not. And yet B and C are not an option. This doesn't sound rational to me. Why are they not an option for you? I would challenge that assertion with whoever is making the decision. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
My day job company is assosiate member of Eclipse so of course Eclipse is tool to use. Markku On 2.3.2012 18:14, Wayne Fay wrote: You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that ... Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Help me understand this line of thinking... Product A is demonstrably broken for what we need and has been since 2008. Products B and C support our needs perfectly well. One is free, one is not. And yet B and C are not an option. This doesn't sound rational to me. Why are they not an option for you? I would challenge that assertion with whoever is making the decision. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
On Sat, Mar 3, 2012 at 6:28 AM, Markku Saarela markku.saar...@iki.fi wrote: Our releases do not have any configuration files in artifact's, instead manifest classpaths has directory name to point directory that has those files. We use separate build to assembly different configurations into different environments putting configurations in place. I like to use Eclipse ability to hot deploy modifications of code into server while debugging development trunk code. So what you say and my experience it is impossible to use multi-module project imported with project references for developing software with hot deployment and also unit testing without having profiles to set resource directories for Eclipse unit testing and deploying into server. There is nothing stopping you creating an extra level of abstraction, i.e. mymodule-unittests You move all your unit tests out of the original module mymodule and into mymodule-unittests. Obviously mymodule-unittests would depend on mymodule That way you can run unit tests, but you would only ever deploy mymodule, with no way to pollute with unit tests. p.s. Given Eclipse is open source, if this was a defect that you *really* cared about, you should provide a patch. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
On 02/03/2012 1:32 AM, Markku Saarela wrote: Hi, Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin you have to use profiles, because Eclipse does not isolate test code and test resources. Eclipse does /src/main/ code /src/test ... test code and resources You need to set your maven properly but it works fine unless I don't understand your issue. Only way to do it what i have figured out is to have two profiles one for running application in app server and another for unit testing same code. Those profiles has only resources and testResources definitions. Separating test code for separate code is not an option, because then Sonar reports 0 % coverage. rgds, Markku On 1.3.2012 22:55, Ron Wheeler wrote: On 01/03/2012 2:43 PM, offbyone wrote: Ok so I should create a base pom with a war configuration and then a separate pom for each site that depends on this with overlays to add the extra configuration file. I will try. If I am interpreting your comments correctly, profiles allow for a user to flaten a maven build deployment, but this is a bad practice and it is better to make your maven structure deep. So are profiles going to be deprecated? I would think I am not alone in getting turned down the wrong path because most of the documentation/howtos I have found point to using profiles. There are some uses for profiles that seem harmless so it is a documentation issue. It is fairly common in Apache documentation for the programmers to make a big deal about all the wonderful things that the package can do. They are not particularly concerned about Best Practices. The most common usage is often left out of the documentation since it is dull or not very impressive. This sometimes means that obscure usage of features or seldom used features are heavily documented while the main use case is not described. New Maven users often fall into the trap that you were headed into. A really simple Best Practice that most people use, is hard to find in the documentation while an obscure Worst Practice is described because it shows how clever the software developers are and how powerful the product is. There should be a Best Practice section on the Maven site describing the best way to implement the common software development patterns. There are not really a lot of cases to consider but every new Maven user has to sort out their own case. Ron -- View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Hi, You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that which are test sources and not include them to runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708 So everything under src/test goes also into GlassFish server if you deploy application in Eclipse. That causes that those unit test properties and configuration and classes are picked first and they are effective and application does not work. Even worst if you have multi-module project and B module is dependent from A and A project defines SPI interface and has in src/test/java test implementation for that and of course in src/test/resources/META-INF/services SPI file for exposing that test SPI implementation then if B implements also that SPI interface and put SPI file in src/main/resources/META-INF/services, you cannot test you implementation via ServiceLoader because it pick's that module A test implementation. Same goes for properties and everything else. Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Markku On 2.3.2012 15:15, Ron Wheeler wrote: On 02/03/2012 1:32 AM, Markku Saarela wrote: Hi, Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin you have to use profiles, because Eclipse does not isolate test code and test resources. Eclipse does /src/main/ code /src/test ... test code and resources You need to set your maven properly but it works fine unless I don't understand your issue. Only way to do it what i have figured out is to have two profiles one for running application in app server and another for unit testing same code. Those profiles has only resources and testResources definitions. Separating test code for separate code is not an option, because then Sonar reports 0 % coverage. rgds, Markku On 1.3.2012 22:55, Ron Wheeler wrote: On 01/03/2012 2:43 PM, offbyone wrote: Ok so I should create a base pom with a war configuration and then a separate pom for each site that depends on this with overlays to add the extra configuration file. I will try. If I am interpreting your comments correctly, profiles allow for a user to flaten a maven build deployment, but this is a bad practice and it is better to make your maven structure deep. So are profiles going to be deprecated? I would think I am not alone in getting turned down the wrong path because most of the documentation/howtos I have found point to using profiles. There are some uses for profiles that seem harmless so it is a documentation issue. It is fairly common in Apache documentation for the programmers to make a big deal about all the wonderful things that the package can do. They are not particularly concerned about Best Practices. The most common usage is often left out of the documentation since it is dull or not very impressive. This sometimes means that obscure usage of features or seldom used features are heavily documented while the main use case is not described. New Maven users often fall into the trap that you were headed into. A really simple Best Practice that most people use, is hard to find in the documentation while an obscure Worst Practice is described because it shows how clever the software developers are and how powerful the product is. There should be a Best Practice section on the Maven site describing the best way to implement the common software development patterns. There are not really a lot of cases to consider but every new Maven user has to sort out their own case. Ron -- View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
We have been developing and maintaining a large portal application with over 70 WAR files in Eclipse with Maven since 2007 and several smaller portals and standalone applications. We have not had this problem. That is not to say that I am an expert in Eclipse but we know enough to make it work. We do not use maven-eclipse-plug-in. We use the assembly plug-in to build our war files. Perhaps that is the difference. We also deploy to Tomcat which might be a better servlet engine than Glassfish. I am not sure how relevant our experience is to your problem but if I can provide any additional information that you think might help, let me know. Ron On 02/03/2012 10:19 AM, Markku Saarela wrote: Hi, You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that which are test sources and not include them to runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708 So everything under src/test goes also into GlassFish server if you deploy application in Eclipse. That causes that those unit test properties and configuration and classes are picked first and they are effective and application does not work. Even worst if you have multi-module project and B module is dependent from A and A project defines SPI interface and has in src/test/java test implementation for that and of course in src/test/resources/META-INF/services SPI file for exposing that test SPI implementation then if B implements also that SPI interface and put SPI file in src/main/resources/META-INF/services, you cannot test you implementation via ServiceLoader because it pick's that module A test implementation. Same goes for properties and everything else. Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Markku On 2.3.2012 15:15, Ron Wheeler wrote: On 02/03/2012 1:32 AM, Markku Saarela wrote: Hi, Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin you have to use profiles, because Eclipse does not isolate test code and test resources. Eclipse does /src/main/ code /src/test ... test code and resources You need to set your maven properly but it works fine unless I don't understand your issue. Only way to do it what i have figured out is to have two profiles one for running application in app server and another for unit testing same code. Those profiles has only resources and testResources definitions. Separating test code for separate code is not an option, because then Sonar reports 0 % coverage. rgds, Markku On 1.3.2012 22:55, Ron Wheeler wrote: On 01/03/2012 2:43 PM, offbyone wrote: Ok so I should create a base pom with a war configuration and then a separate pom for each site that depends on this with overlays to add the extra configuration file. I will try. If I am interpreting your comments correctly, profiles allow for a user to flaten a maven build deployment, but this is a bad practice and it is better to make your maven structure deep. So are profiles going to be deprecated? I would think I am not alone in getting turned down the wrong path because most of the documentation/howtos I have found point to using profiles. There are some uses for profiles that seem harmless so it is a documentation issue. It is fairly common in Apache documentation for the programmers to make a big deal about all the wonderful things that the package can do. They are not particularly concerned about Best Practices. The most common usage is often left out of the documentation since it is dull or not very impressive. This sometimes means that obscure usage of features or seldom used features are heavily documented while the main use case is not described. New Maven users often fall into the trap that you were headed into. A really simple Best Practice that most people use, is hard to find in the documentation while an obscure Worst Practice is described because it shows how clever the software developers are and how powerful the product is. There should be a Best Practice section on the Maven site describing the best way to implement the common software development patterns. There are not really a lot of cases to consider but every new Maven user has to sort out their own case. Ron -- View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that ... Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Help me understand this line of thinking... Product A is demonstrably broken for what we need and has been since 2008. Products B and C support our needs perfectly well. One is free, one is not. And yet B and C are not an option. This doesn't sound rational to me. Why are they not an option for you? I would challenge that assertion with whoever is making the decision. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
In multi-module project i hit the same problem with m2e and maven-eclipse-plugin. Are you saying not to import multi-module projects into Eclipse, instead every module separately? Or you don't use server plugins to deploy application instead you deploy outside Eclipse and use remote application debugging? But still this does not prevent unit tests failing with multi-module configuration because of this dependent project classpath has those artifacts in it's classpath before it's own ones. So if you have solution to this i am more than happy to hear it. Markku On 2.3.2012 17:50, Ron Wheeler wrote: We have been developing and maintaining a large portal application with over 70 WAR files in Eclipse with Maven since 2007 and several smaller portals and standalone applications. We have not had this problem. That is not to say that I am an expert in Eclipse but we know enough to make it work. We do not use maven-eclipse-plug-in. We use the assembly plug-in to build our war files. Perhaps that is the difference. We also deploy to Tomcat which might be a better servlet engine than Glassfish. I am not sure how relevant our experience is to your problem but if I can provide any additional information that you think might help, let me know. Ron On 02/03/2012 10:19 AM, Markku Saarela wrote: Hi, You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that which are test sources and not include them to runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708 So everything under src/test goes also into GlassFish server if you deploy application in Eclipse. That causes that those unit test properties and configuration and classes are picked first and they are effective and application does not work. Even worst if you have multi-module project and B module is dependent from A and A project defines SPI interface and has in src/test/java test implementation for that and of course in src/test/resources/META-INF/services SPI file for exposing that test SPI implementation then if B implements also that SPI interface and put SPI file in src/main/resources/META-INF/services, you cannot test you implementation via ServiceLoader because it pick's that module A test implementation. Same goes for properties and everything else. Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Markku On 2.3.2012 15:15, Ron Wheeler wrote: On 02/03/2012 1:32 AM, Markku Saarela wrote: Hi, Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin you have to use profiles, because Eclipse does not isolate test code and test resources. Eclipse does /src/main/ code /src/test ... test code and resources You need to set your maven properly but it works fine unless I don't understand your issue. Only way to do it what i have figured out is to have two profiles one for running application in app server and another for unit testing same code. Those profiles has only resources and testResources definitions. Separating test code for separate code is not an option, because then Sonar reports 0 % coverage. rgds, Markku On 1.3.2012 22:55, Ron Wheeler wrote: On 01/03/2012 2:43 PM, offbyone wrote: Ok so I should create a base pom with a war configuration and then a separate pom for each site that depends on this with overlays to add the extra configuration file. I will try. If I am interpreting your comments correctly, profiles allow for a user to flaten a maven build deployment, but this is a bad practice and it is better to make your maven structure deep. So are profiles going to be deprecated? I would think I am not alone in getting turned down the wrong path because most of the documentation/howtos I have found point to using profiles. There are some uses for profiles that seem harmless so it is a documentation issue. It is fairly common in Apache documentation for the programmers to make a big deal about all the wonderful things that the package can do. They are not particularly concerned about Best Practices. The most common usage is often left out of the documentation since it is dull or not very impressive. This sometimes means that obscure usage of features or seldom used features are heavily documented while the main use case is not described. New Maven users often fall into the trap that you were headed into. A really simple Best Practice that most people use, is hard to find in the documentation while an obscure Worst Practice is described because it shows how clever the software developers are and how powerful the product is. There should be a Best Practice section on the Maven site describing the best way to implement the common software development patterns. There are not really a lot of cases
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
I am not sure if this directly answers your question but perhaps a bit of background helps. We use Eclipse STS which comes with Maven support built in. We used to waste so much time upgrading Eclipse and getting everyone configured in the same way. Now it is a single download (BIG) to get everything that you need except Subversion. We have individual projects since the project is divided up on functional lines with core modules for the database access and some modules that can best be described as utilities (messaging for example). This means that for any maintenance activity almost all of the modules are not affected. In addition, modules are worked on by different people. No one would have all of modules checked out at once. Certainly you would not have them open in Eclipse. We use SNAPSHOTs during development and maintenance. We do not make all of the 70 modules carry the same release version. It is possible to see a version 1.10.3 of the overall application running with most of the WAR files as version 1.10 if they were bug free up to the 1.10.3 release. We do some unit testing and do most of our testing on the developer's workstation. We have at least 1 test server where developers can test in an environment that is almost identical to production and can be tested by the client(s). More than 1 if we have a big maintenance issue while we are trying to get a major development tested. We are starting to use the cloud for this so the actual number of test servers potentially available is close to infinite. We deploy the WAR files by hand to the appropriate server. We use JNDI to support our Spring configurations so we do not have any variation in the WARs between test and different production servers. This is certainly not the only way to do things but I have never heard of any problems with test classes or test configurations leaking into production. The build is described in the master POM for the project. The master POM is the key to every project and contains everything that is common between modules so the module poms are pretty small. Below is the build description from the master POM for a project. I hope that this helps a bit. Ron build sourceDirectorysrc/main/sourceDirectory scriptSourceDirectorysrc/main/scripts/scriptSourceDirectory testSourceDirectorysrc/test/testSourceDirectory outputDirectorytarget/classes/outputDirectory testOutputDirectorytarget/test-classes/testOutputDirectory resources resource directorysrc/main/directory excludes exclude**/*.java/exclude /excludes /resource /resources testResources testResource directorytest/directory excludes exclude**/*.java/exclude /excludes /testResource /testResources directorytarget/directory plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration encodingUTF-8/encoding source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version2.5/version configuration encodingUTF-8/encoding /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.2/version configuration warSourceDirectoryWebContent/warSourceDirectory archive manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries /manifest /archive /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.4/version configuration archive manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries /manifest /archive /configuration /plugin /plugins pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.3/version executions execution phasepackage/phase goals goalsingle/goal /goals configuration archive manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries /manifest /archive descriptorRefs descriptorRef jar-with-dependencies /descriptorRef /descriptorRefs /configuration /execution /executions /plugin /plugins /pluginManagement /build Ron On 02/03/2012 2:00 PM, Markku Saarela wrote: In multi-module project i hit the same problem with m2e and maven-eclipse-plugin. Are you saying not to import multi-module projects into Eclipse, instead every module separately? Or you don't use server plugins to deploy application instead you deploy outside Eclipse and use remote application debugging? But still this does not prevent unit tests failing with multi-module configuration because of this dependent project classpath has those artifacts in it's classpath before it's own ones. So if you have solution to this i am more than
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
/addDefaultSpecificationEntries /manifest /archive descriptorRefs descriptorRef jar-with-dependencies /descriptorRef /descriptorRefs /configuration /execution /executions /plugin /plugins /pluginManagement /build Ron On 02/03/2012 2:00 PM, Markku Saarela wrote: In multi-module project i hit the same problem with m2e and maven-eclipse-plugin. Are you saying not to import multi-module projects into Eclipse, instead every module separately? Or you don't use server plugins to deploy application instead you deploy outside Eclipse and use remote application debugging? But still this does not prevent unit tests failing with multi-module configuration because of this dependent project classpath has those artifacts in it's classpath before it's own ones. So if you have solution to this i am more than happy to hear it. Markku On 2.3.2012 17:50, Ron Wheeler wrote: We have been developing and maintaining a large portal application with over 70 WAR files in Eclipse with Maven since 2007 and several smaller portals and standalone applications. We have not had this problem. That is not to say that I am an expert in Eclipse but we know enough to make it work. We do not use maven-eclipse-plug-in. We use the assembly plug-in to build our war files. Perhaps that is the difference. We also deploy to Tomcat which might be a better servlet engine than Glassfish. I am not sure how relevant our experience is to your problem but if I can provide any additional information that you think might help, let me know. Ron On 02/03/2012 10:19 AM, Markku Saarela wrote: Hi, You don't understand how Eclipse IDE works. Eclipse does not have different classpaths for testing and actual runtime. So Eclipse basic design is faulty. There is bug open since 2008 to provide means to tell Eclipse that which are test sources and not include them to runtime classpath. https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708 So everything under src/test goes also into GlassFish server if you deploy application in Eclipse. That causes that those unit test properties and configuration and classes are picked first and they are effective and application does not work. Even worst if you have multi-module project and B module is dependent from A and A project defines SPI interface and has in src/test/java test implementation for that and of course in src/test/resources/META-INF/services SPI file for exposing that test SPI implementation then if B implements also that SPI interface and put SPI file in src/main/resources/META-INF/services, you cannot test you implementation via ServiceLoader because it pick's that module A test implementation. Same goes for properties and everything else. Of course NetBeans and IntelliJ has correct way to do things but they are not an option. Markku On 2.3.2012 15:15, Ron Wheeler wrote: On 02/03/2012 1:32 AM, Markku Saarela wrote: Hi, Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin you have to use profiles, because Eclipse does not isolate test code and test resources. Eclipse does /src/main/ code /src/test ... test code and resources You need to set your maven properly but it works fine unless I don't understand your issue. Only way to do it what i have figured out is to have two profiles one for running application in app server and another for unit testing same code. Those profiles has only resources and testResources definitions. Separating test code for separate code is not an option, because then Sonar reports 0 % coverage. rgds, Markku - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using build profiles for WAR plugin [maven-eclipse-plugin]
Hi, Developing with Eclipse IDE and JavaEE server using maven-eclipse-plugin you have to use profiles, because Eclipse does not isolate test code and test resources. Only way to do it what i have figured out is to have two profiles one for running application in app server and another for unit testing same code. Those profiles has only resources and testResources definitions. Separating test code for separate code is not an option, because then Sonar reports 0 % coverage. rgds, Markku On 1.3.2012 22:55, Ron Wheeler wrote: On 01/03/2012 2:43 PM, offbyone wrote: Ok so I should create a base pom with a war configuration and then a separate pom for each site that depends on this with overlays to add the extra configuration file. I will try. If I am interpreting your comments correctly, profiles allow for a user to flaten a maven build deployment, but this is a bad practice and it is better to make your maven structure deep. So are profiles going to be deprecated? I would think I am not alone in getting turned down the wrong path because most of the documentation/howtos I have found point to using profiles. There are some uses for profiles that seem harmless so it is a documentation issue. It is fairly common in Apache documentation for the programmers to make a big deal about all the wonderful things that the package can do. They are not particularly concerned about Best Practices. The most common usage is often left out of the documentation since it is dull or not very impressive. This sometimes means that obscure usage of features or seldom used features are heavily documented while the main use case is not described. New Maven users often fall into the trap that you were headed into. A really simple Best Practice that most people use, is hard to find in the documentation while an obscure Worst Practice is described because it shows how clever the software developers are and how powerful the product is. There should be a Best Practice section on the Maven site describing the best way to implement the common software development patterns. There are not really a lot of cases to consider but every new Maven user has to sort out their own case. Ron -- View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5528994.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Eclipse Plugin 2.9 Released
The Maven team is pleased to announce the release of the Maven Eclipse Plugin, version 2.9 The Maven Eclipse Plugin is used to generate Eclipse IDE files (*.classpath, *.wtpmodules and the .settings folder) for use with a project. http://maven.apache.org/plugins/maven-eclipse-plugin/ [Please see Maven Integration for Eclipse m2e (http://eclipse.org/m2e/) if you want Maven embedded in Eclipse.] You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.9/version /plugin Release Notes - Maven 2.x Eclipse Plugin - Version 2.9 ** Bug * [MECLIPSE-388] - Correct classpath ordering in .classpath * [MECLIPSE-434] - WTP 2.0 Documentation * [MECLIPSE-472] - Bad dependencies (version list) in .classpath whereas compilation (and dependency:tree) use the rigth one * [MECLIPSE-548] - MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath * [MECLIPSE-576] - Merge resource dirs shall pass gracefully * [MECLIPSE-585] - [regression] plugin fails to create Eclipse projects in 2.7 * [MECLIPSE-587] - maven-eclipse-plugin creates wrong org.eclipse.wst.common.project.facet.core.xml for ear-projects when javaee:javaee-api s used * [MECLIPSE-597] - Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management) * [MECLIPSE-599] - Broken link to j2ee-simple.tar.gz on multi-module-projects.html * [MECLIPSE-605] - JRE position in Eclipse generated classpath is different from the one used in Maven compiler * [MECLIPSE-621] - mvn eclipse:eclipse fails or doesn't generate proper .classpath when specifying the same resource directory with different filtering rules * [MECLIPSE-627] - Wrong classname used in documentation at additionalBuildcommands * [MECLIPSE-642] - String index out of range during eclipse:eclipse for a project that works with 2.7 * [MECLIPSE-665] - wrong classpath order generated in .classpath file for transitive dependencies * [MECLIPSE-669] - Don't report missing source/javadoc jars when download is false * [MECLIPSE-676] - linkedResources: location vs locationURI * [MECLIPSE-692] - .project contains projects which were skipped during reactor build ** Improvement * [MECLIPSE-350] - Allow to bypass the automatic search of JEE (and related) APIs versions * [MECLIPSE-499] - Improve eclipse:eclipse excludes option * [MECLIPSE-652] - Ability to map a webapp to the root context * [MECLIPSE-691] - Add Websphere 7 runtime support * [MECLIPSE-693] - Some generated xml files are missing their xml-header * [MECLIPSE-694] - Add JEE6 support * [MECLIPSE-696] - Allow file contents to be obtained from url or location does not work behind a firewall ** New Feature * [MECLIPSE-561] - Provide a way to choose .classpath ordering test-first vs. test-last Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Anyone help me about classpathContainers in maven-eclipse-plugin?
On Tue, Dec 20, 2011 at 4:45 PM, zuxiong lin linzuxiong1...@gmail.com wrote: I have a webapp project under eclipse by my colleage. So it has WEB-INF/lib directory and dependcy packages are put in by my colleage. Now I have create a pom file for the project. But import the maven project , I also need to configurate the classpath for it through project --properties--Java Build Path--Libraries -- Add Library -- Web App Libraries--... Why does it still need the classpath ???How do I fix it ? By the way , we use eclipse-jee version 3.7 SR1 like : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.8/version configuration wtpmanifesttrue/wtpmanifest wtpapplicationxmltrue/wtpapplicationxml projectnatures projectnatureorg.eclipse.jdt.core.javanature/projectnature projectnatureorg.eclipse.wst.common.modulecore.ModuleCoreNature/projectnature projectnatureorg.eclipse.jem.workbench.JavaEMFNature/projectnature projectnatureorg.eclipse.wst.common.project.facet.core.nature/projectnature /projectnatures classpathContainers classpathContainerorg.eclipse.jdt.launching.JRE_CONTAINER/classpathContainer !-- classpathContainerorg.eclipse.jst.j2ee.internal.web.container/artifact/classpathContainer -- classpathContainerorg.eclipse.jst.j2ee.internal.web.container/classpathContainer !-- classpathContainerorg.eclipse.jst.j2ee.internal.module.container/classpathContainer -- /classpathContainers /configuration /plugin I dont see a WTP specification in your plugin settings. http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html I dont use WTP so you will have to read the docs and do some fiddling. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Anyone help me about classpathContainers in maven-eclipse-plugin?
classpathContainerorg.eclipse.jst.j2ee.internal.web.container/classpathContainer is not right??? wtpapplicationxmltrue/wtpapplicationxml is not right , too?? But I donot get any useful details in http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html 2011/12/20 Barrie Treloar baerr...@gmail.com On Tue, Dec 20, 2011 at 4:45 PM, zuxiong lin linzuxiong1...@gmail.com wrote: I have a webapp project under eclipse by my colleage. So it has WEB-INF/lib directory and dependcy packages are put in by my colleage. Now I have create a pom file for the project. But import the maven project , I also need to configurate the classpath for it through project --properties--Java Build Path--Libraries -- Add Library -- Web App Libraries--... Why does it still need the classpath ???How do I fix it ? By the way , we use eclipse-jee version 3.7 SR1 like : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.8/version configuration wtpmanifesttrue/wtpmanifest wtpapplicationxmltrue/wtpapplicationxml projectnatures projectnatureorg.eclipse.jdt.core.javanature/projectnature projectnatureorg.eclipse.wst.common.modulecore.ModuleCoreNature/projectnature projectnatureorg.eclipse.jem.workbench.JavaEMFNature/projectnature projectnatureorg.eclipse.wst.common.project.facet.core.nature/projectnature /projectnatures classpathContainers classpathContainerorg.eclipse.jdt.launching.JRE_CONTAINER/classpathContainer !-- classpathContainerorg.eclipse.jst.j2ee.internal.web.container/artifact/classpathContainer -- classpathContainerorg.eclipse.jst.j2ee.internal.web.container/classpathContainer !-- classpathContainerorg.eclipse.jst.j2ee.internal.module.container/classpathContainer -- /classpathContainers /configuration /plugin I dont see a WTP specification in your plugin settings. http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html I dont use WTP so you will have to read the docs and do some fiddling. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Anyone help me about classpathContainers in maven-eclipse-plugin?
I have a webapp project under eclipse by my colleage. So it has WEB-INF/lib
directory
and dependcy packages are put in by my colleage.
Now I have create a pom file for the project. But import the maven project
, I also need to configurate the classpath for it through
project --properties--Java Build Path--Libraries -- Add Library -- Web
App Libraries--...
Why does it still need the classpath ???How do I fix it ?
By the way , we use eclipse-jee version 3.7 SR1
like :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
version2.8/version
configuration
wtpmanifesttrue/wtpmanifest
wtpapplicationxmltrue/wtpapplicationxml
projectnatures
projectnatureorg.eclipse.jdt.core.javanature/projectnature
projectnatureorg.eclipse.wst.common.modulecore.ModuleCoreNature/projectnature
projectnatureorg.eclipse.jem.workbench.JavaEMFNature/projectnature
projectnatureorg.eclipse.wst.common.project.facet.core.nature/projectnature
/projectnatures
classpathContainers
classpathContainerorg.eclipse.jdt.launching.JRE_CONTAINER/classpathContainer
!--
classpathContainerorg.eclipse.jst.j2ee.internal.web.container/artifact/classpathContainer
--
classpathContainerorg.eclipse.jst.j2ee.internal.web.container/classpathContainer
!--
classpathContainerorg.eclipse.jst.j2ee.internal.module.container/classpathContainer
--
/classpathContainers
/configuration
/plugin
More details in the POM of attachment.
Thanks.
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;
modelVersion4.0.0/modelVersion
groupIdcom.kingsoft.tpan/groupId
artifactIdappsvr/artifactId
packagingwar/packaging
version3.1.${BUILD_NUMBER}-RELEASE/version
nameappsvr3.1/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.8.1/version
scopetest/scope
/dependency
!--这里下面的两个dependency, servlet-api与jsp-api所需 --
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.5/version
scopeprovided/scope
/dependency
dependency
groupIdjavax.servlet.jsp/groupId
artifactIdjsp-api/artifactId
version2.1/version
scopeprovided/scope
/dependency
/dependencies
build
finalName${project.artifactId}-${project.version}/finalName
plugins
plugin
groupIdcom.google.code.maven-replacer-plugin/groupId
artifactIdmaven-replacer-plugin/artifactId
version1.3.8/version
executions
execution
phaseprepare-package/phase
goals
goalreplace/goal
/goals
/execution
/executions
configuration
ignoreMissingFiletrue/ignoreMissingFile
filesrc/main/resources/build.version/file
outputFiletarget/classes/build.version/outputFile
regexfalse/regex
replacements
replacement
token$BUILD_NUMBER$/token
value${BUILD_NUMBER}/value
/replacement
replacement
token$LABEL$/token
value${project.artifactId}-${project.version}/value
/replacement
/replacements
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.5/version
configuration
encodingUTF-8/encoding
/configuration
/plugin
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
compilerArguments
extdirs${basedir}/src/main/webapp/WEB-INF/lib/extdirs
/compilerArguments
source1.6/source
target1.6/target
encodingUTF-8/encoding
/configuration
/plugin
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.9/version
configuration
argLine-Xmx256m -XX:PermSize=256m -XX:MaxPermSize=256m/argLine
skipfalse/skip
includes
include**/AppSvrPBApiTest.java/include
include**/AppSvrPBApiPartitionTest.java/include
/includes
disableXmlReportfalse/disableXmlReport
printSummarytrue/printSummary
enableAssertionsfalse/enableAssertions
useManifestOnlyJarfalse/useManifestOnlyJar
forkModealways/forkMode
additionalClasspathElements
additionalClasspathElement${basedir}/src/main/webapp/WEB-INF/lib/apache-mime4j-0.6.jar/additionalClasspathElement
additionalClasspathElement${basedir}/src/main/webapp/WEB-INF/lib/commons-io-1.4.jar/additionalClasspathElement
additionalClasspathElement${basedir}/src/main/webapp/WEB-INF/lib/httpclient-4.0.jar/additionalClasspathElement
additionalClasspathElement${basedir}/src/main/webapp/WEB-INF/lib/httpcore-4.0.1.jar/additionalClasspathElement
additionalClasspathElement${basedir}/src/main/webapp/WEB-INF/lib/httpcore-nio-4.0.1.jar/additionalClasspathElement
additionalClasspathElement${basedir}/src/main/webapp/WEB-INF/lib/httpmime-4.0.jar/additionalClasspathElement
Re: Does maven eclipse plugin downloads unnecesary artifacts?
Thanks Barrie! 2011/11/18 Barrie Treloar baerr...@gmail.com: On Fri, Nov 18, 2011 at 6:19 AM, Gabriel Belingueres belingue...@gmail.com wrote: Hi! I usually use the maven eclipse plugin (v2.8) using the downloadSources and downloadJavadocs properties, however I added some runtime scoped dependency but the eclipse plugin downloads the sources.jar and javadoc.jar too of that library (also no other dependency depends on that runtime scoped library). I agree beforehand that it is no harm to download the sources or javadocs, I just wonder if it is really needed, it is a plugin bug or it is just how maven works for all plugins. I'm not really awake enough to remember the details, but I think the eclipse plugin needs to setup your classpath to also include the runtime dependencies. When configuring the classpath Eclipse does not know about Maven's scopes so everything is treated the same - i.e. attempting to get sources or javadocs. This may come in handy when you run your app inside eclipse and you find a bug in a runtime depenendency. When you debug and step into the .class file you will have the sources available. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Does maven eclipse plugin downloads unnecesary artifacts?
Hi! I usually use the maven eclipse plugin (v2.8) using the downloadSources and downloadJavadocs properties, however I added some runtime scoped dependency but the eclipse plugin downloads the sources.jar and javadoc.jar too of that library (also no other dependency depends on that runtime scoped library). I agree beforehand that it is no harm to download the sources or javadocs, I just wonder if it is really needed, it is a plugin bug or it is just how maven works for all plugins. Regards, Gabriel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Does maven eclipse plugin downloads unnecesary artifacts?
On Fri, Nov 18, 2011 at 6:19 AM, Gabriel Belingueres belingue...@gmail.com wrote: Hi! I usually use the maven eclipse plugin (v2.8) using the downloadSources and downloadJavadocs properties, however I added some runtime scoped dependency but the eclipse plugin downloads the sources.jar and javadoc.jar too of that library (also no other dependency depends on that runtime scoped library). I agree beforehand that it is no harm to download the sources or javadocs, I just wonder if it is really needed, it is a plugin bug or it is just how maven works for all plugins. I'm not really awake enough to remember the details, but I think the eclipse plugin needs to setup your classpath to also include the runtime dependencies. When configuring the classpath Eclipse does not know about Maven's scopes so everything is treated the same - i.e. attempting to get sources or javadocs. This may come in handy when you run your app inside eclipse and you find a bug in a runtime depenendency. When you debug and step into the .class file you will have the sources available. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin: pde support and OSGiManifest writer
I guess there wouldn't be any issue removing it adding a warning pointing to the Felix plugin. Osgi manifests are better handled there. On Fri, Sep 23, 2011 at 8:01 AM, Barrie Treloar baerr...@gmail.com wrote: Does anyone actually use pde mode in maven-eclipse-plugin? The support looks pretty basic and there are other better options like tycho and felix for doing this stuff. EclipseOSGiManifestWriter has been deprecated in favour of felix and I wonder whether its worth keeping the other stuff around. I realise that not every use of the plugin is going to be on the user list - but it can give a gauge of sentiment. Opinions welcome. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin: pde support and OSGiManifest writer
Carlos Sanchez wrote: I guess there wouldn't be any issue removing it adding a warning pointing to the Felix plugin. Osgi manifests are better handled there. +1 - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin: pde support and OSGiManifest writer
+1 Having fewer partial implementations to confuse folks is always better IMO. On 9/27/11 2:08 AM, Carlos Sanchez wrote: I guess there wouldn't be any issue removing it adding a warning pointing to the Felix plugin. Osgi manifests are better handled there. On Fri, Sep 23, 2011 at 8:01 AM, Barrie Treloarbaerr...@gmail.com wrote: Does anyone actually use pde mode in maven-eclipse-plugin? The support looks pretty basic and there are other better options like tycho and felix for doing this stuff. EclipseOSGiManifestWriter has been deprecated in favour of felix and I wonder whether its worth keeping the other stuff around. I realise that not every use of the plugin is going to be on the user list - but it can give a gauge of sentiment. Opinions welcome. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin: pde support and OSGiManifest writer
FWIW, we're using pde mode at present. We have a largish (~ 40 modules) framework that builds both RCP applications and web applications. I haven't had a chance to figure out how to integrate Tycho into this arrangement. On the surface it looks like you're either using p2 dependencies or maven dependencies but not both. Thanks, Steve C On 23/09/2011, at 4:01 PM, Barrie Treloar wrote: Does anyone actually use pde mode in maven-eclipse-plugin? The support looks pretty basic and there are other better options like tycho and felix for doing this stuff. EclipseOSGiManifestWriter has been deprecated in favour of felix and I wonder whether its worth keeping the other stuff around. I realise that not every use of the plugin is going to be on the user list - but it can give a gauge of sentiment. Opinions welcome. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin: pde support and OSGiManifest writer
On Wed, Sep 28, 2011 at 11:40 AM, Stephen Coy st...@resolvesw.com wrote: FWIW, we're using pde mode at present. We have a largish (~ 40 modules) framework that builds both RCP applications and web applications. I haven't had a chance to figure out how to integrate Tycho into this arrangement. On the surface it looks like you're either using p2 dependencies or maven dependencies but not both. I don't suppose you have some documentation that describes your setup? For the RCP application I was building we used (the now defunct) org.codehaus.mojo:pde-maven-plugin. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin: pde support and OSGiManifest writer
We're building bundles with the following build configuration:
packagingbundle/packaging
build
extensions
extension
groupIdorg.apache.felix/groupId
artifactIdorg.osgi.core/artifactId
version1.2.0/version
/extension
/extensions
plugins
!-- configure the bundle plugin executed as part of the bundle
packaging type --
!-- generate an OSGI manifest --
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
extensionstrue/extensions
configuration
manifestLocationMETA-INF/manifestLocation
instructions
_nousestrue/_nouses
Bundle-SymbolicNamecom.foobar.platform.rules.deployer.config;singleton:=true/Bundle-SymbolicName
Bundle-NameFoobar Deployer Configuration/Bundle-Name
Bundle-RequiredExecutionEnvironmentJavaSE-1.6/Bundle-RequiredExecutionEnvironment
Bundle-DocURL /
Import-Package!*/Import-Package
Private-Packagecom.foobar.platform.rules.deployer.config.*/Private-Package
Export-Package /
Bundle-Activatorcom.foobar.platform.rules.deployer.config.plugin.DeployerConfigPlugin/Bundle-Activator
Bundle-ActivationPolicylazy/Bundle-ActivationPolicy
Embed-Dependency*;scope=compile|runtime;inline=false/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
Include-Resourceplugin.xml,src/main/resources/Include-Resource
Bundle-ClassPath.,{maven-dependencies}/Bundle-ClassPath
Require-Bundleorg.eclipse.core.runtime,org.eclipse.ui,com.foobar.core,com.foobar.core.deployer.rc.config,com.axegroup.rcp.plugins.log4j,org.apache.commons.lang/Require-Bundle
Eclipse-RegisterBuddycom.foobar.core,com.axegroup.rcp.plugins.log4j/Eclipse-RegisterBuddy
/instructions
/configuration
/plugin
!-- Unpack jar dependencies into the target directory so they can
be used by the pde plugin --
plugin
artifactIdmaven-dependency-plugin/artifactId
configuration
excludeTransitivefalse/excludeTransitive
/configuration
executions
execution
idcopy-dependencies/id
goals
goalcopy-dependencies/goal
/goals
configuration
excludeScopeprovided/excludeScope
outputDirectory${basedir}/outputDirectory
overWriteReleasesfalse/overWriteReleases
overWriteSnapshotsfalse/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer
/configuration
/execution
/executions
/plugin
!-- clean up all the dependency jars dumped in the plugin root
directory for the pde plugin --
plugin
artifactIdmaven-clean-plugin/artifactId
configuration
filesets
fileset
directory${basedir}/directory
includes
include*.jar/include
/includes
followSymlinksfalse/followSymlinks
/fileset
/filesets
/configuration
/plugin
!-- configuration for the Eclipse IDE --
plugin
artifactIdmaven-eclipse-plugin/artifactId
configuration
pdetrue/pde
useProjectReferencesfalse/useProjectReferences
classpathContainers
classpathContainerorg.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6/classpathContainer
classpathContainerorg.eclipse.pde.core.requiredPlugins/classpathContainer
/classpathContainers
/configuration
executions
execution
idrun eclipse plugin/id
phaseprepare-package/phase
goals
goalclean/goal
goaleclipse/goal
/goals
/execution
/executions
/plugin
maven-eclipse-plugin: pde support and OSGiManifest writer
Does anyone actually use pde mode in maven-eclipse-plugin? The support looks pretty basic and there are other better options like tycho and felix for doing this stuff. EclipseOSGiManifestWriter has been deprecated in favour of felix and I wonder whether its worth keeping the other stuff around. I realise that not every use of the plugin is going to be on the user list - but it can give a gauge of sentiment. Opinions welcome. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
I essentially have the same problem. I am just getting started with Groovy for this project. Environment: Ubuntu 11.04 Eclipse 3.7 Groovy Eclipse plugin 2.5.1 Maven 2.2.1 Following the instructions in the Groovy Eclipse Plugin page (http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven), I ran the mvn archetype:generate command, and it generated a project for me. Then I did mvn eclipse:eclipse and then imported that project into Eclipse. But the project flags errors in src/test/java/JavaTest because the package is not right. Fixed that. Next src/main/java/JavaMain.java is in error because it cannot find GroovyHello. Sure enough, that is not compiled. So I checked the build path, and like Sebastian found, src/main/groovy does not include groovy files at all...so I added an include of **/*.groovy. That still doesn't fix it, though. None of the groovy files ever get compiled to .class files in the output folder. At this point I don't have a clue how to get Eclipse to build these files. I think I'll come at it from the Eclipse side and create a Groovy project. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-Eclipse-Plugin-doesn-t-include-all-source-paths-in-generated-classpath-file-in-a-Java-Groovy-pt-tp4535545p4583476.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
You probably need to configure your Eclipse project as a Groovy project (through a nature I think). Please not that you can configure the Maven Eclipse plugin to add specific natures when eclipse:eclipse is run. Regards Jeff On Wed, Jul 13, 2011 at 7:26 PM, DaveyBob psyn...@yahoo.com wrote: I essentially have the same problem. I am just getting started with Groovy for this project. Environment: Ubuntu 11.04 Eclipse 3.7 Groovy Eclipse plugin 2.5.1 Maven 2.2.1 Following the instructions in the Groovy Eclipse Plugin page (http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven), I ran the mvn archetype:generate command, and it generated a project for me. Then I did mvn eclipse:eclipse and then imported that project into Eclipse. But the project flags errors in src/test/java/JavaTest because the package is not right. Fixed that. Next src/main/java/JavaMain.java is in error because it cannot find GroovyHello. Sure enough, that is not compiled. So I checked the build path, and like Sebastian found, src/main/groovy does not include groovy files at all...so I added an include of **/*.groovy. That still doesn't fix it, though. None of the groovy files ever get compiled to .class files in the output folder. At this point I don't have a clue how to get Eclipse to build these files. I think I'll come at it from the Eclipse side and create a Groovy project. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-Eclipse-Plugin-doesn-t-include-all-source-paths-in-generated-classpath-file-in-a-Java-Groovy-pt-tp4535545p4583476.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
On Thu, Jul 14, 2011 at 3:09 AM, Jeff MAURY jeffma...@jeffmaury.com wrote: You probably need to configure your Eclipse project as a Groovy project (through a nature I think). Please not that you can configure the Maven Eclipse plugin to add specific natures when eclipse:eclipse is run. Groovy support in maven-eclipse-plugin may not be complete. You are welcome to provide patches with test cases to fix this. And Sebastian, it would be nice to hear how you went. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
On Thu, Jul 14, 2011 at 9:07 AM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Jul 14, 2011 at 3:09 AM, Jeff MAURY jeffma...@jeffmaury.com wrote: You probably need to configure your Eclipse project as a Groovy project (through a nature I think). Please not that you can configure the Maven Eclipse plugin to add specific natures when eclipse:eclipse is run. Groovy support in maven-eclipse-plugin may not be complete. You are welcome to provide patches with test cases to fix this. I can see from the IT pom that there are no Groovy natures installed. But when you run mvn compile it will compile the Groovy files. See http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/groovy/pom.xml Their documentation (http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven) has a bug !-- Optional, include this piece for integration with Eclipse -- plugin artifactId/artifactId configuration additionalProjectnatures projectnatureorg.eclipse.jdt.groovy.core.groovyNature/projectnature /additionalProjectnatures /configuration /plugin ... What's the artifactId? I think it should be maven-eclipse-plugin. And their archetype also needs updating to match their documentation as it does not include this configuration. I've updated the IT pom to include the nature now. But its still a manual job for any groovy users to do this, its not something maven-eclipse-plugin can do automatically for you. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
On Thu, Jun 30, 2011 at 12:45 AM, Sebastian Goldt sd...@cam.ac.uk wrote: Sebastian, its been five days and no feedback. Have you worked out your problem? Has any of this thread been useful? It would be nice from an archive perspective if you could comment on your resolution so others can avoid this problem in the future. Especially if there was something not clear that caused you to make a mistake, that would be a good opportunity to fix up any documentation so others don't have the same problems. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
It's an M2Eclipse problem. I think you should rather user their ML. -- Guillaume Le 29/06/2011 17:15, Sebastian Goldt a écrit : Hi all, today, I run into some problems with the Maven Eclipse Plugin 2.8 using Maven 3.0.3 on an Ubuntu 11.04 while setting up a mixed Java / Groovy project. It seems as if the eclipse plugin doesn't include all source code folders in the generated .project file. I haven't found anything on the internet on that particular issue so far... *Details:* My project in question contains both tests and main source code in java as well as in groovy, so I have the four folders src/main/java, src/main/groovy, src/test/java and src/test/groovy which are added to the project with the Build Helper Maven Plugin (1.6). When I generate the eclipse project files using eclipse:eclipse, the generated .classpath file only contains the src/main/groovy folder and not the src/test/groovy folder. *Reproduction:* The easiest way to reproduce the problem is by using a java/groovy project quickstarter from codehaus: 1. Create a dummy groovy/java project by using typing: mvn archetype:generate -DarchetypeGroupId=org.codehaus.groovy -DarchetypeArtifactId=groovy-eclipse-quickstart -DarchetypeVersion=2.5.1-M3-SNAPSHOT -DgroupId=foo -DartifactId=bar -Dversion=1 -DinteractiveMode=false -DarchetypeRepository= https://nexus.codehaus.org/content/repositories/snapshots/ 2. Create Eclipse project files mvn eclipse:eclipse When inspecting the generated .classpath file, you will notice that the src/test/groovy path is missing. Note that if you wanted to import the project into eclipse, you would have to set up the eclipse plugin in your pom as to include *.groovy classes on your build path and properly organise the files in packages; however, this wouldn't change the actual problem in any way. *Workaround:* Simply import the project into Eclipse and declare the src/test/groovy folder as source folder. Is this a bug or is there another mistake? Regards, Sebastian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
On Thu, Jun 30, 2011 at 4:43 PM, Guillaume Polet guillaume.po...@gmail.com wrote: It's an M2Eclipse problem. I think you should rather user their ML. [del] mvn eclipse:eclipse He's not using m2e. I'm looking into it... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
On Thu, Jun 30, 2011 at 12:45 AM, Sebastian Goldt sd...@cam.ac.uk wrote: [del] My project in question contains both tests and main source code in java as well as in groovy, so I have the four folders src/main/java, src/main/groovy, src/test/java and src/test/groovy which are added to the project with the Build Helper Maven Plugin (1.6). When I generate the eclipse project files using eclipse:eclipse, the generated .classpath file only contains the src/main/groovy folder and not the src/test/groovy folder. *Reproduction:* The easiest way to reproduce the problem is by using a java/groovy project quickstarter from codehaus: 1. Create a dummy groovy/java project by using typing: mvn archetype:generate -DarchetypeGroupId=org.codehaus.groovy -DarchetypeArtifactId=groovy-eclipse-quickstart -DarchetypeVersion=2.5.1-M3-SNAPSHOT -DgroupId=foo -DartifactId=bar -Dversion=1 -DinteractiveMode=false -DarchetypeRepository= https://nexus.codehaus.org/content/repositories/snapshots/ Created an IT for this case to see what happens 2. Create Eclipse project files mvn eclipse:eclipse When inspecting the generated .classpath file, you will notice that the src/test/groovy path is missing. Note that if you wanted to import the project into eclipse, you would have to set up the eclipse plugin in your pom as to include *.groovy classes on your build path and properly organise the files in packages; however, this wouldn't change the actual problem in any way. m-e-p will run anything else bound to lifecycles lifecycle iddefault/id !-- START SNIPPET: eclipse-plugin-lifecycle -- phases generate-sources/ generate-resources/ generate-test-sources/ generate-test-resources/ /phases !-- END SNIPPET: eclipse-plugin-lifecycle -- /lifecycle So it should run build-helper to attach the groovy directories. I can see in the debug logs [DEBUG] testOutput toRelativeAndFixSeparator D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy , D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy\target\test-classes [DEBUG] testOutput after toRelative : target/test-classes [DEBUG] Processing resource dir: D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy\src\main\resources [DEBUG] Resource dir: D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy\src\main\resources either missing or not a directory. [DEBUG] Processing resource dir: D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy\src\test\resources [DEBUG] Resource dir: D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy\src\test\resources either missing or not a directory. [INFO] Not writing settings - defaults suffice [DEBUG] Processing classpath for: source src/test/java: output=target/test-classes, include=[**/*.java], exclude=[], test=true, filtering=false; default output=target/classes [DEBUG] Processing classpath for: source src/main/java: output=null, include=[**/*.java], exclude=[], test=false, filtering=false; default output=target/classes [DEBUG] Processing classpath for: source src/main/groovy: output=null, include=[**/*.java], exclude=[], test=false, filtering=false; default output=target/classes [INFO] Wrote Eclipse project for bar to D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\groovy. So groovy is available in the src directory list. The generated .classpath classpath classpathentry kind=src path=src/test/java output=target/test-classes including=**/*.java/ classpathentry kind=src path=src/main/java including=**/*.java/ classpathentry kind=src path=src/main/groovy including=**/*.java/ classpathentry kind=output path=target/classes/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ classpathentry kind=var path=M2_REPO/org/codehaus/groovy/groovy-all/1.8.0/groovy-all-1.8.0.jar/ classpathentry kind=var path=M2_REPO/junit/junit/4.8.2/junit-4.8.2.jar/ /classpath This is using the latest released m-eclipse-p of 2.8. Try running mvn -X eclipse:eclipse This will print out the debug statements. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
On Thu, Jun 30, 2011 at 09:13, Guillaume Polet guillaume.po...@gmail.comwrote: It's an M2Eclipse problem. I think you should rather user their ML. No, he's using the maven-eclipse-plugin. Not m2eclipse. /Anders -- Guillaume Le 29/06/2011 17:15, Sebastian Goldt a écrit : Hi all, today, I run into some problems with the Maven Eclipse Plugin 2.8 using Maven 3.0.3 on an Ubuntu 11.04 while setting up a mixed Java / Groovy project. It seems as if the eclipse plugin doesn't include all source code folders in the generated .project file. I haven't found anything on the internet on that particular issue so far... *Details:* My project in question contains both tests and main source code in java as well as in groovy, so I have the four folders src/main/java, src/main/groovy, src/test/java and src/test/groovy which are added to the project with the Build Helper Maven Plugin (1.6). When I generate the eclipse project files using eclipse:eclipse, the generated .classpath file only contains the src/main/groovy folder and not the src/test/groovy folder. *Reproduction:* The easiest way to reproduce the problem is by using a java/groovy project quickstarter from codehaus: 1. Create a dummy groovy/java project by using typing: mvn archetype:generate -DarchetypeGroupId=org.**codehaus.groovy -DarchetypeArtifactId=groovy-**eclipse-quickstart -DarchetypeVersion=2.5.1-M3-**SNAPSHOT -DgroupId=foo -DartifactId=bar -Dversion=1 -DinteractiveMode=false -DarchetypeRepository= https://nexus.codehaus.org/**content/repositories/**snapshots/https://nexus.codehaus.org/content/repositories/snapshots/ 2. Create Eclipse project files mvn eclipse:eclipse When inspecting the generated .classpath file, you will notice that the src/test/groovy path is missing. Note that if you wanted to import the project into eclipse, you would have to set up the eclipse plugin in your pom as to include *.groovy classes on your build path and properly organise the files in packages; however, this wouldn't change the actual problem in any way. *Workaround:* Simply import the project into Eclipse and declare the src/test/groovy folder as source folder. Is this a bug or is there another mistake? Regards, Sebastian --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Eclipse Plugin doesn't include all source paths in generated .classpath file in a Java / Groovy project
Hi all, today, I run into some problems with the Maven Eclipse Plugin 2.8 using Maven 3.0.3 on an Ubuntu 11.04 while setting up a mixed Java / Groovy project. It seems as if the eclipse plugin doesn't include all source code folders in the generated .project file. I haven't found anything on the internet on that particular issue so far... *Details:* My project in question contains both tests and main source code in java as well as in groovy, so I have the four folders src/main/java, src/main/groovy, src/test/java and src/test/groovy which are added to the project with the Build Helper Maven Plugin (1.6). When I generate the eclipse project files using eclipse:eclipse, the generated .classpath file only contains the src/main/groovy folder and not the src/test/groovy folder. *Reproduction:* The easiest way to reproduce the problem is by using a java/groovy project quickstarter from codehaus: 1. Create a dummy groovy/java project by using typing: mvn archetype:generate -DarchetypeGroupId=org.codehaus.groovy -DarchetypeArtifactId=groovy-eclipse-quickstart -DarchetypeVersion=2.5.1-M3-SNAPSHOT -DgroupId=foo -DartifactId=bar -Dversion=1 -DinteractiveMode=false -DarchetypeRepository= https://nexus.codehaus.org/content/repositories/snapshots/ 2. Create Eclipse project files mvn eclipse:eclipse When inspecting the generated .classpath file, you will notice that the src/test/groovy path is missing. Note that if you wanted to import the project into eclipse, you would have to set up the eclipse plugin in your pom as to include *.groovy classes on your build path and properly organise the files in packages; however, this wouldn't change the actual problem in any way. *Workaround:* Simply import the project into Eclipse and declare the src/test/groovy folder as source folder. Is this a bug or is there another mistake? Regards, Sebastian
maven eclipse plugin
Hi all, I am trying to set up code styles, work space and so on, but it doesn't work. Does anybody know if maven plug in eclipse is working for these kind of set up? I am using eclipse helios thanks in advance
Re: maven eclipse plugin
On 18/04/2011 10:18 AM, Fernando Wermus wrote: Hi all, I am trying to set up code styles, work space and so on, but it doesn't work. Does anybody know if maven plug in eclipse is working for these kind of set up? I am using eclipse helios thanks in advance You might want to move to the STS version of Eclipse. All the required Java development plug-ins are preloaded and the Maven integration works very well since M2 is built-in. We have used it for almost 2 years and is much easier to get started with STS than an out-of-the-box Eclipse since you just install and go (still need to add Subversion for licensing reasons but it is made easy) Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven eclipse plugin
On Mon, Apr 18, 2011 at 11:48 PM, Fernando Wermus fwer...@odeasrl.com.ar wrote: Hi all, I am trying to set up code styles, work space and so on, but it doesn't work. Does anybody know if maven plug in eclipse is working for these kind of set up? I am using eclipse helios If you are talking about m2e, this isn't the correct mailing list. If you are talking about maven-eclipse-plugin then: * Coding Styles: http://maven.apache.org/plugins/maven-eclipse-plugin/examples/load-code-styles.html * Checkstyle: http://maven.apache.org/plugins/maven-eclipse-plugin/examples/configure-checkstyle.html I put all this guff into your parent project's pom in build/pluginManagement so you dont have to specify it per project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Eclipse Plugin - how to remove M2_REPO classpath variable
Does anyone know a way to remove the M2_REPO classpath variable that was added using mvn -Declipse.workspace=pathtoworkspace eclipse:configure-workspace? (I'm created another workspace and would like to clean up the first workspace.) I've tried running mvn eclipse:clean before re-running eclipse:configure-workspace again but that doesn't do it. Also, M2_REPO is marked (non modifiable), so I'm unable to remove it manually using menu Window Preferences Java Build Path Classpath Variables. Searched past 12 month archives but didn't see anything on this topic... Thank you -CL
Re: Maven Eclipse Plugin - how to remove M2_REPO classpath variable
Does anyone know a way to remove the M2_REPO classpath variable that was added using mvn -Declipse.workspace=pathtoworkspace eclipse:configure-workspace? I don't know how (or even if) you can do this with the Eclipse plugin, but nothing is stopping you from doing it manually by editing the dot files (.classpath, .project, etc) in your project directory with Notepad or another editor. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven Eclipse Plugin - how to remove M2_REPO classpath variable
I don’t know how to remove it. But in eclipse you can go to preferences - maven - user settings and “reindex” the location. Perhaps that helps depending on what the problem is. /Ludwig From: Wayne Fay [mailto:wayne...@gmail.com] Sent: den 5 februari 2011 16:25 To: Maven Users List Subject: Re: Maven Eclipse Plugin - how to remove M2_REPO classpath variable Does anyone know a way to remove the M2_REPO classpath variable that was added using mvn -Declipse.workspace=pathtoworkspace eclipse:configure-workspace? I don't know how (or even if) you can do this with the Eclipse plugin, but nothing is stopping you from doing it manually by editing the dot files (.classpath, .project, etc) in your project directory with Notepad or another editor. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3423 - Release Date: 02/04/11
Re: Missing goal eclipse:m2eclipse in version 2.8 of the Maven Eclipse plugin
On 18 December 2010 05:08, Barrie Treloar baerr...@gmail.com wrote: On Thu, Dec 16, 2010 at 9:39 PM, Stefan Eder stefan.e...@ebuconnect.de wrote: Hi, since quite a while I am using Maven and Eclipse together with the Eclipse plugin for Maven and the Maven plugin for Eclipse. And it is just great. But in the version 2.8 of the Eclipse plugin for Maven I am (hardly) missing the goal m2eclipse. How can I tell the version 2.8 of the Eclipse plugin to create .classpath files that refer to MAVEN2_CLASSPATH_CONTAINER and to add Maven nature and build command to the .project files without touching the corresponding poms? You don't, you use m2eclipse directly. If you are using m2eclipse, you *CAN NOT* use maven-eclipse-plugin, hence it being removed in 2.8 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Just wondering why support for $ mvn eclipse:m2eclipse was dropped from the maven-eclipse-plugin in version 2.8? I don't understand why maven-eclipse-plugin and using m2eclipse are incompatible. What command line should I now be using instead? Or should I just stick with version 2.7? As I don't want to store the eclipse project in source control, or have to manually create the eclipse project. I just want a simple command line to automatically create the project file so I can them just import them, or re-execute and refresh the project. John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Missing goal eclipse:m2eclipse in version 2.8 of the Maven Eclipse plugin
On Mon, Jan 17, 2011 at 6:22 AM, John Patrick nhoj.patr...@gmail.com wrote: On 18 December 2010 05:08, Barrie Treloar baerr...@gmail.com wrote: On Thu, Dec 16, 2010 at 9:39 PM, Stefan Eder stefan.e...@ebuconnect.de wrote: Hi, since quite a while I am using Maven and Eclipse together with the Eclipse plugin for Maven and the Maven plugin for Eclipse. And it is just great. But in the version 2.8 of the Eclipse plugin for Maven I am (hardly) missing the goal m2eclipse. How can I tell the version 2.8 of the Eclipse plugin to create .classpath files that refer to MAVEN2_CLASSPATH_CONTAINER and to add Maven nature and build command to the .project files without touching the corresponding poms? You don't, you use m2eclipse directly. If you are using m2eclipse, you *CAN NOT* use maven-eclipse-plugin, hence it being removed in 2.8 [del] Just wondering why support for $ mvn eclipse:m2eclipse was dropped from the maven-eclipse-plugin in version 2.8? I don't understand why maven-eclipse-plugin and using m2eclipse are incompatible. m2eclipse is an Eclipse plugin that embed Maven. eclipse:eclipse is a Maven plugin that generates eclipse's files so you can import your Maven projects. Choose one and use it. They are maintained by two different groups and trying to import each others details is too error prone. What command line should I now be using instead? Or should I just stick with version 2.7? If you are using m2eclipse, then there is no need for command line. As I don't want to store the eclipse project in source control, or have to manually create the eclipse project. I just want a simple command line to automatically create the project file so I can them just import them, or re-execute and refresh the project. Neither m2eclipse or eclipse:eclipse require your to place eclipse project files in source control. m2eclipse will auto-generate the files for you. Since I dont use m2eclipse, I can't tell you how. You will need to read the documentation. It's meant to be simple. Probably something like Import... m2eclipse maven project... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Missing goal eclipse:m2eclipse in version 2.8 of the Maven Eclipse plugin
On Thu, Dec 16, 2010 at 9:39 PM, Stefan Eder stefan.e...@ebuconnect.de wrote: Hi, since quite a while I am using Maven and Eclipse together with the Eclipse plugin for Maven and the Maven plugin for Eclipse. And it is just great. But in the version 2.8 of the Eclipse plugin for Maven I am (hardly) missing the goal m2eclipse. How can I tell the version 2.8 of the Eclipse plugin to create .classpath files that refer to MAVEN2_CLASSPATH_CONTAINER and to add Maven nature and build command to the .project files without touching the corresponding poms? You don't, you use m2eclipse directly. If you are using m2eclipse, you *CAN NOT* use maven-eclipse-plugin, hence it being removed in 2.8 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Missing goal eclipse:m2eclipse in version 2.8 of the Maven Eclipse plugin
Hi, since quite a while I am using Maven and Eclipse together with the Eclipse plugin for Maven and the Maven plugin for Eclipse. And it is just great. But in the version 2.8 of the Eclipse plugin for Maven I am (hardly) missing the goal m2eclipse. How can I tell the version 2.8 of the Eclipse plugin to create .classpath files that refer to MAVEN2_CLASSPATH_CONTAINER and to add Maven nature and build command to the .project files without touching the corresponding poms? Thanks, Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Missing goal eclipse:m2eclipse in version 2.8 of the Maven Eclipse plugin
You can't (in 2.8) - you can specify the old version of the plugin with the m2eclipse goal on the command line. Or (preffered) just import the projects in eclipse as maven projects, and let m2eclipse create your project files with the correct natures. /James -Original Message- From: Stefan Eder [mailto:stefan.e...@ebuconnect.de] Sent: 16 December 2010 11:09 To: users@maven.apache.org Subject: Missing goal eclipse:m2eclipse in version 2.8 of the Maven Eclipse plugin Hi, since quite a while I am using Maven and Eclipse together with the Eclipse plugin for Maven and the Maven plugin for Eclipse. And it is just great. But in the version 2.8 of the Eclipse plugin for Maven I am (hardly) missing the goal m2eclipse. How can I tell the version 2.8 of the Eclipse plugin to create .classpath files that refer to MAVEN2_CLASSPATH_CONTAINER and to add Maven nature and build command to the .project files without touching the corresponding poms? Thanks, Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **
Re: maven-eclipse-plugin
On Mon, Dec 6, 2010 at 10:39 AM, Brian Topping topp...@codehaus.org wrote: On a related note, can anyone summarize what the best way of maintaining eclipse projects from Maven is? I use IDEA, and the best way from there is IDEA itself, not with the IDEA plugin for Maven. Is the same true for Eclipse that the IDE plugin for Maven is better than the Maven plugin for the IDE? If so, what is the best plugin for Eclipse (there seems to be more than one). You won't get any consensus here. I've tried M2Eclipse (a number of times) and it hasn't worked well enough for me, so I have stuck with m-eclipse-p. But there are plenty of people who are happy with M2Eclipse. Or as Ron points out, you can give Eclipse/STS a go. (Just remember to read the TCs) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-eclipse-plugin
Hi all, Does anybody know in which version the support for wtp 2.x was added? And when will support for wtp 3.x be added? Thanks! -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin
On Mon, Dec 6, 2010 at 12:51 AM, Asmann, Roland roland.asm...@adesso.at wrote: Hi all, Does anybody know in which version the support for wtp 2.x was added? Not really, you'd have to trawl through the code base to see for sure. http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html lists the versions available And when will support for wtp 3.x be added? There is no active development for adding wtp 3.x support. Feel free to create a jira, integration tests and patches. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin
On a related note, can anyone summarize what the best way of maintaining eclipse projects from Maven is? I use IDEA, and the best way from there is IDEA itself, not with the IDEA plugin for Maven. Is the same true for Eclipse that the IDE plugin for Maven is better than the Maven plugin for the IDE? If so, what is the best plugin for Eclipse (there seems to be more than one). Thanks, Brian On Dec 5, 2010, at 6:41 PM, Barrie Treloar wrote: On Mon, Dec 6, 2010 at 12:51 AM, Asmann, Roland roland.asm...@adesso.at wrote: Hi all, Does anybody know in which version the support for wtp 2.x was added? Not really, you'd have to trawl through the code base to see for sure. http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html lists the versions available And when will support for wtp 3.x be added? There is no active development for adding wtp 3.x support. Feel free to create a jira, integration tests and patches. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin
On 05/12/2010 7:09 PM, Brian Topping wrote: On a related note, can anyone summarize what the best way of maintaining eclipse projects from Maven is? I use IDEA, and the best way from there is IDEA itself, not with the IDEA plugin for Maven. Is the same true for Eclipse that the IDE plugin for Maven is better than the Maven plugin for the IDE? If so, what is the best plugin for Eclipse (there seems to be more than one). The Eclipse/STS from Springsource is the easiest way to get Eclipse integrated with Maven. Thanks, Brian On Dec 5, 2010, at 6:41 PM, Barrie Treloar wrote: On Mon, Dec 6, 2010 at 12:51 AM, Asmann, Rolandroland.asm...@adesso.at wrote: Hi all, Does anybody know in which version the support for wtp 2.x was added? Not really, you'd have to trawl through the code base to see for sure. http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html lists the versions available And when will support for wtp 3.x be added? There is no active development for adding wtp 3.x support. Feel free to create a jira, integration tests and patches. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
adding java sources to classpath with maven-eclipse-plugin
(Please CC me on replies, I am not subscribed to this list) Hi there, I have a GWT project which programatically starts a DevMode shell. The problem I have is that GWT needs access to the Java source code in the classpath at runtime. I have tried adding my src/main/java directory to the resources list (in the following snippet), but this doesn't seem to have the desired effect. build resources resource directorysrc/main/java/directory /resource /resources ... /build Basically the following code should not throw an exception when run as an Eclipse JUnit test. classLoader.getResource(com/mycompany/mypackage/client/MainPage.java) The test passes when running mvn test, but when running it inside an Eclipse project generated with mvn eclipse:eclipse, it fails (resource not found). As a workaround I just add the src/main/java directory to the runtime classpath and then GWT is happy and I'm happy. :) $ mvn -version Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000) Java version: 1.6.0_22 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.5.8 arch: x86_64 Family: mac Using org.apache.maven.plugins:maven-eclipse-plugin:2.7. Thanks for your help! Regards, James - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: adding java sources to classpath with maven-eclipse-plugin
James Ring wrote: (Please CC me on replies, I am not subscribed to this list) Hi there, I have a GWT project which programatically starts a DevMode shell. The problem I have is that GWT needs access to the Java source code in the classpath at runtime. I have tried adding my src/main/java directory to the resources list (in the following snippet), but this doesn't seem to have the desired effect. Why not use the sources plugin to generate an attached -sources jar with the sources? You can thewn add this artifact as additional dependency in places where you need it. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: adding java sources to classpath with maven-eclipse-plugin
add an include pattern. Default maven filters out java files. Martijn On Sun, Nov 7, 2010 at 11:26 AM, James Ring s...@jdns.org wrote: (Please CC me on replies, I am not subscribed to this list) Hi there, I have a GWT project which programatically starts a DevMode shell. The problem I have is that GWT needs access to the Java source code in the classpath at runtime. I have tried adding my src/main/java directory to the resources list (in the following snippet), but this doesn't seem to have the desired effect. build resources resource directorysrc/main/java/directory /resource /resources ... /build Basically the following code should not throw an exception when run as an Eclipse JUnit test. classLoader.getResource(com/mycompany/mypackage/client/MainPage.java) The test passes when running mvn test, but when running it inside an Eclipse project generated with mvn eclipse:eclipse, it fails (resource not found). As a workaround I just add the src/main/java directory to the runtime classpath and then GWT is happy and I'm happy. :) $ mvn -version Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000) Java version: 1.6.0_22 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.5.8 arch: x86_64 Family: mac Using org.apache.maven.plugins:maven-eclipse-plugin:2.7. Thanks for your help! Regards, James - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
john.vint wrote: This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. Lets assume a person is working on two different version (two releases being developed in parallel). They will both have the same artifact ID but eclipse forces a different project name. I don't think asking m-e-p to offer this functionality is really an isnane request. An alternative: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse- mojo.html#projectNameTemplate - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
On Sat, Oct 30, 2010 at 2:34 AM, john.vint johnvin...@gmail.com wrote:
This is not m-e-p's problem. Stop renaming your projects if you want
to use m-e-p and use it to regenerate the .project files. Keep the
name as the artifactId, or change the artifactId in the pom to meet
your needs.
Lets assume a person is working on two different version (two releases being
developed in parallel). They will both have the same artifact ID but
eclipse forces a different project name. I don't think asking m-e-p to
offer this functionality is really an isnane request.
The eclipse:eclipse plugin has worked perfectly fine as I have used it minus
this one issue. The resolution was extremely easy.
Including a new configuration parameter the method createEclipseWriterConfig
just needs
if(evaluateArtifactsFromEclipseWorkspace){
projectName = projectBaseDir.getName();
}
Problem solved.
Sure, the other way to solve it is to have two workspaces, one for
each release you are working on.
And this doesn't require changes to the code.
The other benefit is that if you are using Ctrl+Shift+T to find
classes you only get the release you are working on.
I've tried using the one workspace with multiple releases and it drove me nuts.
(Your sanity may vary)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
This is not m-e-p's problem. Stop renaming your projects if you want
to use m-e-p and use it to regenerate the .project files. Keep the
name as the artifactId, or change the artifactId in the pom to meet
your needs.
Lets assume a person is working on two different version (two releases being
developed in parallel). They will both have the same artifact ID but
eclipse forces a different project name. I don't think asking m-e-p to
offer this functionality is really an isnane request.
The eclipse:eclipse plugin has worked perfectly fine as I have used it minus
this one issue. The resolution was extremely easy.
Including a new configuration parameter the method createEclipseWriterConfig
just needs
if(evaluateArtifactsFromEclipseWorkspace){
projectName = projectBaseDir.getName();
}
Problem solved.
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-eclipse-plugin-Does-not-resolve-workspace-project-name-tp3237890p3242262.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Fay wayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
On 28/10/2010 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. I guess that you could take a copy and continue to maintain it. If you want to build a team to maintain it and share it, then you probably want to get the Maven group to cooperate. If you are the only user/developer, you are off to the races. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Ron Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Faywayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
On Thu, Oct 28, 2010 at 2:54 PM, Ron Wheeler rwhee...@artifact-software.com wrote: It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. maven-eclipse-plugin works roughly 100% of the time here, but the m2eclipse plugin fails miserably with our maven project setup. And yes we tried the latest version. It always results in having to download and install vanilla eclipse. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. Meh. sounds like having a commercial stake in the project. I happen to like commandline mvn eclipse:eclipse without having to bloat my eclipse installation with unnecessary plugins—eclipse has trouble enough keeping up with the size of our projects. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Why is it older? Because you don't like command line tools? Happening to like command line tools make someone a dinosaur? Is the maven-eclipse-plugin old because it is not given any resources by sonatype which happens to maintain the m2eclipse plugin? Why bother with building a release for maven at all? Doesn't m2eclipse supplant that too? Martijn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
Ron, m-e-p works better than M2ECLIPSE in many cases. Further, you have no proof here that I can see that the m-e-p is dead. To quote the plugin site: Last Published: 2010-02-25 | Version: 2.8 If someone posts a patch, I don't think there/s much evidence that it will be ignored. --benson On Thu, Oct 28, 2010 at 8:54 AM, Ron Wheeder rwhee...@artifact-software.com wrote: On 28/10/2010 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. I guess that you could take a copy and continue to maintain it. If you want to build a team to maintain it and share it, then you probably want to get the Maven group to cooperate. If you are the only user/developer, you are off to the races. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Ron Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Faywayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
We're not stopping you from taking it. Put it in Github and hack away. On Oct 28, 2010, at 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Fay wayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: maven-eclipse-plugin Does not resolve workspace project name
Wrong person. I was not the person claiming that patches were not being deployed. Ron On 28/10/2010 9:36 AM, Benson Margulies wrote: Ron, m-e-p works better than M2ECLIPSE in many cases. Further, you have no proof here that I can see that the m-e-p is dead. To quote the plugin site: Last Published: 2010-02-25 | Version: 2.8 If someone posts a patch, I don't think there/s much evidence that it will be ignored. --benson On Thu, Oct 28, 2010 at 8:54 AM, Ron Wheeder rwhee...@artifact-software.com wrote: On 28/10/2010 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. I guess that you could take a copy and continue to maintain it. If you want to build a team to maintain it and share it, then you probably want to get the Maven group to cooperate. If you are the only user/developer, you are off to the races. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Ron Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Faywayne...@gmail.comwrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectNameto override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
m-e-p works better than M2ECLIPSE in many cases. Further, you have no proof here that I can see that the m-e-p is dead. To quote the plugin I am the one who said for all intents, m-e-p is dead based entirely on JIRA activity and releases, as well as the existence of newer (and largely perceived as superior) tooling that is now available if you are using Maven and Eclipse. If someone posts a patch, I don't think there/s much evidence that it will be ignored. I'm also the one who said to go ahead and hack it to add this functionality and submit a patch. You may also end up supporting your own internal release of this plugin indefinitely, so realize that right up front. So how does one get ownership of the plugin? I've contributed 2 This is open source so no one is stopping you from creating a fork. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
2010/10/28 Wayne Fay wayne...@gmail.com: So how does one get ownership of the plugin? I've contributed 2 This is open source so no one is stopping you from creating a fork. Sorry to jump in but, in the Apache Committers' FAQ I read: http://www.apache.org/dev/committers.html#committer-responsibilities snip Applying patches In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into ASF repositories. /snip If you don't want to apply patches to m.e.p, please deprecate it, move it to archive, and abandon it *explicitly*. Or, if you don't want it, you have the responsibility *at least* to discuss them. Otherwise, contributors and committers are simply wasting time. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
I agree, there are many plugins that Maven developers just don't look after and they should be ejected and taken out of the org.maven.plugins name space. Anything there people assume are maintained which simply is not the case. On Oct 28, 2010, at 10:58 AM, Antonio Petrelli wrote: 2010/10/28 Wayne Fay wayne...@gmail.com: So how does one get ownership of the plugin? I've contributed 2 This is open source so no one is stopping you from creating a fork. Sorry to jump in but, in the Apache Committers' FAQ I read: http://www.apache.org/dev/committers.html#committer-responsibilities snip Applying patches In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into ASF repositories. /snip If you don't want to apply patches to m.e.p, please deprecate it, move it to archive, and abandon it *explicitly*. Or, if you don't want it, you have the responsibility *at least* to discuss them. Otherwise, contributors and committers are simply wasting time. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: maven-eclipse-plugin Does not resolve workspace project name
On 28/10/2010 9:35 AM, Martijn Dashorst wrote: On Thu, Oct 28, 2010 at 2:54 PM, Ron Wheeler rwhee...@artifact-software.com wrote: It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. maven-eclipse-plugin works roughly 100% of the time here, but the m2eclipse plugin fails miserably with our maven project setup. And yes we tried the latest version. It always results in having to download and install vanilla eclipse. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. Meh. sounds like having a commercial stake in the project. I happen to like commandline mvn eclipse:eclipse without having to bloat my eclipse installation with unnecessary plugins—eclipse has trouble enough keeping up with the size of our projects. No commercial interest. It is free and I love getting everything I need installed in one download. Just add Hibernate plug-in and I am set to go. We used vanilla Eclipse for a few years but every time we installed a new version we lost a day. Now we are done in1/2 an hour or less. I will not say that it is a small download or does not include stuff that I do not use. I love the Maven tools. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Why is it older? Because you don't like command line tools? Happening to like command line tools make someone a dinosaur? I am too old to be enamoured with command line tools. I first started editing with Teco (after abandoning punched cards in the 60s). I can still get around in vi. I like editing XML by hand but prefer to use the POM GUI editor. I like pointing and clicking and checking off some buttons to get Maven to do what I want. I guess that I regard liking command line tools as eccentric at most. I am old enough to be careful with the word dinosaur in a forum that caters to a younger high-tech crowd. :-) Is the maven-eclipse-plugin old because it is not given any resources by sonatype which happens to maintain the m2eclipse plugin? Why bother with building a release for maven at all? Doesn't m2eclipse supplant that too? Martijn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
Yup, it's in ASF svn, and if the project isn't willing to own it, they should attic it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
On 27/10/2010 1:28 PM, Wayne Fay wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Or just move to Eclipse/STS(free) and get everything, all included. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-eclipse-plugin Does not resolve workspace project name
When running the eclipse goal, the project name that gets set in the project description may not be the project you will initially save it as. For example, I create a project with some name. I configure a pom to have a different artifactId, groupId that do not relate to the project name I originally configured it with. When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Now lets say we have a new project that depends on the project we just created. We run the eclipse goal on the new project, and with useProjectReferences enabled, the classpath references the name of the project based on the artifactID. This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? -- View this message in context: http://maven.40175.n5.nabble.com/maven-eclipse-plugin-Does-not-resolve-workspace-project-name-tp3237890p3237890.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-eclipse-plugin install-plugin simple example not working?
Dear All:
I am on Ubuntu 10.04 amd64 with a fresh Helios install.
I do:
rm -rf ~/.m2/repository/org/eclipse/ mvn eclipse:to-maven
plug-ins successfully installed into local repository.
Then I have a very simple pom.xml
http://maven.40175.n5.nabble.com/file/n2843283/pom.xml pom.xml
that is basically from:
http://docs.codehaus.org/display/MAVENUSER/Eclipse+Plugin
I do a mvn clean install:
mi...@misha-d630:~/tmp$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] Building Collaboratory Client Container
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] artifact org.eclipse:osgi: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from
central
[INFO] artifact org.eclipse.core:jobs: checking for updates from central
[INFO] artifact org.eclipse.equinox:registry: checking for updates from
central
[INFO] artifact org.eclipse.equinox:preferences: checking for updates from
central
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Couldn't find a version in [3.2.1-R32x_v20060717, 3.2.100-v20070522,
3.3.0-v20100503] to match range [3.3.0,4.0.0)
org.eclipse.equinox:preferences:jar:null
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Path to dependency:
1) nl.collaboratory.client:client-plugin-container:pom:1.0-SNAPSHOT
2) org.eclipse.core:runtime:jar:3.6.0-v20100505
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Thu Sep 16 22:29:43 CDT 2010
[INFO] Final Memory: 13M/490M
[INFO]
mi...@misha-d630:~/tmp$
This line:
Couldn't find a version in [3.2.1-R32x_v20060717, 3.2.100-v20070522,
3.3.0-v20100503] to match range [3.3.0,4.0.0)
seems like a bug in maven-eclipse-plugin? Clearly 3.3.0-v20100503] does in
fact match range [3.3.0,4.0.0)...
Any ideas/hints?
Thank you
Misha Koshelev
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-eclipse-plugin-install-plugin-simple-example-not-working-tp2843283p2843283.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
maven-eclipse-plugin Own settings and .project-properties
Hello everybody, i'd like to achieve the following: - Importing a maven project into eclipse via m2eclipse - Write my own settings files to hide target, .project etc. from eclipse navigator and mylyn task context (Properties-Resource-Resource Filter) - Install eclipse-plugins if thats possible I read the instructions on http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html but they didn't quite work for me in a maven multi-module project. Are there any useful links or working examples for such a setup out there? Thank you all in advance! Moritz - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin and POM packaging projects
M2Eclipse does some things fine but not all. Use case: pom A define a resource folder I have in eclipse, imported with M2E, project A and B, the latter inherit from A. Change the resource folder in A from eclipse, save. Nothing change in eclipse. So while changing a dep in the pom make the builder run, changing resourcer requires maven-eclipse-plugin. Or maybe I am making something wrong. On Wed, Jun 16, 2010 at 9:18 PM, Wayne Fay wayne...@gmail.com wrote: Actually, m-e-p does not create any .project while M2Eclipse import both of them... and the multi-module is useless and I will just delete it. IMO you are better off just switching over to m2eclipse full time instead of continuing to fight with m-e-p. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Daniele Dellafiore http://danieledellafiore.net
Re: maven-eclipse-plugin and POM packaging projects
you can right click on one of the project root folders, select the maven item and one of the sub-menu items will do what you want -S On 17 June 2010 12:28, Daniele Dellafiore ilde...@gmail.com wrote: M2Eclipse does some things fine but not all. Use case: pom A define a resource folder I have in eclipse, imported with M2E, project A and B, the latter inherit from A. Change the resource folder in A from eclipse, save. Nothing change in eclipse. So while changing a dep in the pom make the builder run, changing resourcer requires maven-eclipse-plugin. Or maybe I am making something wrong. On Wed, Jun 16, 2010 at 9:18 PM, Wayne Fay wayne...@gmail.com wrote: Actually, m-e-p does not create any .project while M2Eclipse import both of them... and the multi-module is useless and I will just delete it. IMO you are better off just switching over to m2eclipse full time instead of continuing to fight with m-e-p. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Daniele Dellafiore http://danieledellafiore.net
Re: maven-eclipse-plugin and POM packaging projects
On Tue, Jun 15, 2010 at 12:04 PM, Daniele Dellafiore ilde...@gmail.com wrote: I have patched maven-eclipse-plugin to create an eclipse project also for projects with pom packaging type. I was wondering if this was a bug or a feature and if someone is interested in the plugin behaving this way other than me. I am glad the pom packaging projects don't generate .project files anymore. It was a drag with importing multimodule projects in eclipse. Far more easy to get all non-pom projects in one go, and just add the three pom type projects. My €0.02 (which isn't that much worth nowadays) Martijn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin and POM packaging projects
Mixed feeling for me. MultiModule pom project aren't to be imported as a project, I do agree. But parent kind of pom project, I would like to see them imported. Problem is that there is no way in maven to make a distinction. Actually, m-e-p does not create any .project while M2Eclipse import both of them... and the multi-module is useless and I will just delete it. On Wed, Jun 16, 2010 at 5:14 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Tue, Jun 15, 2010 at 12:04 PM, Daniele Dellafiore ilde...@gmail.com wrote: I have patched maven-eclipse-plugin to create an eclipse project also for projects with pom packaging type. I was wondering if this was a bug or a feature and if someone is interested in the plugin behaving this way other than me. I am glad the pom packaging projects don't generate .project files anymore. It was a drag with importing multimodule projects in eclipse. Far more easy to get all non-pom projects in one go, and just add the three pom type projects. My €0.02 (which isn't that much worth nowadays) Martijn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Daniele Dellafiore http://danieledellafiore.net
Re: maven-eclipse-plugin and POM packaging projects
Actually, m-e-p does not create any .project while M2Eclipse import both of them... and the multi-module is useless and I will just delete it. IMO you are better off just switching over to m2eclipse full time instead of continuing to fight with m-e-p. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-eclipse-plugin and POM packaging projects
Hi everyone. I have patched maven-eclipse-plugin to create an eclipse project also for projects with pom packaging type. I was wondering if this was a bug or a feature and if someone is interested in the plugin behaving this way other than me. In case, I can work on it and submit a patch. I would also like to share with you my thoughts about the pom packaging: basically I think that pom is misleading, because you can make multi-module and use it for inheritance and developers are confused. I think that a best practice is to avoid that a multi-module is also inherited by others and that having different keywords for packaging type should be better. Something like multi-module and abstract. What do you think? -- Daniele Dellafiore http://danieledellafiore.net
Re: [maven-eclipse-plugin] Spring dependencies omitted
On Thu, Mar 11, 2010 at 6:39 PM, Pascal Kesseli pascal_kess...@hotmail.comwrote: Hi everyone Being a typical maven fan, I tried to manage our eclipse plugins using maven. To do so, I configured the maven-eclipse-plugin as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.8/version configuration pdetrue/pde manifestMETA-INF/MANIFEST.MF/manifest spring version2.5.6/version file-patternspring.cfg.xml/file-pattern basedirsrc/main/resources/basedir /spring /configuration /plugin First off, I am not even sure what exactly the spring-tag in here is good for? What does the plugin do with that information? Secondly, as described on the apache website, the plugin is supposed to copy all the dependencies as jars to my project root. While that works well with almost any dependency, the plugin constantly ignores any Spring dependency I have added to my project, such as spring-aspects, spring-core or spring-test. Does anybody know where that behavior evolves from? I'm not sure that the pde mode does what you think it does. See http://maven.apache.org/plugins/maven-eclipse-plugin/pde.html Note that the scope of the *maven-eclipse-plugin* is to synchronise the Eclipse *.project* and *.classpath* files with the configuration found in the pom file. Once you have finished configuring the Eclipse plugin as below, and once you have run the *eclipse:eclipse* goal, you will be in a position to build your plugin code with the Eclipse IDE, or the Eclipse headless PDE buildhttp://www.eclipse.org/articles/Article-PDE-Automation/automation.html. The Eclipse headless PDE build can be triggered from within Maven using the pde-maven-plugin http://mojo.codehaus.org/pde-maven-plugin/ To get maven to build PDE projects I have used (3 years ago) the plugin (now unmaintained) http://mojo.codehaus.org/pde-maven-plugin/ You may also be able to use Tycho http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview I also cant see any documentation about using the configuration section as you have done - which tends to indicate its not supported.
[maven-eclipse-plugin] Spring dependencies omitted
Hi everyone Being a typical maven fan, I tried to manage our eclipse plugins using maven. To do so, I configured the maven-eclipse-plugin as follows: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.8/version configuration pdetrue/pde manifestMETA-INF/MANIFEST.MF/manifest spring version2.5.6/version file-patternspring.cfg.xml/file-pattern basedirsrc/main/resources/basedir /spring /configuration /plugin First off, I am not even sure what exactly the spring-tag in here is good for? What does the plugin do with that information? Secondly, as described on the apache website, the plugin is supposed to copy all the dependencies as jars to my project root. While that works well with almost any dependency, the plugin constantly ignores any Spring dependency I have added to my project, such as spring-aspects, spring-core or spring-test. Does anybody know where that behavior evolves from? Thanks in advance for any help on this issue and best regards Pascal Kesseli - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[maven-eclipse-plugin] Resources are copied to root?
Hi everyone Using the following build spec in my pom.xml build defaultGoalcompile/defaultGoal sourceDirectorysrc/main/java/sourceDirectory outputDirectorytarget/main/outputDirectory resources resource directorysrc/main/resources/directory targetPathch/hsr/ifs/flexclipse/resources/targetPath /resource /resources ... /build my resources are copied to target/main instead to target/main/ch/hsr/ifs/flexclipse/resources when using the configuration generated by the maven-eclipse-plugin in pde mode, using the following config: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId version2.8/version configuration pdetrue/pde manifestMETA-INF/MANIFEST.MF/manifest spring version2.5.6/version file-patternspring.cfg.xml/file-pattern basedirsrc/main/resources/basedir /spring /configuration /plugin Did I miss something here or how can I get the maven-eclipse-plugin to create a project that copies my resources to the desired resources directory? Thanks in advance for any suggestions and best regards Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Windows versus maven-eclipse-plugin versus file: url
Oh, duh. Thanks. On Mon, Mar 1, 2010 at 7:16 PM, Barrie Treloar baerr...@gmail.com wrote: On Tue, Mar 2, 2010 at 7:05 AM, Benson Margulies bimargul...@gmail.com wrote: I'm on Windows, running mvn from cygwin, using the maven-eclipse-plugin. I construct a file URL that works fine in IE and firefox, but fails in maven: [INFO] Unable to read file: file://C:/cygwin2/home/benson/wst/BasisCodeFormatter.xml Anyone have a suggestion? Try http://en.wikipedia.org/wiki/File_URI_scheme Your url looks like it has two slashes which impies C: is the hostname. Try file:///C:/cygwin2/home/benson/wst/BasisCodeFormatter.xml - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Windows versus maven-eclipse-plugin versus file: url
I'm on Windows, running mvn from cygwin, using the maven-eclipse-plugin. I construct a file URL that works fine in IE and firefox, but fails in maven: [INFO] Unable to read file: file://C:/cygwin2/home/benson/wst/BasisCodeFormatter.xml Anyone have a suggestion?
Re: Windows versus maven-eclipse-plugin versus file: url
On Tue, Mar 2, 2010 at 7:05 AM, Benson Margulies bimargul...@gmail.com wrote: I'm on Windows, running mvn from cygwin, using the maven-eclipse-plugin. I construct a file URL that works fine in IE and firefox, but fails in maven: [INFO] Unable to read file: file://C:/cygwin2/home/benson/wst/BasisCodeFormatter.xml Anyone have a suggestion? Try http://en.wikipedia.org/wiki/File_URI_scheme Your url looks like it has two slashes which impies C: is the hostname. Try file:///C:/cygwin2/home/benson/wst/BasisCodeFormatter.xml - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
