Re: Changes in how exclusions are applied transitively ?
[See my reply below the quote.] Wed, 24 Jul 2013 20:20:49 +0200, /Grégory Joseph/: I can't seem to find an accurate trace of this in the release notes, so I thought I'd just ping the list - Changes in how exclusions are applied transitively between Maven 2.2.1 and 3.1 ? Here's a situation: A has dependencies on B and C. Both transitively depend on D (through X, which is irrelevant, I think) but B excludes it (on its dep declaration of X) With 2.2.1, D was (wrongly imo) excluded from A (depending on dependency order, seemingly) With 3.1, it appears to behave correctly. Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now where I need to work around the bug, currently by removing the exclusions. That's currently OK, but at some point, those exclusions will be re-added (in A or in a new project) and we'll face the same issue again, without any clue as to why. How have people dealt with this so far ? I'm not sure I fully understand you, but I'm also stuck with Maven 2.2.1 currently, and I've noticed when excluding a transitive dependency it excludes it from other dependencies which have it as a transitive dependency. The other dependencies I don't want to exclude the transitive dependency from are either test or provided (needed only during build, actually). To workaround this I've declared the dependency I want to exclude as provided in a 'dependencyManagement' section, so it doesn't get included automatically in WAR and similar packages. See if this approach might help you, too. -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Changes in how exclusions are applied transitively ?
Maybe it is documented in aether release note ? We probably should add a link to it or include it in our release note. This is the problem to have a core component outside of the project. It makes it difficult to have a global overview of all changes done in the project itself and all its dependencies updates. - Arnaud Le 28 juil. 2013 à 11:55, Stanimir Stamenkov s7a...@netscape.net a écrit : [See my reply below the quote.] Wed, 24 Jul 2013 20:20:49 +0200, /Grégory Joseph/: I can't seem to find an accurate trace of this in the release notes, so I thought I'd just ping the list - Changes in how exclusions are applied transitively between Maven 2.2.1 and 3.1 ? Here's a situation: A has dependencies on B and C. Both transitively depend on D (through X, which is irrelevant, I think) but B excludes it (on its dep declaration of X) With 2.2.1, D was (wrongly imo) excluded from A (depending on dependency order, seemingly) With 3.1, it appears to behave correctly. Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now where I need to work around the bug, currently by removing the exclusions. That's currently OK, but at some point, those exclusions will be re-added (in A or in a new project) and we'll face the same issue again, without any clue as to why. How have people dealt with this so far ? I'm not sure I fully understand you, but I'm also stuck with Maven 2.2.1 currently, and I've noticed when excluding a transitive dependency it excludes it from other dependencies which have it as a transitive dependency. The other dependencies I don't want to exclude the transitive dependency from are either test or provided (needed only during build, actually). To workaround this I've declared the dependency I want to exclude as provided in a 'dependencyManagement' section, so it doesn't get included automatically in WAR and similar packages. See if this approach might help you, too. -- Stanimir - 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 / javac does not compile classes to target folder
2013/7/26 Wayne Fay wayne...@gmail.com: wayne, thanks a lot for your response, it helped to figure out what's going on. I'm very glad to hear it! i was wondering if maven could detect that javac does not end successfully, and then abort and blame the compilation directly instead of building an I agree this sounds like a reasonable change to Maven. I'm a bit surprised it is not already handled -- you'd think javac would error with a status indicating error which Maven would pick up and report back to the user. If you have a few minutes, could I convince you to post a JIRA defect against hmmm maven-compiler-plugin or perhaps plexus-compiler? This assumes you have a Xircles account etc. i've found a workaround for my compilation, so for me the case is closed. thanks again! A bit weird a sample project could help BTW did you read http://maven.apache.org/plugins/maven-compiler-plugin/ the first sentence regarding using javac? Could you let us know the workaround, so if/when someone else has this trouble, they know what to do about it? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Stop offline mode artifact version renumbering
Hi Eric, Not sure if I got you either, but see if this can help you out. Where is the jetty with 'unwanted' version coming from? Use mvn dependency:tree, but don't completely rely on results, as it is broken (there's an issue on this in jira) and you might find the artifact, that adds the wrong jetty as transitive dependency. For this artifact, add jetty to excludes (in your pom - don't manipulate jetty poms). In case something from jetty is now missing, add it in dependecies explicitly. Another approach, which is easier but might not always work is to define add dependencyManagement section and specify there all jetty versions you want to use. Forcing maven into taking what you have in the local repo by manipulating local repo xml's scares me off. I'd trust pom.xml's of my project, fine-tune it, test with -o on another box. Ziga On Sat, Jul 27, 2013 at 3:48 AM, Ron Wheeler rwhee...@artifact-software.com wrote: I am not sure that I understand the problem but will version ranges in dependency specifications help? Ron On 26/07/2013 12:01 PM, Bahmer, Eric V wrote: I've searched through a few years archives of the mailing list and can't seem to find an answer to an issue that's been bugging me for a while now. We've been using a highly customized third-party application for a while now and are looking to upgrade to a newer version. The new version uses maven for part of it's build process. I work in an environment that for SECURITY reasons I must run my build in OFFLINE mode. I have already rebuilt over 600 rpms to have all the necessary dependencies available locally. The problem I'm having is this: The project uses jetty, it calls for version 7.5.3 to be used, I have a patched 8.1.0 installed. Maven will resolve jetty correctly, however one of the jetty jars will end up with it's version number altered in the distribution. jetty-server-8.1.0.v20120127.**jar jetty-servlet-8.1.0.v20120127.**jar jetty-start-7.5.3.v20111011.**jar This will not work as jetty-start reads it's own filename string and attempts to load other jetty jars with the same version string. I can get around the problem by replacing the jetty version number version.jetty tag in the parent pom, which will make jetty-start have the same 8.1.0 version number. However, jetty isn't the only jar that this is happening to. The overall project which isn't entirely java has a few sub-projects built separately exhibiting this same behavior and I would rather avoid replacing every version number in every pom or adding them if they don't have them just so that all related packages like jetty, spring, or resteasy have matching version numbers. I also don't want several copies of the same jar with different filenames because the version number is different for the sub-projects. Otherwise I have to put a bunch of ugly loops in my rpm spec file to clean up both before the build and after. Is there a way to force resolution of my locally installed version numbers and NOT rename the jar files to an incorrect version number? I've already tried the versions plugin, the dependency plugin, -U, -Dmaven.ignore.versions as well as combinations of them all. I repeat that I have all necessary dependencies locally installed for offline build. I know my versions work. I want maven to ignore what the poms say about version and take the version number from what I have installed. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
