Maven fails to resolve version range for import
I think I found a bug in Maven, but I am not sure. Maybe I am doing something wrong, so Maven Committers, please judge the following case: A version range in a dependency like... org.glassfish.jersey.core jersey-server [2.0.0, 3.0.0) mvn dependency:tree ...results in a correctly resolved output... ... +- org.glassfish.jersey.core:jersey-server:jar:3.0.0-RC2:compile ... But when instead using the same version range IN AN IMPORTED BOM, then... org.glassfish.jersey jersey-bom [2.0.0, 3.0.0) pom import org.glassfish.jersey.core jersey-server mvn dependency:tree ...results in this error message as it was not resolved: downloading from xxx: http://xxx:8081/content/groups/public/org/glassfish/jersey/jersey-bom/%5B2.0.0,%203.0.0)/jersey-bom-%5B2.0.0,%203.0.0).pom Non-resolvable import POM: Could not find artifact org.glassfish.jersey:jersey-bom:pom:[2.0.0, 3.0.0) In fact, calling curl -i http://nexus:8081/content/groups/public/org/glassfish/jersey/jersey-bom/%5B2.0.0,%203.0.0)/jersey-bom-%5B2.0.0,%203.0.0).pom tells us that such a URL does not exist: HTTP/1.1 400 Invalid repository path. So am I doing or assuming something wrong here (e. g. possibly includes deliberately will not resolve version ranges) or is that simply a bug in Maven (which I should report in the issue tracker)? Thanks! -Markus
AW: Keeping dependency out of all classpaths
The third party plugin does not expect anything from the classpath as it is a non-Java Maven plugin. Imagine this case: The ZIP (hypothetically) contains SVG, the third party plugin renders into PDF, the PDF goes into the WAR as a resource. Again, just hypothetically. Just ignore WHY the ZIP is not a "normal" ZIP but concentrate on "it is of no value for the Java compiler and not processable by it". But let's make the use case even easier: Just kick the third party plugin out of the project and instead let's just use the normal dependency plugin pick some content from the ZIP file to put it into the WAR. Then your question is gone, but still the problem exists: The Maven compiler plugin fails because the ZIP is not in the expected format to be processable by the Maven compiler plugin. That ZIP simply is NOT INTENDED to be consumed by the Maven Compiler plugin. BTW, your assumption is wrong: Java does NOT say "ALL zip MUST be on the classpath", it just says "THOSE zips that you WANT to consume by the compiler must be on the classpath". This is a huge difference! -Markus -Ursprüngliche Nachricht- Von: Tamás Cservenák Gesendet: Freitag, 10. Juni 2022 13:53 An: Maven Users List Betreff: Re: Keeping dependency out of all classpaths So let's enumerate what we have so far: - the ZIP is built in same multi module build, and is "intentionally incompatible" - the ZIP should be a dependency of WAR module, needed for Maven to be able to make proper build ordering decisions - Java specifically says "JARs and ZIPs are added to classpath" - only third party plugin processes the content of zip file - the result of WAR module class compilation AND third party plugin output should be part of resulting WAR But I still have questions: - how is the third party plugin expecting the input? Is injecting a project and programmatically finding the ZIP? Or does it expect it on the classpath? (as in this case) IMO, still the custom packaging (well, artifact handler bit) is the solution here, especially as both, producing ZIP and consuming ZIP happens in the same multi module build. Either the plugin should define type=foo-plugin-resources or something like that, or you could define custom packaging (as you do build the zip file) and use custom type to reference ZIP dependency? HTH T On Fri, Jun 10, 2022 at 1:23 PM [Quipsy] Markus Karg wrote: > It is a dependency because it shall be built with -am if this project > is built, and it is consumed by this project using third party > plugins. But it simply is not consumed by the Java toolchain. This has > nothing to do with the plugin. The WAR produced here is built from > Java source compiled to Java classes and from ZIP-delivered binaries > to be put into the WAR as simple resources. There is nothing special > with that content nor with that properties. I do not see that the > third party plugin is the problem here; the problem is solely the "ALL > zips go into the Java classpath" default policy, which simply is > wrong: Even if the third-party plugin is removed, still it ist he > Maven compiler plugin which fails when it assumes specific ZIP format. > > So there is no misusing dependencies at all. > > -Markus > > > -Ursprüngliche Nachricht- > Von: Tamás Cservenák > Gesendet: Freitag, 10. Juni 2022 13:15 > An: Maven Users List > Betreff: Re: Keeping dependency out of all classpaths > > Well, shoot in the dark: why is this ZIP a _dependency_ in the first place? > As you say "they solely serve as an input to third party plugins (not > dealing with Java at all)". If so, maybe the plugin needs improvement > itself, and allow it's configuration to pick up the zip that holds > resources needed/used by only itself, instead to "force" these inputs > through the whole build ONLY to be fed/found/used by that 3rd party plugin? > > IMO, the plugin in question should stop misusing project dependencies, > that again, if it is part of multi module build (so project > ordering/inter dependencies should remain correct), then yes, maven > should "know" about it, should be dependency, but then again the > plugin itself should declare custom packaging (my 1st mail), and that is the > proper solution IMO. > > T > > > On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg > wrote: > > > That might work, but my intention is not to play with arbitrary > > experimental PRs, but is to find a consensus, what such a future > > feature should look like to get it accepted by the Maven team. Is > > that specific PR agreed to get adopted to Maven 4? IIUC this PR > > stops adding ANY zips tot he classpath, but how to keep a specific > > one one > still? > > > &
AW: Keeping dependency out of all classpaths
It is a dependency because it shall be built with -am if this project is built, and it is consumed by this project using third party plugins. But it simply is not consumed by the Java toolchain. This has nothing to do with the plugin. The WAR produced here is built from Java source compiled to Java classes and from ZIP-delivered binaries to be put into the WAR as simple resources. There is nothing special with that content nor with that properties. I do not see that the third party plugin is the problem here; the problem is solely the "ALL zips go into the Java classpath" default policy, which simply is wrong: Even if the third-party plugin is removed, still it ist he Maven compiler plugin which fails when it assumes specific ZIP format. So there is no misusing dependencies at all. -Markus -Ursprüngliche Nachricht- Von: Tamás Cservenák Gesendet: Freitag, 10. Juni 2022 13:15 An: Maven Users List Betreff: Re: Keeping dependency out of all classpaths Well, shoot in the dark: why is this ZIP a _dependency_ in the first place? As you say "they solely serve as an input to third party plugins (not dealing with Java at all)". If so, maybe the plugin needs improvement itself, and allow it's configuration to pick up the zip that holds resources needed/used by only itself, instead to "force" these inputs through the whole build ONLY to be fed/found/used by that 3rd party plugin? IMO, the plugin in question should stop misusing project dependencies, that again, if it is part of multi module build (so project ordering/inter dependencies should remain correct), then yes, maven should "know" about it, should be dependency, but then again the plugin itself should declare custom packaging (my 1st mail), and that is the proper solution IMO. T On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg wrote: > That might work, but my intention is not to play with arbitrary > experimental PRs, but is to find a consensus, what such a future > feature should look like to get it accepted by the Maven team. Is that > specific PR agreed to get adopted to Maven 4? IIUC this PR stops > adding ANY zips tot he classpath, but how to keep a specific one one still? > > -Ursprüngliche Nachricht- > Von: Tamás Cservenák > Gesendet: Freitag, 10. Juni 2022 12:13 > An: Maven Users List > Betreff: Re: Keeping dependency out of all classpaths > > If you can use Maven4, try out this one: > https://github.com/apache/maven/pull/752 > > T > > On Fri, Jun 10, 2022 at 12:00 PM Tamás Cservenák > wrote: > > > I see. > > > > Well, as long as oracle Java doco says this: > > > > Class paths to the JAR, zip or class files. Each class path should > > end with a file name or directory depending on what you are setting > > the class path to, as follows: > > * For a JAR or zip file that contains class files, the class path > > ends with the name of the zip or JAR file. > > > > > > Maven should comply, no? Or could maven do something about "zip file > > that contains class files"? > > > > T > > > > On Fri, Jun 10, 2022 at 11:28 AM [Quipsy] Markus Karg > > > > wrote: > > > >> Thanks for the quick tip. > >> > >> While it might solve the actual problem I did have this morning, it > >> is neither a clean nor a general solution for everybody and for > >> always, as it still implies that all ZIPs shall go in the Java > >> classpath unless custom-packaged. Which means, possibly repackage > >> rather EACH ZIP, as least ZIPs shall go on the classpath in reality > >> (in 20+ years fulltime with Java I never wanted to add any ZIP to > >> the > Java classpath). > >> > >> In fact, the actual intention of this discussion is not how to make > >> my personal POM build right now (it in fact already does as I do > >> not have any tests, so I could go with runtime scope), but what I > >> want to reach is that we find a consensus how a clean and generic > >> solution should look like -- and propose that solution to the Maven > >> team. > >> > >> Thanks! > >> -Markus > >> > >> > >> -Ursprüngliche Nachricht- > >> Von: Tamás Cservenák > >> Gesendet: Freitag, 10. Juni 2022 11:13 > >> An: Maven Users List > >> Betreff: Re: Keeping dependency out of all classpaths > >> > >> Howdy, > >> > >> just a quick idea: introduce your own packaging "quipsy-zip"? (yes, > >> you'd need your extension to be added to build, but it's worth it, > trust me). > >> > >> Look here:
AW: Keeping dependency out of all classpaths
That might work, but my intention is not to play with arbitrary experimental PRs, but is to find a consensus, what such a future feature should look like to get it accepted by the Maven team. Is that specific PR agreed to get adopted to Maven 4? IIUC this PR stops adding ANY zips tot he classpath, but how to keep a specific one one still? -Ursprüngliche Nachricht- Von: Tamás Cservenák Gesendet: Freitag, 10. Juni 2022 12:13 An: Maven Users List Betreff: Re: Keeping dependency out of all classpaths If you can use Maven4, try out this one: https://github.com/apache/maven/pull/752 T On Fri, Jun 10, 2022 at 12:00 PM Tamás Cservenák wrote: > I see. > > Well, as long as oracle Java doco says this: > > Class paths to the JAR, zip or class files. Each class path should end > with a file name or directory depending on what you are setting the > class path to, as follows: > * For a JAR or zip file that contains class files, the class path > ends with the name of the zip or JAR file. > > > Maven should comply, no? Or could maven do something about "zip file > that contains class files"? > > T > > On Fri, Jun 10, 2022 at 11:28 AM [Quipsy] Markus Karg > wrote: > >> Thanks for the quick tip. >> >> While it might solve the actual problem I did have this morning, it >> is neither a clean nor a general solution for everybody and for >> always, as it still implies that all ZIPs shall go in the Java >> classpath unless custom-packaged. Which means, possibly repackage >> rather EACH ZIP, as least ZIPs shall go on the classpath in reality >> (in 20+ years fulltime with Java I never wanted to add any ZIP to the Java >> classpath). >> >> In fact, the actual intention of this discussion is not how to make >> my personal POM build right now (it in fact already does as I do not >> have any tests, so I could go with runtime scope), but what I want to >> reach is that we find a consensus how a clean and generic solution >> should look like -- and propose that solution to the Maven team. >> >> Thanks! >> -Markus >> >> >> -Ursprüngliche Nachricht- >> Von: Tamás Cservenák >> Gesendet: Freitag, 10. Juni 2022 11:13 >> An: Maven Users List >> Betreff: Re: Keeping dependency out of all classpaths >> >> Howdy, >> >> just a quick idea: introduce your own packaging "quipsy-zip"? (yes, >> you'd need your extension to be added to build, but it's worth it, trust me). >> >> Look here: >> >> https://github.com/apache/maven/blob/master/maven-artifact/src/main/j >> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L58 >> >> So, your packaging defines (name="quipsy-zip", extension="zip", >> addedToClasspath=false... it should work, and you'd depend on this >> zip as >> >> >> org.group >> artifact >> 1.0 >> quipsy-zip >> >> >> See >> >> https://medium.com/javarevisited/create-your-own-maven-packaging-2d69 >> ad832720 >> (note: if you are NOT building this ZIP with maven, then you do not >> need lifecycle mapping, only the ArtifactHandler ) >> >> >> https://github.com/apache/maven/blob/master/maven-artifact/src/main/j >> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31 >> >> >> HTH >> T >> >> >> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg >> >> wrote: >> >> > How can I keep a dependency out of all classpaths? >> > >> > I do have a dependency in my project that produces a ZIP full of >> > resources. None of those resources is actually of any use for the >> > Java compiler; they solely serve as an input to third party plugins >> > (not dealing with Java at all). Unfortunately the Maven Compiler >> > plugin sees that ZIP and tries to read it, leading to error >> > messages as the ZIP is in an "unexpected" format (for now let's >> > just say, it is intentionally incompatible). So the question is, >> > how to tell Maven to not put that dependency on ANY Java classpath? >> > >> > >> > 1. "runtime" Scope: compile is happy now, but test-compile still >> fails >> > 2. Moving the dependency from being a project dependency to >> > being a plugin-specific dependency: compile and test-compile are >> > happy now, but -am doesn't build the dependency anymore and >> > dependency:tree (and other >> > scanners) does not tell me about the existence oft hat dependency at all &g
AW: Keeping dependency out of all classpaths
I think the biggest problem actually ist hat Maven once was build with Java in mind, then developed to a cross-platform tool. Just because a ZIP is a ZIP does not tell us to put ALL zips on the classpath. Hence what we need is either a generic exclusion mechanism or a generic inclusion mechanism what goes on the classpath and what not. This is a Java-only problem, so the solution should be in the Java-specific plugins. I could imagine that a good solution would be to extend the compiler plugin with classpath-excludes accepting dependency coordinates. -Markus -Ursprüngliche Nachricht- Von: Tamás Cservenák Gesendet: Freitag, 10. Juni 2022 12:01 An: Maven Users List Betreff: Re: Keeping dependency out of all classpaths I see. Well, as long as oracle Java doco says this: Class paths to the JAR, zip or class files. Each class path should end with a file name or directory depending on what you are setting the class path to, as follows: * For a JAR or zip file that contains class files, the class path ends with the name of the zip or JAR file. Maven should comply, no? Or could maven do something about "zip file that contains class files"? T On Fri, Jun 10, 2022 at 11:28 AM [Quipsy] Markus Karg wrote: > Thanks for the quick tip. > > While it might solve the actual problem I did have this morning, it is > neither a clean nor a general solution for everybody and for always, > as it still implies that all ZIPs shall go in the Java classpath > unless custom-packaged. Which means, possibly repackage rather EACH > ZIP, as least ZIPs shall go on the classpath in reality (in 20+ years > fulltime with Java I never wanted to add any ZIP to the Java classpath). > > In fact, the actual intention of this discussion is not how to make my > personal POM build right now (it in fact already does as I do not have > any tests, so I could go with runtime scope), but what I want to reach > is that we find a consensus how a clean and generic solution should > look like -- and propose that solution to the Maven team. > > Thanks! > -Markus > > > -Ursprüngliche Nachricht- > Von: Tamás Cservenák > Gesendet: Freitag, 10. Juni 2022 11:13 > An: Maven Users List > Betreff: Re: Keeping dependency out of all classpaths > > Howdy, > > just a quick idea: introduce your own packaging "quipsy-zip"? (yes, > you'd need your extension to be added to build, but it's worth it, trust me). > > Look here: > > https://github.com/apache/maven/blob/master/maven-artifact/src/main/ja > va/org/apache/maven/artifact/handler/ArtifactHandler.java#L58 > > So, your packaging defines (name="quipsy-zip", extension="zip", > addedToClasspath=false... it should work, and you'd depend on this > zip as > > > org.group > artifact > 1.0 > quipsy-zip > > > See > > https://medium.com/javarevisited/create-your-own-maven-packaging-2d69a > d832720 > (note: if you are NOT building this ZIP with maven, then you do not > need lifecycle mapping, only the ArtifactHandler ) > > > https://github.com/apache/maven/blob/master/maven-artifact/src/main/ja > va/org/apache/maven/artifact/handler/ArtifactHandler.java#L31 > > > HTH > T > > > On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg > wrote: > > > How can I keep a dependency out of all classpaths? > > > > I do have a dependency in my project that produces a ZIP full of > > resources. None of those resources is actually of any use for the > > Java compiler; they solely serve as an input to third party plugins > > (not dealing with Java at all). Unfortunately the Maven Compiler > > plugin sees that ZIP and tries to read it, leading to error messages > > as the ZIP is in an "unexpected" format (for now let's just say, it > > is intentionally incompatible). So the question is, how to tell > > Maven to not put that dependency on ANY Java classpath? > > > > > > 1. "runtime" Scope: compile is happy now, but test-compile still fails > > 2. Moving the dependency from being a project dependency to being > > a plugin-specific dependency: compile and test-compile are happy > > now, but -am doesn't build the dependency anymore and > > dependency:tree (and other > > scanners) does not tell me about the existence oft hat dependency at all > > 3. "resource" Scope: would be exactly what I like to do, but > > Maven does not have such a scope: compile and test-compile would be > > happy, and -am still would build the dependency just like other > > scanners it would still see the dependency > > > > In the end, the big
AW: Keeping dependency out of all classpaths
Thanks for the quick tip. While it might solve the actual problem I did have this morning, it is neither a clean nor a general solution for everybody and for always, as it still implies that all ZIPs shall go in the Java classpath unless custom-packaged. Which means, possibly repackage rather EACH ZIP, as least ZIPs shall go on the classpath in reality (in 20+ years fulltime with Java I never wanted to add any ZIP to the Java classpath). In fact, the actual intention of this discussion is not how to make my personal POM build right now (it in fact already does as I do not have any tests, so I could go with runtime scope), but what I want to reach is that we find a consensus how a clean and generic solution should look like -- and propose that solution to the Maven team. Thanks! -Markus -Ursprüngliche Nachricht- Von: Tamás Cservenák Gesendet: Freitag, 10. Juni 2022 11:13 An: Maven Users List Betreff: Re: Keeping dependency out of all classpaths Howdy, just a quick idea: introduce your own packaging "quipsy-zip"? (yes, you'd need your extension to be added to build, but it's worth it, trust me). Look here: https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L58 So, your packaging defines (name="quipsy-zip", extension="zip", addedToClasspath=false... it should work, and you'd depend on this zip as org.group artifact 1.0 quipsy-zip See https://medium.com/javarevisited/create-your-own-maven-packaging-2d69ad832720 (note: if you are NOT building this ZIP with maven, then you do not need lifecycle mapping, only the ArtifactHandler ) https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L31 HTH T On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg wrote: > How can I keep a dependency out of all classpaths? > > I do have a dependency in my project that produces a ZIP full of > resources. None of those resources is actually of any use for the Java > compiler; they solely serve as an input to third party plugins (not > dealing with Java at all). Unfortunately the Maven Compiler plugin > sees that ZIP and tries to read it, leading to error messages as the > ZIP is in an "unexpected" format (for now let's just say, it is > intentionally incompatible). So the question is, how to tell Maven to > not put that dependency on ANY Java classpath? > > > 1. "runtime" Scope: compile is happy now, but test-compile still fails > 2. Moving the dependency from being a project dependency to being a > plugin-specific dependency: compile and test-compile are happy now, > but -am doesn't build the dependency anymore and dependency:tree (and > other > scanners) does not tell me about the existence oft hat dependency at all > 3. "resource" Scope: would be exactly what I like to do, but Maven > does not have such a scope: compile and test-compile would be happy, > and -am still would build the dependency just like other scanners it > would still see the dependency > > In the end, the bigger question actually is, how to tell ANY plugin to > ignore particular dependencies of my POM? Just because my project is > of type WAR does not mean that EVERYTING it depends upon shall be > processed by the Java toolchain... Maybe it would be better if the > Maven Compiler Plugin JUST puts those dependencies on the classpath that > actually are JARs...? > > Thanks a lot! > -Markus > >
Keeping dependency out of all classpaths
How can I keep a dependency out of all classpaths? I do have a dependency in my project that produces a ZIP full of resources. None of those resources is actually of any use for the Java compiler; they solely serve as an input to third party plugins (not dealing with Java at all). Unfortunately the Maven Compiler plugin sees that ZIP and tries to read it, leading to error messages as the ZIP is in an "unexpected" format (for now let's just say, it is intentionally incompatible). So the question is, how to tell Maven to not put that dependency on ANY Java classpath? 1. "runtime" Scope: compile is happy now, but test-compile still fails 2. Moving the dependency from being a project dependency to being a plugin-specific dependency: compile and test-compile are happy now, but -am doesn't build the dependency anymore and dependency:tree (and other scanners) does not tell me about the existence oft hat dependency at all 3. "resource" Scope: would be exactly what I like to do, but Maven does not have such a scope: compile and test-compile would be happy, and -am still would build the dependency just like other scanners it would still see the dependency In the end, the bigger question actually is, how to tell ANY plugin to ignore particular dependencies of my POM? Just because my project is of type WAR does not mean that EVERYTING it depends upon shall be processed by the Java toolchain... Maybe it would be better if the Maven Compiler Plugin JUST puts those dependencies on the classpath that actually are JARs...? Thanks a lot! -Markus
AW: Maven Dependency Plugin
Thank you for this information. It is a bit misleading that the line says "as introduced" (past tense) for a release that actually does not exist yet. Would it be OK if I file a PR to clarify that? What is the anticipated release date of Maven 3.7.0 that I could announce there? -Markus -Ursprüngliche Nachricht- Von: John Patrick Gesendet: Montag, 26. Oktober 2020 12:07 An: Maven Users List Betreff: Re: Maven Dependency Plugin If you read the opening line it talks about Maven 3.7.0, which is not yet released. If you want to use a maven wrapper before v3.7.0, then use this https://github.com/takari/maven-wrapper. The upgrade from takari to maven is easy but does allow you to change your documentation, process and ci process instead of waiting until v3.7.0. I did test the maven-wrapper-plugin a few months ago and I had to add a staging repo of something like this before it worked https://repository.apache.org/service/local/repositories/maven-XXX/content/. But can't remember what XXX it was as I've got ~10 in my settings.xml commented out. John On Mon, 26 Oct 2020 at 10:53, Markus Karg wrote: > > When I am using this plugin > https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails > because it apparently cannot find needed runtime files on Maven Central. This > limitation is not told on that page. Is that a bug or am I doing something > wrong? > -Markus > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Dependency Plugin
When I am using this plugin https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails because it apparently cannot find needed runtime files on Maven Central. This limitation is not told on that page. Is that a bug or am I doing something wrong? -Markus
mvn dependency:purge-local-repository fails to resolve, but subsequent mvn dependency:go-offline succeeds
Using Maven since 10+ years, we have a strange problem with MVN 3.5.0. What we want to achieve is to ensure that all dependencies are latest version, even if somebody did a bad thing and replaced a release version in Nexus. So we type: mvn dependency:purge-local-repository This fails to re-resolve some of the artifacts in our POM (but not specific artifacts; always different ones!). But when we then (yes, directly subsequent) type: mvn dependency:go-offline it perfectly re-resolves and downloads everything -yes, even the failing ones- from Nexus. This is driving us nuts! Is that a bug or are we completely misunderstanding the concept of these commands? -Markus
RE: java import package and maven dependencies
Sorry I have no experience with IntelliJ, as I solely use Eclipse. -Original Message- From: Lin Ma [mailto:lin...@gmail.com] Sent: Montag, 23. März 2015 23:05 To: Maven Users List Subject: Re: java import package and maven dependencies Thanks Markus, Do you know on IntelliJ, how to see Maven update Classpath and settings in IntelliJ how Classpath by Maven is prioritized among other Jars/paths on Classpath? regards, Lin On Mon, Mar 23, 2015 at 2:07 AM, Markus Karg k...@quipsy.de wrote: With at runtime I mean when Eclipse is performing the 'organize import' functionality or its various variants. -Ursprüngliche Nachricht- Von: Lin Ma [mailto:lin...@gmail.com] Gesendet: Montag, 23. März 2015 08:59 An: Maven Users List Betreff: Re: java import package and maven dependencies Thanks Markus, For at runtime, I think you do not mean when running the Java application, but when we add a new dependency in pom.xml, Maven will download the dependency and add the JAR into Classpath which Eclipse will recognize? -- so that the import package statements could be recognized and resolved in IDE? regards, Lin On Mon, Mar 23, 2015 at 12:29 AM, Markus Karg k...@quipsy.de wrote: Lin, there is no magic involved. Maven produces a Class Path at runtime made up from the declared dependencies in the effective POM (i. e. your explicit POM and any explicit and implicit parent POMs, and any implied POMs due to dependencies). Eclipse uses that Class Path as part of the one it constructs on its own, you even can tell Eclipse the rank where to put the Maven Classpath relatively to siblings. Eclipse just checks all Classes in the Classpath for name equality, picks the sole match automatically, or provides a list of possible matches for the user to pick from. That's all. Pretty simple and straightforward, and everything but magic. Regards -Markus -Ursprüngliche Nachricht- Von: Lin Ma [mailto:lin...@gmail.com] Gesendet: Montag, 23. März 2015 06:24 An: Maven Users List Betreff: java import package and maven dependencies Hi Maven masters, It is magic when we add dependencies in Maven pom.xml, IDE like IntelliJ could resolve it for java import package statement at the beginning of each .java file. Want to learn a bit more how Maven or IDE will use dependencies in Maven pom.xml file to resolve import package in .java file automatically? Does it on the backend download and put the jar in dependencies in class path, and treat it the same as manually add an external jar file? Any good articles are appreciated. thanks in advance, Lin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: java import package and maven dependencies
Lin, there is no magic involved. Maven produces a Class Path at runtime made up from the declared dependencies in the effective POM (i. e. your explicit POM and any explicit and implicit parent POMs, and any implied POMs due to dependencies). Eclipse uses that Class Path as part of the one it constructs on its own, you even can tell Eclipse the rank where to put the Maven Classpath relatively to siblings. Eclipse just checks all Classes in the Classpath for name equality, picks the sole match automatically, or provides a list of possible matches for the user to pick from. That's all. Pretty simple and straightforward, and everything but magic. Regards -Markus -Ursprüngliche Nachricht- Von: Lin Ma [mailto:lin...@gmail.com] Gesendet: Montag, 23. März 2015 06:24 An: Maven Users List Betreff: java import package and maven dependencies Hi Maven masters, It is magic when we add dependencies in Maven pom.xml, IDE like IntelliJ could resolve it for java import package statement at the beginning of each .java file. Want to learn a bit more how Maven or IDE will use dependencies in Maven pom.xml file to resolve import package in .java file automatically? Does it on the backend download and put the jar in dependencies in class path, and treat it the same as manually add an external jar file? Any good articles are appreciated. thanks in advance, Lin
AW: java import package and maven dependencies
With at runtime I mean when Eclipse is performing the 'organize import' functionality or its various variants. -Ursprüngliche Nachricht- Von: Lin Ma [mailto:lin...@gmail.com] Gesendet: Montag, 23. März 2015 08:59 An: Maven Users List Betreff: Re: java import package and maven dependencies Thanks Markus, For at runtime, I think you do not mean when running the Java application, but when we add a new dependency in pom.xml, Maven will download the dependency and add the JAR into Classpath which Eclipse will recognize? -- so that the import package statements could be recognized and resolved in IDE? regards, Lin On Mon, Mar 23, 2015 at 12:29 AM, Markus Karg k...@quipsy.de wrote: Lin, there is no magic involved. Maven produces a Class Path at runtime made up from the declared dependencies in the effective POM (i. e. your explicit POM and any explicit and implicit parent POMs, and any implied POMs due to dependencies). Eclipse uses that Class Path as part of the one it constructs on its own, you even can tell Eclipse the rank where to put the Maven Classpath relatively to siblings. Eclipse just checks all Classes in the Classpath for name equality, picks the sole match automatically, or provides a list of possible matches for the user to pick from. That's all. Pretty simple and straightforward, and everything but magic. Regards -Markus -Ursprüngliche Nachricht- Von: Lin Ma [mailto:lin...@gmail.com] Gesendet: Montag, 23. März 2015 06:24 An: Maven Users List Betreff: java import package and maven dependencies Hi Maven masters, It is magic when we add dependencies in Maven pom.xml, IDE like IntelliJ could resolve it for java import package statement at the beginning of each .java file. Want to learn a bit more how Maven or IDE will use dependencies in Maven pom.xml file to resolve import package in .java file automatically? Does it on the backend download and put the jar in dependencies in class path, and treat it the same as manually add an external jar file? Any good articles are appreciated. thanks in advance, Lin
AW: AW: mvn clean package requests access rights for local Nexus repository
As I said I cannot reproduce the bug anymore, so do you think the requested test makes any sense still? -Ursprüngliche Nachricht- Von: Martin Gainty [mailto:mgai...@hotmail.com] Gesendet: Donnerstag, 19. März 2015 02:04 An: users@maven.apache.org Betreff: RE: AW: mvn clean package requests access rights for local Nexus repository as bernd suggested can you view possible access when you enable -X? might also help to see extension errors with -e mvn -e -X package package.out can we view package.out? I would be interested looking at the netstat deltas specifically shnetstat -a netstat_before.log run command shmvn -X package run another shell and view any new network connections netstat -a netstat_after.log any deltas between netstat_before.log and netstat_after.log can you display both here so we can diff the 2 files? ? Martin From: k...@quipsy.de To: users@maven.apache.org Date: Wed, 18 Mar 2015 16:42:06 +0100 Subject: AW: mvn clean package requests access rights for local Nexus repository Bernd, your theory failed the test: * Unplugged USB stick, so Maven has no passwords anymore * Removed .m2\repository folder from disk, so Maven is enforced to download rather everything newly from our Nexus mirror * mvn clean package built maven-dependency-plugin without any problem Conclusion: It is definitively NOT a download problem, but still supports my theory that maven-dependency-plugin wants to UPLOAD something at package phase. If I just would have kept the protocol earlier today, I could tell you what thing actually it was... :-( Regards -Markus -Ursprüngliche Nachricht- Von: Bernd [mailto:e...@zusammenkunft.net] Gesendet: Mittwoch, 18. März 2015 14:27 An: Maven Users List Betreff: Re: mvn clean package requests access rights for local Nexus repository Hello, It sounds more like a download as it does not ask again. You can wipe your local repo cache (or use a different one in settings.xml) and try to reproduce the problem. If you run with -X and actually keep the maven log output you should be able to see the access in question. Gruss Bernd Am 18.03.2015 14:02 schrieb Markus Karg k...@quipsy.de: Dear Maven Experts, just did svn checkout to get trunk of maven-dependency-plugin, and wanted to build it using mvn clean package. What then happened is really scary: * It complained about missing access on that path where my USB stick stores the encrypted password for my local Nexus repository. * My local Nexus repository is a mirror of central with public access, only demanding passwords for uploads. * I plugged in my stick, did mvn clean package again, and it worked pretty well. * REMOVED my stick, and since then mvn clean package works without, still! That looks if packaging maven-dependency-plugin would need to WRITE into my Nexus (possibly central?) at package phase, if a particular thing is not found there. This is scary, as nobody expects UPLOADS are done at packaging. If somebody has an explanation why that happens, I'd ask him to publish here, so everybody will understand the reason for this! :) Regards -Markus B KKK KCB [ X ܚX KK[XZ[ \ \ ][ X ܚX PX] [ \X K ܙ B ܈Y][ ۘ[ [X[ K[XZ[ \ \ Z[ X] [ \X K ܙ B - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn clean package requests access rights for local Nexus repository
Dear Maven Experts, just did svn checkout to get trunk of maven-dependency-plugin, and wanted to build it using mvn clean package. What then happened is really scary: * It complained about missing access on that path where my USB stick stores the encrypted password for my local Nexus repository. * My local Nexus repository is a mirror of central with public access, only demanding passwords for uploads. * I plugged in my stick, did mvn clean package again, and it worked pretty well. * REMOVED my stick, and since then mvn clean package works without, still! That looks if packaging maven-dependency-plugin would need to WRITE into my Nexus (possibly central?) at package phase, if a particular thing is not found there. This is scary, as nobody expects UPLOADS are done at packaging. If somebody has an explanation why that happens, I'd ask him to publish here, so everybody will understand the reason for this! :) Regards -Markus
AW: mvn clean package requests access rights for local Nexus repository
Bernd, your theory failed the test: * Unplugged USB stick, so Maven has no passwords anymore * Removed .m2\repository folder from disk, so Maven is enforced to download rather everything newly from our Nexus mirror * mvn clean package built maven-dependency-plugin without any problem Conclusion: It is definitively NOT a download problem, but still supports my theory that maven-dependency-plugin wants to UPLOAD something at package phase. If I just would have kept the protocol earlier today, I could tell you what thing actually it was... :-( Regards -Markus -Ursprüngliche Nachricht- Von: Bernd [mailto:e...@zusammenkunft.net] Gesendet: Mittwoch, 18. März 2015 14:27 An: Maven Users List Betreff: Re: mvn clean package requests access rights for local Nexus repository Hello, It sounds more like a download as it does not ask again. You can wipe your local repo cache (or use a different one in settings.xml) and try to reproduce the problem. If you run with -X and actually keep the maven log output you should be able to see the access in question. Gruss Bernd Am 18.03.2015 14:02 schrieb Markus Karg k...@quipsy.de: Dear Maven Experts, just did svn checkout to get trunk of maven-dependency-plugin, and wanted to build it using mvn clean package. What then happened is really scary: * It complained about missing access on that path where my USB stick stores the encrypted password for my local Nexus repository. * My local Nexus repository is a mirror of central with public access, only demanding passwords for uploads. * I plugged in my stick, did mvn clean package again, and it worked pretty well. * REMOVED my stick, and since then mvn clean package works without, still! That looks if packaging maven-dependency-plugin would need to WRITE into my Nexus (possibly central?) at package phase, if a particular thing is not found there. This is scary, as nobody expects UPLOADS are done at packaging. If somebody has an explanation why that happens, I'd ask him to publish here, so everybody will understand the reason for this! :) Regards -Markus
AW: How to configure maven-dependency-plugin's encoding used for unpack?
No I have never heard of vfs-maven-plugin before, and I doubt it will be an easy solution, as the download address is not known in the POM -- it is a DEPENDENCY, hence the dependency resolution mechanism has to be used. -Ursprüngliche Nachricht- Von: Andreas Gudian [mailto:andreas.gud...@gmail.com] Gesendet: Dienstag, 17. März 2015 20:20 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? Markus, as for an ASAP quick fix, did you try using the vfs-maven-plugin to unpack your zip files? I don't fully understand your usecase, but I use that one to download and unpack zip files within a maven build. 2015-03-17 13:34 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com : I can guarantee a timely review, which is about as much as we guarantee around here :) There is a practical issue, since maven assembly plugin uses a parameter called archiverConfig configure the Archiver. I am still pondering if for assembly I should supply the *same* config object or create a separate one called unarchiverConfig. The same would apply for dependency plugin, since we'd definitely want this to be done in the same manner. Kristian 2015-03-17 9:49 GMT+01:00 Markus Karg k...@quipsy.de: Great, thanks a lot! :-) But let's negotiate one thing upfront: If we provide code that adds encoding to maven-dependency-plugin's configuration, which essentially forwards the encoding to the Plexus Unarchiver, and it looks good to you from a technical view, will you guarantee us that it will definitively up in the plugin? I have to ask that upfront because of the discussion going on here currently about the general usefulness of encodings and we must not spend any time into providing code if it ends up in the trash due to different opinions within the pluging management team. So if you can ensure this, we will lookup some people coding the solution. Thanks! -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Dienstag, 17. März 2015 08:39 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I'm not kidding about anything. I reopened the issue. If you make a patch that applies encoding to zip files I can review that. Kristian 2015-03-17 8:27 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, you're kidding, don't you? ;-) what you propose does not work. We are an ISV providing a download for virtually anybody. We cannot tell the world Hey, you cannot simply use Windows to unzip, but you must first download some other application, because we're using Maven, and it is unable to deal with encodings.. :-( We are NOT packaging a jar file. We are packaging a zip file. In fact I never mentioned jar AFAIK. That one is publicly downloadable. Some team told us they use that zip as a dependency and need to unpack it as part of their prepare-package phase (they only need some files, not the full zip). At that moment, then file names are turned into garbage. If there is headroom, then let's use that headroom. All we demand is a way to tell in the POM that the plexus zip unarchiver used by maven-dependency-plugin for that single artifactItem shall use CP850. :-) I'm talking about http://jira.codehaus.org/browse/MDEP-436 Thank you for your kind help. Regards -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 21:19 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? There is no way to specify unarchiver encoding in the dependency plugin, I have checked. So currently you have to make your users install a less brain dead zip program than the windows compressed folder mechanism. I am also slightly questioning of what you are trying to achieve here; if you are unpacking a jar file then it *will* and *should* be UTF8, meaning you cannot use the lobotomized zip support that is included in windows, no matter what. I don't see us fixing /that/ issue, since we'd be violating the jar specification. If your dependency is to an actual zip file, we have slightly more headroom, and such a patch might be applied. I am not sure which issue you are referring to, I know there is one for assembly-plugin (http://jira.codehaus.org/browse/MASSEMBLY-748) since the encoding feature should be fixed to work for unpack too. Kristian 2015-03-16 15:04 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so
AW: How to configure maven-dependency-plugin's encoding used for unpack?
My posting was an example why non-UTF-8-ZIPs are needed to be supported by maven-dependency-plugin. It was definitively not intended as a claim that all Windows editions exactly need CP850. Sorry for the misunderstanding. -Ursprüngliche Nachricht- Von: bmat...@gmail.com [mailto:bmat...@gmail.com] Im Auftrag von Baptiste Mathus Gesendet: Dienstag, 17. März 2015 06:40 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? And this is actually not even always true, CP1252 is also often used on Windows (in France for example). Encoding is actually a quite simple problem, but transfer makes it difficult to handle as each move has to take care of what it does. As for the JIRA tickets, if you feel this is not OK, feel free to comment/reopen/create the ones you want. But also beware that without a patch, in that very specific situation, it's not very likely someone else will spend time to fix it. HTH Cheers 2015-03-16 15:04 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so people on the Windows world will virtually every create CP850-ZIPs! Do you know about any plans to support this, or what is the intended future of this issue? Thanks -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 13:46 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I did not actually look at the implementation on the dependency plugin, but it is actually technically impossible to supply the encoding parameter to *unzip* via the archiverConfig tag. So until this is fixed, UTF-8 zip archives are the only ones that will work (with plexus unzip archiver). Kristian 2015-03-16 13:05 GMT+01:00 Adrien Rivard adrien.riv...@gmail.com: If I'm reading the documentation correctly, archiverConfigencoding only apply to filter resources, not to zip them. In any case I would try using utf-8. On Mon, Mar 16, 2015 at 12:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I dont believe there is support for specifying encoding to unzip. At least assembly only provides config to zip. Call it a bug, call it a feature :( Kristian 2015-03-16 12:12 GMT+01:00 Markus Karg k...@quipsy.de: To preserve German umlauts in file names within a ZIP, we are using... archiverConfig encodingCP850/encoding /archiverConfig ...in the maven-assembly-plugin configuration, which is working well. :) Next we want to use maven-dependency-plugin to unpack that ZIP. How can we configure maven-dependency-plugin:unpack so it will apply CP850 when unpacking that ZIP? Thanks! -Markus -- Adrien Rivard -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: How to configure maven-dependency-plugin's encoding used for unpack?
The ASSEMBLY plugin forwards its own encoding to the Plexus Archiver internally. That way you can create ZIPs with CP850. :-) The DEPENDENCY plugin intenrally uses the Plexus ZipUnarchiver. The Plexus ZipUnarchiver is a special form of the AbstractUnarchiver, which has a method setEncoding(String) (http://plexus.codehaus.org/plexus-components/plexus-archiver/apidocs/org/codehaus/plexus/archiver/zip/AbstractZipUnArchiver.html#setEncoding(java.lang.String) ). But the dependency plugin has no encoding to forwards to the Plexus ZipArchiver to make use it this. :-( -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 20:25 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I don't really see that the dependency plugin has any support for encoding in pack or unpack. Where did you see that ? Kristian 2015-03-16 15:04 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so people on the Windows world will virtually every create CP850-ZIPs! Do you know about any plans to support this, or what is the intended future of this issue? Thanks -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 13:46 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I did not actually look at the implementation on the dependency plugin, but it is actually technically impossible to supply the encoding parameter to *unzip* via the archiverConfig tag. So until this is fixed, UTF-8 zip archives are the only ones that will work (with plexus unzip archiver). Kristian 2015-03-16 13:05 GMT+01:00 Adrien Rivard adrien.riv...@gmail.com: If I'm reading the documentation correctly, archiverConfigencoding only apply to filter resources, not to zip them. In any case I would try using utf-8. On Mon, Mar 16, 2015 at 12:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I dont believe there is support for specifying encoding to unzip. At least assembly only provides config to zip. Call it a bug, call it a feature :( Kristian 2015-03-16 12:12 GMT+01:00 Markus Karg k...@quipsy.de: To preserve German umlauts in file names within a ZIP, we are using... archiverConfig encodingCP850/encoding /archiverConfig ...in the maven-assembly-plugin configuration, which is working well. :) Next we want to use maven-dependency-plugin to unpack that ZIP. How can we configure maven-dependency-plugin:unpack so it will apply CP850 when unpacking that ZIP? Thanks! -Markus -- Adrien Rivard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: How to configure maven-dependency-plugin's encoding used for unpack?
Hervé, can you please elaborate for non-committers like me: (a) Why shall I open another issue that contains essentially the same text as the already-existing and non-fixed-but-marked-as-resolved one http://jira.codehaus.org/browse/MDEP-436 ? The result would be the same: Kristian assumes it is fixed, and again closes it. So what do we gain ? (b) Why adding a new configuration property encoding to maven-dependency-plugin's configuration would (even hypothetically) break anything ? (c) What you assume how anybody should be able to use maven-dependency-plugin's unpack target on CP850-ZIPs ? Just to make me understand. :-) Thanks -Markus -Ursprüngliche Nachricht- Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] Gesendet: Dienstag, 17. März 2015 08:36 An: Maven Users List Betreff: Re: AW: How to configure maven-dependency-plugin's encoding used for unpack? Le mardi 17 mars 2015 08:19:20 Markus Karg a écrit : (1) Normal users (non-comitters) do not have permission to reopen issues so I really beg for your kind help to reopen this issue for me! :-) no, please don't reopen the issue: open another issue (2) Despite all the quirks of Windows, the ZIP specification does not say a word about encoding, we had the discussion on dev@ mailing list in october and we based our decision partly on PKWARE's old documentation see http://mail-archives.apache.org/mod_mbox/maven-dev/201410.mbox/%3C1632789.Hzz1ElkyQm%40herve-desktop%3E so it is pretty correct to use any decoding in ZIPs. As a consequence, maven-dependency-plugin MUST either be able to detect the encoding OR MUST have configurable encoding (plexus unarchiver already provides setEncoding BTW). I actually do not understand the discussion about this. I have such ZIPs, these are compliant with the ZIP specification, please provide the Zip specifications you're referring to: having a common reference is the first problem we faced, ie we could not find any shared reference and maven-dependency-plugin cannot handle it. So instead of complaining about Windows being quirky wouldn't it make more sense to simply provide maven-dependency-plugin the same encoding option that maven-assembly-plugin already has? I mean, that would be straightforward, simple to implement, pragmatic and would actually help us (we are stuck with this!) while discussions about Windows do not. ;-) I suppose there are multiple zip encoders and decoders on every platform: the problem is with some decoders, IIUC, not the whole platform that executes it Maybe there is a trick so one can configure plexus unarchiver's setEncoding via the POM, but we simply don't know how to do that. So if you know that trick, then please share your knowledge with us. We do not insist on a fix for the plugin, but we really need a solution ASAP! :-) given the problem on shared zip structure reference, we really fear that fixing the issue for one user will break the other one, using another zip decoder Regards, Hervé Thanks a lot! -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Dienstag, 17. März 2015 07:06 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? This is really only a question about the borked zip file explorer that is default in windows. Quality zip clients always works fine on Windows. The miserable story is documented entirely at http://commons.apache.org/proper/commons-compress/zip.html#Encoding and is an enjoyable read for anyone who wants the full story :) For the assembly plugin I have scheduled http://jira.codehaus.org/browse/MASSEMBLY-748 for the next release, which should be soonish. For the dependency plugin I am still not convinced that this should be supported. Unlike the ZIP specification, the Jar specification is crystal clear on UTF-8 only, which means we'd be breaking something that is not broken. Kristian 2015-03-17 6:39 GMT+01:00 Baptiste Mathus bmat...@batmat.net: And this is actually not even always true, CP1252 is also often used on Windows (in France for example). Encoding is actually a quite simple problem, but transfer makes it difficult to handle as each move has to take care of what it does. As for the JIRA tickets, if you feel this is not OK, feel free to comment/reopen/create the ones you want. But also beware that without a patch, in that very specific situation, it's not very likely someone else will spend time to fix it. HTH Cheers 2015-03-16 15:04 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so people on the Windows world will virtually every create CP850
AW: How to configure maven-dependency-plugin's encoding used for unpack?
Kristian, you're kidding, don't you? ;-) what you propose does not work. We are an ISV providing a download for virtually anybody. We cannot tell the world Hey, you cannot simply use Windows to unzip, but you must first download some other application, because we're using Maven, and it is unable to deal with encodings.. :-( We are NOT packaging a jar file. We are packaging a zip file. In fact I never mentioned jar AFAIK. That one is publicly downloadable. Some team told us they use that zip as a dependency and need to unpack it as part of their prepare-package phase (they only need some files, not the full zip). At that moment, then file names are turned into garbage. If there is headroom, then let's use that headroom. All we demand is a way to tell in the POM that the plexus zip unarchiver used by maven-dependency-plugin for that single artifactItem shall use CP850. :-) I'm talking about http://jira.codehaus.org/browse/MDEP-436 Thank you for your kind help. Regards -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 21:19 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? There is no way to specify unarchiver encoding in the dependency plugin, I have checked. So currently you have to make your users install a less brain dead zip program than the windows compressed folder mechanism. I am also slightly questioning of what you are trying to achieve here; if you are unpacking a jar file then it *will* and *should* be UTF8, meaning you cannot use the lobotomized zip support that is included in windows, no matter what. I don't see us fixing /that/ issue, since we'd be violating the jar specification. If your dependency is to an actual zip file, we have slightly more headroom, and such a patch might be applied. I am not sure which issue you are referring to, I know there is one for assembly-plugin (http://jira.codehaus.org/browse/MASSEMBLY-748) since the encoding feature should be fixed to work for unpack too. Kristian 2015-03-16 15:04 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so people on the Windows world will virtually every create CP850-ZIPs! Do you know about any plans to support this, or what is the intended future of this issue? Thanks -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 13:46 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I did not actually look at the implementation on the dependency plugin, but it is actually technically impossible to supply the encoding parameter to *unzip* via the archiverConfig tag. So until this is fixed, UTF-8 zip archives are the only ones that will work (with plexus unzip archiver). Kristian 2015-03-16 13:05 GMT+01:00 Adrien Rivard adrien.riv...@gmail.com: If I'm reading the documentation correctly, archiverConfigencoding only apply to filter resources, not to zip them. In any case I would try using utf-8. On Mon, Mar 16, 2015 at 12:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I dont believe there is support for specifying encoding to unzip. At least assembly only provides config to zip. Call it a bug, call it a feature :( Kristian 2015-03-16 12:12 GMT+01:00 Markus Karg k...@quipsy.de: To preserve German umlauts in file names within a ZIP, we are using... archiverConfig encodingCP850/encoding /archiverConfig ...in the maven-assembly-plugin configuration, which is working well. :) Next we want to use maven-dependency-plugin to unpack that ZIP. How can we configure maven-dependency-plugin:unpack so it will apply CP850 when unpacking that ZIP? Thanks! -Markus -- Adrien Rivard
AW: How to configure maven-dependency-plugin's encoding used for unpack?
Great, thanks a lot! :-) But let's negotiate one thing upfront: If we provide code that adds encoding to maven-dependency-plugin's configuration, which essentially forwards the encoding to the Plexus Unarchiver, and it looks good to you from a technical view, will you guarantee us that it will definitively up in the plugin? I have to ask that upfront because of the discussion going on here currently about the general usefulness of encodings and we must not spend any time into providing code if it ends up in the trash due to different opinions within the pluging management team. So if you can ensure this, we will lookup some people coding the solution. Thanks! -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Dienstag, 17. März 2015 08:39 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I'm not kidding about anything. I reopened the issue. If you make a patch that applies encoding to zip files I can review that. Kristian 2015-03-17 8:27 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, you're kidding, don't you? ;-) what you propose does not work. We are an ISV providing a download for virtually anybody. We cannot tell the world Hey, you cannot simply use Windows to unzip, but you must first download some other application, because we're using Maven, and it is unable to deal with encodings.. :-( We are NOT packaging a jar file. We are packaging a zip file. In fact I never mentioned jar AFAIK. That one is publicly downloadable. Some team told us they use that zip as a dependency and need to unpack it as part of their prepare-package phase (they only need some files, not the full zip). At that moment, then file names are turned into garbage. If there is headroom, then let's use that headroom. All we demand is a way to tell in the POM that the plexus zip unarchiver used by maven-dependency-plugin for that single artifactItem shall use CP850. :-) I'm talking about http://jira.codehaus.org/browse/MDEP-436 Thank you for your kind help. Regards -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 21:19 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? There is no way to specify unarchiver encoding in the dependency plugin, I have checked. So currently you have to make your users install a less brain dead zip program than the windows compressed folder mechanism. I am also slightly questioning of what you are trying to achieve here; if you are unpacking a jar file then it *will* and *should* be UTF8, meaning you cannot use the lobotomized zip support that is included in windows, no matter what. I don't see us fixing /that/ issue, since we'd be violating the jar specification. If your dependency is to an actual zip file, we have slightly more headroom, and such a patch might be applied. I am not sure which issue you are referring to, I know there is one for assembly-plugin (http://jira.codehaus.org/browse/MASSEMBLY-748) since the encoding feature should be fixed to work for unpack too. Kristian 2015-03-16 15:04 GMT+01:00 Markus Karg k...@quipsy.de: Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so people on the Windows world will virtually every create CP850-ZIPs! Do you know about any plans to support this, or what is the intended future of this issue? Thanks -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 13:46 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I did not actually look at the implementation on the dependency plugin, but it is actually technically impossible to supply the encoding parameter to *unzip* via the archiverConfig tag. So until this is fixed, UTF-8 zip archives are the only ones that will work (with plexus unzip archiver). Kristian 2015-03-16 13:05 GMT+01:00 Adrien Rivard adrien.riv...@gmail.com: If I'm reading the documentation correctly, archiverConfigencoding only apply to filter resources, not to zip them. In any case I would try using utf-8. On Mon, Mar 16, 2015 at 12:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I dont believe there is support for specifying encoding to unzip. At least assembly only provides config to zip. Call it a bug, call it a feature :( Kristian 2015-03-16 12:12 GMT+01:00
AW: How to configure maven-dependency-plugin's encoding used for unpack?
Kristian, can you please reopen the item then? I mean, it simply is not fixed, because UTF-8 ZIPs are not a solution: Windows cannot correctly display them, so people on the Windows world will virtually every create CP850-ZIPs! Do you know about any plans to support this, or what is the intended future of this issue? Thanks -Markus -Ursprüngliche Nachricht- Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no] Im Auftrag von Kristian Rosenvold Gesendet: Montag, 16. März 2015 13:46 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? I did not actually look at the implementation on the dependency plugin, but it is actually technically impossible to supply the encoding parameter to *unzip* via the archiverConfig tag. So until this is fixed, UTF-8 zip archives are the only ones that will work (with plexus unzip archiver). Kristian 2015-03-16 13:05 GMT+01:00 Adrien Rivard adrien.riv...@gmail.com: If I'm reading the documentation correctly, archiverConfigencoding only apply to filter resources, not to zip them. In any case I would try using utf-8. On Mon, Mar 16, 2015 at 12:34 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I dont believe there is support for specifying encoding to unzip. At least assembly only provides config to zip. Call it a bug, call it a feature :( Kristian 2015-03-16 12:12 GMT+01:00 Markus Karg k...@quipsy.de: To preserve German umlauts in file names within a ZIP, we are using... archiverConfig encodingCP850/encoding /archiverConfig ...in the maven-assembly-plugin configuration, which is working well. :) Next we want to use maven-dependency-plugin to unpack that ZIP. How can we configure maven-dependency-plugin:unpack so it will apply CP850 when unpacking that ZIP? Thanks! -Markus -- Adrien Rivard
RE: Maven Central Opinion
I uploaded lots of not-even-Mavenized prebuilt JARs to Maven Central and can tell you that you simply misunderstood these terms as essential requirements -- in fact most of them are only best practices. You do neither need to have the Sonatype POM, it will just make things easier, nor do you have to use SNAPSHOTs. You can simply upload a prebuilt JAR file. The only hard requirements are a good POM, signing the JAR with GPG, uploading it to the OSS nexus instance, then closing and releasing it. This it at-most simple and done in minutes. If you need help, feel free to contact me at mar...@headcrashing.eu, I can guide you. -Original Message- From: Tommy Svensson [mailto:to...@natusoft.se] Sent: Sonntag, 5. Januar 2014 14:15 To: Maven Users List Subject: Maven Central Opinion I was asked to submit one of my opensource tools at github to maven central. This turned out to be a rather complex procedure. Sonatype puts the following requirements on anyone wanting to submit to maven central: - You are forced to set a Sonatype pom as parent of your project and thus inherit things you have no control over. - You are forced to have a SNAPSHOT version even if you have no use for such. - You are forced at submission time to select a new version for your software even if you have no idea if it will be a minor, bugfix or new functionality at this point in time. - Your public repository (github, etc) which you are forced to point out in your pom are no longer yours to decide over. It will be updated during the submission process. - After running 3 different mvn commands you also need to login to Sonatypes nexus server and release the artifacts before the become available. The idea of the maven repository that has grown larger than maven itself is a completely brilliant idea. It takes open source to a new level where anyone can just depend on other open source code and automatically download it on build. This is really good for the open source world (well, at least the Java/JVM part of it) . The fact that the release process to this central repository is far too complex, I see as a really great problem, inhibiting the easy sharing of open source work. I have often found open source tools and frameworks that are not available in maven central, and that is because not everyone is willing to put up with this, which now also includes myself. As I see it, either this procedure needs to be changed to provide a trivial release of binary artifacts without affecting your poms, or there need to be an alternative open repository providing ease of release, where it is trivial for anyone to share their binaries for easy access by others. I'm wondering if I'm alone in this view or if there are others who agree with me ? Tommy Svensson - 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: AW: AW: AW: mvn release:prepare does not update parent version
Robert, no need to teach me about completeness of reports -- I am in the reverse situation day by day as you can imagine. The problem was that I had the problem since I migrated to Maven 3 from day one with even the smallest possible POM (it looked 'obvious' to me) and did not have the idea there might be a fix already already which is not contained in Maven 3 so far. In fact this is why I would love to have the ability to use version ranges in plugin dependencies! ;-) Anyways, as all is fixed now, thanks for the kind help! :-) -Markus -Original Message- From: Robert Scholte [mailto:rfscho...@apache.org] Sent: Freitag, 8. November 2013 18:52 To: Maven Users List Subject: Re: AW: AW: AW: mvn release:prepare does not update parent version Op Fri, 08 Nov 2013 16:30:30 +0100 schreef Markus Karg k...@quipsy.de: I wonder why someone fixed it but didn't close https://jira.codehaus.org/browse/MRELEASE-837...! Well, is was probably already fixed for a long time. Since you only had a description it will take some time to fix it, since it must first be reproducible. That's why attaching a sample project helps, and a patch with a possible fix even more. In this case it was the log-file which triggered me: first update the version of the plugin and see if it has been already been fixed. It is all about being as complete as possible :) Robert - 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
AW: AW: AW: mvn release:prepare does not update parent version
Martin, thank you for your explanations, but as it turned out the problem is fixed simply by using version 2.4.2 of the release plugin. I wonder why someone fixed it but didn't close https://jira.codehaus.org/browse/MRELEASE-837...! Thanks for all -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: mvn release:prepare does not update parent version
Sorry for the really long delay, but there had been several urgent projects meanwhile. I built a really microscopic project which showcases the problem. It consists of a rather empty parent POM which has been released as 1.0 plus a super-simple POM using that one as a company parent POM. So this is NOT a module! Please check the marked lines to understand my problem! POM before release: 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/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion artifactIdmy-artifact/artifactId namemy-artifact/name parent groupIdmy.group/groupId artifactIdmy-parent/artifactId version1.0-SNAPSHOT/version /parent scm developerConnectionscm:svn:svn://svn/Research/my-artifact/trunk/developerConnection /scm distributionManagement repository idreleases/id urlhttp://nexus.quipsy.local/nexus/content/repositories/releases/url /repository snapshotRepository idsnapshots/id urlhttp://nexus.quipsy.local/nexus/content/repositories/snapshots/url /snapshotRepository /distributionManagement /project Preparing and performing the release: C:\Users\Markus Karg\workspace\artifact\my-artifactmvn release:prepare release:perform [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building my-artifact 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-release-plugin:2.0:prepare (default-cli) @ my-artifact --- [INFO] Verifying that there are no local modifications... [INFO] Executing: cmd.exe /X /C svn --non-interactive status [INFO] Working directory: C:\Users\Markus Karg\workspace\artifact\my-artifact [INFO] Checking dependencies and plugins for snapshots ... There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : Resolve Project Dependency Snapshots.: 'my.group:my-parent' set to release? (yes/no) yes: : What is the next development version? (1.1-SNAPSHOT) 1.1-SNAPSHOT: : What is the release version for my-artifact? (my.group:my-artifact) 1.0: : What is SCM release tag or label for my-artifact? (my.group:my-artifact) my-artifact-1.0: : What is the new development version for my-artifact? (my.group:my-artifact) 1.1-SNAPSHOT: : [INFO] Transforming 'my-artifact'... [INFO] Not generating release POMs [INFO] Executing goals 'clean verify'... [WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance. [INFO] [INFO] Scanning for projects... [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] Building my-artifact 1.0 [INFO] [INFO] [INFO] [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ my-artifact --- [INFO] [INFO] [INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ my-artifact --- [INFO] [debug] execute contextualize [INFO] [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] [INFO] skip non existing resourceDirectory C:\Users\Markus Karg\workspace\artifact\my-artifact\src\main\resources [INFO] [INFO] [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ my-artifact --- [INFO] [INFO] No sources to compile [INFO] [INFO] [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ my-artifact --- [INFO] [debug] execute contextualize [INFO] [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] [INFO] skip non existing resourceDirectory C:\Users\Markus Karg\workspace\artifact\my-artifact\src\test\resources [INFO] [INFO] [INFO] [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ my-artifact --- [INFO] [INFO] No sources to compile [INFO] [INFO] [INFO] [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ my-artifact --- [INFO] [INFO] No tests to run. [INFO] [INFO] Surefire report directory: C:\Users\Markus Karg\workspace\artifact\my-artifact\target\surefire-reports [INFO] [INFO] --- [INFO] T E S T S [INFO] --- [INFO] [INFO] Results : [INFO] [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] [INFO] [INFO] --- maven-jar-plugin:2.3.2:jar (default-jar) @ my-artifact --- [INFO] [WARNING] JAR will be empty - no content was marked for inclusion! [INFO
AW: AW: mvn release:prepare does not update parent version
Martin, thanks for your ideas, but... MG the previous email was an attempt to explain prepare-mojo will update current or children artifacts but not parent artifacts I agree that the docs do not say anything about the parent, but my question is not about the docs, it is about this question the plugin is actually asking: Resolve Project Dependency Snapshots.: 'my.group:my-parent' set to release? (yes/no) yes: yes What is the next development version? (1.1-SNAPSHOT) 1.1-SNAPSHOT: my.group:my-parent *is the parent*. So why does this plugin ask this question? *That* is my question! :-) Also, I do not want to use another third-party plugin to update the parent at every *deploy*. I only want the parent to be corrected to that level the Maven Release Plugin suggests automatically *when preparing the release* (and only then!). So unless prepare-release is a phase (which I am not aware of) your suggested trick is not a solution to my actual problem. :-( Thanks! -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
As a Maven user I think that everybody who is working on a project should behave the same. Hence, I would say, PMC members should rather certainly demonstrate how to live the community rules. -Ursprüngliche Nachricht- Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Gesendet: Donnerstag, 25. Juli 2013 15:16 An: Maven Users List; Maven Developers List Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md) There are two schools of thought amongst the current members of this projects PMC. Without wanting to deliberately tip my hand and reveal where my opinion is, we would like to solicit the opinions if the community that we serve. Please give us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: Author: jdcasey Date: Wed Jul 24 23:21:58 2013 New Revision: 1506778 URL: http://svn.apache.org/r1506778 Log: Adding section on PMC standards of community commitment Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project -roles.md?rev=1506778r1=1506777r2=1506778view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 23:21:58 2013 @@ -176,6 +176,29 @@ The Project Management Committee has the * Voting on release artifacts. * !-- TODO: get the rest of these -- + Standards for Community Commitment + +In the spirit of supporting the health of our community, Project +Management Committee members refrain from actions that subvert the +functioning of the committee itself. + +First, Project Management Committee members should not maintain long-running +forks of Maven code outside of the project itself. Making significant +changes to Maven code outside of the project displays a lack of +investment in the community. Additionally, attempting to re-integrate +a large number of code changes in bulk overwhelms the ability of +volunteers in the community to review (and potentially veto) the +changes. This effectively thwarts the policing function of the PMC. + +Second, Project Management Committee members should not divert work +on redesigning, reimplementing, or improving Maven code to +alternative projects outside of this community for the purposes of +reintroducing them as replacement for existing Maven code. While +there is a danger here of falling into a Not Invented Here mentality, +new projects +created by Maven PMC members strictly to replace Maven code should +not be allowed. + ### [Project Management Chair]( http://www.apache.org/foundation/how-it-works.html#pmc-chair) For various legal reasons, there are certain things that the Apache -- Sent from my phone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: mvn release:prepare does not update parent version
Martin, I don't know why you're asking this. What has this to do with my actual scenario? I am doing something completely different and my question was not targeting your scenario. Thanks -Markus -Ursprüngliche Nachricht- Von: Martin Gainty [mailto:mgai...@hotmail.com] Gesendet: Dienstag, 23. Juli 2013 23:24 An: users@maven.apache.org Betreff: RE: mvn release:prepare does not update parent version Markus Parent.pom | v - | | v v Child1.pom Child2.pom release:prepare where property updates/changes Child1.pom Child11.pom Child12.pom | v --- | | v v Child11.pom Child12.pom can you envision a scenario where release plugin should break inheritance and update Parent instead of child module s ? Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Subject: RE: mvn release:prepare does not update parent version Date: Mon, 22 Jul 2013 22:29:07 +0200 From: k...@quipsy.de To: users@maven.apache.org Thanks for picking up this thread! I am using: Maven 3.0.4 and maven-release-plugin 2.4.1 -Markus Hi, which version of Maven and Maven-Release-Plugin are you using? On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg k...@quipsy.de wrote: I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus - 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
AW: mvn release:prepare does not update parent version
You don't get my point. My problem is that the plugin asks me to provide the version to set for the parentversion tag, but it actually does not use it. This is what I complain about, solely. I don't want to update anything else. -Ursprüngliche Nachricht- Von: christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] Gesendet: Dienstag, 23. Juli 2013 10:10 An: Maven Users List Betreff: AW: mvn release:prepare does not update parent version Hi, is there actually a reason why only the artifacts in the build are updated? I would agree that without providing versions for artifacts manually, this could cause problems, but when using the feature described here: http://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html It is possible to provide separate versions for every module. In my release I provided release and development versions for all modules (also ones not in the reactor), but the release:prepare simply skipped those not in the build. I had to create a patched version for this, but it was a pretty unsatisfying solution. If the plugin would for example update all those versions in the reactor plus all those I manually provided a version for, might solve Markus' problems. Chris -Ursprüngliche Nachricht- Von: jieryn [mailto:jie...@gmail.com] Gesendet: Montag, 22. Juli 2013 20:36 An: Maven Users List Betreff: Re: mvn release:prepare does not update parent version Greetings, On Mon, Jul 22, 2013 at 8:25 AM, Markus Karg k...@quipsy.de wrote: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. -Jesse - 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
AW: mvn release:prepare does not update parent version
But why is release:prepare explicitly asking me whether I want to update that number and what that number is, when it is intended behaviour that it does not actually set that number into the POM? I would understand all what you say if the plugin would not ask for the next development version of parent. But it DOES ask. -Ursprüngliche Nachricht- Von: Russell Gold [mailto:r...@gold-family.us] Gesendet: Dienstag, 23. Juli 2013 10:27 An: Maven Users List Betreff: Re: mvn release:prepare does not update parent version The example you mention updates the build artifacts only. When you release code, you would of course assign a version number to the release, and you can specify what snapshot version you want to use next. That makes the release consistent with all of the tests. It's simple labeling what is being released. Changing the version number of outside artifacts that you reference, on the other hand, is a change in the definition and functionality of the system. There is no particular reason to expect it to work, and more than if you decided to ask Maven to modify any other code in your system. Russ On Jul 23, 2013, at 4:10 AM, christofer.d...@c-ware.de wrote: Hi, is there actually a reason why only the artifacts in the build are updated? I would agree that without providing versions for artifacts manually, this could cause problems, but when using the feature described here: http://maven.apache.org/maven-release/maven-release-plugin/examples/no n-interactive-release.html It is possible to provide separate versions for every module. In my release I provided release and development versions for all modules (also ones not in the reactor), but the release:prepare simply skipped those not in the build. I had to create a patched version for this, but it was a pretty unsatisfying solution. If the plugin would for example update all those versions in the reactor plus all those I manually provided a version for, might solve Markus' problems. Chris -Ursprüngliche Nachricht- Von: jieryn [mailto:jie...@gmail.com] Gesendet: Montag, 22. Juli 2013 20:36 An: Maven Users List Betreff: Re: mvn release:prepare does not update parent version Greetings, On Mon, Jul 22, 2013 at 8:25 AM, Markus Karg k...@quipsy.de wrote: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. -Jesse - 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 - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn release:prepare does not update parent version
I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus
mvn release:prepare does not update parent version
I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mvn release:prepare does not update parent version
Thanks for picking up this thread! I am using: Maven 3.0.4 and maven-release-plugin 2.4.1 -Markus Hi, which version of Maven and Maven-Release-Plugin are you using? On Mon, Jul 22, 2013 at 9:25 AM, Markus Karg k...@quipsy.de wrote: I'm driving nuts with mvn release:prepare...: When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Thanks! -Markus - 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: mvn release:prepare does not update parent version
Thanks for picking this up. Please find answers inlined. :-) When I do mvn release:prepare, Maven asks whether I want to update all SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? [INFO] Checking dependencies and plugins for snapshots ... There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 1 Resolve Project Dependency Snapshots.: 'de.foo:my-company-pom' set to release? (yes/no) yes: : yes What is the next development version? (4.34.5-SNAPSHOT) 4.34.5-SNAPSHOT: : 4.34.5-SNAPSHOT 'de.foo:my-library' set to release? (yes/no) yes: : ... As you see, it asks whether I want to set the reference to the parent (my-company-pom) to release, and I say: yes. Then it suggests to reference the latest company pom, which actually is 4.34.5-SNAPSHOT, which I confirmed. (in reality I just press [Enter], but I added the value here for better readability) I say yes and confirm all suggested replacement versions unchanged. When Maven is done, I check the POM.xml. It is correctly rewritten for all references, but not for the parent version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. I do not want to update the parent project itself. I want to replace the reference to the SNAPSHOT parent by a reference to the RELEASE parent. Which is not horrible, but certainly what everybody wants when doing a release and having just released the parent one minute before. The parent version still references the *old* SNAPSHOT, while obviously it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. This is not a submodule. I do not talk about a multi-module project at all. This is a simple standalone project, which references a company POM. The company POM was released a minute ago, and now I want to release this project. So I cannot run the release from the parent, obviously. Can somebody tell me what I have to do so that mvn release:prepare will also make the parent version point tot he *next* SNAPSHOT, as it does it correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. Please read above lines. As it is a standalone project, I DO run the release from the proper location. I actually HAVE released the parent bevore. All I want to get is that the release plugin doeas what it actually announced to do. It asked me what parent version I want, and it just discards the information. That's what I complain about. Regards -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to prevent renaming of third-party file?
My project is dependent on a third-party JAR file which will be installed on the target machine by a mechanism other than Maven. Hence, I have no influence on its actual file name. As I want Maven to automatically build the MANIFEST's Class-Path entry, I have put the same third-party JAR into my Nexus instance and added a dependency on it, which works well, but apparently renames the JAR file. So in the end my own JAR will not find that third party JAR on the target machine, as it simply seeks for the wrong name. How can I tell Maven that it must not rename the third party JAR when uploading it into Nexus and / or to use the original third party file name when building the Class-Path (without providing a static Class-Path entry in my POM, which is definitively not what I want)? Thanks! -Markus
How to tell Maven to generate code when XSL has changed?
I am using xml-maven-plugin to generate Java code from XML: groupIdorg.codehaus.mojo/groupId artifactIdxml-maven-plugin/artifactId version1.0/version executions execution phasegenerate-sources/phase goals goaltransform/goal /goals /execution /executions This works well, but now I want that it automatically executes as soon as the used transformation XSLT file was modified. So how can I tell maven that it shall do generate-sources as soon as a particular file was touched? Thanks! -Markus
AW: How to tell Maven to put DLL dependency into java.library.path?
Maybe you like to vote or comment: http://jira.codehaus.org/browse/MNG-5448 ? :-) Regards -Markus -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Montag, 25. März 2013 17:04 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? dont think maven can do that ( surefire understand jars but not dll/so ). I am facing the same issue and the best I can come up ATM is to configure every single project -D On Mon, Mar 25, 2013 at 12:58 AM, Markus Karg k...@quipsy.de wrote: Dan, thank you for this tip. I is working very well. But one question I still do have: If I have a second project which needs the same native dependency, obviously I have to tell configure maven-surefire-plugin again. This is a bit strange, as obviously the fact that the configuration is needed is related to the dependency, not to the dependent project. I wonder if Maven has a solution that roughly spoken does the same but is configured inside oft he dependency's POM, not inside oft he dependent POM? That would allow to use the dependency as any other dependency without having to remember that it actually is a DLL... Thanks! -Markus -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 17:41 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? - Use maven profile to detect OS arch and set it into a maven property - Use maven-dependcy-plugin to down all requires dll. Make sure to take advantage of the property set in step 1 - Configure maven-surefire-plugin to set PATH env variable into the download directory Good luck -D On Wed, Feb 27, 2013 at 6:58 AM, Markus Karg k...@quipsy.de wrote: My POM declared a dependency to a DLL: dependency groupIdnet.sf.jacob-project/groupId artifactIdjacob-runtime/artifactId typedll/type classifierx64/classifier version1.17-M2/version scoperuntime/scope /dependency (1)How can I tell Maven that when doing mvn test, that DLL shall be found on java.library.path, so that the JVM can load native classes from it (using JNI)? (2)How can I tell Maven that it shall not statically be x64, but instead it depends on the architecture of the system actually executing mvn test (e. g. x86)? Thanks! J -Markus - 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
AW: How to tell Maven to put DLL dependency into java.library.path?
Dan, thank you for this tip. I is working very well. But one question I still do have: If I have a second project which needs the same native dependency, obviously I have to tell configure maven-surefire-plugin again. This is a bit strange, as obviously the fact that the configuration is needed is related to the dependency, not to the dependent project. I wonder if Maven has a solution that roughly spoken does the same but is configured inside oft he dependency's POM, not inside oft he dependent POM? That would allow to use the dependency as any other dependency without having to remember that it actually is a DLL... Thanks! -Markus -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 17:41 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? - Use maven profile to detect OS arch and set it into a maven property - Use maven-dependcy-plugin to down all requires dll. Make sure to take advantage of the property set in step 1 - Configure maven-surefire-plugin to set PATH env variable into the download directory Good luck -D On Wed, Feb 27, 2013 at 6:58 AM, Markus Karg k...@quipsy.de wrote: My POM declared a dependency to a DLL: dependency groupIdnet.sf.jacob-project/groupId artifactIdjacob-runtime/artifactId typedll/type classifierx64/classifier version1.17-M2/version scoperuntime/scope /dependency (1)How can I tell Maven that when doing mvn test, that DLL shall be found on java.library.path, so that the JVM can load native classes from it (using JNI)? (2)How can I tell Maven that it shall not statically be x64, but instead it depends on the architecture of the system actually executing mvn test (e. g. x86)? Thanks! J -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: How to tell Maven to put DLL dependency into java.library.path?
The bad thing is that just I noticed that m2e actually *clears* already manually configured native library paths from Eclipse's build path config! So while it is unable to *set* that information, it is checky enough to *remove* correct, existing, wanted settings. :-( -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Donnerstag, 28. Februar 2013 08:49 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? I think that would work if you invoke 'maven install' using m2e. However, if you use eclispe's unit test, that may not possible since I too could not working. I basically configure eclispe or put the dlls in my system path -D On Wed, Feb 27, 2013 at 11:21 PM, Markus Karg k...@quipsy.de wrote: I fact these are not my DLLs but are ready-to-use artifacts of the JACOCO project on SourceForge. So I will *never* build them on my own. But I need to have it working m2e. Do you think your solution will convince m2e to add lib to java.library.path? -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 22:29 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? if you already have all you DLL loaded at your maven repo, Then it make sense to do so at this moment if you are required to build dll with maven, better look into NAR -D On Wed, Feb 27, 2013 at 12:35 PM, Wayne Fay wayne...@gmail.com wrote: thank you for this interesting idea. I think this would be the most sophisticated (most mavenic) solution, but I have the feeling that Dan's to be simpler to set up in the short term for a Maven novice? Go with Dan's solution for now, but I think you'll change to the Nar plugin eventually. 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
AW: How to tell Maven to put DLL dependency into java.library.path?
Who said that I do not use the EclEmma Eclipse plugin? Actually I do. :-) But that does neither solve the problem that each new guy in the team needs to set up his java.library.path in Eclipse again, nor the problem that a CI server like Jenkins / Hudson needs to know about all native libraries for running unit tests. *And* m2e clears the manual native lib settings in Eclipse each time it updates from the POM.xml! ;-( -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Donnerstag, 28. Februar 2013 08:54 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? Why not just use the EclEmma Eclipse plugin? It uses Jacoco from what I read on their web site, despite the emma in the name of the plugin. /Anders On Thu, Feb 28, 2013 at 8:48 AM, Dan Tran dant...@gmail.com wrote: I think that would work if you invoke 'maven install' using m2e. However, if you use eclispe's unit test, that may not possible since I too could not working. I basically configure eclispe or put the dlls in my system path -D On Wed, Feb 27, 2013 at 11:21 PM, Markus Karg k...@quipsy.de wrote: I fact these are not my DLLs but are ready-to-use artifacts of the JACOCO project on SourceForge. So I will *never* build them on my own. But I need to have it working m2e. Do you think your solution will convince m2e to add lib to java.library.path? -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 22:29 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? if you already have all you DLL loaded at your maven repo, Then it make sense to do so at this moment if you are required to build dll with maven, better look into NAR -D On Wed, Feb 27, 2013 at 12:35 PM, Wayne Fay wayne...@gmail.com wrote: thank you for this interesting idea. I think this would be the most sophisticated (most mavenic) solution, but I have the feeling that Dan's to be simpler to set up in the short term for a Maven novice? Go with Dan's solution for now, but I think you'll change to the Nar plugin eventually. 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: How to tell Maven to put DLL dependency into java.library.path?
EclEmma simply runs code coverage. AFAIK it does not care about java.library.path at all. My actual need is one POM-centric declaration of a DLL dependency that works in *any* tools able to deal with POMs. :-) -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Donnerstag, 28. Februar 2013 12:25 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? Ok. I just assumed that the EclEmma Eclipse plugin would handle all of this in Eclipse. I haven't used it myself. Any CI problems are not related to this; I was just focusing on the Eclipse part of the problem. /Anders On Thu, Feb 28, 2013 at 11:08 AM, Markus Karg k...@quipsy.de wrote: Who said that I do not use the EclEmma Eclipse plugin? Actually I do. :-) But that does neither solve the problem that each new guy in the team needs to set up his java.library.path in Eclipse again, nor the problem that a CI server like Jenkins / Hudson needs to know about all native libraries for running unit tests. *And* m2e clears the manual native lib settings in Eclipse each time it updates from the POM.xml! ;-( -Ursprüngliche Nachricht- Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag von Anders Hammar Gesendet: Donnerstag, 28. Februar 2013 08:54 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? Why not just use the EclEmma Eclipse plugin? It uses Jacoco from what I read on their web site, despite the emma in the name of the plugin. /Anders On Thu, Feb 28, 2013 at 8:48 AM, Dan Tran dant...@gmail.com wrote: I think that would work if you invoke 'maven install' using m2e. However, if you use eclispe's unit test, that may not possible since I too could not working. I basically configure eclispe or put the dlls in my system path -D On Wed, Feb 27, 2013 at 11:21 PM, Markus Karg k...@quipsy.de wrote: I fact these are not my DLLs but are ready-to-use artifacts of the JACOCO project on SourceForge. So I will *never* build them on my own. But I need to have it working m2e. Do you think your solution will convince m2e to add lib to java.library.path? -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 22:29 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? if you already have all you DLL loaded at your maven repo, Then it make sense to do so at this moment if you are required to build dll with maven, better look into NAR -D On Wed, Feb 27, 2013 at 12:35 PM, Wayne Fay wayne...@gmail.com wrote: thank you for this interesting idea. I think this would be the most sophisticated (most mavenic) solution, but I have the feeling that Dan's to be simpler to set up in the short term for a Maven novice? Go with Dan's solution for now, but I think you'll change to the Nar plugin eventually. 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 - 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
How to tell Maven to put DLL dependency into java.library.path?
My POM declared a dependency to a DLL: dependency groupIdnet.sf.jacob-project/groupId artifactIdjacob-runtime/artifactId typedll/type classifierx64/classifier version1.17-M2/version scoperuntime/scope /dependency (1)How can I tell Maven that when doing mvn test, that DLL shall be found on java.library.path, so that the JVM can load native classes from it (using JNI)? (2)How can I tell Maven that it shall not statically be x64, but instead it depends on the architecture of the system actually executing mvn test (e. g. x86)? Thanks! J -Markus
RE: How to tell Maven to put DLL dependency into java.library.path?
Dan, sounds reasonable. I think I'll do that! :-) Thanks a lot! -Markus -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Mittwoch, 27. Februar 2013 17:41 To: Maven Users List Subject: Re: How to tell Maven to put DLL dependency into java.library.path? - Use maven profile to detect OS arch and set it into a maven property - Use maven-dependcy-plugin to down all requires dll. Make sure to take advantage of the property set in step 1 - Configure maven-surefire-plugin to set PATH env variable into the download directory Good luck -D On Wed, Feb 27, 2013 at 6:58 AM, Markus Karg k...@quipsy.de wrote: My POM declared a dependency to a DLL: dependency groupIdnet.sf.jacob-project/groupId artifactIdjacob-runtime/artifactId typedll/type classifierx64/classifier version1.17-M2/version scoperuntime/scope /dependency (1)How can I tell Maven that when doing mvn test, that DLL shall be found on java.library.path, so that the JVM can load native classes from it (using JNI)? (2)How can I tell Maven that it shall not statically be x64, but instead it depends on the architecture of the system actually executing mvn test (e. g. x86)? Thanks! J -Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to tell Maven to put DLL dependency into java.library.path?
Jörg, thank you for this interesting idea. I think this would be the most sophisticated (most mavenic) solution, but I have the feeling that Dan's to be simpler to set up in the short term for a Maven novice? Thanks! :-) Markus -Original Message- From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] Sent: Mittwoch, 27. Februar 2013 18:03 To: users@maven.apache.org Subject: Re: How to tell Maven to put DLL dependency into java.library.path? Hi Marcus, Markus Karg wrote: My POM declared a dependency to a DLL: dependency groupIdnet.sf.jacob-project/groupId artifactIdjacob-runtime/artifactId typedll/type classifierx64/classifier version1.17-M2/version scoperuntime/scope /dependency (1)How can I tell Maven that when doing mvn test, that DLL shall be found on java.library.path, so that the JVM can load native classes from it (using JNI)? (2)How can I tell Maven that it shall not statically be x64, but instead it depends on the architecture of the system actually executing mvn test (e. g. x86)? Have a look at the nar plugin. Create a JNI example project and have a look at the artifacts it will create. You may pack your DLLs into similar artifacts and then use this plugin to download and unpack the native stuff automatically when using those artifacts as dependency. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: How to tell Maven to put DLL dependency into java.library.path?
Possibly. Because in fact, I need other tools to understand the need for java.library.path, too, mosty the m2e Eclipse plugin, which I doubt will understand any manual PATH changes in the surefire config (does it?). -Ursprüngliche Nachricht- Von: Wayne Fay [mailto:wayne...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 21:35 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? thank you for this interesting idea. I think this would be the most sophisticated (most mavenic) solution, but I have the feeling that Dan's to be simpler to set up in the short term for a Maven novice? Go with Dan's solution for now, but I think you'll change to the Nar plugin eventually. 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
AW: How to tell Maven to put DLL dependency into java.library.path?
I fact these are not my DLLs but are ready-to-use artifacts of the JACOCO project on SourceForge. So I will *never* build them on my own. But I need to have it working m2e. Do you think your solution will convince m2e to add lib to java.library.path? -Ursprüngliche Nachricht- Von: Dan Tran [mailto:dant...@gmail.com] Gesendet: Mittwoch, 27. Februar 2013 22:29 An: Maven Users List Betreff: Re: How to tell Maven to put DLL dependency into java.library.path? if you already have all you DLL loaded at your maven repo, Then it make sense to do so at this moment if you are required to build dll with maven, better look into NAR -D On Wed, Feb 27, 2013 at 12:35 PM, Wayne Fay wayne...@gmail.com wrote: thank you for this interesting idea. I think this would be the most sophisticated (most mavenic) solution, but I have the feeling that Dan's to be simpler to set up in the short term for a Maven novice? Go with Dan's solution for now, but I think you'll change to the Nar plugin eventually. 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 is in no danger of being replaced :-)
Jason, thank you for that concise information. It would be great if you could also publish a quarterly sampled line graph on the same stats, so one could easily identify and trends in this. :-) Regards Markus From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Donnerstag, 27. September 2012 20:03 To: Maven Users List Subject: Maven is in no danger of being replaced :-) I was curious to see what the breakdown is of Maven, Ivy and Gradle use so I took the block of traffic from last week and filtered down the unique IPs per tool across its versions. If you want to take a look at the data pulled you can see it here: https://gist.github.com/3794963 I used easily identifiable user agents. As Dan Kulp pointed out in IRC many versions of Maven 2.0.x are not accounted for because we never specified a user agent. So if anything, Maven's portion of the pie is bigger. Older versions of Gradle used Ivy, and older versions of Ivy also didn't identify itself correctly. Let's just say it all comes out in the wash and this is what we're left with. This is only traffic against Maven Central so it's hard to tell what's behind repository managers. But I think this is fairly representative. So as far as I can tell empirically from data gathered from the logs in Maven Central, Maven is in no danger of being replaced anytime soon. I believe that the Aether Ant tasks will ultimately replace Ivy in Ant builds, and Gradle has been around for 5 years (give or take) and it's not really making much of a dent. 0952.png Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
RE: How to put a dependency in the classpath BEFORE jre.jar?
Strub, thank you for your comments. Unfortunately (as I already wrote two times before) this thread started by the exact problem of overloading a JRE class (Resource annotation) by javaee6.jar... so it just don't work (otherwise I wouldn't have started this thread). Anyway, thanks for chiming in! :-) Regards Markus -Original Message- From: Mark Struberg [mailto:strub...@yahoo.de] Sent: Dienstag, 25. September 2012 21:48 To: Maven Users List Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? I did not read through the whole thread, so maybe I missed (sorry for that). Afaik maven plugins use a different ClassLoader hierarchy than you might expect. Most frameworks use ParentClassLoaderFirst, but maven afaik uses ClientClassLoaderFirst. Which means it's perfectly fine to to put a javax.* dependency in your plugin classpath. The only thing which is not allowed is to overwrite native SE stuff. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Users List users@maven.apache.org Cc: Sent: Tuesday, September 25, 2012 8:08 PM Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - 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: How to put a dependency in the classpath BEFORE jre.jar?
If there is a real interest in my participation I would be glad to join. But to tell it frankly, I enjoyed lots of forums and lists where people talked and talked and talked (I am an EG member and know how long companies can talk just to not being forced to change one code line) and did never come to a consensus. So do you actually see any chances of a solution for the described problem? See, if not, it makes no sense that I add another thread on the dev list. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Dienstag, 25. September 2012 20:09 To: Maven Users List Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? Markus, If you want to join in on the fun of the development community, please join us on the dev list. As you've heard on this thread, your particular concern smacks into a messy conundrum about our desire to avoid breaking other people's tools that read poms -- no matter how poorly coded. However, there is a design in progress, it needs more refinement, and mostly it will need people to actually code it. --benson - 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: How to put a dependency in the classpath BEFORE jre.jar?
I did never suggest to modify the POM and said no word about any future form of the POM, so I skip your comments about that and right go on with the idea of a Platform: I like some of your idea about the concept of a platform but this is not as trivial as you think. There is the issue of building with JDK5 an artifact to be run on JDK5 or JDK6 The idea of having a Platform interface actually solves exactly that problem, since the JDK5 platform will tell how to build on JDK5, while the JDK6 platform will tell how to build on JDK6. Are you sure that you mean build? What are you building that is different? Yes, I mean *build*. My source code needs the @Resource(lookup = ...) field, which comes with Java EE 6, while Java SE 6 only has @Resource without the field lookup. So my code simply does not build, as long as javaee6.jar ist a simple dependency in the user classpath. I need to have it in the bootstrap classpath. This is why this thread is called How to put a dependency in the classpath BEFORE jre.jar? and the original problem that started it. It still sounds like an installation issue and Package is what an installer builder creates. If you follow the thread to the start you will see that it has nothing to do with packaging. Maven will build the modules that you need to create the package of jars that gets installed. ...and how does that solve the case described by me now for the second time...? ;-) Regards Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
Stephen, I did never suggest to modify the POM and said no word about any future form of the POM, so I skip your comments about that and right go on with the idea of a Platform: I like some of your idea about the concept of a platform but this is not as trivial as you think. There is the issue of building with JDK5 an artifact to be run on JDK5 or JDK6 The idea of having a Platform interface actually solves exactly that problem, since the JDK5 platform will tell how to build on JDK5, while the JDK6 platform will tell how to build on JDK6. There is the issue of somebody building their own patched JAX-RS and publishing at their own coordinates... how would the platform know that com.foobar.manchu:jersey-patched-by-bob:0.1.2 is supposed to be endorsed... other than by scanning the jar file and looking for paths within For this, there is a Java standard already: The spec and impl information in the MANIFEST.MF file of the JAR was invented exactly to answer this question. No need to parse or scan anything, just applying a well-known, very old and approved standard! What do we do when building a .WAR that includes that dependency? I do not see what shall be the problem with a WAR? For compiling it, you need the dependency. Whether or not it is endorsed or not, is decided by the Platform. What endorsed specs it implements is to be found in its MANIFEST.MF. Can you describe the problem that you see? Please file a JIRA so that your platform idea does not get lost in the ML, but I don't think in its current shape that it is the right solution. Do you honestly think it is worth getting filed if it is not the right solution? I would be more thinking along the lines of a platform packaging type... ...which implies a POM change... coupled with the provides (sort of inverse of dependencies) element or scope... My reasoning is this... when you need to replace an endorsed dependency what you are really saying is I *need* to run on a different platform The Endorsed mechanism is just a way of modifying the platform that you run on without having to produce a custom build of that platform... So to my mind, you create modules for the platforms that you require... those platforms have their dependencies listed as either provides elements in a model 5 pom, or as scopeprovides/scope (in a model 5 pom again... because unfortunately the allowed values of the scope element are locked in model 4) so we can filter the dependencies appropriately... If I understand correctly, then you simply will replace the Platform interface by a Platform packaging type, hence allowing people to easily defined their own platform? Well, why not? Do you file a JIRA for this? It would be nice if we could find a way of building the same module for multiple platforms at the same time... but the key here is to realize that it is not the .jar that you build for a platform... but the executable .jar or the .war or the .ear, etc that you build for the platform... so those would be thin modules, and duplication of modules is less of an issue... IOW one module per platform... though nothing to stop multiple executions of the maven war plugin with the different platforms configured... works too because (bar skinny wars in ear) .war files are a final end of the chain artifact. I think this is not correct: For example, there might be difference in a thin JAR for Java 5 to Java 6, too. For example, if it is not a complete library that you depend upon (hence is endorsed), but if it is one or two single classes that exist in Java 6 but did not in Java 5 so you ship them *within* the Java 5 release of your thin JAR. [In fact, if we look at this from a better decomposition PoV might make more sense to have a webapp packaging that holds the .war content and make .war a final end of the line artifact... but getting sidetracked again] With this model... you would also see platforms for each of the JavaEE containers, as well as a generic JavaEE specification platform... [the webapp packaging then becomes more needed... think of skinny .wars being packaged into a .ear for each platform that you want to deploy the .ear onto... on older platforms you might need the newer version of JSF, on TomEE you may need additional dependencies because it is implementing one profile, etc] IOW I think the concept of a platform is a good idea... but there is a lot more to it than meets the eye. Never said that it will be easy. But we *need* platforms in Maven 4. Either way. -Stephen P.S. I am quite sure others will come along and poke holes in my ideas above too! On 22 September 2012 10:19, Markus KARG mar...@headcrashing.eu wrote: Stephen, if we would never address problems that seem hard to fix at first sight, then the Maven core would never evolve and other system would take over some day. So a discussion like this one is essential for the future of this tool
RE: How to put a dependency in the classpath BEFORE jre.jar?
(though very java focused I admit) endorsed does not make sense outside of java 2. Whether a dependency needs to be endorsed or not depends on the jvm version it targets... A dep can be fine until it gets added to the jvm spec. 3. It should probably more correctly be scopeendorsed/scope 4. Where would you package an endorsed dependency within a .war or .ear file? And don't get me started on the fact that to change this requires changing the Pom format (which potentially could break ivy, gradle, leinengen, sbt, etc) Not an easy problem to solve, but I feel your pain On Friday, 21 September 2012, Markus KARG wrote: Thank you for pointing me to this excellent blog entry, but in fact I wonder why such a great tool like Maven doesn't have built-in support for endorsed dependencies? I mean, in the end a different compiler might break the solution, so it would be a good idea if a dependency could simply marked as endorsedtrue/endorsed. -Original Message- From: Claves Do Amaral [mailto:claves.doama...@igmarkets.comjavascript:; ] Sent: Donnerstag, 20. September 2012 10:30 To: Maven Users List Subject: RE: How to put a dependency in the classpath BEFORE jre.jar? If I understand the problem well, this is equivalent to provide endorsed libraries at runtime. I have found this resource, that looks a bit dated, but it may work. Not sure if Maven 3 offers a better solution http://www.mindbug.org/2009/02/adding-endorsements-to-mavens- plugins.html Claves -Original Message- From: Markus Karg [mailto:k...@quipsy.de javascript:;] Sent: 20 September 2012 09:22 To: users@maven.apache.org javascript:; Subject: How to put a dependency in the classpath BEFORE jre.jar? I have a dependency on javaee.jar, which provides newer versions for classes found in JRE's jre.jar (particularly the @Resource annotation). But javaee.jar is always appended to the classpath, while to be able to load the newer version, I need to PREFIX it before jre.jar instead. How can I configure this in the POM? The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG is a trading name of IG Markets Limited, a company registered in England and Wales under number 04008957. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 195355. --- - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to put a dependency in the classpath BEFORE jre.jar?
Thank you for pointing me to this excellent blog entry, but in fact I wonder why such a great tool like Maven doesn't have built-in support for endorsed dependencies? I mean, in the end a different compiler might break the solution, so it would be a good idea if a dependency could simply marked as endorsedtrue/endorsed. -Original Message- From: Claves Do Amaral [mailto:claves.doama...@igmarkets.com] Sent: Donnerstag, 20. September 2012 10:30 To: Maven Users List Subject: RE: How to put a dependency in the classpath BEFORE jre.jar? If I understand the problem well, this is equivalent to provide endorsed libraries at runtime. I have found this resource, that looks a bit dated, but it may work. Not sure if Maven 3 offers a better solution http://www.mindbug.org/2009/02/adding-endorsements-to-mavens- plugins.html Claves -Original Message- From: Markus Karg [mailto:k...@quipsy.de] Sent: 20 September 2012 09:22 To: users@maven.apache.org Subject: How to put a dependency in the classpath BEFORE jre.jar? I have a dependency on javaee.jar, which provides newer versions for classes found in JRE's jre.jar (particularly the @Resource annotation). But javaee.jar is always appended to the classpath, while to be able to load the newer version, I need to PREFIX it before jre.jar instead. How can I configure this in the POM? The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG is a trading name of IG Markets Limited, a company registered in England and Wales under number 04008957. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the Financial Services Authority. FSA Register number 195355. - 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
How to put a dependency in the classpath BEFORE jre.jar?
I have a dependency on javaee.jar, which provides newer versions for classes found in JRE's jre.jar (particularly the @Resource annotation). But javaee.jar is always appended to the classpath, while to be able to load the newer version, I need to PREFIX it before jre.jar instead. How can I configure this in the POM?
RE: How to put a dependency in the classpath BEFORE jre.jar?
So there is no pure Maven support for this? -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Donnerstag, 20. September 2012 11:46 To: Maven Users List Subject: Re: How to put a dependency in the classpath BEFORE jre.jar? I *think* you should be able to do this by specifying an endorsed directory to be used. This would be standard Java procedure, nothing Maven specific. Something like the following in the config of (for example) the compiler plugin config: compilerargument-Djava.endorsed.dirs=blabla/compilerargument Should be possible to do something similar for test executions with surefire as well. /Anders On Thu, Sep 20, 2012 at 10:21 AM, Markus Karg k...@quipsy.de wrote: I have a dependency on javaee.jar, which provides newer versions for classes found in JRE's jre.jar (particularly the @Resource annotation). But javaee.jar is always appended to the classpath, while to be able to load the newer version, I need to PREFIX it before jre.jar instead. How can I configure this in the POM? - 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: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
This is a known bug. See:
http://jira.codehaus.org/browse/MJAR-156
http://jira.codehaus.org/browse/MACR-4
Please comment and vote these bugs that you also suffer from this problem
and want to see it fixed.
-Original Message-
From: it-media.k...@daimler.com [mailto:it-media.k...@daimler.com]
Sent: Mittwoch, 22. August 2012 15:18
To: users@maven.apache.org
Subject: Manifest of WAR contains wrong references to SNAPSHOT-versions
of EAR-based libaries
Hello,
I've come across a rather sever problem in our environment. We create
EAR-projects that contain WAR-modules and use the old-fashioned way to
handle skinny WAR-files by denoting the maven-war-plugin to exclude all
jar-files and rather put them in the EAR-lib-directory. This is done by
the following plugin configurations for EAR and WAR:
EAR-pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
version6/version
defaultLibBundleDirlib//defaultLibBundleDir
generateApplicationXmltrue/generateApplicationXml
archive
manifestEntries
Implementation-TitleDAAS BE/
Implementation-Title
Implementation-Version${project.version}
${timestamp}/Implementation-Version
/manifestEntries
/archive
security
security-role id=CONFIG
role-nameCONFIG/role-name
/security-role
security-role id=WEBSERVICE_GET
role-nameWEBSERVICE_GET/role-name
/security-role
security-role id=WEBSERVICE_SET
role-nameWEBSERVICE_SET/role-name
/security-role
/security
modules
webModule
groupIddaas-backend/groupId
artifactIddaas-backend-war/artifactId
contextRootDaas/contextRoot
bundleFileNamedaas-backend-war.war/
bundleFileName
/webModule
ejbModule
groupIddaas-backend/groupId
artifactIddaas-backend-
system/artifactId
bundleFileNamedaas-backend-system.jar/
bundleFileName
/ejbModule
/modules
/configuration
/plugin
WAR-pom.xml:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
failOnMissingWebXmlfalse/failOnMissingWebXml
packagingExcludesWEB-INF/lib/*.jar/
packagingExcludes
archive
manifest
addClasspathtrue/addClasspath
classpathPrefixlib//classpathPrefix
/manifest
/archive
/configuration
/plugin
However, in case a SNAPSHOT-version of a dependency is added to both,
the EAR and the WAR, the corresponding MANIFEST-ClassPath-Entry of the
dependency is created wrong as shown below:
Generated ClassPath:
Class-Path: daas-backend-system.jar lib/websphere-admin-client-2012.2.
0-SNAPSHOT.jar lib/logging-5.0.0.jar lib/util-5.0.0.jar lib/jaxb2-bas
ics-runtime-0.6.3.jar lib/websphere-admin-client-2012.2.0-20120822.03
1057-2.jar lib/poi-3.7.jar lib/commons-beanutils-1.8.3.jar lib/jbpm-j
pdl-4.5-20120709.122214-1.jar lib/jbpm-api-4.5-20120709.122204-2.jar
lib/jbpm-pvm-4.5-20120709.122211-1.jar lib/jbpm-log-4.5-20120709.1222
06-2.jar lib/hibernate-core-3.6.7.Final.jar lib/antlr-2.7.6.jar lib/c
ommons-collections-3.1.jar lib/dom4j-1.6.1.jar lib/hibernate-commons-
annotations-3.2.0.Final.jar lib/hibernate-jpa-2.0-api-1.0.1.Final.jar
lib/slf4j-api-1.6.1.jar lib/slf4j-jdk14-1.6.2.jar lib/commons-lang-2
.6.jar lib/soap-2.3.1.jar lib/guava-11.0.1.jar lib/jsr305-1.3.9.jar
Here the snapshots have been created as:
lib/websphere-admin-client-2012.2.0-20120822.031057-2.jar
lib/jbpm-jpdl-4.5-20120709.122214-1.jar
lib/jbpm-api-4.5-20120709.122204-2.jar
lib/jbpm-pvm-4.5-20120709.122211-1.jar
lib/jbpm-log-4.5-20120709.122206-2.jar
But the EAR-lib directory contains them as
lib/websphere-admin-client-SNAPSHOT.jar
lib/jbpm-jpdl-4.5-SNAPSHOT.jar
lib/jbpm-api-4.5-SNAPSHOT.jar
lib/jbpm-pvm-4.5-SNAPSHOT.jar
lib/jbpm-log-4.5-SNAPSHOT.jar
The only solution that I could think of to this is to manually add the
wrong dependencies by adding the following to the
RE: Best Practices for Passwords and Usernames
For security reasons it is a good idea to have the passwords encrypted on a
USB stick, see http://maven.apache.org/guides/mini/guide-encryption.html
-Original Message-
From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com]
Sent: Mittwoch, 15. August 2012 14:41
To: maven users
Subject: Best Practices for Passwords and Usernames
Are there some best practices around how and where to store usernames,
passwords and other secret information wrt the local user?
For example, what I have been doing in my user settings.xml is (the
following), but is there some other best practice I should be
following?
In particular, I am trying to set up conventions to be used from our
corporate POM that are based on a common 'user' profile.
Cheers, Eric
?xml version=1.0 encoding=utf-8?
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
profiles
profile
iduser/id
properties
com.perforce.p4maven.usernameEric_Kolotyluk/com.perforce.p4maven.use
rname
com.perforce.p4maven.passwordsecret/com.perforce.p4maven.password
org.apache.maven.plugins.maven-release-
plugin.username${com.perforce.p4maven.username}/org.apache.maven.plug
ins.maven-release-plugin.username
org.apache.maven.plugins.maven-release-
plugin.password${com.perforce.p4maven.password}/org.apache.maven.plug
ins.maven-release-plugin.password
/properties
/profile
/profiles
activeProfiles
activeProfileuser/activeProfile
/activeProfiles
/settings
-
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
AW: Failsafe Plugin: How to get resource dependencies for integration-tests?
Thanks to all for all the kind help! In fact I made it work, and the solution is as simple as using the dependency plugin: plugin artifactIdmaven-dependency-plugin/artifactId version2.4/version executions execution idcopy/id phaseintegration-test/phase goals goalcopy/goal /goals configuration artifactItems artifactItem groupIdG/groupId artifactIdA/artifactId versionV/version typedb/type destFileNamemyDbFile.db/destFileName /artifactItem /artifactItems /configuration /execution /executions /plugin Regards Markus -Ursprüngliche Nachricht- Von: Laird Nelson [mailto:ljnel...@gmail.com] Gesendet: Freitag, 27. Juli 2012 17:31 An: Maven Users List Betreff: Re: Failsafe Plugin: How to get resource dependencies for integration-tests? On Fri, Jul 27, 2012 at 7:27 AM, Martin Gainty mgai...@hotmail.com wrote: Marcus you can copy applicable resources with maven-resources-plugin http://maven.apache.org/plugins/maven-resources-plugin/examples/copy-resources.htmljustremember to hook the phase you want to bind to e.g. phasevalidate/phasemaven phases are listed here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecy cle.html You might also find this helpful: http://maven.apache.org/plugins/maven-remote-resources-plugin/ Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Failsafe Plugin: How to get resource dependencies for integration-tests?
Good point! :-) -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Montag, 30. Juli 2012 16:11 To: Maven Users List Subject: Re: Failsafe Plugin: How to get resource dependencies for integration-tests? I suggest binding to the pre-integration-test phase as there is no guarantee that the dependency plugin will always execute before failsafe if you are binding to the integration-test phase On 30 July 2012 11:12, Markus Karg k...@quipsy.de wrote: Thanks to all for all the kind help! In fact I made it work, and the solution is as simple as using the dependency plugin: plugin artifactIdmaven-dependency-plugin/artifactId version2.4/version executions execution idcopy/id phaseintegration-test/phase goals goalcopy/goal /goals configuration artifactItems artifactItem groupIdG/groupId artifactIdA/artifactId versionV/version typedb/type destFileNamemyDbFile.db/destFileName /artifactItem /artifactItems /configuration /execution /executions /plugin Regards Markus -Ursprüngliche Nachricht- Von: Laird Nelson [mailto:ljnel...@gmail.com] Gesendet: Freitag, 27. Juli 2012 17:31 An: Maven Users List Betreff: Re: Failsafe Plugin: How to get resource dependencies for integration-tests? On Fri, Jul 27, 2012 at 7:27 AM, Martin Gainty mgai...@hotmail.com wrote: Marcus you can copy applicable resources with maven-resources-plugin http://maven.apache.org/plugins/maven-resources-plugin/examples/copy- resources.htmljustrememberto hook the phase you want to bind to e.g. phasevalidate/phasemaven phases are listed here: http://maven.apache.org/guides/introduction/introduction-to-the- life cy cle.html You might also find this helpful: http://maven.apache.org/plugins/maven-remote-resources-plugin/ Best, Laird -- http://about.me/lairdnelson - 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
Failsafe Plugin: How to get resource dependencies for integration-tests?
Hello Maven Community, I have a complex setup to do for an end-to-end integration test. For this, I am using the Maven Failsafe plugin. As the test needs some resources to run (which I plan to put into Nexus as this feels just natural), I want to tell Maven that when the integration test is running, it shall download them and put them on the HDD. Is there a way to specifiy such intergration-test-scoped dependencies? Thanks! Markus
RE: No versions available but actually local repository contains it!
Even if I remove *all* hamcrest-core artifacts from my Nexus and local repo, Maven 3.0.4 again pulls some artifacts, but does not use 1.3 when I say [1.3]. But I want exactly 1.3. So what next to try? Can you give me an idea how a test case should be made up to let you reproduce this? -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Mittwoch, 25. Juli 2012 16:14 To: users@maven.apache.org Subject: RE: No versions available but actually local repository contains it! Importance: High javadoc suggests bracket version bracket or [version] for exact match http://maven.apache.org/plugins/maven-enforcer- plugin/rules/versionRanges.html if you specify a specifiv version such as version1.3/versionand you get any other version such as 1.1 or 1.2 then that is a bugperhaps a 1.2 or 1.1 was installed into 1.3 and you never had thie opportunity to update the .pom and plugin.xml to proper version? If you can provide a complete testcase on this behaviour...then please file a bug herehttp://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira. plugin.system.project%3Apopularissues-panel Thanks,Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Subject: No versions available but actually local repository contains it! Date: Wed, 25 Jul 2012 09:27:05 +0200 From: k...@quipsy.de To: users@maven.apache.org I have a very strange problem with Maven 3.0.4 running on JDK 1.6.0_26 on Win 7 Pro SP1 (64 Bit): When I want to compile, Maven says that it cannot resolve a dependency: No versions available for org.hamcrest:hamcrest-core:jar:[1.3,1.3] within specified range. But actually, Maven in fact successfully downloaded exactly that JAR and POM in exactly that version from Nexus (hence, from Maven Central in turn), as I can see the JAR and POM in both, my local repository and my Nexus instance! The weird thing is, if I replace [1.3] by [1.2] it does NOT complain about missing dependency! Weird, isn't it? And it gets even more weird: If I change my POM to relax the requested range from [1.2] to simply 1.2 (without braces, just to see what happens) it downloads version 1.1. But for what, if a 1.2 and 1.3 already are there? How can I fix this? I definitively need version 1.3, which IS available in my local repository, my Nexus instance and Maven Central! Thanks a lot! Markus - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: No versions available but actually local repository contains it!
How does that explain the local behaviour? I remove everything (the complete groupId folder) from my local repo and Nexus instance, trigger a build, and get the same problem again: The file with version 1.3 is then found in Nexus and local repo, but maven still says that 1.3 is not existing when forcing [1.3]. BTW, the problematic artifact is org.hamcrest:hamcrest-core:1.3. -Original Message- From: Milos Kleint [mailto:mkle...@gmail.com] Sent: Mittwoch, 25. Juli 2012 09:33 To: Maven Users List Subject: Re: No versions available but actually local repository contains it! there's some code in latest maven that not only checks the presence of the jar/pom in local repository but also some additional metadata which describes where it was downloaded from. where is defined by repository id. if the repository id in your project is missing in the current metadata, a new attempt will be made to download it. if it fails, the build fails as well. That way maven shoudl enforce that your project is always buildable with given pom content. Milos On Wed, Jul 25, 2012 at 9:27 AM, Markus Karg k...@quipsy.de wrote: I have a very strange problem with Maven 3.0.4 running on JDK 1.6.0_26 on Win 7 Pro SP1 (64 Bit): When I want to compile, Maven says that it cannot resolve a dependency: No versions available for org.hamcrest:hamcrest-core:jar:[1.3,1.3] within specified range. But actually, Maven in fact successfully downloaded exactly that JAR and POM in exactly that version from Nexus (hence, from Maven Central in turn), as I can see the JAR and POM in both, my local repository and my Nexus instance! The weird thing is, if I replace [1.3] by [1.2] it does NOT complain about missing dependency! Weird, isn't it? And it gets even more weird: If I change my POM to relax the requested range from [1.2] to simply 1.2 (without braces, just to see what happens) it downloads version 1.1. But for what, if a 1.2 and 1.3 already are there? How can I fix this? I definitively need version 1.3, which IS available in my local repository, my Nexus instance and Maven Central! Thanks a lot! Markus - 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
No versions available but actually local repository contains it!
I have a very strange problem with Maven 3.0.4 running on JDK 1.6.0_26 on Win 7 Pro SP1 (64 Bit): When I want to compile, Maven says that it cannot resolve a dependency: No versions available for org.hamcrest:hamcrest-core:jar:[1.3,1.3] within specified range. But actually, Maven in fact successfully downloaded exactly that JAR and POM in exactly that version from Nexus (hence, from Maven Central in turn), as I can see the JAR and POM in both, my local repository and my Nexus instance! The weird thing is, if I replace [1.3] by [1.2] it does NOT complain about missing dependency! Weird, isn't it? And it gets even more weird: If I change my POM to relax the requested range from [1.2] to simply 1.2 (without braces, just to see what happens) it downloads version 1.1. But for what, if a 1.2 and 1.3 already are there? How can I fix this? I definitively need version 1.3, which IS available in my local repository, my Nexus instance and Maven Central! Thanks a lot! Markus
RE: Issue-wise Crowdfunding platform for Maven
Would be good if each funding item would contain a link to the particular item in the project's tracker, so it is easier to learn about the issue's details. -Original Message- From: tony Tony [mailto:t...@freedomsponsors.com] Sent: Freitag, 13. Juli 2012 22:38 To: users@maven.apache.org; d...@maven.apache.org Subject: Issue-wise Crowdfunding platform for Maven Hi all, I have set up a website where people can place small money bounties for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or Jenkins, or Hibernate, or whatever). So far it's only got two real offers - and one of them I placed myself (JENKINS-9216: Make OpenID work with Google Apps accountshttp://www.freedomsponsors.com/core/issue/11/make-openid-work- with-google-apps-accounts ), but I really think that as it gets more popular, such a tool can have a big positive impact on a lot of open source projects, especially popular ones like Maven. If you think so too, I welcome you to use it -- www.freedomsponsors.com :-) Cheers Tony Lâmpada - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Issue-wise Crowdfunding platform for Maven
Just found it... It's a bit small and hidden due to the black colour. -Original Message- From: Markus KARG [mailto:mar...@headcrashing.eu] Sent: Sonntag, 15. Juli 2012 09:17 To: 'Maven Users List'; d...@maven.apache.org Subject: RE: Issue-wise Crowdfunding platform for Maven Would be good if each funding item would contain a link to the particular item in the project's tracker, so it is easier to learn about the issue's details. -Original Message- From: tony Tony [mailto:t...@freedomsponsors.com] Sent: Freitag, 13. Juli 2012 22:38 To: users@maven.apache.org; d...@maven.apache.org Subject: Issue-wise Crowdfunding platform for Maven Hi all, I have set up a website where people can place small money bounties for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or Jenkins, or Hibernate, or whatever). So far it's only got two real offers - and one of them I placed myself (JENKINS-9216: Make OpenID work with Google Apps accountshttp://www.freedomsponsors.com/core/issue/11/make-openid- work - with-google-apps-accounts ), but I really think that as it gets more popular, such a tool can have a big positive impact on a lot of open source projects, especially popular ones like Maven. If you think so too, I welcome you to use it -- www.freedomsponsors.com :-) Cheers Tony Lâmpada - 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
AW: How to correctly make an EJB module dependend of the interface JAR of a RAR?
Any other opinions? Any solutions? I cannot believe that an EAR must not only contain the RAR but also a duplicate (!) of the RA' public interface. -Ursprüngliche Nachricht- Von: Markus KARG [mailto:mar...@headcrashing.eu] Gesendet: Dienstag, 19. Juni 2012 22:26 An: Markus Karg Betreff: FW: How to correctly make an EJB module dependend of the interface JAR of a RAR? -Original Message- From: Stephen Coy [mailto:st...@resolvesw.com] Sent: Donnerstag, 23. Februar 2012 03:13 To: Maven Users List Subject: Re: How to correctly make an EJB module dependend of the interface JAR of a RAR? I suspect that you will have deployment issues if the EJB module does not have visibility of the interface classes. You should perhaps be placing this jar in the EAR/lib directory (assuming a JEE5+ compliant container) and sharing it between the RAR and EJB jar. On 22/02/2012, at 5:13 AM, Markus Karg wrote: I have set up a typical EAR scenario, where a EJB module and a RAR module are packaged into a EAR module (using the respective package types of ear, ejb and rar). To be able to compile the EJB module, I have to make it dependend of the interface JAR (which is later packed into the RAR) with compile scope. But, this leads to the fact that the EAR later contains not only the EJB and the RAR, but also the interface JAR. As the interface JAR already is contained in the RAR, this is redundant. What is The Maven Way to prevent this redundance, so the EAR will not contain the additional interface JAR? - 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: How to correctly make an EJB module dependend of the interface JAR of a RAR?
I understand your concerns, but as a Jave EE server very well knows what a RAR is good for and how it is structured, it should be able to provide the interface JAR without the need for physical duplication. In the end, to make this clear to the server, this is the sole reason for the complexity of RAR packaging. -Original Message- From: Laird Nelson [mailto:ljnel...@gmail.com] Sent: Montag, 25. Juni 2012 15:49 To: Maven Users List Subject: Re: How to correctly make an EJB module dependend of the interface JAR of a RAR? On Mon, Jun 25, 2012 at 2:27 AM, Markus Karg k...@quipsy.de wrote: Any other opinions? Any solutions? I cannot believe that an EAR must not only contain the RAR but also a duplicate (!) of the RA' public interface. Recall that a .rar can be deployed as a standalone module, consumable by other modules (including .ears) on the application server. A .rar's public interface could therefore be required both by the .rar itself (to provide an appropriate connection factory, etc.), and by the callers in some .ear somewhere that use it. That is, I believe, the rationale for the interface duplication. For my resource adapters, I have three small Maven projects: * The public API project. This is basically interfaces only. It depends on nothing. * A jca project. This is the logic of the resource adapter. It depends solely on the public API and the JCA classes (provided scope). * A rar project. This is packaging only and depends on the other two. In my .ear file (for application-scoped .rars, which is what you're talking about, which makes deployment with GlassFish very difficult, incidentally, but that's a side issue), I include the public API project as a runtime dependency (it ends up in the lib directory) and the rar project as a typerar/type runtime dependency (it ends up at the root level). Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven for Software Installation
Ideally for this, Maven (and such, the JVM) would be contained as an itegral part of the popular operating systems like Windows, MacOS and Linux. What a perfect world. ;-) -Original Message- From: Eric Kolotyluk [mailto:eric.koloty...@gmail.com] Sent: Donnerstag, 21. Juni 2012 21:54 To: Maven Users List Subject: Maven for Software Installation I have brought this notion up before, but I have been thinking about it a bit more. Would it make sense to use Maven technology for software deployment and installation as opposed to just builds? What I envision is something akin to the Global Assembly Cache in .NET, but for Maven artifacts. In particular, the local repository would act like a GAC, but you might want to separate a system local repository from the user local repositories. The basic idea is that when deploying/installing software you would not bundle all your dependent artifact into your installer, rather you would just bundle their coordinates. At installation time you would install the Maven Installer if it was not already there, then your installer would work in conjunction with the Maven Installer. Basically the Maven Installer subsystem would simply download the dependent artifacts from Maven Central or elsewhere, and put them in the System Repository (similar to the GAC). One benefit of this is that if you have a lot of software that all reference the same artifacts, they can share copies. Other benefits would be similar to those for the .NET GAC, although hopefully we could avoid some of the problems the GAC has created. Another benefit is that installers could be smaller by not bundling in dependent artifacts. Installation could be faster in that if dependent artifacts are already in the System Repository downloading and installing them is unnecessary. So am I just thinking crazy, or is there any potential benefit to this idea? Cheers, Eric - 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: How to tell EAR packager to use the exact names created by addClasspathtrue/addClasspath?
Maven is 3.0.4 What exactly do you think is the bug: The fact that Class-Path is replacing -SNAPSHOT by version, or the fact that EAR plugin is NOT doing so? Thanks! Markus -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Montag, 12. März 2012 11:21 To: Maven Users List Subject: Re: How to tell EAR packager to use the exact names created by addClasspathtrue/addClasspath? Sounds like a bug when building a multi-module project. File a JIRA ticket with a test project to recreate the issue. Also, if you're not using Maven 3, try to build with that as well to see if that solves the problem. /Anders On Mon, Mar 12, 2012 at 10:06, Markus Karg k...@quipsy.de wrote: I am using the ear and acr plugins to build an ear that contains an app-client. It all works well but one thing is always wrong: The car must use addClasspathtrue/addClasspath so the client will find the needed libraries. When those libraries are SNAPSHOTs, the created manifest entry contains not SNAPSHOT but the latest date (as usual with SNAPSHOTs). But the ear plugin doesn't care for this. It always uses SNAPSHOT (the word, not the latest version). As a result, at runtime the client will not find the needed libraries, as it looks for it by date, but it actually is named SNAPSHOT. For me this looks like a bug in the conception of the EAR plugin: It must not statically build the name from the version string, but it certainly needs to use the actual name of the artifact (here: the date of the snapshot). Is that really a bug or am I too dumb to see the light? ;-) Regards Markus - 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
How to tell EAR packager to use the exact names created by addClasspathtrue/addClasspath?
I am using the ear and acr plugins to build an ear that contains an app-client. It all works well but one thing is always wrong: The car must use addClasspathtrue/addClasspath so the client will find the needed libraries. When those libraries are SNAPSHOTs, the created manifest entry contains not SNAPSHOT but the latest date (as usual with SNAPSHOTs). But the ear plugin doesn't care for this. It always uses SNAPSHOT (the word, not the latest version). As a result, at runtime the client will not find the needed libraries, as it looks for it by date, but it actually is named SNAPSHOT. For me this looks like a bug in the conception of the EAR plugin: It must not statically build the name from the version string, but it certainly needs to use the actual name of the artifact (here: the date of the snapshot). Is that really a bug or am I too dumb to see the light? ;-) Regards Markus
RE: EAR project produces application.xml, but EJB module is missing
What do you mean with maps to? -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Sonntag, 4. März 2012 13:01 To: Maven Users List Subject: Re: EAR project produces application.xml, but EJB module is missing Because ejb type maps to jar extension On Sunday, 4 March 2012, Markus KARG mar...@headcrashing.eu wrote: You are right, when adding typeejb/type it is working! I missed the fact that maven coordinates include the packaging, while the default packaging is typejar/type. The odd thing is that dependency resolution is working without that. So it actually seems, module resolution is working correctly while dependency resolution ignores type. Thanks a lot! Markus -Original Message- From: Stephen Coy [mailto:st...@resolvesw.com] Sent: Sonntag, 4. März 2012 09:44 To: Maven Users List Subject: Re: EAR project produces application.xml, but EJB module is missing The number one reason I've had this problem in the past is forgetting to specify: typeejb/type in the dependency declarations for EJB jars. On 04/03/2012, at 2:33 AM, Markus KARG wrote: Maven 3.0.4 is producing application.xml containing module entries for some dependencies (RAR modules), but which is missing module entries for other dependencies (EJB modules). This is weird as the pom more or less is empty. It just contains the dependencies (RAR modules and EJB modules) and Java EE version (6). So I assume one cannot do wrong. Is that a bug in Maven or what the heck is the trick to get module entries for EJB modules? - 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: EAR project produces application.xml, but EJB module is missing
You are right, when adding typeejb/type it is working! I missed the fact that maven coordinates include the packaging, while the default packaging is typejar/type. The odd thing is that dependency resolution is working without that. So it actually seems, module resolution is working correctly while dependency resolution ignores type. Thanks a lot! Markus -Original Message- From: Stephen Coy [mailto:st...@resolvesw.com] Sent: Sonntag, 4. März 2012 09:44 To: Maven Users List Subject: Re: EAR project produces application.xml, but EJB module is missing The number one reason I've had this problem in the past is forgetting to specify: typeejb/type in the dependency declarations for EJB jars. On 04/03/2012, at 2:33 AM, Markus KARG wrote: Maven 3.0.4 is producing application.xml containing module entries for some dependencies (RAR modules), but which is missing module entries for other dependencies (EJB modules). This is weird as the pom more or less is empty. It just contains the dependencies (RAR modules and EJB modules) and Java EE version (6). So I assume one cannot do wrong. Is that a bug in Maven or what the heck is the trick to get module entries for EJB modules? - 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
EAR project produces application.xml, but EJB module is missing
Maven 3.0.4 is producing application.xml containing module entries for some dependencies (RAR modules), but which is missing module entries for other dependencies (EJB modules). This is weird as the pom more or less is empty. It just contains the dependencies (RAR modules and EJB modules) and Java EE version (6). So I assume one cannot do wrong. Is that a bug in Maven or what the heck is the trick to get module entries for EJB modules?
How to correctly make an EJB module dependend of the interface JAR of a RAR?
I have set up a typical EAR scenario, where a EJB module and a RAR module are packaged into a EAR module (using the respective package types of ear, ejb and rar). To be able to compile the EJB module, I have to make it dependend of the interface JAR (which is later packed into the RAR) with compile scope. But, this leads to the fact that the EAR later contains not only the EJB and the RAR, but also the interface JAR. As the interface JAR already is contained in the RAR, this is redundant. What is The Maven Way to prevent this redundance, so the EAR will not contain the additional interface JAR?
How to deal with maintenance branches?
What is Maven 3's best practice to deal with Maintenance Branches (non-feature, bug-fix-only line of development)? Our company needs to maintain a second development line besides trunk, which we call The Maintenance Branch, for those customers having signed a maintenance contract for one particular version (e. g. when signed for 1.1.0 he will receive bug fixes 1.1.* but not features 1.2.*). This means, besides trunk (which always contains the latest features), we have branches/1.1-maintenance (with 1.1 being the version number that this branch was forked from to further get bug fixed but not feature-extended). Due to the rules of the contracts, in that branches, all bug fixes must go in, but no new features. Before using maven this was simple, as it was completely manual work. But now we start using Maven, and get into some CI and dependency trouble. In trunk we always have SNAPSHOT versions, obviously, as we add features daily til we reach the release day. Just when we do a release (1.0, 2.0, etc.) we use the maven release plugin to get tagged branches (non-SNAPSHOT). From those tagged branches, we copy our maintenance branches (using svn cp directly as we do not know how to tell maven to do so, BTW). So, the maintenance branch is NOT a SNAPSHOT version, as the release obviously is never a SNAPSHOT version. Now we like to use CruiseControl to do CI. We expect no problems in trunk as all are SNAPSHOT versions, so a change to a dependency will trigger maven2snapshotdependency to effectively compile and test the dependent project each time the dependency changes (as the name says: it detects snapshot changes of dependencies). Great! But what to do with the Maintenance Branch? As soon as we merge a fix for a dependency into that svn branch, we want CruiseControl to do CI. But we do not expect that maven2snapshotdependency will recognize the modified dependency -- as the maintenance branch is not SNAPSHOT (as it was created by copying the release tag in svn). We need a solution for THAT and have NO CLUE! We had the idea that we could just manually increase the version's z (from x.y.z) of the product with each merged fix to express that this is a bug fix, and add -SNAPSHOT to all projects in the Maintenance Branch to activate the maven2snapshotdependency again. I assume that would work. But, besides a LOT of manual work (we have nearly one hundred projects), we would break the possibility to replace a JAR inside a customer's installation (i. e. to actually provide the fix to the requesting customer): As Maven's best practice is to add the version to the name, increasing the minor version to express the bug fix level would result in dependencies getting not found by the JVM's classloader anymore, as Java's META-INF dependency resolution technology cannot deal with partially changed names but insists on the exact same JAR name (and such the version number) of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-JAR). We could provide a custom artifact name to the pom enforcing abc-x.y.0.jar always, but as it seems, this is not Maven's best practice (otherwise maven would do it automatically), so we assume there is a totally different solution we just do no see. So please, Maven Experts in this forum, enlight us! What is The Maven Way of dealing with Maintenance Branches? What is the big trick that we just do not see to get CI and dependency JAR loading running on bug-fix-only branches? Many, many thanks in advance. We know this is a very specific question, but everything else is solved and this one blocks us. :-) Regards Markus
How to readl with maintenance branches?
What is Maven 3's best practice to deal with Maintenance Branches (non-feature, bug-fix-only line of development)? Our company needs to maintain a second development line besides trunk, which we call The Maintenance Branch, for those customers having signed a maintenance contract for one particular version (e. g. when signed for 1.1.0 he will receive bug fixes 1.1.* but not features 1.2.*). This means, besides trunk (which always contains the latest features), we have branches/1.1-maintenance (with 1.1 being the version number that this branch was forked from to further get bug fixed but not feature-extended). Due to the rules of the contracts, in that branches, all bug fixes must go in, but no new features. Before using maven this was simple, as it was completely manual work. But now we start using Maven, and get into some CI and dependency trouble. In trunk we always have SNAPSHOT versions, obviously, as we add features daily til we reach the release day. Just when we do a release (1.0, 2.0, etc.) we use the maven release plugin to get tagged branches (non-SNAPSHOT). From those tagged branches, we copy our maintenance branches (using svn cp directly as we do not know how to tell maven to do so, BTW -- we expect that release:branch could do this in future but we have not checked it so far). So, the maintenance branch is NOT a SNAPSHOT version, as the release obviously is never a SNAPSHOT version. Now we like to use CruiseControl to do CI. We expect no problems in trunk as all are SNAPSHOT versions, so a change to a dependency will trigger maven2snapshotdependency to effectively compile and test the dependent project each time the dependency changes (as the name says: it detects snapshot changes of dependencies). Great! But what to do with the Maintenance Branch? As soon as we merge a fix for a dependency into that svn branch, we want CruiseControl to do CI. But we do not expect that maven2snapshotdependency will recognize the modified dependency -- as the maintenance branch is not SNAPSHOT (as it was created by copying the release tag in svn). We need a solution for THAT and have NO CLUE! We had the idea that we could just manually increase the version's z (from x.y.z) of the product with each merged fix to express that this is a bug fix, and add -SNAPSHOT to all projects in the Maintenance Branch to activate the maven2snapshotdependency again. I assume that would work. But, besides a LOT of manual work (we have nearly one hundred projects), we would break the possibility to replace a JAR inside a customer's installation (i. e. to actually provide the fix to the requesting customer): As Maven's best practice is to add the version to the name, increasing the minor version to express the bug fix level would result in dependencies getting not found by the JVM's classloader anymore, as Java's META-INF dependency resolution technology cannot deal with partially changed names but insists on the exact same JAR name (and such the version number) of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-JAR). We could provide a custom artifact name to the pom enforcing abc-x.y.0.jar always, but as it seems, this is not Maven's best practice (otherwise maven would do it automatically), so we assume there is a totally different solution we just do no see. So please, Maven Experts in this forum, enlight us! What is The Maven Way of dealing with Maintenance Branches? What is the big trick that we just do not see to get CI and dependency JAR loading running on bug-fix-only branches? Many, many thanks in advance. We know this is a very specific question, but everything else is solved and this one blocks us. :-) Regards Markus
RE: How to readl with maintenance branches?
Thank you for opening the discussion. :-) I see two problems with the idea of lib-1.1.1-SNAPSHOT in the maintenance branch of what was previously released as lib-1.1: (1) The original app-1.1.0.jar was delivered to the customer with META-INF/MANIFEST.MF containing Class-Path: entries for dependency loading of lib-1.1.0.jar. If we now provide lib-1.1.1.jar, the JVM's original classloader is unable to find the new jar, obviously. As a solution we could deliver JARs that have version-free artifact names (so any bug fix JAR would match), but we noticed that mvn deploy ignores this setting (while mvn install respects it). So it simply does not work. Another idea would be to provide virtually unchanged app-1.1.1.jar in turn containing a different Class-Path entry for the renamed dependency, but I doubt that CruiseControl is able to provide such logic so it will end up in lots of manual version upgrading work, which we do not want to perfom manually (but certainly we expect this to be the most pure and clean way to deal with it, as it clearly expresses that a change in the lib results in a change of the app). (2) As we have to provide a tested hot fix jar ASAP after fixing a bug, actually EACH commit to the SCM in the maintenance branch has to force a mvn deploy on the CI server -- to the RELEASE (!) repository, as it will get sent away to the customer and is not just waiting in the SNAPSHOT repository for some fine day when we think it is time to assemble and ship a completely updated maintenance installer bundle. As the project is in SNAPSHOT state, it will publish to the SNAPSHOT directory. See, ALL commits to the maintenance branch actually are completed fixes and there are no commits for half-done things. So to make the artifact end up in the right (public, RELEASE) repository, it simply must not be declared as being a SNAPSHOT (while actually you are right, it in fact IS a SNAPSHOT, but one that in turn is to be RELEASEd immediately). A workaround would be to run mvn scm:checkin release:prepare mvn:perform by the developer of the fix (instead of simple svn commit) but this looks a bit scary as we have to do it for each single fix. In a large company with a second QA contact having to test first this wouldn't be an issue I think, but as we simply rely on the CI server to do the tests we in fact do not have a two-step release approach but the CI server MUST release the fix if the tests are OK. So you see, we in fact have ideas for solutions, but we like to know what the real Maven Way is to deal with this questions. :-) Regards Markus -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Samstag, 11. Februar 2012 15:53 To: Maven Users List Subject: Re: How to readl with maintenance branches? There are better experts in the forum who know more about CI but I can make at least 1 contribution that might help. I am not sure that your situation is that uncommon. I am not sure why you would not have SNAPSHOTs on the maintenance branch. We would expect to have versions 1.1, 1.1.0-SNAPSHOT and 1.2-SNAPSHOT all in existence at the same time if we had a 1.1 in production and were simultaneously developing 1.2 while fixing 1.1 by creating a 1.1.0 version to be delivered to the 1.1 clients. We do not use CI so we would probably have a test environment where many of the modules would be quickly moved to 1.1.1 since they are not affected by the bug fix while some of the modules would be a 1.1.0- SNAPSHOT until they had passed the testing. I hope that this moves the conversation forward. Ron On 11/02/2012 7:11 AM, Markus KARG wrote: What is Maven 3's best practice to deal with Maintenance Branches (non-feature, bug-fix-only line of development)? Our company needs to maintain a second development line besides trunk, which we call The Maintenance Branch, for those customers having signed a maintenance contract for one particular version (e. g. when signed for 1.1.0 he will receive bug fixes 1.1.* but not features 1.2.*). This means, besides trunk (which always contains the latest features), we have branches/1.1-maintenance (with 1.1 being the version number that this branch was forked from to further get bug fixed but not feature-extended). Due to the rules of the contracts, in that branches, all bug fixes must go in, but no new features. Before using maven this was simple, as it was completely manual work. But now we start using Maven, and get into some CI and dependency trouble. In trunk we always have SNAPSHOT versions, obviously, as we add features daily til we reach the release day. Just when we do a release (1.0, 2.0, etc.) we use the maven release plugin to get tagged branches (non- SNAPSHOT). From those tagged branches, we copy our maintenance branches (using svn cp directly as we do not know how to tell maven to do so, BTW -- we expect that release:branch could do
Is there a mavenized library for copying files?
I am writing a plugin which needs to copy files. Since the File.rename() command can fail if source and target are on different drives, and since I don't want to write my own byte mover loop, I wonder whether there is an out-of-the-box file copy / file move library that I can just call?
RE: Version range excluding SNAPSHOTs
So this means that there is no *real* solution to get alphas but not SNAPSHOTs? [1.0,1.1-!) 1.0-SNAPSHOT 1.0 1.1-SNAPSHOT 1.1 But in ASCII ! is A therefore 1.1-! 1.1-SNAPSHOT 1.1 1.1-! is also 1.1-alpha-1 My project is dependent of some library. I want to always use the latest bugfix but not any new features. So I added version[1.0,1.1)/version which allows me to use all bugfixes of the 1.0 release. But when I check the actually used version, I see that 1.1-SNAPSHOT is getting used! How can I prevent this? Is there a way to say anything between 1.0 smaller than 1.1, but NOT SNAPSHOTS? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Version range excluding SNAPSHOTs
Will that prevent usage of 1.0.1-SNAPSHOT but allow 1.0.1-alpha-1 through 1.0.-zzz-99 ? how about [1.0,1.1-SNAPSHOT) ? So this means that there is no *real* solution to get alphas but not SNAPSHOTs? [1.0,1.1-!) 1.0-SNAPSHOT 1.0 1.1-SNAPSHOT 1.1 But in ASCII ! is A therefore 1.1-! 1.1-SNAPSHOT 1.1 1.1-! is also 1.1-alpha-1 My project is dependent of some library. I want to always use the latest bugfix but not any new features. So I added version[1.0,1.1)/version which allows me to use all bugfixes of the 1.0 release. But when I check the actually used version, I see that 1.1-SNAPSHOT is getting used! How can I prevent this? Is there a way to say anything between 1.0 smaller than 1.1, but NOT SNAPSHOTS? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Version range excluding SNAPSHOTs
My project is dependent of some library. I want to always use the latest bugfix but not any new features. So I added version[1.0,1.1)/version which allows me to use all bugfixes of the 1.0 release. But when I check the actually used version, I see that 1.1-SNAPSHOT is getting used! How can I prevent this? Is there a way to say anything between 1.0 smaller than 1.1, but NOT SNAPSHOTS?
[Plugin-Development] Why is my plugin not executed?
I have developed an empty plugin, that does nothing, just to learn how to do it. It works well directly but is not executed in the default @phase?! The mojo echos a message to the user, and it is annotated as @phase generate-resources which seems to be done correctly as the resulting plugin.xml contains: phasegenerate-resources/phase I have installed the plugin in my local repository and when executing that mojo manually (mvn myplugin:mymojo) I can see the echo message. Then I bound the plugin to a sample project (that also does nothing, just an instance of the quickstart archetype): 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 groupIdsample/groupId artifactIdsample/artifactId packagingjar/packaging version1.0-SNAPSHOT/version build plugins plugin artifactIdmaven-my-plugin/artifactId /plugin /plugins /build /project But when running mvn compile, my mojo is NOT called. Why? It looks like the phasegenerate-resources/phase is getting ignored! Using mvn -X compile I can see that the plugin is detected and correctly resolved, but not executed...?! ... Maven version: 2.0.10 Java version: 1.6.0_10 OS name: windows xp version: 5.1 arch: x86 Family: windows ... [DEBUG] maven-my-plugin: resolved to version 0.1-SNAPSHOT from local repository ... [DEBUG] maven-my-plugin: using locally installed snapshot [DEBUG] maven-my-plugin: using locally installed snapshot ... ...But no other lines containing the name of my plugin...! Any help appreciated! :-) Thanks Markus
Extension-List:
I need to create a JAR file that has Extension-List: entries inside, since it is dependent of several Java Optional Extensions installed in jre/lib/ext. How can I tell Maven2 that my project is dependent not of another Maven project, but of a standard extension (so that it does not create Class-Path: but Extension-List:)? -- QUIPSY QUALITY GmbH Ein Unternehmen der MES-Gruppe Stuttgarter Strasse 23 D-75179 Pforzheim Tel: 07231-9189-52 Fax: 07231-9189-59 www.quipsy.de [EMAIL PROTECTED] Registergericht Mannheim HRB 502922 Geschäftsführer: Reiner J. Marquart Diese E-Mail enthält persönliche, vertrauliche und vor Weitergabe geschützte Informationen und ist ausschließlich für den vorgesehenen o.g. Empfänger (Adressaten) bestimmt. Falls Sie diese E-Mail versehentlich erhalten haben und nicht der vorgesehene Empfänger sind, bitten wir Sie, die E-Mail und deren Anhänge nicht aufzubewahren, nicht zu vervielfältigen, nicht zu nutzen und nicht weiterzugeben. Bitte informieren Sie uns als Absender über diesen Zustellungsfehler und löschen Sie die E-Mail. begin:vcard fn:Markus KARG, staatl. gepr. Inf. n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Leiter Implementierung und Design / Leader Implementation and Design tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
How to query our own repository?
We have just set up our own repository server in our department and deployed several artefacts into it. Now I need to tell my project that it has to look for a dependency not only at Ibiblio, but also in my our department's repository. Since the department's repository shall be the central place for all sharing, I don't like to put that into the pom.xml of my project, but I want to have it in my laptop's settings.xml. How do I do that? Thanks a lot Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: AS400
Maven is 100% pure Java. So if you have Java on your AS400 (which is available from IBM AFAIK) why not just giving it a try and let us all know? ;-) Have Fun Markus Johan Vogelzang schrieb: Does Maven run on AS400 machine's? Thanx begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Feature Request: Improved support for third party JARs
Dear Maven Community, currently Maven's support for third party JARs (i. e., JARs not built with Maven that do not have the version found in their file name) is problematic. If you have followed the FOP discussion lately happened in this list, you will understand that there is a need to improve Maven's support for JARs with Non-Mavenized-Names. I have files a feature request with the JIRA system on Codehaus. If you are interested in this feature, please log in and vote for it. Here is the URL: http://jira.codehaus.org/browse/MNG-2572 Thanks Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
Carlos, I don't know if you ALSO read the part where I said that I will provide another pom.xml instead of another binary (it was your solution proposal, actually)? Markus Carlos Sanchez schrieb: I don't know if you ALSO read the part where I said we DO NOT repackage binaries, so your proposed solution is not acceptable.. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: Carlos Sanchez schrieb: fop 0.20.5 pom was provided by Joerg Schaible http://jira.codehaus.org/browse/MEV-386 That was at the point we allowed changing poms in the repo, now it is not possible to change that pom. Jörg, why do you discuss things with me under this topic but not telling me that YOU was the one providing the bug? Why hiding this information? No one will blame you for your fault, we're just looking for a solution. Carlos, thank you. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Repository Policy
Actually I don't know it myself, since I am a beginner. But there must be a Maven way to solve the problem (otherwise this would make install:install-file totally useless, since least pre-packaged binary are named in the correct way using -x.y.z versions). I'll start another thread to ask for help on this. Thanks Markus Carlos Sanchez schrieb: ok, provide the pom, and explain the reasons in a jira, because for what I read till now I don't see how the heck are you gonna solve it in a maven way. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
Jörg Schaible schrieb: Markus KARG wrote on Thursday, September 21, 2006 9:27 AM: Carlos, I don't know if you ALSO read the part where I said that I will provide another pom.xml instead of another binary (it was your solution proposal, actually)? When do *you* get it, that you cannot provide a POM that matches this class path: As soon as someone tells me. Thank you for doing it. As I wrote days before, I am a Maven starter. Nobody ever told me that it is impossible to say I need a jar but it doesn't have a version. Thank you for beeing so kind to teach me. :-) So actually there is no solution then, but the problem still exists. I can workaround locally, but this cannot be the end of the story. So I will file a request for enhancement with Maven itself. Thanks a lot Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Repository Policy
Jörg was so kind to tell me that this is not possible in Maven, I didn't know before (actually this is written nowhere and there was no real concensus on the version policy of Maven -- some where talking about planned features, some where talking about the schema only beeing a good advice and so on). Know I know. Discussions can be so easy once everyone understands that not everyone is a Maven professional. :-) Thanks Markus Carlos Sanchez schrieb: As I said somewhere you'll have to probably rename the jars AFTER downloading if you want them to match the manifest On 9/21/06, Markus KARG [EMAIL PROTECTED] wrote: Actually I don't know it myself, since I am a beginner. But there must be a Maven way to solve the problem (otherwise this would make install:install-file totally useless, since least pre-packaged binary are named in the correct way using -x.y.z versions). I'll start another thread to ask for help on this. Thanks Markus Carlos Sanchez schrieb: ok, provide the pom, and explain the reasons in a jira, because for what I read till now I don't see how the heck are you gonna solve it in a maven way. On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: When you build A you don't know anything about C-2.0.1 because it does not exist. Versions in repository explicitly define what versions the have been released against or tested with. If I release A 2.0 depending in C 2.0 and then I want to say i'm compatible with C 2.0.1 I have to update myself releasing A 2.0.1, because people using A 2.0 may not be compatible with C 2.0.1 and don't want automatic change of version That's what I think, too. And that's the reason, why fop-0.20.5.jar is correct while the pom.xml provided is incorrect: The pom assumes later versions to become dependencies, while the JAR itself doesn't include versions. So a pom has to be provided that depends on version-free JAR names. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
Jörg, No need to, it will be rejected. See, how could Maven ever locate and download a unique artifact without a version? That's one of the critical poiints providing a POM for a library that is not build with Maven. First you have to look at the provided docs to learn about the deps and their versions, then you'll examine the provided jars - since the docs are often out of date. If the jars have versions in their names, good. If not, look at the manifest and take the implementation version. If the manifest is vanilla, it gets problematic. I meanwhile take the date of the manifest itself in the jar for such a version: org.whatever.group:archive-with-vanilla-manifest:20040323.123456 And it can be cumbersome if you try to publish the pom here - for FOP I also had to provide the POMs for the JAI artifacts ... But any of this actions does not help if the original artifact defines a classpath in its manifest. There are two problems: 1/ the referenced artifacts have no version 2/ Maven selects a different version integrating the artifact into a container First problem is not solvable - at least not within the public repo. Second problem might just indicate a version problem that cannot be solved either, since Maven has a reason to select a different version, becasue other artifacts reference the same dep in a different version. To resolve your case, I would first establish a private repo for your group/company. Then create a FOP jar without that classpath entry (e.g. with version 0.20.5-company-1) and add it to this repo. The use a company wide global POM where you define in the dependencyManagement that FOP version. Nevertheless you have to know, that any other 'public' artifact depending on FOP will reference the other version, so you have to take care of this. The only possible solution for ibiblio would be a release of the jar without the manifest entry from the FOP team. But I doubt that will ever happen, since they work since years on the next version ;-) thank you for this additional words. Actually it was not clear to me that I cannot tell Maven that a dependancy has to be taken as it is (without adding a version number). Certainly it is well known to me that Maven has a version adding facility, but it is not written somewhere that it cannot be switched off. Also I think writing a request for enhancement will get rejected in any ways: My proposal would be to add a pom entry that specifies Maven: This is the actual JAR name, do not try to further do anything with it.. Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
That's wrong. Maven automatically creates the correct Class-Path attributes in the manifest, and it's up to the fop team to decide what third party library versions to use. No! If any library would declare a Class-Path in its deps, you could nearly use none in combination. Just because you can Maven configure to generate it, it is not said that it makes any sence. The classpath entry are useful for jars that behave as applications, but not for libraries that are suppoed to be used by applications. Actually you can use it because the classes in the Class-Path entry of one jar will be taken into account only by fop. If you have other libs that need other versions, those can use them since the Class-Loader-Hierarchy will take respect of that (if not, it is a bug in the JRE). begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
Wayne Fay schrieb: As previously mentioned, it is quite honestly not possible to fix that specific version of the pom. For a very brief period of time, Maven was allowing changes to poms but then realized this was a bad idea. So instead the proper way to fix issues like this is to actually release a new version of the Maven artifact including an updated pom. That's why I am asking for the name of the maintainer, so that I can ask him to do that... As for the question who is the maintainer of this pom -- unless the FOP team has specifically taken over the Maven artifact for their project, **anyone** can be the maintainer. This means you, or me, or any one else interested enough in Maven and FOP to actually do the work and submit the Maven Upload JIRA. So anyone can just put up some buggy JARs into that repository. Do you think this to be beneficial for the overall quality of the content...? In this case, I would suggest the following, as you appear to be very well versed in this particular artifact and it sounds like the FOP team does not currently maintain the pom file... Not only not currently. THEY HAVE NEITHER WRITTEN IT. THE FOP TEAM DOES NOT AT ALL KNOW OF ITS PURE EXISTENCE. Clear now? ;-) Download the FOP source code (or binary if you won't compile it) for version 0.20.5 Download the pom.xml for version 0.20.5 Alter the pom.xml as needed and bump version to 0.20.5.1 Compile the source code if needed and package the JAR Create the Maven artifact bundle using the new 0.20.5.1 pom (Install this artifact in your local repo and make sure it works like you expect by using it in your project, check the Class-Path etc) Create a new Maven JIRA for this new version and attach your new bundle to the issue Wait for feedback from Carlos et al and hope you didn't screw anything up; if so, adjust your bundle as requested and re-upload Once accepted, the new artifact will appear in Central So actually Carlos is the maintainer? That's all I liked to know actually. So I'll look into doing that. This is your best approach (imo) to get this updated FOP artifact installed in the Maven Repo. Unless of course someone else has a better suggestion... You asked about quality control previously... The assumption is that the people contributing builds to Maven are competent enough to create proper builds with reasonable pom.xml files etc. Ideally every Java project will eventually take over as maintainers of the Maven artifact but this is not required, nor is it entirely reasonable to expect it to ever occur. You need to know that our company is deeply involved into the business of quality assurance. So what you write is wrong. Nobody can rely on others to be good enough. You need to control quality EVER. As a proof, see the FOP project. Nobody knows where the author of that buggy pom.xml was, and it needed a two days discussion on how to fix it. That's not quality assurance, that's pure random. This is acceptable for any repository, but not for that one that is listed automatically with every installation of Maven 2.0.4. While there is some checking and testing before artifacts are installed into Central, in general, its not reasonable to expect the handful of Maven Repo maintainers to know everything about every project, so instead they simply trust the community and provide a way to easily update the artifacts, so when problems appear, the community can easily take care of it. Maven automatically looks for updates to artifacts, so new versions are pulled down and used as they are made available. Well, in case of FOP this trust doesn't seem to work... Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
i.e. No on maintains the FOP available in the repo. It is there as a convenience only. I might also suggest you adjust your attitude. Sorry for beeing rude and thank you for telling me. It wasn't my intention. But see, I just want to know who is the guy that has write access to the FOP's pom.xml. After two days I get told Carlos, while Carlos actually wasn't able to tell me that directly in his first email. Isn't it ironic to discuss two days (over 20 emails) instead of just writing Hi, I'm Carlos, it's me whom you have to send the fixed pom.xml? Don't you think you would be a bit rude then, too? Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
Barrie Treloar schrieb: Carlos did tell you who maintains it and the answer is no one. Carlos is just one of the people who will upload your pom and artifact if you follow the instructions on the web site. So you are able to make the necessary changes and get it fixed. The problem that Jorg points out is still outstanding is what naming conventions should be used to indicate that this fixes a problem with an already released version of the artifact. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If Carlos is able to upload it while I seem not to be, he actually is in the role of the maintainer. Where am I going wrong with that assumption? Markus begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
So the policy is A bug cannot be fixed?! Jochen Wiedmann schrieb: Markus KARG wrote: If Carlos is able to upload it while I seem not to be, he actually is in the role of the maintainer. Where am I going wrong with that assumption? Your assumption is, that he is able to change files in the repository. The answer is he isn't. Ok, he may be able to do that technically, but the policy is clearly that already released files are left unchanged - forever. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
So since bugs once released cannot get fixed without changing the version (what is problematic with FOP as we have discussed today), this is one more reason for not let anybody upload things without doing quality control. :-) Wayne Fay schrieb: Yes, this is the point of the discussion. Please search this mail list (Nabble etc) and Maven Dev to see the entire history of this issue. Increment version by one, upload it, and allow Maven to find the updated version the next time your build runs, it will automatically find and use it. Wayne On 9/20/06, Markus KARG [EMAIL PROTECTED] wrote: So the policy is A bug cannot be fixed?! Jochen Wiedmann schrieb: Markus KARG wrote: If Carlos is able to upload it while I seem not to be, he actually is in the role of the maintainer. Where am I going wrong with that assumption? Your assumption is, that he is able to change files in the repository. The answer is he isn't. Ok, he may be able to do that technically, but the policy is clearly that already released files are left unchanged - forever. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: Who is the maintainer of the fop:fop project found on repo1.maven.org?
Actually I never voted for using ibiblio but just added a dependency to fop:fop to my project, while in fact Maven 2.0.4 automatically has choosen to pull it from ibiblio. That's why I said: Since ibiblio is choosen automatically by Maven until manually de-configured, that repository must undergo better quality assurance than any other repository that is NOT already configured in Maven 2.0.4. That's my key point. I do not blame anybody for doing or not doing anything, but I just say that anything that works automatically in Maven 2.0.4 has to undergo the same quality restrictions than maven itself. Markus Jörg Schaible schrieb: Hi Markus, Markus KARG wrote on Wednesday, September 20, 2006 9:35 AM: Wayne Fay schrieb: [snip] This is your best approach (imo) to get this updated FOP artifact installed in the Maven Repo. Unless of course someone else has a better suggestion... You asked about quality control previously... The assumption is that the people contributing builds to Maven are competent enough to create proper builds with reasonable pom.xml files etc. Ideally every Java project will eventually take over as maintainers of the Maven artifact but this is not required, nor is it entirely reasonable to expect it to ever occur. You need to know that our company is deeply involved into the business of quality assurance. So what you write is wrong. Nobody can rely on others to be good enough. You need to control quality EVER. [snip] At this point i stopped reading and I suggest you to stop using ibiblio at all. In this case you must build your repository on your own from scratch and I advice, that you prevent any of your Maven installation reaching out to the internet (since they might access arbirtary repos not under your control). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
