Re: Problem with scopes in dependencies
Using help:effective-pom it shows the 'correct', in term of Maven 3, scope which is not the expected scope. Whatever scope I set in my pom it is the scope defined (or not) in the parent pom's dependency management that is used. this is quite blocking as it means that you can't use the dependecyManagement with dependencies that might be used in other scopes. On Mon, Mar 14, 2011 at 2:49 PM, Benjamin Bentmann wrote: > Emmanuel Hugonnet wrote: > >> How can I display the genuine scope of my dependecy ? > > mvn -X ... > > The debug log will print the project dependency tree before the project gets > build. > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Problem with scopes in dependencies
Hi, I am using Maven 3.0.x (2 or 3= and I have the following problem : I use a parent POM with dependency management which is the good way to do this. We are building for JBoss 4 and JBoss 6 and if for JBoss6 XercesImpl is provided, for JBoss4 it is required with the Assembly Plugin. So in my parent pom I have specified a "provided" scope and I override it in the jboss4 specific pom with a "compile" scope. One would expect that the xercesImpl.jar would be present in the resulting war, as i take runtime jars but the xerces jar is not here. If I put the scope "provided" in the Jboss 6 pom and "compile" in the parent pom, I get the xerces.jar. I have tried maven-dependency-plugin:tree:2.2 but all is I expected, so it seems to be a mven 3 issue since maven-dependency-plugin still uses maven2. How can I display the genuine scope of my dependecy ? Emmanuel - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Bring Maven to the Color age
Hi, I have written a patch for plexus ConsoleLogger (PLX-421) so that Maven's output are colorized if you are using a pseud-terminal and have set the system property 'colorized.console' to 'true'. This could provides a solution to http://jira.codehaus.org/browse/MNG-3507. Emmanuel
http://jira.codehaus.org/browse/MCHANGES-78
Hi, I have updated the code for this enhancement. It parses svn messages to produce the changelog in the site. This way you don't have to maintain a changes.xml file. Now it uses Maven-SCM API and it is Java 1.4 compliant. regards, Emmanuel
Re: Changes plugin contribution
Emmanuel Venisse a écrit : Emmanuel Hugonnet a écrit : zze-HUGONNET E ext RD-BIZZ a écrit : Emmanuel Hugonnet a écrit : Stephane Nicoll a écrit : Hi, Where is the source code of your plugin? If it's valuable we can certainly have a look :) Thanks, Stéphane On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote: Hi, I have developped a Maven2 plugin that build a report equivalent to the changes report but which uses svn comment parsing instead of changes.xml. The parsing rules are configurable and can be overriden (I am providing 2 rules as examples). Links to the bug trackers are also configurable with currently 2 kinds of links (JIRA and Sourceforge) but it supports also a pattern to create them. I would like to contribute it to the maven-changes-plugin since it loks to be a feature improvement of it. The only problem with this plugin is that is doesn't use plexus-utils for the cli but my 'own' implementation using the jdk API for processes. Is the changes-plugin team interested in it ? Should I move it to codehaus and wait for a possible merger after ? Thanks, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry if I make a double post. Well it is currently on my workstation. I can send it to you by mail or maybe I could create a JIRA for the changes-plugin and put it there. What is the best solution ? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok I have attached the code with the JIRA *MCHANGES-78 <http://jira.codehaus.org/browse/MCHANGES-78>. *Give it a try ;o) You should have some comment on your svn with @fix:bug_ref; Comment or @update:;Comment etc. Feel free to ask any question if it is not clear as I am not an english spoken person ;o) Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I have rewritten it to be compatible with JDK 1.4 . As for Emmanuel's remarks I agree that it should be better but Maven-SCM is not easy to use since I have to create my own svn provider (extending the current one) just to add the xml option. Also it seems to execute the list and log commands recursively (maybe I made some mistakes while trying to use it) and I just gave up :o( If you think that this plugin is useful and someone could spare some time or some example on own to start with plexus cli and Maven-SCM considering these issues I would gratefully comply to Emmanuel's remarks and clean my code. I don't know why you need the list command (haven't look at your code yet) but for the log command, you can look at the changelog plugin, it's its job. Emmanuel Thanks, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi, I use the list command to get all the tags and their revision numbers so I can group comments per releases (assuming each entry in tags is a release). This way you get your changelog per release and what is currently in the trunk. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changes plugin contribution
zze-HUGONNET E ext RD-BIZZ a écrit : Emmanuel Hugonnet a écrit : Stephane Nicoll a écrit : Hi, Where is the source code of your plugin? If it's valuable we can certainly have a look :) Thanks, Stéphane On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote: Hi, I have developped a Maven2 plugin that build a report equivalent to the changes report but which uses svn comment parsing instead of changes.xml. The parsing rules are configurable and can be overriden (I am providing 2 rules as examples). Links to the bug trackers are also configurable with currently 2 kinds of links (JIRA and Sourceforge) but it supports also a pattern to create them. I would like to contribute it to the maven-changes-plugin since it loks to be a feature improvement of it. The only problem with this plugin is that is doesn't use plexus-utils for the cli but my 'own' implementation using the jdk API for processes. Is the changes-plugin team interested in it ? Should I move it to codehaus and wait for a possible merger after ? Thanks, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry if I make a double post. Well it is currently on my workstation. I can send it to you by mail or maybe I could create a JIRA for the changes-plugin and put it there. What is the best solution ? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok I have attached the code with the JIRA *MCHANGES-78 <http://jira.codehaus.org/browse/MCHANGES-78>. *Give it a try ;o) You should have some comment on your svn with @fix:bug_ref; Comment or @update:;Comment etc. Feel free to ask any question if it is not clear as I am not an english spoken person ;o) Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I have rewritten it to be compatible with JDK 1.4 . As for Emmanuel's remarks I agree that it should be better but Maven-SCM is not easy to use since I have to create my own svn provider (extending the current one) just to add the xml option. Also it seems to execute the list and log commands recursively (maybe I made some mistakes while trying to use it) and I just gave up :o( If you think that this plugin is useful and someone could spare some time or some example on own to start with plexus cli and Maven-SCM considering these issues I would gratefully comply to Emmanuel's remarks and clean my code. Thanks, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changes plugin contribution
Emmanuel Hugonnet a écrit : Stephane Nicoll a écrit : Hi, Where is the source code of your plugin? If it's valuable we can certainly have a look :) Thanks, Stéphane On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote: Hi, I have developped a Maven2 plugin that build a report equivalent to the changes report but which uses svn comment parsing instead of changes.xml. The parsing rules are configurable and can be overriden (I am providing 2 rules as examples). Links to the bug trackers are also configurable with currently 2 kinds of links (JIRA and Sourceforge) but it supports also a pattern to create them. I would like to contribute it to the maven-changes-plugin since it loks to be a feature improvement of it. The only problem with this plugin is that is doesn't use plexus-utils for the cli but my 'own' implementation using the jdk API for processes. Is the changes-plugin team interested in it ? Should I move it to codehaus and wait for a possible merger after ? Thanks, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry if I make a double post. Well it is currently on my workstation. I can send it to you by mail or maybe I could create a JIRA for the changes-plugin and put it there. What is the best solution ? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok I have attached the code with the JIRA *MCHANGES-78 <http://jira.codehaus.org/browse/MCHANGES-78>. *Give it a try ;o) You should have some comment on your svn with @fix:bug_ref; Comment or @update:;Comment etc. Feel free to ask any question if it is not clear as I am not an english spoken person ;o) Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changes plugin contribution
Stephane Nicoll a écrit : Hi, Where is the source code of your plugin? If it's valuable we can certainly have a look :) Thanks, Stéphane On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote: Hi, I have developped a Maven2 plugin that build a report equivalent to the changes report but which uses svn comment parsing instead of changes.xml. The parsing rules are configurable and can be overriden (I am providing 2 rules as examples). Links to the bug trackers are also configurable with currently 2 kinds of links (JIRA and Sourceforge) but it supports also a pattern to create them. I would like to contribute it to the maven-changes-plugin since it loks to be a feature improvement of it. The only problem with this plugin is that is doesn't use plexus-utils for the cli but my 'own' implementation using the jdk API for processes. Is the changes-plugin team interested in it ? Should I move it to codehaus and wait for a possible merger after ? Thanks, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sorry if I make a double post. Well it is currently on my workstation. I can send it to you by mail or maybe I could create a JIRA for the changes-plugin and put it there. What is the best solution ? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven - Plexus relationship
Hi,
We have a problem with ${basedir} evaluation under M$ Windows which
gives us a path mixing \ and / when filtering resources.
This seems to be coming from plexus-utils (cf.
http://jira.codehaus.org/browse/MRESOURCES-10) and looks corrected since
plexus-utils 1.2 :o)
So I have tried to upgrade maven-resources-plugin dependecy to
plexus-utils 1.4 (this comes from maven-resources-plugin depending on
maven-compiler-plugin depending on plexus-utils:1.0.4) but this did not
correct my problem.
Emmanuel Venisse suggested to upgrade the plexus-utils.jar in
$M2_HOME/core but this did not correct our problem:o( and raised a
question in my mind:
Who is in charge with interpreting ${basedir} ? Is it the plexus /
plexus utils from maven's core or the plexus-utils which is referenced
in transitive dependency from the plugin ?
I am quite at lost here because while I understand that plugins depend
on the maven-plugin-api and maven-compiler-plugin and etc. this should
be a 'provided' dependency as you need them to compile but they should
be provided by the maven/plexus container. This way, the plugins may not
be backward compatible but upgrading plexus into maven should be far easier.
My 2 cents
Emmanuel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-changes-plugin questions
Jeff Jensen a écrit : I like the changes page as a "simplified, user-friendly" list of notable changes made for each release. The defect/RFE tracking system has the details for the initiated users when desired. Quoting Stephane Nicoll <[EMAIL PROTECTED]>: On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: I never really understood the changes.xml myself, as I don't want to keep things in an issue tracking system and changes.xml or is this for folks who don't employ an issue tracking system? Yes and no. I've always seen it as a "technical" changelog of the project. When end-users create issues, the summary is not always understandable so we end up with a list of "things" beings solved. The changes.xml allows to describe in more details what happened. It's a good thing actually and it's certainly a good alternative for people not using an Issue tracker that maven handles. Stéphane - Keeping it in a maven-changes-plugin brings M1 and M2 more in sync than they were before, which eases migration pains. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi, I agree with you and I think that the information should be in the scm comments to refer to the bug tracking system. We have developed such a maven plugin that parses subversion comments to create a changelog page with only significant modifications displayed and links to the corrected bugs if needed. So users can see in what state each release and the trunk is. I hope to be able to release it publicly. If you feel this is something useful I would be able to convince my boss more easily. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven properties evaluation
zze- HUGONNET E ext RD-BIZZ a écrit : Hi, It looks like properties and map, as component, are not evaluated in the same way in Maven. I am setting a MavenProject.property in a Mojo to use it in another one in another phase. If I use a Map to pass this value (a String) all is correct but if I use a Properties the property is not evaluated. To add more to my confusion, if I use a Maven property (like basedir) it is correctly evaluated. I am quite at lost here. I have posted a JIRA on this subject on SURFIRE (http://jira.codehaus.org/browse/SUREFIRE-60) where I found this problem but to me this looks like a Maven or Plexus issue. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This is a duplicate of http://jira.codehaus.org/browse/MNG-2201. Sorry for the inconvenience. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven properties evaluation
Hi, It looks like properties and map, as component, are not evaluated in the same way in Maven. I am setting a MavenProject.property in a Mojo to use it in another one in another phase. If I use a Map to pass this value (a String) all is correct but if I use a Properties the property is not evaluated. To add more to my confusion, if I use a Maven property (like basedir) it is correctly evaluated. I am quite at lost here. I have posted a JIRA on this subject on SURFIRE (http://jira.codehaus.org/browse/SUREFIRE-60) where I found this problem but to me this looks like a Maven or Plexus issue. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven's classpaths (Was: [discuss] Java 5)
[EMAIL PROTECTED] a écrit : Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 28.11.2006 15:54:34: I have to edit the pom.xml of maven-plugin-tools-java to set the version of qdox to 1.6.1 and then all is fine. Hi, This is a temporary solution I use with a proximity proxy and an overriding pom.xml but my question is more theorical than practical ;-) Why can't I override this dependency? In the pom, you can tell maven how to compile and test *your* code. From maven's point of view, the maven-plugin-tools-java is "external" and outside the scope of the dependencies in your pom.xml. Imagine: A plugin depends on some class in qdox 1.5 which is deprecated and was removed in qdox 1.6. Now, your project says "I depend on qdox 1.6". If maven took this into account when loading plugins, the plugin wouldn't work and there was no way to make it work without breaking the build of your project. A deadlock. Therefore, maven carefully separates the classpaths from every plugin from your project. You can have plugin A which needs qdox 1.5 and plugin B which needs qdox 2.0 in the *same* build and include qdox 1.6 in your project and it will work. A solution might be to extend maven's xml merge mechanism. If you could add "patches" to pom.xml and settings.xml//profile, then it would be possible to override the values in other POM's (for example, to patch the POM of maven-plugin-tools-java to depend on a different version of qdox). Here, I must ask how economical that would be. As it is, the solution is simple (at least when you're used at how simple it is to setup and compile maven projects) and the question is how useful such a patch mechanism will be (ie. how often can you fix your problems with it?). Regards, Hi, Thank you, this was the answer I was looking for :o) I thought I was missing something and you pointed right to it. I understand your point of view and agree with it. I will stick to my solution with my modified version of maven-plugin-tools-java waiting for the futur release. Regards, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
[EMAIL PROTECTED] a écrit : Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 28.11.2006 14:24:44: I have to edit the pom.xml of maven-plugin-tools-java to set the version of qdox to 1.6.1 and then all is fine. My solution in such a case: - Download the source for the broken plugin - Fix the dependencies - Increment the version by 1 (i.e. 2.0.2 in this case). - Deploy the new plugin to a local repository Now, you can use this version in your projects until the bug is fixed. You might also want to add -SNAPSHOT to the version but then, you have to make sure that you're not getting into conflicts with the official snapshots. If the plugin is released with the very same version, you have to delete it manually on your side but until then, you can work. How about a -PATCH version? :-) Regards, Hi, This is a temporary solution I use with a proximity proxy and an overriding pom.xml but my question is more theorical than practical ;-) Why can't I override this dependency ? To me this is a core maven problem, it seems that since it is the core of maven plugin management that doesn't take into account the configuration set in my pom.xml. While I agree that you have these dependencies to core maven-plugin-tools, I think it should be overridable. I am no maven guru and I don't understand all of its arcane and this is a bit to much hard-core for me, that's why I didn't post a Jira. I don't know if its a feature or a bug :oP Regards, Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
Tom Huybrechts a écrit :
On 11/27/06, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
This plugin uses sourcelevel 1.5:
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/repositorytools-maven-plugin
... and it does have non-mojo classes that do not have these
constraints (see the components package)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
If I add an enum in its own file in this plugin I get a build failure :(
without any reference from a MOJO. This is most infortunate and blocking
in my opinion.
The enum :
package org.codehaus.mojo.repositorytools;
/**
*
* @author ehugonnet
*/
public enum OperationTypeEnum {
ADD,UPDATE, FIX, REMOVE;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
Tom Huybrechts a écrit : I write all my mojo's with 1.5. You just need to avoid using annotations and generics in the signature of your classes (fields, methods and their annotations). Tom So maybe you can enlight me ;-) : maven-plugin-tools-java (2.0.1 to 2.0.5-SNAPSHOT) has a dependency on qdox 1.5 which is jdk 1.5 incompatible. How did you resolve this problem ? I maybe wrong but your constraint apply to all the classes of my plugin not just my MOJO, so this means I must code with 1.4 style :( Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Java 5
Brett Porter a écrit : This would have zero impact on applications built with Maven. I'd been meaning to follow this up. Let me see what happened with the user survey... - Brett On 26/11/2006, at 12:49 PM, Brian E. Fox wrote: Our experience with our products is that not enough of the available portal and app servers support JDK 1.5 or our customers haven't yet upgraded. That unfortunately means we are stuck on 1.4 for the near future. I think many business customers are in the same predicament where we can't dictate the JDK required. If maven suddenly required Java 1.5, we would be in a serious bind and it would limit adoption of Maven 2.1. -Original Message- From: Rahul Thakur [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 7:55 PM To: Maven Developers List Subject: Re: [discuss] Java 5 This thread kinda died off silently Just wondering if there was a user survey about switching to Java 5.0? Rahul - Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Sunday, July 09, 2006 6:09 AM Subject: Re: [discuss] Java 5 On 7 Jul 06, at 2:36 AM 7 Jul 06, Brett Porter wrote: Hi, I wanted to get thoughts on starting to require a Java 5 JVM to run stuff we build. We currently restrict to 1.4 across the board. I think before this can be done we need to make sure we're not making life difficult for people. It may be the case that most people don't have a problem using a 1.5 JDK in their environment but it might be an ideal time to use one of the online survey services to take a real poll. If the vast majority of users were not adversely affected by a move to 1.5 I would be fine with, as I'd like to use 1.5 where possible. But if it's not the case we probably should hold off on this requirement. Here's what I'm thinking: - MRM and Continuum should switch now. Stuff built there is rarely consumed elsewhere, and a Java 5 requirement outside of that is reasonable - We could switch for Maven 2.1, as long as we have improved support for invoking external toolchains. This would facilitate doing some much nicer stuff with plugins like annotations. - A generified plexus would be very cool, but is an aside here and post plexus-1.0 in my opinion. - I think it's best to keep the lower requirement on Doxia, Surefire (1.3), and Wagon for now. Does anyone have any thoughts on this? I'll likely propose a vote on the first point before the first/next releases of them unless there are reasons not to. Cheers, Brett --Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi, We are using jdk1.5 and I ran into serious troubles to build a 1.5 plugin (using enum and generics) because maven-plugin-tools is not JDK1.5 compatible even in snapshot :(. My opinion is that a least we should have the ability to use what 1.5 gives us (annotations for plugin description, enum, generics, concurrency ...) with an old style tools or retroveawer (http://retroweaver.sourceforge.net/) to get the 1.4 compatibility. My 2 cents Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
