Re: Problem with Scope of Transitive Dependencies
Jason, thanks for the response. I agree that my example was not very good and your proposal (separate module into api- and implementation-module) works here. To be more precise we have a dao-api, a dao-impl, a service-api and a service-impl module. However, the problem with the resulting scope still exists in the following two cases: 1.) Many of our JUnit tests are integration tests, so that the jars that are used by Hibernate must be available at runtime for the module service-impl but they must not be in the compilation-classpath. 2.) The dao-impl Module depends on Hibernate, but Libraries that are used by Hibernate (e.g. cglib, asm and antlr) shall not be used directly in the dao-impl Module but shall only be used at runtime of tests. -Ursprüngliche Nachricht- Von: Maven Developers List dev@maven.apache.org Gesendet: 23.03.07 14:20:06 An: Maven Developers List dev@maven.apache.org Betreff: Re: Problem with Scope of Transitive Dependencies On 23 Mar 07, at 7:18 AM 23 Mar 07, Thomas R. wrote: Hello, we are developing a very large project with a layered architecture. We decided to use Maven (Version 2.0.4) in order to have a good dependency-management. We are now facing the following problem with transitive dependencies: Consider following (simplified) example: We have a module DAO and a module SERVICE. The module SERVICE depends on DAO. Furthermore the module DAO depends on Hibernate. We now want to ensure that there is no compilation-dependency from SERVICE to Hibernate. This is the only way to really make sure that no developer uses any Hibernate- classes in the SERVICE-module accidentally. There are many other examples like this where we do not want a transitive dependency to get the scope compile. Your DAO should have an API, the service should only depend on the DAO API. The only thing your developers would see are the DAO interfaces in their IDE for example. I am assuming that your developers must see the DAO API in order for them to do any work? If you separate the interface from the implementation, have 2 JARs, and then only specify the specific implementations in your runtime distributions then your developers will be shielded from the specific implementations. In your case Hibernate. It boils down to mixing your concerns. In this case interface with implementation details. What are you using for your runtime system? For testing services what I have done in cases like your is to make a mock DAO with some test data so that developers can exercise their service in tests but still not be exposed to a real implementation. If you want them to test with the Hibernate then you can specify that as a test = scope for that particular service. What's below is far too complicated and not necessary. Separating your API from implementations is the way to go. And if you ever want to create an implementation of your DAO based on JPA for example then you don't have to then scrape our the interfaces you've bound up with Hibernate in one JAR. Separating these JARs goes a long way to having a flexible architecture and helps enforce the rules you want for your developers. Jason. In the maven documentation we found the following comment under Transitive Dependencies / Dependency Scope for the resulting scope when DAO uses Hibernate in scope compile and SERVICE uses DAO in scope compile: (*) Note: it is intended that this should be runtime instead, so that all compile dependencies must be explicitly listed - however, there is the case where the library you depend on extends a class from another library, forcing you to have available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive. (see http://maven.apache.org/guides/introduction/introduction-to- dependency-mechanism.html) For a large project with many (sometimes inexperienced) developers all over the world this makes it impossible to retain full control about the proper compliance of the basic architecture principles. So it is impossible for us to use transitive dependencies so that we are looking for an alternative. We see the following possibilities: 1.) Patch Maven: We could patch the maven-Installation by replacing the file lib/maven-artifact-2.0.4.jar with an own implementation of the class that computes the resulting scope. We would like to avoid this since every developer would have to do this manually, so that we would do this only as last option when we see that there is no other possibility. Is it planned to change the transitive scope in this case to test resp. runtime later? Or perhaps will there be a possibility to have influence on the resulting scope per configuration in the pom.xml? 2.) Inheritance: We don't use transitive
Re: Problem with Scope of Transitive Dependencies
On 24 Mar 07, at 9:19 AM 24 Mar 07, Thomas R. wrote: Jason, thanks for the response. I agree that my example was not very good and your proposal (separate module into api- and implementation-module) works here. To be more precise we have a dao-api, a dao-impl, a service-api and a service-impl module. However, the problem with the resulting scope still exists in the following two cases: 1.) Many of our JUnit tests are integration tests, so that the jars that are used by Hibernate must be available at runtime for the module service-impl but they must not be in the compilation-classpath. We could definitely improve some of our tooling if you're developers are seeing Hibernate I assume they are using an IDE and I know at least for IDEA the plugin exposes test scoped dependencies for application sources. It would certainly be nice to prevent that from happening. 2.) The dao-impl Module depends on Hibernate, but Libraries that are used by Hibernate (e.g. cglib, asm and antlr) shall not be used directly in the dao-impl Module but shall only be used at runtime of tests. For 2.1 I agree (and there is a JIRA) issue that the compile scope should be turned off for transitive deps. We have a case here now where plugins have been picking up plexus-utils transitively and using it, but not declaring it which is causing a problem. This too I believe is a serious problem but this change will seriously change the behavior of builds and won't be available in 2.0.x. Jason. -Ursprüngliche Nachricht- Von: Maven Developers List dev@maven.apache.org Gesendet: 23.03.07 14:20:06 An: Maven Developers List dev@maven.apache.org Betreff: Re: Problem with Scope of Transitive Dependencies On 23 Mar 07, at 7:18 AM 23 Mar 07, Thomas R. wrote: Hello, we are developing a very large project with a layered architecture. We decided to use Maven (Version 2.0.4) in order to have a good dependency-management. We are now facing the following problem with transitive dependencies: Consider following (simplified) example: We have a module DAO and a module SERVICE. The module SERVICE depends on DAO. Furthermore the module DAO depends on Hibernate. We now want to ensure that there is no compilation-dependency from SERVICE to Hibernate. This is the only way to really make sure that no developer uses any Hibernate- classes in the SERVICE-module accidentally. There are many other examples like this where we do not want a transitive dependency to get the scope compile. Your DAO should have an API, the service should only depend on the DAO API. The only thing your developers would see are the DAO interfaces in their IDE for example. I am assuming that your developers must see the DAO API in order for them to do any work? If you separate the interface from the implementation, have 2 JARs, and then only specify the specific implementations in your runtime distributions then your developers will be shielded from the specific implementations. In your case Hibernate. It boils down to mixing your concerns. In this case interface with implementation details. What are you using for your runtime system? For testing services what I have done in cases like your is to make a mock DAO with some test data so that developers can exercise their service in tests but still not be exposed to a real implementation. If you want them to test with the Hibernate then you can specify that as a test = scope for that particular service. What's below is far too complicated and not necessary. Separating your API from implementations is the way to go. And if you ever want to create an implementation of your DAO based on JPA for example then you don't have to then scrape our the interfaces you've bound up with Hibernate in one JAR. Separating these JARs goes a long way to having a flexible architecture and helps enforce the rules you want for your developers. Jason. In the maven documentation we found the following comment under Transitive Dependencies / Dependency Scope for the resulting scope when DAO uses Hibernate in scope compile and SERVICE uses DAO in scope compile: (*) Note: it is intended that this should be runtime instead, so that all compile dependencies must be explicitly listed - however, there is the case where the library you depend on extends a class from another library, forcing you to have available at compile time. For this reason, compile time dependencies remain as compile scope even when they are transitive. (see http://maven.apache.org/guides/introduction/introduction-to- dependency-mechanism.html) For a large project with many (sometimes inexperienced) developers all over the world this makes it impossible to retain full control about the proper compliance of the basic architecture principles. So it is impossible for us to use transitive dependencies so that we are looking for an alternative. We see the following possibilities: 1.) Patch Maven: We could patch the
[RESULT][VOTE] Release maven-plugin-plugin 2.3
Here are the results of this vote: +1 Binding: Dennis Lundberg, Stephane Nicoll, Jason val Zyl, John Casey, Vincent Siveton +1 Non-binding: Brian E. Fox, Daniel Kulp, Andrew Williams I will proceed with the release. Dennis Lundberg wrote: Hi, I'd like to release maven-plugin-plugin-2.3. There is only one issue fixed for this release, but it's an important one. It adds support for @since tags for mojo parameters. This is an important improvement to our plugin documentation: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139fixfor=13114 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-plugin-plugin-2.3/ Staged at: http://people.apache.org/~dennisl/staging-repository-plugins/ A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Whats wrong with Maven at the moment - maven-site-plugin fails!
Jason van Zyl [EMAIL PROTECTED] writes: But then plugins needing to build ids need a dependency on the xhtml module. Is that better? And link/anchor generation is needed for e.g. pdf, too. Providing this functionality would IMHO be the job of the core of a system, not one of the components. Best regards Henning On 22 Mar 07, at 7:28 PM 22 Mar 07, Henning P. Schmiedehausen wrote: Jason van Zyl [EMAIL PROTECTED] writes: On 22 Mar 07, at 11:56 AM 22 Mar 07, Emmanuel Venisse wrote: I think we'll need to modify more report plugins with the same patch No, I should just put the HtmlTools back and deprecate it. I didn't know people were pulling out core utilities, but not surprising. I'll restore the original location. And how are plugins supposed to generate the same link information as the Doxia core? That is the reason why that patch went in there in the first place. There was a change in the way Doxia created attributes on the pages and Plugins which reference these attributes (e.g. html anchors) suddently broke. At least in my understanding, you provide a class that offers this functionality in a central place and let both pieces (Doxia and the plugins) reference it so that the next change will not break this again. Just deprecating the class and saying do no longer use it is IMHO not the right way to go. It needs to go into the module where it belongs. It should not be used from its current location as it doesn't belong there. it belongs in the xhtml module. Best regards Henning Jason. Emmanuel Emmanuel Venisse a écrit : Fixed. Wendy Smoak a écrit : On 3/22/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: All is fixed, but I can't deploy doxia because files are in read mode for group. Jason, can you fix it? Thanks. Your Doxia change fixed 'mvn site' but now I'm seeing a problem in the Changes plugin: ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure /home/continuum/working-directory/8/src/main/java/org/apache/ maven/plugin/changes/ChangesReportGenerator.java:[22,37] package org.apache.maven.doxia.module does not exist /home/continuum/working-directory/8/src/main/java/org/apache/ maven/plugin/changes/ChangesReportGenerator.java:[188,60] cannot find symbol symbol : variable HtmlTools location: class org.apache.maven.plugin.changes.ChangesReportGenerator --- -- 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Whats wrong with Maven at the moment - maven-site-plugin fails!
On 24 Mar 07, at 1:03 PM 24 Mar 07, Henning P. Schmiedehausen wrote: Jason van Zyl [EMAIL PROTECTED] writes: But then plugins needing to build ids need a dependency on the xhtml module. Is that better? And link/anchor generation is needed for e.g. pdf, too. Then it should be put into the appropriate sink with a method to have that work. Providing this functionality would IMHO be the job of the core of a system, not one of the components. Writing anchors for a specific type of output is the concern of the module producing the output. Jason. Best regards Henning On 22 Mar 07, at 7:28 PM 22 Mar 07, Henning P. Schmiedehausen wrote: Jason van Zyl [EMAIL PROTECTED] writes: On 22 Mar 07, at 11:56 AM 22 Mar 07, Emmanuel Venisse wrote: I think we'll need to modify more report plugins with the same patch No, I should just put the HtmlTools back and deprecate it. I didn't know people were pulling out core utilities, but not surprising. I'll restore the original location. And how are plugins supposed to generate the same link information as the Doxia core? That is the reason why that patch went in there in the first place. There was a change in the way Doxia created attributes on the pages and Plugins which reference these attributes (e.g. html anchors) suddently broke. At least in my understanding, you provide a class that offers this functionality in a central place and let both pieces (Doxia and the plugins) reference it so that the next change will not break this again. Just deprecating the class and saying do no longer use it is IMHO not the right way to go. It needs to go into the module where it belongs. It should not be used from its current location as it doesn't belong there. it belongs in the xhtml module. Best regards Henning Jason. Emmanuel Emmanuel Venisse a écrit : Fixed. Wendy Smoak a écrit : On 3/22/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: All is fixed, but I can't deploy doxia because files are in read mode for group. Jason, can you fix it? Thanks. Your Doxia change fixed 'mvn site' but now I'm seeing a problem in the Changes plugin: ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure /home/continuum/working-directory/8/src/main/java/org/apache/ maven/plugin/changes/ChangesReportGenerator.java:[22,37] package org.apache.maven.doxia.module does not exist /home/continuum/working-directory/8/src/main/java/org/apache/ maven/plugin/changes/ChangesReportGenerator.java:[188,60] cannot find symbol symbol : variable HtmlTools location: class org.apache.maven.plugin.changes.ChangesReportGenerator - -- -- 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - 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]
MKS Support
Hi, this seems to be a reoccuring question, is anybody working on MKS Source Integrity support? I found some mails from May/June last year in the archive but nothing else. Regards, Niklas. -- Niklas Grossmann [EMAIL PROTECTED]
Re: MKS Support
Hi, I don't think or maybe an hidden development. Emmanuel Niklas Grossmann a écrit : Hi, this seems to be a reoccuring question, is anybody working on MKS Source Integrity support? I found some mails from May/June last year in the archive but nothing else. Regards, Niklas.
Re: Unit Test inheritance in a multi-pom project?
Hi GreJ, I believe that is correct. A mvn install must be done in order to make the test jars available on the classpath to compile against for the inherited tests. I agree that it is unfortunate that an install must be done in order to run the tests. Maven developers, Should I submit a feature request on Jira? It would be something to the effect like Test jars / test-classes source directories need to be available on the classpath within the reactor during the test-compile phase so users don't need to perform an install in order to compile against code in other test-jars / test-classes source directories How's that sound? It would also be handy to have transitive dependency management of the test-jars, but that should probably be for another feature request. Thanks, Jim On 3/23/07, GreJ [EMAIL PROTECTED] wrote: Hi, Thanks for your answer, I do several tests, and in fact it doesn't work without install. The test jar really needed to be installed in the local repository(?). This is my project layout -Root +sslServer +client client must use the test-jar generated by the sslServer module. So here is the dependencies of the client module : dependencies dependency artifactIdsslServer/artifactId groupIdorg.inpres/groupId version1.0/version /dependency dependency groupIdorg.inpres/groupId artifactIdaw-sslServer/artifactId version1.0/version typetest-jar/type /dependency /dependencies There is no problem to resolvethe dependency to the org.inpres:sslServer. By compile, or package, there is no problem. But the test-jar ist not found while no install is called. It's pitty to need to run the install and so to install all the jars if we just need to compile the tests :( Is there a praticular reason that the sslServer dependency is found by compile or packaging, but not the tests? My aim is just to compile or run the tests, where the tests of the client need classes from the sslServer... -- View this message in context: http://www.nabble.com/Unit-Test-inheritance-in-a-multi-pom-project--tf3442738s177.html#a9644535 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
any progress? is there something yet to do or anybody can call a vote / release it? On 3/17/07, Jason van Zyl [EMAIL PROTECTED] wrote: Yes, actually. Kenney fixed the tests so we can probably shove this out the door. It's still on my list, just been working on 2.0.6. Jason. On 17 Mar 07, at 6:35 PM 17 Mar 07, Niall Pemberton wrote: Any progress on this? Niall On 3/2/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 3/2/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 2 Mar 07, at 7:28 AM 2 Mar 07, Niall Pemberton wrote: ping :-) I just released a snapshot, do you think you could give it a whirl quickly? I ran mvn source:jar for commons validator with the new snapshot and everything was fine (with a resource element for something in the root directory). Niall Jason. On 2/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/18/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Feb 07, at 9:32 AM 18 Feb 07, Niall Pemberton wrote: On 2/15/07, Stephane Nicoll [EMAIL PROTECTED] wrote: Yes. I need to check with Jason because it seems he's found a problem meanwhile. Any news on this - can the release go out (sorry to keep buging you)? No, I found regressions after the vote. I've fixed most of the issues, but want to add two more tests and fix the integration tests. Early next week I'll put it up the vote again. Feel free to try a snapshot, I deployed it so you can try it which will help me release it faster. OK thanks - I tried out the the 2.0.4-SNAPSHOT (with Commons Validator) and it built the sources jar fine. Niall jason. Niall I'll keep you posted. Stéphane On 2/15/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 2/12/07, Stephane Nicoll [EMAIL PROTECTED] wrote: Yes please. We need to wait a bit more. I'll make sure to send a mail with the vote result. Has enough time lapsed yet to declare a result and cut the release? Thanks Niall Thanks, Stéphane On 2/12/07, Jason van Zyl [EMAIL PROTECTED] wrote: Stephane, Would you like me to copy this over to the production repository for the release? Jason. On 11 Feb 07, at 10:42 AM 11 Feb 07, Jason van Zyl wrote: +1 Thanks Stephane, Jason. On 11 Feb 07, at 5:11 AM 11 Feb 07, Stephane Nicoll wrote: Hi, This release fixes all known issues. Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 ** Bug * [MSOURCES-6] - Sources plugin ignores resource includes/excludes ** Improvement * [MSOURCES-11] - When source plugin is used, it should make sure it is invoked during install Revision: 505872 The staging bits are available as well: http://people.apache.org/~snicoll/maven-staging/ repo/ org/ apache/ maven/plugins/maven-source-plugin/2.0.3/ Vote opens for 72hours. My +1 Thanks, Stéphane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: dev- [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] - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The
M2 FAQ has ibiblio ref
The M2 FAQ has a ref to ibiblio. Does this need to change to the new Maven Central ref? http://maven.apache.org/general.html#available-plugins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 FAQ has ibiblio ref
tha info is not even applicable anymore On 3/24/07, Jeff Jensen [EMAIL PROTECTED] wrote: The M2 FAQ has a ref to ibiblio. Does this need to change to the new Maven Central ref? http://maven.apache.org/general.html#available-plugins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2 FAQ has ibiblio ref
OK, would you like me to remove the question entirely or change it to something correct you have in mind? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Saturday, March 24, 2007 10:22 PM To: Maven Developers List Subject: Re: M2 FAQ has ibiblio ref tha info is not even applicable anymore On 3/24/07, Jeff Jensen [EMAIL PROTECTED] wrote: The M2 FAQ has a ref to ibiblio. Does this need to change to the new Maven Central ref? http://maven.apache.org/general.html#available-plugins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
Re: M2 FAQ has ibiblio ref
On 3/24/07, Jeff Jensen [EMAIL PROTECTED] wrote: OK, would you like me to remove the question entirely or change it to something correct you have in mind? I'd point at this list instead: http://maven.apache.org/plugins/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] maven-dependency-plugin 2.0-alpha-4 AND maven-dependency-analyzer 1.0-alpha-2
I'd like to release maven-dependency-plugin:2.0-alpha-4 and the shared maven-dependency-analyzer 1.0-alpha-2 that it depends on. Tags: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug in-2.0-alpha-4/ http://svn.apache.org/repos/asf/maven/shared/tags/maven-dependency-analy zer-1.0-alpha-2/ Staged at: http://people.apache.org/~brianf/staging-repository Changes: Fixed several issues related to the new analyze and analyze-dep-mgt goals: Release Notes - Maven 2.x Dependency Plugin - Version 2.0-alpha-4 ** Bug * [MDEP-72] - IllegalArgumentException: Cannot accept visitor on URL when project contains a non-jar (e.g. zip) dependency * [MDEP-73] - dependency:analyze in a packaging=pom project should skip, not die or produce a redundant report * [MDEP-74] - dependencies in test scope are not handled properly by analyze * [MDEP-77] - dependency:analyze is reporting impossible results * [MDEP-78] - analyze-dep-mgt has the labels reversed * [MDEP-79] - index out of bounds exception on analyze against maven-war-plugin ** Improvement * [MDEP-76] - It would be nice to analyze dependencyManagement exclusions as well as versions Vote is open for 72 hours. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
