Maven fails to resolve version range for import

[[Quipsy] Markus Karg]

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

[[Quipsy] Markus Karg]

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
> sti

AW: Keeping dependency out of all classpaths

[[Quipsy] Markus Karg]

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).
> >>
> >> L

AW: Keeping dependency out of all classpaths

[[Quipsy] Markus Karg]

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

AW: Keeping dependency out of all classpaths

[[Quipsy] Markus Karg]

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
> >
>

AW: Keeping dependency out of all classpaths

[[Quipsy] Markus Karg]

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

[[Quipsy] Markus Karg]

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

[Markus Karg]

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

[Markus Karg]

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

[Markus Karg]

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

[Markus Karg]

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  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  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

[Markus Karg]

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  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: java import package and maven dependencies

[Markus Karg]

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

[Markus Karg]

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
sh>netstat -a  > netstat_before.log
run command
sh>mvn -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" :
> 
> > 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

AW: "mvn clean package" requests access rights for local Nexus repository

[Markus Karg]

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" :

> 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
>
>
>

"mvn clean package" requests access rights for local Nexus repository

[Markus Karg]

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?

[Markus Karg]

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 
:

> 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 :
> > Great, thanks a lot! :-)
> >
> > But let's negotiate one thing upfront: If we provide code that adds
>  to maven-dependency-plugin's , 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 :
> >
> >> 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.
> >>
&g

AW: How to configure maven-dependency-plugin's encoding used for unpack?

[Markus Karg]

Great, thanks a lot! :-)

But let's negotiate one thing upfront: If we provide code that adds  
to maven-dependency-plugin's , 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 :

> 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 :
>
> > 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  tag. So until this is fixed, UTF-8 
> > zip archives are the only ones that will work (with plexus unzip
> archiver)

AW: AW: How to configure maven-dependency-plugin's encoding used for unpack?

[Markus Karg]

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  to 
maven-dependency-plugin's  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  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 :
> 
> 
> > 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

AW: How to configure maven-dependency-plugin's encoding used for unpack?

[Markus Karg]

The ASSEMBLY plugin forwards its own  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  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 :

> 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  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 :
>
> > If I'm reading the documentation correctly, 
> >  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 :
> > >
> > > > To preserve German umlauts in file names within a ZIP, we are
> using...
> > > >
> > > > 
> > > > CP850
> > > > 
> > > >
> > > > ...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: How to configure maven-dependency-plugin's encoding used for unpack?

[Markus Karg]

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 :

> 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  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 :
>
> > If I'm reading the documentation correctly, 
> >  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 :
> > >
> > > > To preserve German umlauts in file names within a ZIP, we are
> using...
> > > >
> > > > 
> > > > CP850
> > > > 
> > > >
> > > > ...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?

[Markus Karg]

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 :

> 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  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 :
>
> > If I'm reading the documentation correctly, 
> >  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 :
> > >
> > > > To preserve German umlauts in file names within a ZIP, we are
> using...
> > > >
> > > > 
> > > > CP850
> > > > 
> > > >
> > > > ...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  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?

[Markus Karg]

(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! :-)

(2) Despite all the quirks of Windows, the ZIP specification does not say a 
word about encoding, 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, 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  
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. ;-)

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! :-)

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 :

> 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 :
>
> > 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  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 :
> >
> > > If I'm reading the documentation correctly, 
> > >  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 :(
> > > >
&

AW: How to configure maven-dependency-plugin's encoding used for unpack?

[Markus Karg]

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  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 :

> If I'm reading the documentation correctly,   
> 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 :
> >
> > > To preserve German umlauts in file names within a ZIP, we are using...
> > >
> > > 
> > > CP850
> > > 
> > >
> > > ...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
>

How to configure maven-dependency-plugin's encoding used for unpack?

[Markus Karg]

To preserve German umlauts in file names within a ZIP, we are using...


CP850


...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

RE: Maven Central Opinion

[Markus Karg]

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

[Markus Karg]

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 :

> 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

[Markus Karg]

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: AW: mvn release:prepare does not update parent version

[Markus Karg]

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: mvn release:prepare does not update parent version

[Markus Karg]

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:

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";>
  4.0.0
  my-artifact
  my-artifact
  
my.group
my-parent
1.0-SNAPSHOT
  
  

scm:svn:svn://svn/Research/my-artifact/trunk
  
  

  releases
  http://nexus.quipsy.local/nexus/content/repositories/releases


  snapshots
  http://nexus.quipsy.local/nexus/content/repositories/snapshots

  


Preparing and performing the release:

C:\Users\Markus Karg\workspace\artifact\my-artifact>mvn 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] [INFO] Building jar: C:\Users\Markus 
Karg\workspace\artifact\my-artifact\target\my-artifact-1.0.jar
[INFO] 

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)

[Markus Karg]

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=1506778&r1=1506777&r2=1506778&view=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.
>  * 
>
> + 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

[Markus Karg]

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  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  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  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

[Markus Karg]

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 . 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  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

AW: mvn release:prepare does not update parent version

[Markus Karg]

You don't get my point. My problem is that the plugin asks me to provide the 
version to set for the  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  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

RE: mvn release:prepare does not update parent version

[Markus Karg]

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

RE: mvn release:prepare does not update parent version

[Markus Karg]

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  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

mvn release:prepare does not update parent version

[Markus Karg]

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

mvn release:prepare does not update parent version

[Markus Karg]

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

How to prevent renaming of third-party file?

[Markus Karg]

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?

[Markus Karg]

I am using xml-maven-plugin to generate Java code from XML:

 

   org.codehaus.mojo

   xml-maven-plugin

   1.0

   

 

generate-sources



   transform



 

   

 

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?

[Markus Karg]

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  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  wrote:
>> My POM declared a dependency to a DLL:
>>
>>
>>
>> 
>>
>> net.sf.jacob-project
>>
>> jacob-runtime
>>
>> dll
>>
>> x64
>>
>> 1.17-M2
>>
>> runtime
>>
>> 
>>
>>
>>
>> (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?

[Markus Karg]

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  wrote:
> My POM declared a dependency to a DLL:
>
>
>
> 
>
> net.sf.jacob-project
>
> jacob-runtime
>
> dll
>
> x64
>
> 1.17-M2
>
> runtime
>
> 
>
>
>
> (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?

[Markus Karg]

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  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  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  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 
> 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

AW: How to tell Maven to put DLL dependency into java.library.path?

[Markus Karg]

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  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  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  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?

[Markus Karg]

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  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  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?

[Markus Karg]

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  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

AW: How to tell Maven to put DLL dependency into java.library.path?

[Markus Karg]

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

RE: How to tell Maven to put DLL dependency into java.library.path?

[Markus Karg]

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:
> >
> >
> >
> > 
> >
> > net.sf.jacob-project
> >
> > jacob-runtime
> >
> > dll
> >
> > x64
> >
> > 1.17-M2
> >
> > runtime
> >
> > 
> >
> >
> >
> > (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

RE: How to tell Maven to put DLL dependency into java.library.path?

[Markus Karg]

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  wrote:
> > My POM declared a dependency to a DLL:
> >
> >
> >
> > 
> >
> > net.sf.jacob-project
> >
> > jacob-runtime
> >
> > dll
> >
> > x64
> >
> > 1.17-M2
> >
> > runtime
> >
> > 
> >
> >
> >
> > (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

How to tell Maven to put DLL dependency into java.library.path?

[Markus Karg]

My POM declared a dependency to a DLL:

 



net.sf.jacob-project

jacob-runtime

dll

x64

1.17-M2

runtime



 

(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: Maven is in no danger of being replaced :-)

[Markus KARG]

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?

[Markus KARG]

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?

[Markus KARG]

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 
> > To: Maven Users List 
> > 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?

[Markus KARG]

> > 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?

[Markus KARG]

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 
> elements in a model 5 pom, or as provides (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.
> 
>

RE: How to put a dependency in the classpath BEFORE jre.jar?

[Markus KARG]

en Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Samstag, 22. September 2012 00:09
> To: Maven Users List
> Subject: Re: How to put a dependency in the classpath BEFORE jre.jar?
> 
> 1. Maven is not just about java (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 endorsed 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 true.
> >
> > > -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
> >
> >


-
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?

[Markus KARG]

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
true.

> -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

RE: How to put a dependency in the classpath BEFORE jre.jar?

[Markus KARG]

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:
> -Djava.endorsed.dirs=blabla
> 
> 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  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

How to put a dependency in the classpath BEFORE jre.jar?

[Markus Karg]

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: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries

[Markus KARG]

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
> 
> 
> org.apache.maven.plugins
> maven-ear-plugin
> 
> 6
> lib/
> 
> true
> 
> 
> DAAS BE Implementation-Title>
> ${project.version}
> ${timestamp}
> 
> 
> 
> 
> CONFIG
> 
> 
> WEBSERVICE_GET
> 
> 
> WEBSERVICE_SET
> 
> 
> 
> 
> daas-backend
> daas-backend-war
> Daas
> daas-backend-war.war bundleFileName>
> 
> 
> daas-backend
> daas-backend-
> system
> daas-backend-system.jar bundleFileName>
> 
> 
> 
> 
> 
> WAR-pom.xml:
> 
> 
> org.apache.maven.plugins
> maven-war-plugin
> 
> false
> WEB-INF/lib/*.jar packagingExcludes>
> 
> 
> true
> lib/
> 
> 
> 
> 
> 
> 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 maven-war-plugin
> configuration:
> 
> 
> org.apache.maven.plugins
> maven-war-plugin
> 
> false
> WEB-INF/lib/*.jar packagingExcludes>
> 
> 
> true
> lib/
> 
> 
> daas-backend-system.jar
> lib/websphere-admin-client-2012.2.0-SNAPSHOT.jar
> lib/jbpm-api-4.5-SNAPSHOT.jar lib/jbpm-log-4.5-SNAPSHOT.jar lib/jbpm-
> jpdl-4.5-SNAPSHOT.jar lib/jbpm-pvm-4.5-SNAPSHOT.jar
> 
> 
> 
> 
> 
> What did I do wrong here? I cannot imagine this happend 

RE: Best Practices for Passwords and Usernames

[Markus KARG]

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
> 
> 
> 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";>
> 
>
>  
>user
>
> Eric_Kolotyluk rname>
> secret
>  plugin.username>${com.perforce.p4maven.username} ins.maven-release-plugin.username>
>  plugin.password>${com.perforce.p4maven.password} ins.maven-release-plugin.password>
>
>  
>
> 
>
>  user
>
> 
> 
> 
> -
> 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: Failsafe Plugin: How to get resource dependencies for integration-tests?

[Markus KARG]

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  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:
> >
> > 
> > maven-dependency-plugin
> > 2.4
> > 
> > 
> > copy
> > integration-test
> > 
> > copy
> > 
> > 
> > 
> > 
> > G
> >
> A
> > V
> > db
> >
> > myDbFile.db
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 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 
> > 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.
> > > validatemaven 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

AW: Failsafe Plugin: How to get resource dependencies for integration-tests?

[Markus Karg]

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:


maven-dependency-plugin
2.4


copy
integration-test

copy




G
A
V
db

myDbFile.db







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  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.
> validatemaven 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

Failsafe Plugin: How to get resource dependencies for integration-tests?

[Markus Karg]

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!

[Markus KARG]

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  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

RE: "No versions available" but actually local repository contains it!

[Markus KARG]

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 1.3and 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

"No versions available" but actually local repository contains it!

[Markus Karg]

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

[Markus KARG]

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
> > accounts<http://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

RE: Issue-wise Crowdfunding platform for Maven

[Markus KARG]

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  (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
> accounts 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: How to correctly make an EJB module dependend of the interface JAR of a RAR?

[Markus KARG]

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  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 rar 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

AW: How to correctly make an EJB module dependend of the interface JAR of a RAR?

[Markus Karg]

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: Maven for Software Installation

[Markus KARG]

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 true?

[Markus KARG]

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
> true?
> 
> 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  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 true 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 true?

[Markus Karg]

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 true 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

[Markus KARG]

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  wrote:
> > You are right, when adding ejb it is working! I missed
> > the
> fact
> > that maven coordinates include the packaging, while the default
> > packaging
> is
> > jar. The odd thing is that dependency resolution is
> > working without that. So it actually seems, module resolution is
> > working correctly while dependency resolution ignores .
> >
> > 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:
> >>
> >>   ejb
> >>
> >> 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 
> >> > entries for some dependencies (RAR modules), but which is missing
> >> >  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
> >>  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

[Markus KARG]

You are right, when adding ejb it is working! I missed the fact
that maven coordinates include the packaging, while the default packaging is
jar. The odd thing is that dependency resolution is working
without that. So it actually seems, module resolution is working correctly
while dependency resolution ignores .

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:
> 
>   ejb
> 
> 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  entries
> > for some dependencies (RAR modules), but which is missing 
> > 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
>  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

[Markus KARG]

Maven 3.0.4 is producing application.xml containing  entries for
some dependencies (RAR modules), but which is missing  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  entries for EJB modules?

How to correctly make an EJB module dependend of the interface JAR of a RAR?

[Markus Karg]

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?

[Markus Karg]

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
"" 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 "" 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 "" 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?

[Markus KARG]

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
&g

How to readl with maintenance branches?

[Markus KARG]

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
"" 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 "" 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 "" 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

 

Is there a mavenized library for copying files?

[Markus KARG]

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

[Markus KARG]

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
> > > [1.0,1.1)
> > > > 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

RE: Version range excluding SNAPSHOTs

[Markus KARG]

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
> [1.0,1.1)
> > 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

Version range excluding SNAPSHOTs

[Markus KARG]

My project is dependent of some library. I want to always use the latest
bugfix but not any new features. So I added [1.0,1.1)
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?

[Markus KARG]

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:  generate-resources

 

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):

 

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";>

  4.0.0

  sample

  sample

  jar

  1.0-SNAPSHOT

  



  

maven-my-plugin

  



  



 

But when running "mvn compile", my mojo is NOT called. Why?

 

It looks like the "generate-resources" 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:

[Markus KARG]

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?

[Markus KARG]

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

[Markus KARG]

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

[Markus KARG]

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?

[Markus KARG]

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: Repository Policy

[Markus KARG]

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?

[Markus KARG]

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

[Markus KARG]

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?

[Markus KARG]

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

[Markus KARG]

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: Repository Policy

[Markus KARG]

Wendy Smoak schrieb:


On 9/20/06, diroussel <[EMAIL PROTECTED]> wrote:

Now, I'm not a .NET expect, so correct me if I'm wrong.  But 
according to
the CLR book [1] one of the ways the CLR is better than the java JVM 
is the

handling of versions and version meta-data.


...

Does that make sense?  Do people think a similar mechanism in maven 
would be

useful?



I'm not sure how much of it can be addressed by Maven vs. needing to
be done in the JVM itself, but you may want to keep an eye on JSR-277,
Java Module System:

  http://www.jcp.org/en/jsr/detail?id=277

I think JSR 277 discusses exactly what we need to solve our quarrel. 
Meanwhile, we should agree on accepting the current specifications (J2EE 
spec, MANIFEST.MF spec) as they are.


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

[Markus KARG]

Carlos Sanchez schrieb:


To make clear to all maven users, this is the current repository policy:

We don't allow pom changes that can alter reproducibility, which means
DEPENDENCIES IN POMS WILL NOT BE CHANGED.

The repo is only a way to distribute other people work. We don't
repackage their work, only exceptions are for distribution of sources
or javadocs when the original project don't provide them.

You CAN NOT PROVIDE YOUR OWN BUILT VERSION OF ANOTHER PROJECT.
As an example if fop adds anything to he manifest that you don't like
or think is wrong it's not our problem, ask them if they want to
change.

You can always as for an upload of anything you want to a group under
your project/domain name, as long as the license allows it.
Eg. I want to provide my own version of fop, created by my project
hosted in foobar.org. I can request an upload under org.foobar group.
I can upload to org.foobar anything I want as long as it follows the
maven conventions.

In case a pom is clearly bad, broken or unmanageable, a new pom can be
uploaded for users convenience, under same version appending -1. The
pom description must clearly state it's just for maven users
convenience and the originating project must be asked to provide the
pom improvements in next version (in case they provided the bad one)
Eg. http://repo1.maven.org/maven2/groovy/groovy/1.0-jsr-05-1/


Now this is clear word! Thank you Carlos!
So we he to change the pom.xml from Jörg SCHAIBLE to mirror the correct 
dependencies and send it to you, and we will do that under version 0.20.5-1.


Thanks a lot for this decision!

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?

[Markus KARG]

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: Who is the maintainer of the fop:fop project found on repo1.maven.org?

[Markus KARG]

But it would be beneficial for you since I would change it in
a way that
FOP is valid for everyone, so you can remove your workarounds.
Since in your case the Class-Path isn't taken into account anyways as
you wrote, what have you lost?
   



Reproducability! If we deploy our final release to an app server that is 
compliant to the spec in this way, well, then it breaks. Now consider a we get 
back a bug report, the assigned developer checks out the version and tries to 
debug it ... and since he gets now suddenly a different FOP cannot reproduce 
the error. *THIS IS MAINTENACE NIGHTMARE*! And that's why a final release must 
never change. If we build a mainenance release including fop-0.20.5-mvn-1 it is 
obvious that we use a different version and that *new* version is supposed to 
fix the problem.
 

If you deploy your final release to an app server that is J2EE 1.4 
compliant, then your application will break currently, due to the bug I 
reported. That's why I want to fix it. If your customer has this 
problem, the your support officer will look into the bug database before 
doing anything else first, where he will find that this is known bug 
that is to be fixed by updating the local repo of the customer to mirror 
the meanwhile fixed fop. What's nightmare with that? It's even better 
than setting up a test environment and let the supporter reconstruct the 
problem. BTW, if you are J2EE compliant, you are deploying EARs, which 
actually are unchanged for your and for your customers. If you change 
the FOP due to my fix, your EAR's version has definitively changed and 
you will see this.



Therefore the only way to fix the repo is to release something new. Andf the 
right thing is to have a new version with a jar that does not have a classpath 
entry in the manifest! If you have two artfiacts with such entries referencing 
the same dep in different version, you cannot even build an EAR with Maven 
containing both libraries.
 

How do you want to hold off me from doing it? Everybody told me this is 
a free land and nobody controls the repo...


Btw, please read the J2EE 1.4 + MANIFEST.MF specifications. It seems 
you're not aware of the need of correct Class-Path: settings to get the 
J2EE certified logo.


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