RE: Problems with the maven-failsafe-plugin and loading of resources from (test-)jars

[Christofer Dutz]

Ok ... so I think I fixed the issue.

In the end the useModulePath was the solution. The problem was that we 
initially had more specific configurations of the failsafe plugin in 
submodules. It seems the re-configuration there, removed that setting again. 
Removing the reconfigurations that weren't doing anything now anyway, made the 
switch actually do it's job.

Now our build is back to normal and we're all happy :-)

Chris


-Original Message-
From: Christofer Dutz  
Sent: Freitag, 28. Januar 2022 09:31
To: Maven Users List 
Subject: RE: Problems with the maven-failsafe-plugin and loading of resources 
from (test-)jars

Hi Falko,

Unfortunately, I've tried disabling the modulePath ... that didn't seem to 
disable this behavior and it continues to use the module path. 

Also tried all sorts of classloaders, that I knew ... none of them worked.

So, I even started adding module-info.java to my src/test/java to open the 
directory with the test resources.
Then the compiler won't compile it unless I add a module-info.java to the 
src/main/java part ... but if I also do that IntelliJ no longer likes any maven 
modules that would access that jar ... geee ... I think today I'll be doing 
some deep classloading debugging. Was just hoping for a simple solution, but I 
guess there isn't.

Chris


-Original Message-
From: Falko Modler  
Sent: Freitag, 28. Januar 2022 01:07
To: users@maven.apache.org
Subject: RE: Problems with the maven-failsafe-plugin and loading of resources 
from (test-)jars

Hi Christofer,

you might want to try disabling 
https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#useModulePath


You could also try to use the TCCL instead 
(Thread.currentThread().getContextClassloader()).

Cheers,

Falko

-
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: Problems with the maven-failsafe-plugin and loading of resources from (test-)jars

[Christofer Dutz]

Hi Falko,

Unfortunately, I've tried disabling the modulePath ... that didn't seem to 
disable this behavior and it continues to use the module path. 

Also tried all sorts of classloaders, that I knew ... none of them worked.

So, I even started adding module-info.java to my src/test/java to open the 
directory with the test resources.
Then the compiler won't compile it unless I add a module-info.java to the 
src/main/java part ... but if I also do that IntelliJ no longer likes any maven 
modules that would access that jar ... geee ... I think today I'll be doing 
some deep classloading debugging. Was just hoping for a simple solution, but I 
guess there isn't.

Chris


-Original Message-
From: Falko Modler  
Sent: Freitag, 28. Januar 2022 01:07
To: users@maven.apache.org
Subject: RE: Problems with the maven-failsafe-plugin and loading of resources 
from (test-)jars

Hi Christofer,

you might want to try disabling 
https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#useModulePath


You could also try to use the TCCL instead 
(Thread.currentThread().getContextClassloader()).

Cheers,

Falko

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Problems with the maven-failsafe-plugin and loading of resources from (test-)jars

[Christofer Dutz]

As usual,

as soon as I take the time to write the email, I seem to find a solution 
shortly after that ...

So, it seems that I managed to load the resource by changing:

this.testsuiteDocumentXml = getClass().getResourceAsStream(testsuiteDocument);

To:

this.testsuiteDocumentXml = 
getClass().getClassLoader().getUnnamedModule().getResourceAsStream(testsuiteDocument);

I think this is probably just a workaround and I am not quite sure about the 
implications. 

So, it this the way to go, or is there a prettier way to fix this?

Chris

-Original Message-
From: Christofer Dutz 
Sent: Donnerstag, 27. Januar 2022 22:59
To: Maven Users List 
Subject: RE: Problems with the maven-failsafe-plugin and loading of resources 
from (test-)jars

Sorry for the double posting ... guess my mailserver had hickups and now I know 
why I had to write it twice 

I think this version might be the better one ..

Chris

-Original Message-
From: Christofer Dutz  
Sent: Donnerstag, 27. Januar 2022 22:57
To: Maven Users List (users@maven.apache.org) 
Subject: Problems with the maven-failsafe-plugin and loading of resources from 
(test-)jars

Hi,

in the Apache PLC4X build we recently noticed that surefire and failsafe 2.22.2 
were missing to pickup some of our tests, which we use with @TestFactory 
annotation.
It turns out that when switching to 3.0.0-M5 this problem is resolved.

However, a new problem is now causing problems.

In our tests we usually load test-jars which contain test-resources which are 
processed in our tests.

They are referenced by the module in this way:


  org.apache.plc4x
  plc4x-protocols-modbus
  0.10.0-SNAPSHOT
  tests
  test-jar
  test


In failsafe the test is unable to load the resources. If I run the identical 
test in surefire, it works. If I run it in failsafe 2.22.2, it works.
In the IDE the tests also work fine.

So, I did some debugging and could see that the classloader used to load the 
resources correctly contains the jar that contains the resources in its 
URLClassPath, however the Classloader doesn't seem to use this.

Anyone got an idea what's going on?

Thanks,
Chris

RE: Problems with the maven-failsafe-plugin and loading of resources from (test-)jars

[Christofer Dutz]

Sorry for the double posting ... guess my mailserver had hickups and now I know 
why I had to write it twice 

I think this version might be the better one ..

Chris

-Original Message-
From: Christofer Dutz  
Sent: Donnerstag, 27. Januar 2022 22:57
To: Maven Users List (users@maven.apache.org) 
Subject: Problems with the maven-failsafe-plugin and loading of resources from 
(test-)jars

Hi,

in the Apache PLC4X build we recently noticed that surefire and failsafe 2.22.2 
were missing to pickup some of our tests, which we use with @TestFactory 
annotation.
It turns out that when switching to 3.0.0-M5 this problem is resolved.

However, a new problem is now causing problems.

In our tests we usually load test-jars which contain test-resources which are 
processed in our tests.

They are referenced by the module in this way:


  org.apache.plc4x
  plc4x-protocols-modbus
  0.10.0-SNAPSHOT
  tests
  test-jar
  test


In failsafe the test is unable to load the resources. If I run the identical 
test in surefire, it works. If I run it in failsafe 2.22.2, it works.
In the IDE the tests also work fine.

So, I did some debugging and could see that the classloader used to load the 
resources correctly contains the jar that contains the resources in its 
URLClassPath, however the Classloader doesn't seem to use this.

Anyone got an idea what's going on?

Thanks,
Chris

Problems with the maven-failsafe-plugin and loading of resources from (test-)jars

[Christofer Dutz]

Hi,

in the Apache PLC4X build we recently noticed that surefire and failsafe 2.22.2 
were missing to pickup some of our tests, which we use with @TestFactory 
annotation.
It turns out that when switching to 3.0.0-M5 this problem is resolved.

However, a new problem is now causing problems.

In our tests we usually load test-jars which contain test-resources which are 
processed in our tests.

They are referenced by the module in this way:


  org.apache.plc4x
  plc4x-protocols-modbus
  0.10.0-SNAPSHOT
  tests
  test-jar
  test


In failsafe the test is unable to load the resources. If I run the identical 
test in surefire, it works. If I run it in failsafe 2.22.2, it works.
In the IDE the tests also work fine.

So, I did some debugging and could see that the classloader used to load the 
resources correctly contains the jar that contains the resources in its 
URLClassPath, however the Classloader doesn't seem to use this.

Anyone got an idea what's going on?

Thanks,
Chris

Problems loading resources in maven-failsafe-plugin 3.0.0-M5 integration tests

[Christofer Dutz]

Hi,

in the Apache PLC4X project we've got some tests that use @TestFactory and 
we've seen failsafe 2.22.2 and surefire 2.22.2 sometimes skip finding these.
So we recently updated to 3.0.0-M5 and noticed that now all tests are correctly 
found.

However we now have a different problem:

In these tests we load xml resources which we import from another module via 
such a dependency:


  org.apache.plc4x
  plc4x-protocols-modbus
  0.10.0-SNAPSHOT
  tests
  test-jar
  test


However, the classloader seems unable to find the resource when running in 
failsafe 3.0.0-M5 ... it works in 2.22.2 and it also works in surefire 3.0.0-M5.

Now to track down the problem I debugged into the test and could see that the 
classloader generally has the right jars in it's Classpath.

The main difference however is that failsafe 3.0.0-M5 is the only version where 
the classloader treats the module as "named module" and goes a completely 
different path inside.

Do you have an idea how I can get my integration-tests to work with failsafe 
3.0.0-M5?

Help greatly appreciated,

Chris

Re: Maven plugin to replace text in file

[Christofer Dutz]

I recently tend to use the groovy plugin to do stuff like at in a portable way.

Chris

Von: Oliver B. Fischer 
Gesendet: Montag, 9. November 2020 22:42
An: Maven Users List ; Arnaud bourree 

Betreff: Re: Maven plugin to replace text in file

IMHO not very portable, as jq is an external dependency and maybe not
available on every machine.

Am 09.11.20 um 18:03 schrieb Arnaud bourree:
> You want to reformat json file ... why not using jq in exec-maven-plugin ?
>
> Arnaud
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fisc...@swe-blog.net
S oliver.b.fischer
J oliver.b.fisc...@jabber.org
X http://xing.to/obf


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Using antlr4-maven-plugin in reproducible builds?

[Christofer Dutz]

Hi all,

I am currently trying to adjust the build configuration of the projects I’m 
involved in to be able to generate reproducible builds.

One of the things I read are important for this, is to fix the line.separator 
so I added that to the “apache-release” profile.

This seems to work perfectly … until one project uses the antlr4-maven-plugin 
(well actually the antlr2 and 3 versions too).
In this case I’m getting angry errors from antlr …

Any other projects have this this issue too? I tried taking it to the antlr 
mailinglist (google group) but not getting any responses from there.


Chris

"Failed to determine Java version for profile" during "mvn site" build ...

[Christofer Dutz]

Hi folks, ...

I'm having some trouble with a profile-activation based on java versions ...

in the PLC4X project we added a self-activating profile that changes the 
surefire and failsafe configuration with Java 9 and above ... everything is 
working nicely ... almost. Our Site-Build however is failing complaining about 
not being able to:


[ERROR] Failed to determine Java version for profile 
_allow_illegal_access_reflection_in_tests @ 
org.apache.plc4x:plc4x-parent:0.8.0-SNAPSHOT, 
/home/jenkins/jenkins-slave/workspace/PLC4X_PLC4X_develop@2/pom.xml, line 1452, 
column 14

Strange thing, same profile was no problem at all to enable in the normal build 
a few Jenkins steps for a normal “mvn deploy” before (Here we're doing a simple 
"mvn site") ... anyone got an idea what could be causing this?

Here a link to the Jenkins output: 
https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/894/console

I did already try a few things (use maven-wrapper, output the mvn and java 
version , and last not least explicitly set the java-version to something) ... 
stupid things is that for building the site this profile is totally useless 
anyway.

I just even moved the profile into a sub-module and the site build is 
restricted to only the parent module anyway … still I’m getting the same error.

Chris

Re: Maven Dependencies Pop Quiz

[Christofer Dutz]

Hi,

I got my score via Twitter ;-)

But till then I didn't know how I performed.

Chris

Am 26.03.20, 19:08 schrieb "Andres Almiray" :

That's strange, you should get the number of correct answers at the end of
the quiz although I don't know if it actually shows you which answers were
incorrect when that's the case.

All data and results will be made public once the quiz is closed.

Thank you for participating.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Thu, Mar 26, 2020 at 7:04 PM jieryn  wrote:

> Kind of frustrating to not be shown my score at the end...
>
> On Thu, Mar 26, 2020 at 1:01 PM Andres Almiray  wrote:
> >
> > Hello everyone!
> >
> > If I can ask you for 15 minutes of your time, I've put of a 14 question
> pop
> > quiz on dependency resolution. I'm hopeful that this quiz will let us
> > realize a few things about the dependency resolution mechanism and its
> > rules, perhaps address concerns in the future and make Maven better as a
> > result.
> >
> > The quiz can be found at https://bit.ly/maven-dependencies-popquiz and
> is
> > totally anonymous (no email address collected). Unless you feel like
> > sharing your name ;-)
> >
> > Some preliminary numbers to this date:
> >
> >  - 3 people have 13 correct answers
> >  - 3 people have 12correct answers
> >  - 10 people have 11 correct answers
> >
> > The current median is 8. Some quick feedback left:
> >
> >  - pretty tricky, even for an almost 20 year maven dude. good job!
> >  - I've never seen documentation on this
> >  - Good food for thought. I guess I generally hope Maven does what I
> expect
> > and when it doesn't, I start specifying more exactly what I want.
> >
> > Please feel free to share it with your colleagues and friends. More
> entries
> > mean more data and better results. Thank you!
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Anyone tried out maven-profiledep-extension?

[Christofer Dutz]

Hi,

in the PLC4X project we are more and more facing the challenge of having 
non-java modules in our build.
The build itself is working nicely and seems to be working like a charm on Mac, 
Linux and Windows.
In order to not overload the casual user with too much build time, setting up 
etc. we defined profiles:

  *   with-cpp
  *   with-python
  *   with-proxy

The problem is, that now in order to build the proxies we need one module 
enabled, which is included in the with-cpp profile.
I know there’s no activation of profiles if another profile is enabled and I 
don’t quite like the property-based activation.

Now I came across this little project here:
https://github.com/sviperll/ozymandias/tree/master/maven-profiledep-extension

And it looks as if it would solve exactly the types of problems we are facing.

Has anyone tried it? What was the experience with it? Are there any 
alternatives?

Feedback greatly appreciated :-)

Chris

Re: Using maven-dependency-plugin:unpack in "mvn compile" build

[Christofer Dutz]

Hi Thomas,

thanks for that info ... I had totally forgotten the prepare-package phase ... 
of course using this would reduce a lot of problems.
I changed our build accordingly. I guess if someone does a "mvn 
prepare-package" ... well I guess then he's just looking for trouble ;-)

Chris

Am 24.03.19, 18:22 schrieb "Thomas Broyer" :

Rule of thumb: in a react build, don't ever use any lifecycle phase prior
to package, and if you want to skip tests, use -DskipTests or
-Dmaven.test.skip. Corollary: stick with "package" and "verify" (I consider
"mvn install" is an anti-pattern).
BTW, as another rule of thumb, use "processClasses" rather than "compile".
If you have users that want to do otherwise, i.e. "mvn processClasses" or
"mvn compile" (or even "mvn test") in a reactor build, then tell them you
rule/assumption, and let them come in with the workaround ;-)

In your specific case though, maybe you should do the unpacking at a later
stage, e.g. prepare-package ?

On Sun, Mar 24, 2019 at 11:51 AM Christofer Dutz 
wrote:

> Hi Maxim,
>
> unfortunately that doesn't help.
> The problem is that if we do a "mvn compile" no archiving (jar/war
> building) is done at all ...
> Guess what we would need, would be profiles based on the last maven phase
> being built.
> So if:
> - "last phase < package" --> Copy the content without unpacking (as the
> File reference returned by dependency resolution references the
> target/classes directory)
> - "last phase > package" --> Unpack the content (as the File reference
> returned by dependency resolution references a Jar/war file)
>
> Chris
>
>
    > Am 22.03.19, 15:02 schrieb "Maxim Solodovnik" :
>
> Hello Chris,
>
> Maybe true of maven-war-plugin
> can help?
>
> On Fri, 22 Mar 2019 at 20:12, Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Hi,
> >
> > we are currently having a little problem with our build.
> > A user complained about not being able to build with a “mvn 
compile”.
> > The reason is that we have one module that builds a web-client
> (bundled as
> > war) and a server module to which the client is copied.
> > We are using the maven-dependency-plugin:unpack to unpack the
> artifact
> > into the server war. This works fine as long as we built to at least
> the
> > “package” phase.
> > If the user builds to something before that, the build fails as the
> > pointer to the client pints to a directory instead of an archive.
> >
> > Is there a way to do some sort of “unpack-or-copy” that copies if
> it’s
> > just a pre-package phase and does the normal unpack if the archives
> have
> > been created.
> >
> > Would be happy to not tell them “just don’t do a `mvn compile` but 
at
> > least a `mvn package`.
> >
> >
> > Chris
> >
>
>
> --
> WBR
> Maxim aka solomax
>
>
>



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Using maven-dependency-plugin:unpack in "mvn compile" build

[Christofer Dutz]

Hi Maxim,

unfortunately that doesn't help.
The problem is that if we do a "mvn compile" no archiving (jar/war building) is 
done at all ...
Guess what we would need, would be profiles based on the last maven phase being 
built.
So if:
- "last phase < package" --> Copy the content without unpacking (as the File 
reference returned by dependency resolution references the target/classes 
directory)
- "last phase > package" --> Unpack the content (as the File reference returned 
by dependency resolution references a Jar/war file)

Chris


Am 22.03.19, 15:02 schrieb "Maxim Solodovnik" :

Hello Chris,

Maybe true of maven-war-plugin
    can help?
    
On Fri, 22 Mar 2019 at 20:12, Christofer Dutz 
wrote:

> Hi,
>
> we are currently having a little problem with our build.
> A user complained about not being able to build with a “mvn compile”.
> The reason is that we have one module that builds a web-client (bundled as
> war) and a server module to which the client is copied.
> We are using the maven-dependency-plugin:unpack to unpack the artifact
> into the server war. This works fine as long as we built to at least the
> “package” phase.
> If the user builds to something before that, the build fails as the
> pointer to the client pints to a directory instead of an archive.
>
> Is there a way to do some sort of “unpack-or-copy” that copies if it’s
> just a pre-package phase and does the normal unpack if the archives have
> been created.
>
> Would be happy to not tell them “just don’t do a `mvn compile` but at
> least a `mvn package`.
>
>
> Chris
>


-- 
WBR
Maxim aka solomax

Using maven-dependency-plugin:unpack in "mvn compile" build

[Christofer Dutz]

Hi,

we are currently having a little problem with our build.
A user complained about not being able to build with a “mvn compile”.
The reason is that we have one module that builds a web-client (bundled as war) 
and a server module to which the client is copied.
We are using the maven-dependency-plugin:unpack to unpack the artifact into the 
server war. This works fine as long as we built to at least the “package” phase.
If the user builds to something before that, the build fails as the pointer to 
the client pints to a directory instead of an archive.

Is there a way to do some sort of “unpack-or-copy” that copies if it’s just a 
pre-package phase and does the normal unpack if the archives have been created.

Would be happy to not tell them “just don’t do a `mvn compile` but at least a 
`mvn package`.


Chris

Re: Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

[Christofer Dutz]

Hi Herve,

well I know for example that I have some libraries, that are statically linked 
and some expect libraries to be installed on the host system.
I had the exact same problem with Flex in the past ... here I could also have 
dynamically linked versions of libraries, then I had to also reference all the 
dynamically linked dependencies of that too.
Usually always some dependencies were intentionally statically linked and some 
intentionally dynamically linked. It all boils down how to interpret the 
transitive dependencies of a dependency depending on its linkage type.

So I guess this would be a quite generic requirement. One I seem to encounter 
multiple times with different languages. 

In my current example of PLC4X with C++, I simply statically link everything.

Chris



Am 08.01.19, 02:59 schrieb "Hervé BOUTEMY" :

let's try to dig into your requirements

instead of trying to explain generic mechanisms, can you provide some 
concrete 
C++ examples, please?

Regards,

Hervé

Le lundi 7 janvier 2019, 14:23:48 CET Christofer Dutz a écrit :
> Hi Hervé,
> 
> thanks for that info ... I adjusted the topic to distinguish from the 
other
> topic :)
 
> Well I first ran into problems when taking over the maintenance of the
> Flexmojos maven plugin, which allowed building Flex applications with
> maven.
 A while ago a "bug" was fixed, which that plugin relied on
> (non-standard scopes were treated as compile when it came to transitive
> dependencies - I think). In flex there were different types of linking
> (Think of it as "static linking" (scope "compile" and "test") and "dynamic
> linking" (scope "rsl") (RSL = Runtime Shared Library)). 
> Now with C/C++ we have a similar problem. 
> 
> What I would like to be able to do, would be that if I am using a plugin 
to
> provide the means to build a custom type of module, that there would be an
> additional extension point in the plugin.xml
 where we could provide an
> additional scope resolver (or whatever we call the thing). So If I'm for
> example providing something that's going to be a "cpp-library" then I 
could
> for example use scopes like "dynamicly-linked" or "staticly-linked" and 
the
> thing would tell maven how to transitively resolve these libraries. 
Ideally
> this would sort of be a stack, so if a scope isn't recognized, it defaults
> to the next level. 
> As this has been a problem I have been running into again and again but
> always with different problems, I would really like to have this solved or
> help with solving it (I'm not expecting you folks to do that for me)
 
> Chris
> 
> 
> PS: I'm currently using the cmake maven plugin abstracting even more from
> the actual build
 
> 
> Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" :
> 
> Hi Christofer,
> 
> I know C/C++ people who used nar-maven-plugin [1] with success: did 
you
> have a 
 look?
> 
> Notice: in Maven, "polyglot" term has always been used for other POM
> format 
 than XML.
> Here, it's more on Maven support for non-java languages
> 
> One key requirement in such multi-languages context will be to have
> common 
 understanding and vocabulary on the requirements of the alternate
> languages, sharing concrete examples to make sure both java and non-java
> people see the same case.
> That was my key finding when I worked a little bit to help these C/C++
> people 
 discover the plugin and find their way. But I never got too much
> in details on how finely they managed dependencies: I know there were both
> static and dynamic libraries, and multi-platform support, then 2 key 
topics
> for C/C++ than Java does not require
> 
> Regards,
> 
> Hervé
> 
> [1] http://maven-nar.github.io/
> 
> Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit :
> 
> > Hi all,
> > 
> > after leaving the Flex project I sort of lost the need for 
supporting
> > alternate dependency strategies. Now in PLC4X we’re currently 
starting
> > to
> > work on the C and C++ versions of our PLC drivers.
> 
>  This brings the old
> 
> > problem up again that not all programming languages have the same
> > super-simple dependency types as Java has them. 
> > I remember us

Supporting custom "Scopes" and Maven support for "Non-Java" languages (WAS: Re: Any update on "polyglot" Maven?)

[Christofer Dutz]

Hi Hervé,

thanks for that info ... I adjusted the topic to distinguish from the other 
topic :)

Well I first ran into problems when taking over the maintenance of the 
Flexmojos maven plugin, which allowed building Flex applications with maven.
A while ago a "bug" was fixed, which that plugin relied on (non-standard scopes 
were treated as compile when it came to transitive dependencies - I think).
In flex there were different types of linking (Think of it as "static linking" 
(scope "compile" and "test") and "dynamic linking" (scope "rsl") (RSL = Runtime 
Shared Library)). 

Now with C/C++ we have a similar problem. 

What I would like to be able to do, would be that if I am using a plugin to 
provide the means to build a custom type of module, that there would be an 
additional extension point in the plugin.xml
where we could provide an additional scope resolver (or whatever we call the 
thing). 
So If I'm for example providing something that's going to be a "cpp-library" 
then I could for example use scopes like "dynamicly-linked" or 
"staticly-linked" and the thing would tell 
maven how to transitively resolve these libraries. Ideally this would sort of 
be a stack, so if a scope isn't recognized, it defaults to the next level.

As this has been a problem I have been running into again and again but always 
with different problems, I would really like to have this solved or help with 
solving it (I'm not expecting you folks to do that for me)

Chris


PS: I'm currently using the cmake maven plugin abstracting even more from the 
actual build


Am 05.01.19, 08:31 schrieb "Hervé BOUTEMY" :

Hi Christofer,

I know C/C++ people who used nar-maven-plugin [1] with success: did you 
have a 
look?

Notice: in Maven, "polyglot" term has always been used for other POM format 
than XML.
Here, it's more on Maven support for non-java languages

One key requirement in such multi-languages context will be to have common 
understanding and vocabulary on the requirements of the alternate 
languages, 
sharing concrete examples to make sure both java and non-java people see 
the 
same case.
That was my key finding when I worked a little bit to help these C/C++ 
people 
discover the plugin and find their way. But I never got too much in details 
on 
how finely they managed dependencies: I know there were both static and 
dynamic libraries, and multi-platform support, then 2 key topics for C/C++ 
than Java does not require

Regards,

    Hervé

[1] http://maven-nar.github.io/

Le vendredi 4 janvier 2019, 11:08:47 CET Christofer Dutz a écrit :
> Hi all,
> 
> after leaving the Flex project I sort of lost the need for supporting
> alternate dependency strategies. Now in PLC4X we’re currently starting to
> work on the C and C++ versions of our PLC drivers.
 This brings the old
> problem up again that not all programming languages have the same
> super-simple dependency types as Java has them. 
> I remember us discussing options to provide extensions for maven, that for
> example the type of a pom would not only pull in a dedicated lifecycle
> mapping, but also provide an alternate dependency resolution mechanism.
 
> In the C/C++ world we unfortunately have things like static and dynamic
> linking etc. I would really like to not start with hacks as I always did
> them in Flex and Flexmojos (which is now no longer possible anyway).
 
> Chris





-
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

Any update on "polyglot" Maven?

[Christofer Dutz]

Hi all,

after leaving the Flex project I sort of lost the need for supporting alternate 
dependency strategies. Now in PLC4X we’re currently starting to work on the C 
and C++ versions of our PLC drivers.
This brings the old problem up again that not all programming languages have 
the same super-simple dependency types as Java has them.

I remember us discussing options to provide extensions for maven, that for 
example the type of a pom would not only pull in a dedicated lifecycle mapping, 
but also provide an alternate dependency resolution mechanism.

In the C/C++ world we unfortunately have things like static and dynamic linking 
etc. I would really like to not start with hacks as I always did them in Flex 
and Flexmojos (which is now no longer possible anyway).

Chris

Re: Can I remove comment in XML using resource filtering

[Christofer Dutz]

You could use the xml-maven-plugin to do an XSLT ... there you should be able 
to remove the comments.

Chris


Am 07.03.18, 17:09 schrieb "Hoa Phan" :

I have some resources filtering to fill in var in XML template, however I 
also want to remove the comments in the XML source. Is there a way to do that?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: per-warm the maven cache for 2 stage Docker build

[Christofer Dutz]

Hi,

When creating a maven plugin for the Edgent project, I also setup an 
integration-test
That allows me to test the functionality of the plugin. I used the 
mrm-maven-plugin and the maven-invoker-plugin to get a dedicated local maven 
repo that is filled with all artifacts pulled in during the build. Eventually 
it might help you with your problem.

Just have a look at this build:
https://github.com/apache/incubator-edgent/tree/develop/utils/edgent-deployment-filter-maven-plugin

Chris


Am 05.03.18, 09:37 schrieb "Adam Sandor" :

Thank you all for the helpful answers. Some of the articles linked does
indeed have a working solution - using "mvn install" instead of "mvn
dependency:go-offline". That way everything gets downloaded. The reason
that wasn't working for me was, that I'm using the Spring Boot plugin which
looks for a main class - so it cannot be run on a pom file with no sources.
I'm still wondering however about the contract for dependency:go-offline...
how can you go-offline if only a part of your dependencies get's cached and
as soon as you try to run install you will run into missing deps?
So the question of the day (maybe worth another thread) is "Isn't mvn
dependency:go-offline supposed to download all dependencies?"

On Tue, Feb 20, 2018 at 7:37 PM Laird Nelson  wrote:

> On Sun, Feb 4, 2018 at 3:58 AM Adam Sandor <
> adam.san...@container-solutions.com> wrote:
>
> > The only missing piece of the puzzle I can’t figure out is how to force
> > Maven to download ALL dependencies just by using the pom file and not
> > executing any compilation.
>
> [snip]
>
> > Now the problem - Maven’s lazy downloading of dependencies. Even if I 
try
> > to execute “mvn dependency:go-offline” Maven still doesn’t download
> plugins
> > and other dependencies, which would only be required during the 
packaging
> > phase.
> >
>
> I dimly recall that if you just do:
>
> mvn dependency:go-offline
>
> …you end up running version 2.8.something of the maven-dependency-plugin.
> Its most recent version is 3.0.2.  I also seem to remember that this fixed
> the issue you describe above.  Maybe try:
>
> mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
>
> …?  Good luck.
>
> Best,
> Laird
>
-- 

Ádám Sándor

Senior Engineer / Consultant

Container Solutions 

0680126174

 



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Skip deploy of test-jars?

[Christofer Dutz]

Hi Robert,

thanks for that ... Option 3 was actually the one I was thinking of too but I 
was hoping that there already had been such a plugin or feature. 
I whipped up a little plugin that we'll have in our code repo and guess we'll 
release it once and then probably forget it's there ;-)

But it's working like a charm and I too think this is the easiest and cleanest 
way to go.

Thanks for your support.

Chris


Am 30.01.18, 21:02 schrieb "Robert Scholte" <rfscho...@apache.org>:

of the 2 option 1 is the cleanest: at least you don't make don't go  
outside of you project like you do with option 2. But it comes with too  
much overhead.

I would go for option 3: write a Maven plugin:
use MavenSession.getProjects() to find the specific instance(s) from which  
you want to copy the sources.
AFAIK there's no such plugin available yet.

thanks,
Robert

On Tue, 30 Jan 2018 09:12:01 +0100, Christofer Dutz  
<christofer.d...@c-ware.de> wrote:

> Regarding the number of kittens being hurt in both ways ... which one  
> would you guys see the one with more happy kittens?
>
> 1) Use the test-jar and unpack it
> 2) Copy classes from a location outside the module (but relative to the  
> current module)
>
> Chris
>
>
    >
> Am 29.01.18, 22:41 schrieb "Christofer Dutz"  
> <christofer.d...@c-ware.de>:
>
> Hi Robert,
>Well in that case I would copy resources from one module to another  
> using relative paths which point outside the module itself.
> That doesn't sound ideal either. At least I always try to avoid  
> accessing things this way cause I have burnt myself too often when doing  
> it.
>With the "test-jar unpacking" one module only consumes maven  
> artifacts another project created.
>Chris
>Am 29.01.18, 18:47 schrieb "Robert Scholte" <rfscho...@apache.org>:
>This makes me wonder: is the pack/unpack already hackish?
> Wouldn't it be nicer to simply copy the content from  
> target/classes +
> target/test-classes?
> With a Maven plugin is it quite simple to access this as part of  
> the
> reactor.
>thanks,
> Robert
>On Sun, 28 Jan 2018 12:52:14 +0100, Christofer Dutz
> <christofer.d...@c-ware.de> wrote:
>> Hi all,
> >
> > in the Apache Edgent (incubating) project we are producing  
> java 8 and
> > java 7 compatible jars by using the retrolambda-maven-plugin.  
> The Java 7
> > versions are just a convenience byproduct for us. In order to  
> do this,
> > we create the jar as well as the test-jars for each module and  
> hava
> > separate java 7 modules where no code is compiled, but instead  
> in the
> > compile phase we unpack the jar and in the compile-test phase  
> we unpack
> > the test-jar of the matching Java 8 module. After unpacking the
> > retrolambda plugin is executed and it generates the Java 7  
> versions.
> > From then on the converted class files are used to run the  
> tests and
> > create the java 7 jars.
> >
> > A little inconvenience of this approach is, that all test-jars  
> are also
> > published to nexus. We do need them to be installed in the  
> local repo,
> > but there is generally no point in deploying them to  
> Maven-Central.
> > While I have no big deals with this, some in the project would  
> like to
> > remove those test-jars from deployment.
> >
> > Is there any way to do this by usual configuration? Right now  
> we are
> > thinking of using the Nexus REST interface to programmatically  
> strip
> > them form the staging repo prior to closing it, but this all  
> feels like
> > a huge hack.
> >
> > Do you have any advice how to do this or some good reasons not  
> to do it?
> >
> > Chris
>
-
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Skip deploy of test-jars?

[Christofer Dutz]

Regarding the number of kittens being hurt in both ways ... which one would you 
guys see the one with more happy kittens?

1) Use the test-jar and unpack it
2) Copy classes from a location outside the module (but relative to the current 
module)

Chris



Am 29.01.18, 22:41 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

Hi Robert,

Well in that case I would copy resources from one module to another using 
relative paths which point outside the module itself. 
That doesn't sound ideal either. At least I always try to avoid accessing 
things this way cause I have burnt myself too often when doing it.

With the "test-jar unpacking" one module only consumes maven artifacts 
another project created.

Chris 



Am 29.01.18, 18:47 schrieb "Robert Scholte" <rfscho...@apache.org>:

This makes me wonder: is the pack/unpack already hackish?
Wouldn't it be nicer to simply copy the content from target/classes +  
target/test-classes?
With a Maven plugin is it quite simple to access this as part of the  
reactor.

thanks,
Robert

    On Sun, 28 Jan 2018 12:52:14 +0100, Christofer Dutz  
<christofer.d...@c-ware.de> wrote:

> Hi all,
>
> in the Apache Edgent (incubating) project we are producing java 8 and 
 
> java 7 compatible jars by using the retrolambda-maven-plugin. The 
Java 7  
> versions are just a convenience byproduct for us. In order to do 
this,  
> we create the jar as well as the test-jars for each module and hava  
> separate java 7 modules where no code is compiled, but instead in the 
 
> compile phase we unpack the jar and in the compile-test phase we 
unpack  
> the test-jar of the matching Java 8 module. After unpacking the  
> retrolambda plugin is executed and it generates the Java 7 versions.  
> From then on the converted class files are used to run the tests and  
> create the java 7 jars.
>
> A little inconvenience of this approach is, that all test-jars are 
also  
> published to nexus. We do need them to be installed in the local 
repo,  
> but there is generally no point in deploying them to Maven-Central.  
> While I have no big deals with this, some in the project would like 
to  
> remove those test-jars from deployment.
>
> Is there any way to do this by usual configuration? Right now we are  
> thinking of using the Nexus REST interface to programmatically strip  
> them form the staging repo prior to closing it, but this all feels 
like  
> a huge hack.
>
> Do you have any advice how to do this or some good reasons not to do 
it?
>
> Chris

-
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: Skip deploy of test-jars?

[Christofer Dutz]

Hi Robert,

Well in that case I would copy resources from one module to another using 
relative paths which point outside the module itself. 
That doesn't sound ideal either. At least I always try to avoid accessing 
things this way cause I have burnt myself too often when doing it.

With the "test-jar unpacking" one module only consumes maven artifacts another 
project created.

Chris 



Am 29.01.18, 18:47 schrieb "Robert Scholte" <rfscho...@apache.org>:

This makes me wonder: is the pack/unpack already hackish?
Wouldn't it be nicer to simply copy the content from target/classes +  
target/test-classes?
With a Maven plugin is it quite simple to access this as part of the  
reactor.

thanks,
Robert

On Sun, 28 Jan 2018 12:52:14 +0100, Christofer Dutz  
<christofer.d...@c-ware.de> wrote:

> Hi all,
>
> in the Apache Edgent (incubating) project we are producing java 8 and  
> java 7 compatible jars by using the retrolambda-maven-plugin. The Java 7  
> versions are just a convenience byproduct for us. In order to do this,  
> we create the jar as well as the test-jars for each module and hava  
> separate java 7 modules where no code is compiled, but instead in the  
> compile phase we unpack the jar and in the compile-test phase we unpack  
> the test-jar of the matching Java 8 module. After unpacking the  
> retrolambda plugin is executed and it generates the Java 7 versions.  
> From then on the converted class files are used to run the tests and  
> create the java 7 jars.
>
> A little inconvenience of this approach is, that all test-jars are also  
> published to nexus. We do need them to be installed in the local repo,  
> but there is generally no point in deploying them to Maven-Central.  
> While I have no big deals with this, some in the project would like to  
> remove those test-jars from deployment.
>
> Is there any way to do this by usual configuration? Right now we are  
> thinking of using the Nexus REST interface to programmatically strip  
> them form the staging repo prior to closing it, but this all feels like  
> a huge hack.
>
> Do you have any advice how to do this or some good reasons not to do it?
>
> Chris

-
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

Skip deploy of test-jars?

[Christofer Dutz]

Hi all,

in the Apache Edgent (incubating) project we are producing java 8 and java 7 
compatible jars by using the retrolambda-maven-plugin. The Java 7 versions are 
just a convenience byproduct for us. In order to do this, we create the jar as 
well as the test-jars for each module and hava separate java 7 modules where no 
code is compiled, but instead in the compile phase we unpack the jar and in the 
compile-test phase we unpack the test-jar of the matching Java 8 module. After 
unpacking the retrolambda plugin is executed and it generates the Java 7 
versions. From then on the converted class files are used to run the tests and 
create the java 7 jars.

A little inconvenience of this approach is, that all test-jars are also 
published to nexus. We do need them to be installed in the local repo, but 
there is generally no point in deploying them to Maven-Central. While I have no 
big deals with this, some in the project would like to remove those test-jars 
from deployment.

Is there any way to do this by usual configuration? Right now we are thinking 
of using the Nexus REST interface to programmatically strip them form the 
staging repo prior to closing it, but this all feels like a huge hack.

Do you have any advice how to do this or some good reasons not to do it?

Chris

Re: Follow up: Building projects for multiple platforms

[Christofer Dutz]

Hi,

Ok … turns out it was a combination of things I had to do.

In the end this configuration worked:


org.apache.maven.plugins
maven-surefire-plugin
2.20

  
**/*Test.class
  
  
${project.build.testOutputDirectory}

  

It seems that testClassesDirectory is used for generated test classes, to I 
just used my retrolambda processed classes as generated classes.
Second thing was to change the directory scanning pattern to look for “class” 
files instead of “java” files. Couldn’t find this documented anyware … again 
the code was the best documentation ;-)

Now I have to get the toolchain thingy to work …

Chris



Am 17.06.17, 18:20 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

Hi Karl Heinz,

I’m already working on this. Now I’m simply setting up a set of “pure-pom” 
modules. I got the dependency plugin to unpack the jar to “target/classes” and 
test-jar to “target/test-classes” and retrolambda is correctly transforming 
them there. Even the animalsniffer is now happy with the 1.7 signatures (It 
fails, if I disable the retrolambda plugin). So right now, all is looking good.

… Except I can’t seem to get surefire to detect any tests.

I also saw the config option to run the tests, unfortunately the unit-test 
jar is created after the unit test phase, using the java8 version shouldn’t 
work. Also I don’t feel that comfortable with reconfiguring the plugins to work 
in different phases just to trick surefire into running my tests … think I’ll 
just grab the sources of the surefire plug in and see if I can find a way to 
make it do what I want :-)

But anyway … I have gotten really far with this approach … thank you for 
that … and I think this will cause far less problems when releasing.

Chris


Am 17.06.17, 16:48 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:

Hi,

    On 17/06/17 16:23, Christofer Dutz wrote:
> I Karl Heinz,
> 
> I think that’s a really good idea … unfortunately I can’t seem to be 
able to run the retrolambda plugin on jars, so I might setup little projects, 
that use the dependency-plugin to unpack the jars and test-jars first and run 
the retrolambda on them and then package them back. Eventually this might also 
help running the testsuite a second time, but with Java7. Is there a way to 
have maven execute tests with a different java version (Run maven with Java 8 
and execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.

That's example for using toolchains...

Running Maven with Java 8 and running Tests with Java 7 ...which should 
be a separate module (otherwise the configuration would be a 
nightmare)...

If I correctly understand that scenario you have a jar build with Java 
8 
in a module call it "xyz-jdk8" also having tests for that ...

Now you need another module (defining toolchains using JDK 7) running 
your tests with surefire (I can remember there is an option to scan 
existing jars which contain tests found it: dependenciesToScan )...and 
run the tests and repackage after retolambda...But you have to be sure 
that the tests don't use JDK 8 specific parts cause they will run on 
JDK 
7 ...

Should working I didn't even test it...

Kidn regards
Karl Heinz Marbaise


> 
> Chris
> 
> Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:
> 
>  Hi,
>  
>  I would make a separate module for java8 and run there the 
retrolambda-
>  maven-plugin and another separate module for java7 and run there 
the
>  retrolambda-
>  maven-plugin as well...than you can make a separate jar file for 
each ...
>  
>  No need for different executions of the compiler plugins etc. and
>  separte output folders configurations etc.
>  
>  This needs to use toolchains and then you can run with a single
>  run...all of them...
>  
>  Just coming into my mind...
>  
>  
>  
>  If i correctly understand you are developing in JDK 8 and than 
you would
>  like to offer a package which supports JDK 7 ..
>  
>  So making a module with JDK 8 code in it pluse unit tests...
>  
>  A separate

Re: Follow up: Building projects for multiple platforms

[Christofer Dutz]

Hi Karl Heinz,

I’m already working on this. Now I’m simply setting up a set of “pure-pom” 
modules. I got the dependency plugin to unpack the jar to “target/classes” and 
test-jar to “target/test-classes” and retrolambda is correctly transforming 
them there. Even the animalsniffer is now happy with the 1.7 signatures (It 
fails, if I disable the retrolambda plugin). So right now, all is looking good.

… Except I can’t seem to get surefire to detect any tests.

I also saw the config option to run the tests, unfortunately the unit-test jar 
is created after the unit test phase, using the java8 version shouldn’t work. 
Also I don’t feel that comfortable with reconfiguring the plugins to work in 
different phases just to trick surefire into running my tests … think I’ll just 
grab the sources of the surefire plug in and see if I can find a way to make it 
do what I want :-)

But anyway … I have gotten really far with this approach … thank you for that … 
and I think this will cause far less problems when releasing.

Chris


Am 17.06.17, 16:48 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:

Hi,

On 17/06/17 16:23, Christofer Dutz wrote:
> I Karl Heinz,
> 
> I think that’s a really good idea … unfortunately I can’t seem to be able 
to run the retrolambda plugin on jars, so I might setup little projects, that 
use the dependency-plugin to unpack the jars and test-jars first and run the 
retrolambda on them and then package them back. Eventually this might also help 
running the testsuite a second time, but with Java7. Is there a way to have 
maven execute tests with a different java version (Run maven with Java 8 and 
execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.

That's example for using toolchains...

Running Maven with Java 8 and running Tests with Java 7 ...which should 
be a separate module (otherwise the configuration would be a nightmare)...

If I correctly understand that scenario you have a jar build with Java 8 
in a module call it "xyz-jdk8" also having tests for that ...

Now you need another module (defining toolchains using JDK 7) running 
your tests with surefire (I can remember there is an option to scan 
existing jars which contain tests found it: dependenciesToScan )...and 
run the tests and repackage after retolambda...But you have to be sure 
that the tests don't use JDK 8 specific parts cause they will run on JDK 
7 ...

Should working I didn't even test it...

Kidn regards
Karl Heinz Marbaise


> 
> Chris
> 
> Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:
> 
>  Hi,
>  
>  I would make a separate module for java8 and run there the 
retrolambda-
>  maven-plugin and another separate module for java7 and run there the
>  retrolambda-
>  maven-plugin as well...than you can make a separate jar file for 
each ...
>  
>  No need for different executions of the compiler plugins etc. and
>  separte output folders configurations etc.
>  
>  This needs to use toolchains and then you can run with a single
>  run...all of them...
>  
>  Just coming into my mind...
>  
>  
>  
>  If i correctly understand you are developing in JDK 8 and than you 
would
>  like to offer a package which supports JDK 7 ..
>  
>  So making a module with JDK 8 code in it pluse unit tests...
>  
>  A separate module which uses the JDK 8 code as dependency and using 
the
>  retrolambda plugin and maybe some supplemental tests on it...using 
JDK 7
>  which can be handled with Toolchain...
>  
>  
>  Kind regards
>  Karl Heinz Marbaise
>  
>  On 16/06/17 14:25, Justin Georgeson wrote:
>  > Instead of tweaking the version, I would configure an executions 
of the compiler plugins compile and testcompile goals to a separate output 
folders, like ${build.directory}${file.separator}classes-java7 and 
${build.directory}${file.separator}test-classes-java7 and then an execution of 
the jar plugin to create/attach a jar with classifier set to 'java7'.
>  >
>  > 
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
>  >
>  > That way you can have both versions build/deploy together in one 
pipeline with the same version.
>  >
>  > You can use propertie

Re: Follow up: Building projects for multiple platforms

[Christofer Dutz]

I Karl Heinz,

I think that’s a really good idea … unfortunately I can’t seem to be able to 
run the retrolambda plugin on jars, so I might setup little projects, that use 
the dependency-plugin to unpack the jars and test-jars first and run the 
retrolambda on them and then package them back. Eventually this might also help 
running the testsuite a second time, but with Java7. Is there a way to have 
maven execute tests with a different java version (Run maven with Java 8 and 
execute the tests with Java 7)?  Right now I’m relying on the animalsniffer 
plugin  to verify my java8 and java7 jars, but the others would feel more 
comfortable if we really ran the tests with a different java version.

Chris

Am 16.06.17, 14:36 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:

Hi,

I would make a separate module for java8 and run there the retrolambda-
maven-plugin and another separate module for java7 and run there the 
retrolambda-
maven-plugin as well...than you can make a separate jar file for each ...

No need for different executions of the compiler plugins etc. and 
separte output folders configurations etc.

This needs to use toolchains and then you can run with a single 
run...all of them...

Just coming into my mind...



If i correctly understand you are developing in JDK 8 and than you would 
like to offer a package which supports JDK 7 ..

So making a module with JDK 8 code in it pluse unit tests...

A separate module which uses the JDK 8 code as dependency and using the 
retrolambda plugin and maybe some supplemental tests on it...using JDK 7 
which can be handled with Toolchain...


Kind regards
Karl Heinz Marbaise

On 16/06/17 14:25, Justin Georgeson wrote:
> Instead of tweaking the version, I would configure an executions of the 
compiler plugins compile and testcompile goals to a separate output folders, 
like ${build.directory}${file.separator}classes-java7 and 
${build.directory}${file.separator}test-classes-java7 and then an execution of 
the jar plugin to create/attach a jar with classifier set to 'java7'.
> 
> 
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
> 
> That way you can have both versions build/deploy together in one pipeline 
with the same version.
> 
> You can use properties in the version if you use Maven 3.5 with some 
other tricks, there was a recent thread on the list about it
> 
> http://www.mail-archive.com/users@maven.apache.org/msg139475.html
> 
> 
>> -Original Message-
>> From: Christofer Dutz [mailto:christofer.d...@c-ware.de]
>> Sent: Friday, June 16, 2017 3:54 AM
>> To: Maven List <users@maven.apache.org>
>> Subject: [EXTERNAL] Follow up: Building projects for multiple platforms
>>
>> External Sender: Use caution with links/attachments.
>>
>>
>>
>> Hi,
>>
>> A short follow up question regarding my last one.
>> In the Edgent maven build, which I am working on, we need to produce 
java8,
>> java7 and android versions of jars. This is done by running the 
retrolambda-
>> maven-plugin on the classes when building the java7 version. To make the
>> dependency resolution work correctly with all variants we decided to use 
the
>> normal version number for the java8 output and add a suffix of “–java7” 
to the
>> version in case of a java7 build (for SNAPSHOT versions the “-java7” is 
included
>> between the version and the “SNAPSHOT”). In order to be able to switch 
the
>> versions by selecting profiles, I used variables for the artifact 
versions.
>> As I know variables for versions of parent poms is a really bad idea 
(Don’t even
>> know if it works), I setup the project to have constant versions in the 
parent
>> poms and only use these for configuring the reactor and the plugins – no
>> dependencies are handled here. The build is working nicey, unfortunately 
the
>> build is outputting hundreds of warnings like this:
>>
>> [WARNING] Some problems were encountered while building the effective 
model
>> for 
org.apache.edgent.analytics:edgent-analytics-sensors:jar:1.2.0-SNAPSHOT
>> [WARNING] 'version' contains an expression but should be a constant. @
>> org.apache.edgent.analytics:edgent-analytics-sensors:${edgent.version},
>> /Users/christoferdutz/Projects/Apache/Edgent/incubator-
>> edgent/analytics/sensors/pom.xml, line 31, column 12
>>
>> Is there a “maven way” (TM) to achieve this sort of thing without the 
warnings?
>>
>> Chris
> 

Follow up: Building projects for multiple platforms

[Christofer Dutz]

Hi,

A short follow up question regarding my last one.
In the Edgent maven build, which I am working on, we need to produce java8, 
java7 and android versions of jars. This is done by running the 
retrolambda-maven-plugin on the classes when building the java7 version. To 
make the dependency resolution work correctly with all variants we decided to 
use the normal version number for the java8 output and add a suffix of “–java7” 
to the version in case of a java7 build (for SNAPSHOT versions the “-java7” is 
included between the version and the “SNAPSHOT”). In order to be able to switch 
the versions by selecting profiles, I used variables for the artifact versions.
As I know variables for versions of parent poms is a really bad idea (Don’t 
even know if it works), I setup the project to have constant versions in the 
parent poms and only use these for configuring the reactor and the plugins – no 
dependencies are handled here. The build is working nicey, unfortunately the 
build is outputting hundreds of warnings like this:

[WARNING] Some problems were encountered while building the effective model for 
org.apache.edgent.analytics:edgent-analytics-sensors:jar:1.2.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @ 
org.apache.edgent.analytics:edgent-analytics-sensors:${edgent.version}, 
/Users/christoferdutz/Projects/Apache/Edgent/incubator-edgent/analytics/sensors/pom.xml,
 line 31, column 12

Is there a “maven way” (TM) to achieve this sort of thing without the warnings?

Chris

Re: Producing java8 and java7 versions

[Christofer Dutz]

Hi Laurent,

I love bleeding edge stuff, but I don’t like SM stuff … guess java 9 multi-jars 
sound more SM than bleeding edge for me.

Guess it would not be good to base the build of an Apache project on that ;-)

Chris

Am 10.06.17, 09:31 schrieb "Laurent Perez" :

On a side note, in a few months, if you like to live dangerously, java9
comes with built-in support for multijar :
http://in.relation.to/2017/02/13/building-multi-release-jars-with-maven/

laurent


2017-06-09 14:07 GMT+02:00 Jörg Schaible :

> Hi Paul,
>
> Paul Hammant wrote:
>
> > Older releases tried to have a single jar that had adaptive bytecode
> > within, right Jörg
> >
> > Specifically, class file formats 49, 50, 51 in one Jar.
>
> This is still the case. The -java7 version just omits class files
> targetting
> Java 8, because in some environments they cause harm if the runtime is not
> yet Java 8 compatible (Android, app servers scanning jars for annotations
> ...).
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
http://blog.jdeuxe.info/;>http://blog.jdeuxe.info/ - Java
entreprise tips & tricks



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Producing java8 and java7 versions

[Christofer Dutz]

Hi Jörg,

We have been discussing this option on the Edgent list and I guess this is the 
way it’s gonna be.

Thanks for your feedback.

Chris



Am 08.06.17, 20:06 schrieb "Jörg Schaible" <joerg.schai...@gmx.de>:

Hi Chistopher,
    
    Christofer Dutz wrote:

> Perhaps not adding any suffix to the version for the java8 version would
> be ok and to add “java7” to the version for the legacy builds would be a
> good compromise.

That's what XStream has done with the last release.

Cheers,
Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Producing java8 and java7 versions

[Christofer Dutz]

Perhaps not adding any suffix to the version for the java8 version would be ok 
and to add “java7” to the version for the legacy builds would be a good 
compromise.

Chris

Am 08.06.17, 11:11 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

So, they are adding the java version as a suffix to the version of the 
artifact … don’t quite know if I really like that solution. I think It would 
break some version related automatisms, but it is definitely a safer solution 
as the classifier solution. But how would such a build look like? Using version 
properties everywhere except the pom type artifacts which are used as parents 
by the leaf artifacts? That could work, but would it break anything with the 
release-plugin?

Chris


Am 08.06.17, 11:04 schrieb "Maxim Solodovnik" <solomax...@gmail.com>:

Hello Chris,

Here is one example:
https://repo1.maven.org/maven2/org/postgresql/postgresql/

WBR, Maxim
(from mobile, sorry for the typos)

On Jun 8, 2017 10:44, "Christofer Dutz" <christofer.d...@c-ware.de> 
wrote:

> Hi,
>
> Currently the Edgent project produces two tar.gz files … one for 
java7 and
> one for java8. Now they would like to produce artifacts for 
Maven-Central.
>
> I’m currently trying to help them with their build by migrating this 
to
> maven. I think that there currently is no clean way to provide both 
java7
> and java8 versions. We could add classifiers, but that would mess up 
the
> dependency resolution mechanism.
>
> Do you guys know how other projects do this sort of thing?
>
> Chris
>



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Producing java8 and java7 versions

[Christofer Dutz]

So, they are adding the java version as a suffix to the version of the artifact 
… don’t quite know if I really like that solution. I think It would break some 
version related automatisms, but it is definitely a safer solution as the 
classifier solution. But how would such a build look like? Using version 
properties everywhere except the pom type artifacts which are used as parents 
by the leaf artifacts? That could work, but would it break anything with the 
release-plugin?

Chris


Am 08.06.17, 11:04 schrieb "Maxim Solodovnik" <solomax...@gmail.com>:

Hello Chris,

Here is one example:
https://repo1.maven.org/maven2/org/postgresql/postgresql/

WBR, Maxim
(from mobile, sorry for the typos)

On Jun 8, 2017 10:44, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

> Hi,
>
> Currently the Edgent project produces two tar.gz files … one for java7 and
> one for java8. Now they would like to produce artifacts for Maven-Central.
>
> I’m currently trying to help them with their build by migrating this to
> maven. I think that there currently is no clean way to provide both java7
> and java8 versions. We could add classifiers, but that would mess up the
> dependency resolution mechanism.
>
> Do you guys know how other projects do this sort of thing?
>
> Chris
>



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Naming apache artifacts

[Christofer Dutz]

Hi,

Another question that came up while at my Maven migration task in the Edgent 
project.
Justin suggested to prefix all artifactIds with “apache-edgent-“. Having a look 
at the Apache Repo it feels like 80% prefix the artifacts with the 
“{projectname}-“ , about 10% with “apache-{projectname}” and another 10% don’t 
prefix at all.

I have to admit, that I usually don’t prefix at all too as I think the groupId 
already sets the context. Ok … in a war archive a project prefix might have a 
slight benefit over a non-project prefix, but adding the “apache-{projectname}“ 
prefix to the artifact id and hereby to the name of the generated jar seems 
unnecessarily verbose.

Are there any best practices, suggestions or guidelines? Guess if adding 
“apache-“ is considered best practice, I think I should adjust this in the Flex 
project too.

Chris

Producing java8 and java7 versions

[Christofer Dutz]

Hi,

Currently the Edgent project produces two tar.gz files … one for java7 and one 
for java8. Now they would like to produce artifacts for Maven-Central.

I’m currently trying to help them with their build by migrating this to maven. 
I think that there currently is no clean way to provide both java7 and java8 
versions. We could add classifiers, but that would mess up the dependency 
resolution mechanism.

Do you guys know how other projects do this sort of thing?

Chris

Re: Maven-Site-Plugin: Generated content?

[Christofer Dutz]

Hi Gerrit,

I am also heavily using the site-plugin to generate the site of the flex 
project.
I didn’t have to provide the generatedSiteDirectory config option at all ... 
As soon as I run: 

mvn site

It generates the „target/site“ directory with all of the site content.

Eventually you could have a look at the maven-site branch of the flex-site repo:
https://git-wip-us.apache.org/repos/asf?p=flex-site.git;a=tree;h=refs/heads/maven-site;hb=refs/heads/maven-site

If you want to generate the site for an apache project, eventually this could 
help (I wrote down everything needed):
http://flex.apache.org/ng/doc-website.html

Chris


Am 04.11.16, 09:20 schrieb "Hohl, Gerrit" :

Hello everyone, :-)

 

I'm trying to create some content for the Maven site during the Maven
build process.

 

I recognized that the maven-site-plugin has a 
configuration property which allows defining a directory which holds
such generated content.

Normally it's the target/generated-site folder.

So I placed an APT as well as a HTML file there.

But nothing happened.

So I defined it in the configuration of the maven-site-plugin in the
pluginManagement section:

${project.build.directory}/generated-site

But also that didn't change anything.

After the Maven build there is still no file in the target/site folder.

Neither the rendered APT file nor the HTML file.

 

Where is my mistake? :-(

 

Regards

Gerrit

 

AW: API for annotation scanning in a mojo?

[Christofer Dutz]

Hi Paul,


Have you thought about writing a Java annotation processor and hooking that up 
in the compiler plugin? I think this is exactly what I would use if I want to 
do something like that.




https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#annotationProcessors


Chris


Von: Paul Benedict 
Gesendet: Mittwoch, 13. Juli 2016 23:13:41
An: Apache Maven Users
Betreff: API for annotation scanning in a mojo?

Is there any existing API in any of these projects [1] for scanning
annotations? I am writing a Mojo and want to scan either the project's
source files or binary files -- haven't decided. The answer will depend on
what APIs are available to me.

[1] https://maven.apache.org/ref/3.3.9/index.html

Cheers,
Paul

AW: Dealing with .jars that have overlapping .classes

[Christofer Dutz]

We use the Tattletale Maven Plugin to scan our applications to finde such 
overlaps: http://docs.jboss.org/tattletale/userguide/1.2/en-US/html/maven.html

Chris


Von: ctrueden.w...@gmail.com  im Auftrag von Curtis 
Rueden 
Gesendet: Freitag, 22. April 2016 21:03
An: Maven Users List
Betreff: Re: Dealing with .jars that have overlapping .classes

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton  wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Dealing with .jars that have overlapping .classes

[Christofer Dutz]

Here I could re-phrase my request to extend the dependencyManagement with the 
ability to add "includes". Cause when dealing with these uber-jars I always 
have to add a set of excludes and would like to have some replacement includes 
... sort of:

dependencyManagement
dependency-x
exludes 
crappy-uber-jar
includes
the individual jars that make up the uber-jar

So I don't have to rely on all users knowing that if they reference 
"dependency-x" they have to manually include all the individual jars (and no 
... a pom handling this is not practical, cause I usually search for jars 
providing a given class and not poms referencing jars that provide a class ;-) )

Chris



Von: ctrueden.w...@gmail.com  im Auftrag von Curtis 
Rueden 
Gesendet: Freitag, 22. April 2016 21:03
An: Maven Users List
Betreff: Re: Dealing with .jars that have overlapping .classes

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton  wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Apache Maven PMD Plugin - Language XML

[Christofer Dutz]

Hi Jeremie,

quite a while ago I helped implement the modular language support for PMD. 
Before that the languages were hard-coded into PMD, but with those changes you 
can extend PMD with any Language you like (and you are willing to implement).

I did this because I didn't want to continue to maintain an insanely old fork 
of PMD used in the Flex project and to add a Flex language module to the 
official PMD distribution. 

I think I noticed quite a lot of new languages on the PMD list.
You can find a list of the official ones and how to provide new languages here: 
http://pmd.sourceforge.net/pmd-5.3.2/customizing/new-language.html

I really hope to find the time to port the FlexPMD to become a PMD plugin soon 

Chris


Von: Jérémie DENOYER 
Gesendet: Donnerstag, 31. März 2016 15:42
An: users@maven.apache.org
Betreff: Apache Maven PMD Plugin - Language XML

Hi,

PMD can be used for XML language (
https://pmd.github.io/pmd-5.4.1/pmd-xml/rules/index.html).
Therefore, Apache Maven PMD Plugin supports only java, javascriptand jsp.

Is somebody aware of any improvement to support new language (like XML)
with the Maven PMD Plugin ?

Regards,

Jérémie
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Plugin dependencies to artifacts of the same build?

[Christofer Dutz]

Ok ... so I did some more debugging ...

I output the classpath and it seemed to contain the jar containing the class I 
tried to load. So I took the urls of the existing Classloader and created a new 
Instance with exactly this set of URLs and I was able to load the class. Is is 
possible that Maven can have problems with classloaders if the JARs it contains 
are replaced during the build?

I did encounter similar problems with other builds and they always occur if I 
load classes in plugins that have been built as part of the build. 

Is there a way to avoid this type of problem?

Chris


Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Dienstag, 29. März 2016 19:14
An: users@maven.apache.org
Betreff: AW: Plugin dependencies to artifacts of the same build?

Sorry ... that email went off unintentionally ... well to continue ... if the 
plugin is part of the reactor:

---
constituent[0]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-api-1.0.2.v20150114.jar
constituent[1]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-connector-basic-1.0.2.v20150114.jar
constituent[2]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-impl-1.0.2.v20150114.jar
constituent[3]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-spi-1.0.2.v20150114.jar
constituent[4]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-transport-wagon-1.0.2.v20150114.jar
constituent[5]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-util-1.0.2.v20150114.jar
constituent[6]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aopalliance-1.0.jar
constituent[7]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/cdi-api-1.0.jar
constituent[8]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/commons-cli-1.2.jar
constituent[9]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/commons-io-2.2.jar
constituent[10]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/commons-lang-2.6.jar
constituent[11]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/guava-18.0.jar
constituent[12]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/javax.inject-1.jar
constituent[13]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/jsoup-1.7.2.jar
constituent[14]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/jsr250-api-1.0.jar
constituent[15]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-aether-provider-3.3.3.jar
constituent[16]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-artifact-3.3.3.jar
constituent[17]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-builder-support-3.3.3.jar
constituent[18]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-compat-3.3.3.jar
constituent[19]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-core-3.3.3.jar
constituent[20]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-embedder-3.3.3.jar
constituent[21]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-model-3.3.3.jar
constituent[22]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-model-builder-3.3.3.jar
constituent[23]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-plugin-api-3.3.3.jar
constituent[24]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-repository-metadata-3.3.3.jar
constituent[25]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-settings-3.3.3.jar
constituent[26]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-settings-builder-3.3.3.jar
constituent[27]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/org.eclipse.sisu.inject-0.3.0.jar
constituent[28]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/org.eclipse.sisu.plexus-0.3.0.jar
constituent[29]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-cipher-1.7.jar
constituent[30]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-component-annotations-1.5.5.jar
constituent[31]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-interpolation-1.21.jar
constituent[32]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-sec-dispatcher-1.3.jar
constituent[33]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-utils-3.0.20.jar
constituent[34]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/sisu-guice-3.2.5-no_aop.jar
constituent[35]: 
file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/slf4j-api-1.7.5.jar
constituent[36]: 
file:

AW: Plugin dependencies to artifacts of the same build?

[Christofer Dutz]

-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jx/0.6.0-SNAPSHOT/compiler-jx-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler/0.6.0-SNAPSHOT/compiler-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jburg-types/0.6.0-SNAPSHOT/compiler-jburg-types-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
/Users/christoferdutz/Maven-Repository/org/antlr/antlr/3.3/antlr-3.3.jar
/Users/christoferdutz/Maven-Repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar
/Users/christoferdutz/Maven-Repository/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar
/Users/christoferdutz/Maven-Repository/antlr/antlr/2.7.7/antlr-2.7.7.jar
/Users/christoferdutz/Maven-Repository/com/google/guava/guava/18.0/guava-18.0.jar
/Users/christoferdutz/Maven-Repository/net/sourceforge/jburg/jburg/1.10.3/jburg-1.10.3.jar
/Users/christoferdutz/Maven-Repository/de/jflex/jflex/1.6.0/jflex-1.6.0.jar
/Users/christoferdutz/Maven-Repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
/Users/christoferdutz/Maven-Repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
/Users/christoferdutz/Maven-Repository/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar
/Users/christoferdutz/Maven-Repository/args4j/args4j/2.0.28/args4j-2.0.28.jar
/Users/christoferdutz/Maven-Repository/org/codeartisans/org.json/20131017/org.json-20131017.jar
/Users/christoferdutz/Maven-Repository/com/google/javascript/closure-compiler/v20151015/closure-compiler-v20151015.jar
/Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library/0.0-20150902-b129bb9e/google-closure-library-0.0-20150902-b129bb9e.jar
/Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library-third-party/0.0-20150902-b129bb9e/google-closure-library-third-party-0.0-20150902-b129bb9e.jar

Can anyone here explain why?

Chris


Von: Christofer Dutz
Gesendet: Dienstag, 29. März 2016 19:13
An: users@maven.apache.org
Betreff: AW: Plugin dependencies to artifacts of the same build?

So I added some code to dump the threads context classpath during the execution 
of the plugin:

If I execute everything without the plugin being part of the reactor, I get 
this:

[INFO] --- flexjs-maven-plugin:0.6.0-SNAPSHOT:generate (default-generate) @ 
flexjs-externs-js ---
Classpath
-
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/flexjs-maven-plugin/0.6.0-SNAPSHOT/flexjs-maven-plugin-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jx/0.6.0-SNAPSHOT/compiler-jx-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler/0.6.0-SNAPSHOT/compiler-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jburg-types/0.6.0-SNAPSHOT/compiler-jburg-types-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
/Users/christoferdutz/Maven-Repository/org/antlr/antlr/3.3/antlr-3.3.jar
/Users/christoferdutz/Maven-Repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar
/Users/christoferdutz/Maven-Repository/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar
/Users/christoferdutz/Maven-Repository/antlr/antlr/2.7.7/antlr-2.7.7.jar
/Users/christoferdutz/Maven-Repository/com/google/guava/guava/18.0/guava-18.0.jar
/Users/christoferdutz/Maven-Repository/net/sourceforge/jburg/jburg/1.10.3/jburg-1.10.3.jar
/Users/christoferdutz/Maven-Repository/de/jflex/jflex/1.6.0/jflex-1.6.0.jar
/Users/christoferdutz/Maven-Repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
/Users/christoferdutz/Maven-Repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
/Users/christoferdutz/Maven-Repository/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar
/Users/christoferdutz/Maven-Repository/args4j/args4j/2.0.28/args4j-2.0.28.jar
/Users/christoferdutz/Maven-Repository/org/codeartisans/org.json/20131017/org.json-20131017.jar
/Users/christoferdutz/Maven-Repository/com/google/javascript/closure-compiler/v20151015/closure-compiler-v20151015.jar
/Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library/0.0-20150902-b129bb9e/google-closure-library-0.0-20150902-b129bb9e.jar
/Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library-third-party/0.0-20150902-b129bb9e/google-closure-library-third-party-0.0-20150902-b129bb9e.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/aether/aether-util/1.13.1/aether-util-1.13.1.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-inject-bean/2.3.0/sisu-inject-bean-2.3.0.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar
/Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus

AW: Plugin dependencies to artifacts of the same build?

[Christofer Dutz]

So I added some code to dump the threads context classpath during the execution 
of the plugin:

If I execute everything without the plugin being part of the reactor, I get 
this:

[INFO] --- flexjs-maven-plugin:0.6.0-SNAPSHOT:generate (default-generate) @ 
flexjs-externs-js ---
Classpath
-
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/flexjs-maven-plugin/0.6.0-SNAPSHOT/flexjs-maven-plugin-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jx/0.6.0-SNAPSHOT/compiler-jx-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler/0.6.0-SNAPSHOT/compiler-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jburg-types/0.6.0-SNAPSHOT/compiler-jburg-types-0.6.0-SNAPSHOT.jar
/Users/christoferdutz/Maven-Repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
/Users/christoferdutz/Maven-Repository/org/antlr/antlr/3.3/antlr-3.3.jar
/Users/christoferdutz/Maven-Repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar
/Users/christoferdutz/Maven-Repository/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar
/Users/christoferdutz/Maven-Repository/antlr/antlr/2.7.7/antlr-2.7.7.jar
/Users/christoferdutz/Maven-Repository/com/google/guava/guava/18.0/guava-18.0.jar
/Users/christoferdutz/Maven-Repository/net/sourceforge/jburg/jburg/1.10.3/jburg-1.10.3.jar
/Users/christoferdutz/Maven-Repository/de/jflex/jflex/1.6.0/jflex-1.6.0.jar
/Users/christoferdutz/Maven-Repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
/Users/christoferdutz/Maven-Repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
/Users/christoferdutz/Maven-Repository/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar
/Users/christoferdutz/Maven-Repository/args4j/args4j/2.0.28/args4j-2.0.28.jar
/Users/christoferdutz/Maven-Repository/org/codeartisans/org.json/20131017/org.json-20131017.jar
/Users/christoferdutz/Maven-Repository/com/google/javascript/closure-compiler/v20151015/closure-compiler-v20151015.jar
/Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library/0.0-20150902-b129bb9e/google-closure-library-0.0-20150902-b129bb9e.jar
/Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library-third-party/0.0-20150902-b129bb9e/google-closure-library-third-party-0.0-20150902-b129bb9e.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/aether/aether-util/1.13.1/aether-util-1.13.1.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-inject-bean/2.3.0/sisu-inject-bean-2.3.0.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar
/Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
/Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
/Users/christoferdutz/Maven-Repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
/Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-compiler-api/2.2/plexus-compiler-api-2.2.jar
/Users/christoferdutz/Maven-Repository/commons-io/commons-io/2.4/commons-io-2.4.jar
/Users/christoferdutz/Maven-Repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.jar
/Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-utils/3.0.3/plexus-utils-3.0.3.jar
/Users/christoferdutz/Maven-Repository/org/apache/flex/flex-tool-api/1.0.0/flex-tool-api-1.0.0.jar
-

In case the plugin is part of the reactor, the list looks like this:



Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Dienstag, 29. März 2016 16:14
An: users@maven.apache.org
Betreff: Plugin dependencies to artifacts of the same build?

Hi,


I am currently trying to sort out some glitches in my Maven build.

I am working on a new flexjs-maven-plugin as part of my efforts to migrate more 
and more of the Apache Flex project to Maven.


In the reactor I have a a compiler, a maven-plugin providing a custom lifecycle 
mapping for FlexJS projects, and a set of libraries that are built using the 
maven-plugin and the compiler (Let's call them "framework"). The maven plugin 
uses an externally released API to decouple the plugin from the compiler.


I know that if you start from scratch, Maven will abort with an error message 
as the maven plugin does not exist and it needs that for the framework. For 
this reason I have a "minimal" profile that simply builds the maven plugin. So 
ideally you only have to build once with the "minimal" profile and then you can 
go back to the "default" profile, which build

Plugin dependencies to artifacts of the same build?

[Christofer Dutz]

Hi,


I am currently trying to sort out some glitches in my Maven build.

I am working on a new flexjs-maven-plugin as part of my efforts to migrate more 
and more of the Apache Flex project to Maven.


In the reactor I have a a compiler, a maven-plugin providing a custom lifecycle 
mapping for FlexJS projects, and a set of libraries that are built using the 
maven-plugin and the compiler (Let's call them "framework"). The maven plugin 
uses an externally released API to decouple the plugin from the compiler.


I know that if you start from scratch, Maven will abort with an error message 
as the maven plugin does not exist and it needs that for the framework. For 
this reason I have a "minimal" profile that simply builds the maven plugin. So 
ideally you only have to build once with the "minimal" profile and then you can 
go back to the "default" profile, which builds everything (I know this is not 
ideal, but I haven't come across a solution that would not have me split up 
everything into completely separate Projects ... anyway ... my problem is not 
directly related to this problem)


If building everything in one big build I get ClassNotFound exceptions from the 
Maven-Plugin complaining the compiler classes not being available, if however I 
build only the framework all is good. So I am guessing that if Maven starts 
building and a plugin references a library that is re-built prior to it's usage 
inside the same build, the jar is no longer available. Why is that the case? 
... Flexmojos (another plugin I have been maintaining for years now) relies 
heavily on this and It must have been working prior to my new plugin.


I am using Maven 3.3.3 and Oracle Java 1.7


Chris

AW: debugging maven-deploy-plugin:deploy-file

[Christofer Dutz]

Just to add my 50ct ... I too encountered a similar problem a few days ago and 
am still having it.

While I had a settings.xml that worked fine for ages I got the exact same 
Unauthorized errors. 
At first I thought I had a problem in my settings but I couldn't find one. I 
"resolved" the problem, by disabling the settings.xml and pulling from maven 
central instead of my private repo ... but that's not a real resolution.

I was also using a pretty recent 3.3.x version (not the 3.3.9 cause it breaks 
most of my important plugins)
My repo is an Artifactory (Haven't updated that for quite some time)

As I don't seem to be alone with this eventually I'll use Wireshark investigate 
what's going over the wire. Mabe this will help find out what's going wrong.

Chris


Von: Mehul Sanghvi 
Gesendet: Dienstag, 9. Februar 2016 15:02
An: Maven Users List
Cc: i...@soebes.de
Betreff: Re: debugging maven-deploy-plugin:deploy-file

The repositoryId is the same for both.  They are getting uploaded to the
same repository.

So face I have tested the following:

1.  verified username/password by logging into the web ui

2.  verified that server id in settings.xml matches the distribution
repository id in the pom.xml

3.  verified correct settings.xml was being used.  I used

   mvn help:effective-settings

4.  verified the url is correct and the protocol being used is http and not
https

5.  using one of the latest versions of maven i.e. 3.3.3





On Tue, Feb 9, 2016 at 4:03 AM, Adrien Rivard 
wrote:

> Hi,
>
>
> I'm guessing you have a mismatch between the repositories ids you have at
> execution and the configured  in your settings.xml (where the
> username/password are).
> Probably the repository id for upload-zip stuff is different that the one
> for upload-jars?
>
>
>
> On Tue, Feb 9, 2016 at 1:54 AM, Mehul Sanghvi 
> wrote:
>
> >
> >
> > I have attached a copy of the pom.xml that I am using.
> >
> >
> >
> > On Mon, Feb 8, 2016 at 4:05 AM, Karl Heinz Marbaise 
> > wrote:
> >
> >> Hi,
> >>
> >> On 2/8/16 6:43 AM, Mehul Sanghvi wrote:
> >>
> >>> I have a project with multiple modules and sub-modules.   Two of the
> >>> modules, use
> >>> the same maven-deploy-plugin:deploy-file logic, just the artefacts they
> >>> are
> >>> working
> >>>
> >>
> >>
> >> Can you show an example of your deploy-file logic? Cause if you are
> >> really using deploy-file goal within your pom file and in your life
> cycle
> >> there is something wrong...
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> with are different.  One module uploads designated JARs to Nexus.  The
> >>> other is
> >>> meant for uploading ZIP files.  Both are activated only if their
> >>> respective
> >>> profiles
> >>> are activated, -Pupload-jars and -Pupload-zips respectively.  Both
> >>> modules
> >>> share the same settings.xml information regarding repositories and
> >>> servers.
> >>>
> >>>
> >>> Upload-jars is able to successfully upload the JARs using deploy-file.
> >>> Upload-zips always fails with:
> >>>
> >>>  Return code is: 401, ReasonPhrase:Unauthorized
> >>>
> >>> How do I figure out the credentials that are being used ?  When I use
> >>>
> >>>  mvn -X
> >>>
> >>> I do not see anything that would indicate what user/passwd combination
> is
> >>> being used.   Any thoughts or suggestions ?
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Mehul N. Sanghvi
> > email: mehul.sang...@gmail.com
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
>
> --
> Adrien Rivard
>



--
Mehul N. Sanghvi
email: mehul.sang...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: debugging maven-deploy-plugin:deploy-file

[Christofer Dutz]

In my case I'm the only user and admin of the Repo Manager.

And I know that I didn't update anything or even log-in to the front end for 
months now. Also I didn't change anything with my settings.xml (even if I 
thought I had but it turned out that it was in another settings.xml). It's 
still the same as in one really old backup.

I'll hope to find some time to investigate this as I know it will bite me 
pretty soon.

Chris


Von: anders.g.ham...@gmail.com <anders.g.ham...@gmail.com> im Auftrag von 
Anders Hammar <and...@hammar.net>
Gesendet: Dienstag, 9. Februar 2016 16:27
An: Maven Users List
Betreff: Re: debugging maven-deploy-plugin:deploy-file

Please keep in mind that there could be authorization rules in the
repository manager that gives access to some groupIds but not others, for
example. You should contact the ones responsible for your repo manager
instance and have them help you!

/Anders

On Tue, Feb 9, 2016 at 4:16 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Just to add my 50ct ... I too encountered a similar problem a few days ago
> and am still having it.
>
> While I had a settings.xml that worked fine for ages I got the exact same
> Unauthorized errors.
> At first I thought I had a problem in my settings but I couldn't find one.
> I "resolved" the problem, by disabling the settings.xml and pulling from
> maven central instead of my private repo ... but that's not a real
> resolution.
>
> I was also using a pretty recent 3.3.x version (not the 3.3.9 cause it
> breaks most of my important plugins)
> My repo is an Artifactory (Haven't updated that for quite some time)
>
> As I don't seem to be alone with this eventually I'll use Wireshark
> investigate what's going over the wire. Mabe this will help find out what's
> going wrong.
>
> Chris
>
> 
> Von: Mehul Sanghvi <mehul.sang...@gmail.com>
> Gesendet: Dienstag, 9. Februar 2016 15:02
> An: Maven Users List
> Cc: i...@soebes.de
> Betreff: Re: debugging maven-deploy-plugin:deploy-file
>
> The repositoryId is the same for both.  They are getting uploaded to the
> same repository.
>
> So face I have tested the following:
>
> 1.  verified username/password by logging into the web ui
>
> 2.  verified that server id in settings.xml matches the distribution
> repository id in the pom.xml
>
> 3.  verified correct settings.xml was being used.  I used
>
>mvn help:effective-settings
>
> 4.  verified the url is correct and the protocol being used is http and not
> https
>
> 5.  using one of the latest versions of maven i.e. 3.3.3
>
>
>
>
>
> On Tue, Feb 9, 2016 at 4:03 AM, Adrien Rivard <adrien.riv...@gmail.com>
> wrote:
>
> > Hi,
> >
> >
> > I'm guessing you have a mismatch between the repositories ids you have at
> > execution and the configured  in your settings.xml (where the
> > username/password are).
> > Probably the repository id for upload-zip stuff is different that the one
> > for upload-jars?
> >
> >
> >
> > On Tue, Feb 9, 2016 at 1:54 AM, Mehul Sanghvi <mehul.sang...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > I have attached a copy of the pom.xml that I am using.
> > >
> > >
> > >
> > > On Mon, Feb 8, 2016 at 4:05 AM, Karl Heinz Marbaise <khmarba...@gmx.de
> >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> On 2/8/16 6:43 AM, Mehul Sanghvi wrote:
> > >>
> > >>> I have a project with multiple modules and sub-modules.   Two of the
> > >>> modules, use
> > >>> the same maven-deploy-plugin:deploy-file logic, just the artefacts
> they
> > >>> are
> > >>> working
> > >>>
> > >>
> > >>
> > >> Can you show an example of your deploy-file logic? Cause if you are
> > >> really using deploy-file goal within your pom file and in your life
> > cycle
> > >> there is something wrong...
> > >>
> > >> Kind regards
> > >> Karl Heinz Marbaise
> > >>
> > >> with are different.  One module uploads designated JARs to Nexus.  The
> > >>> other is
> > >>> meant for uploading ZIP files.  Both are activated only if their
> > >>> respective
> > >>> profiles
> > >>> are activated, -Pupload-jars and -Pupload-zips respectively.  Both
> > >>> modules
> > >>> share the same settings.xml information regarding repositories and
> &

AW: debugging maven-deploy-plugin:deploy-file

[Christofer Dutz]

Yeah I can confirm, that I too couldn't find any reference to invalid login 
attempts in my Artifactory logs.

Chris


Von: Mehul Sanghvi <mehul.sang...@gmail.com>
Gesendet: Dienstag, 9. Februar 2016 21:49
An: Maven Users List
Betreff: Re: debugging maven-deploy-plugin:deploy-file

What should I be looking at on the server side ?  I have access to it, with
admin privs.

I don't know much about it, and am the admin because the people that set it
up have all left
the company.  I'm "it" by default :)

I looked at nexus.log, but nothing happens when I actually run maven with
the pom.xml.  I have compared
the help:effective-settings output for the jars-upload vs zip-upload
profile, and the only difference was
the profile name.

I am trying to figure out from the server side if there is anything
configured incorrectly somewhere, or some role/privilege
that is incorrect, though that doesn't make sense, as its the same user
writing tot he same repository in both cases.




On Tue, Feb 9, 2016 at 10:40 AM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> In my case I'm the only user and admin of the Repo Manager.
>
> And I know that I didn't update anything or even log-in to the front end
> for months now. Also I didn't change anything with my settings.xml (even if
> I thought I had but it turned out that it was in another settings.xml).
> It's still the same as in one really old backup.
>
> I'll hope to find some time to investigate this as I know it will bite me
> pretty soon.
>
> Chris
>
> 
> Von: anders.g.ham...@gmail.com <anders.g.ham...@gmail.com> im Auftrag von
> Anders Hammar <and...@hammar.net>
> Gesendet: Dienstag, 9. Februar 2016 16:27
> An: Maven Users List
> Betreff: Re: debugging maven-deploy-plugin:deploy-file
>
> Please keep in mind that there could be authorization rules in the
> repository manager that gives access to some groupIds but not others, for
> example. You should contact the ones responsible for your repo manager
> instance and have them help you!
>
> /Anders
>
> On Tue, Feb 9, 2016 at 4:16 PM, Christofer Dutz <christofer.d...@c-ware.de
> >
> wrote:
>
> > Just to add my 50ct ... I too encountered a similar problem a few days
> ago
> > and am still having it.
> >
> > While I had a settings.xml that worked fine for ages I got the exact same
> > Unauthorized errors.
> > At first I thought I had a problem in my settings but I couldn't find
> one.
> > I "resolved" the problem, by disabling the settings.xml and pulling from
> > maven central instead of my private repo ... but that's not a real
> > resolution.
> >
> > I was also using a pretty recent 3.3.x version (not the 3.3.9 cause it
> > breaks most of my important plugins)
> > My repo is an Artifactory (Haven't updated that for quite some time)
> >
> > As I don't seem to be alone with this eventually I'll use Wireshark
> > investigate what's going over the wire. Mabe this will help find out
> what's
> > going wrong.
> >
> > Chris
> >
> > 
> > Von: Mehul Sanghvi <mehul.sang...@gmail.com>
> > Gesendet: Dienstag, 9. Februar 2016 15:02
> > An: Maven Users List
> > Cc: i...@soebes.de
> > Betreff: Re: debugging maven-deploy-plugin:deploy-file
> >
> > The repositoryId is the same for both.  They are getting uploaded to the
> > same repository.
> >
> > So face I have tested the following:
> >
> > 1.  verified username/password by logging into the web ui
> >
> > 2.  verified that server id in settings.xml matches the distribution
> > repository id in the pom.xml
> >
> > 3.  verified correct settings.xml was being used.  I used
> >
> >mvn help:effective-settings
> >
> > 4.  verified the url is correct and the protocol being used is http and
> not
> > https
> >
> > 5.  using one of the latest versions of maven i.e. 3.3.3
> >
> >
> >
> >
> >
> > On Tue, Feb 9, 2016 at 4:03 AM, Adrien Rivard <adrien.riv...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > > I'm guessing you have a mismatch between the repositories ids you have
> at
> > > execution and the configured  in your settings.xml (where
> the
> > > username/password are).
> > > Probably the repository id for upload-zip stuff is different that the
> one
> > > for upload-jars?
> > >
> > >
> > >
> > > On Tue, Feb 9, 2016 at 1:54 AM, Mehul Sanghvi <mehul.sang

AW: AW: AW: How to manage dependency "includes"?

[Christofer Dutz]

But yes ... it's exactly what I want ... a "replace-with" option. But with 
exlucdes and includes I thought it should be possible to implement with the 
least impact on the rest of the Maven ecosystem.

Chris


Von: Thomas Broyer <t.bro...@gmail.com>
Gesendet: Samstag, 9. Januar 2016 16:03
An: users@maven.apache.org; rwhee...@artifact-software.com
Betreff: Re: AW: AW: How to manage dependency "includes"?

IIUC, what you really want is a "replace with" rule.

Couldn't that be done by a plugin? You could then configure it in the
parent POM and have it executed everywhere.

Le sam. 9 janv. 2016 10:59, Christofer Dutz <christofer.d...@c-ware.de> a
écrit :

> Thanks for that detailed post, but it's still not what I asked for :-(
> I just finished the transition of ALL of the projects of a large
> international bank from Ant to Maven. In parallell
> what was initially about 70 more or less separate projects, that were
> assembled to one huge monolithic application was changed in order to create
> modules and the ability to assemble several applications, each with
> different focusses.
>
> It was a huge challenge as you have to coordinate the wishes of
> uncountable project-managers, developers and other stakeholders. We
> encountered quite a large number of serious problems. Everyone that has
> worked for a Bank knows you can't just go there and tell them what the
> standard is, cause they'll tell you what their standard is ;-)
>
> So in the end we prohibited (by maven plugin) providing the version of
> third party libraries, enforced the usage of a company-wide
> dependencyManagement pom that is used in every project. Additionally we
> enforced the rules of the dependency plugin to declare used dependencies
> and not to rely on transitive dependencies. With this a lot of our problems
> were solved. Even if the developers complain every now and then, but I
> guess that's the price to pay for giving them the freedom they need and the
> flexibility they want. Introducing a rather strict policy on the process as
> you describe, is completely out of the question. You can't get 40 project
> managers to discuss new versions. This meeting would probably never, ever
> end ;-)
>
> So back to the question none has answered yet (would be cool if maybe
> someone on the dev-team of Maven could respond):
> Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break
> things, and would it be ok to fix up a Pull request implementing that
> functionality?
>
> Chris
>
> 
> Von: Ron Wheeler <rwhee...@artifact-software.com>
> Gesendet: Freitag, 8. Januar 2016 15:58
> An: users@maven.apache.org
> Betreff: Re: AW: AW: How to manage dependency "includes"?
>
> In our setup, each project has its own parent POM and set of aggregated
> third party libraries. Some sharing is done between products for really
> common stuff like Spring, Apache Commons, Tomcat, etc.
> The library com.artifact_software.projectA:reporting-library:1.2 might
> be different from com.artifact_software.projectB:reporting-library:1.2
> if one used BIRT and the other used Jasper Reports.
>
> These should be under the control of the person/team that is responsible
> for deciding what version of the third party libraries are to be allowed.
> The following might be involved in the selection of a new library or a
> request by a developer to upgrade a library.
> - Product Manager - legal/licensing, market acceptance, documentation,
> functionality issues
> - Project manager - scheduling, testing, risk assessment, aggregation
> strategy
> - Lead developer - risk assessment, alternatives, technical analysis,
> aggregation strategy
>
> At the beginning of each development sprint, we review the current
> libraries to see what versions should be updated.
> This does not completely eliminate changes to versions during the
> development process as programmers run into opportunities to use
> features from newer versions or discovery of critical bugs that require
> a library upgrade in mid-sprint.
>
> This review is pretty short and usually involves the entire team so that
> we can estimate the cost of changing a library - what modules will be
> affected and require testing even if they are not being modified as part
> of the sprint.
>
> Once this is done, the developers do not have to worry about
> dependencies. Once the version of
> com.artifact_software.projectA:commons-library:1.2 is set, the
> developers do not have to worry about what version of each of the Apache
> Commons libraries are included and module POMs should not include any
> third party libraries unless there is a 

AW: AW: AW: How to manage dependency "includes"?

[Christofer Dutz]

Wasn't the option to add dependencies programatically by a plugin removed in 
3.3.9? At least this is causing quite some problems with my FLexmojos plugin :-(

Chris


Von: Thomas Broyer <t.bro...@gmail.com>
Gesendet: Samstag, 9. Januar 2016 16:03
An: users@maven.apache.org; rwhee...@artifact-software.com
Betreff: Re: AW: AW: How to manage dependency "includes"?

IIUC, what you really want is a "replace with" rule.

Couldn't that be done by a plugin? You could then configure it in the
parent POM and have it executed everywhere.

Le sam. 9 janv. 2016 10:59, Christofer Dutz <christofer.d...@c-ware.de> a
écrit :

> Thanks for that detailed post, but it's still not what I asked for :-(
> I just finished the transition of ALL of the projects of a large
> international bank from Ant to Maven. In parallell
> what was initially about 70 more or less separate projects, that were
> assembled to one huge monolithic application was changed in order to create
> modules and the ability to assemble several applications, each with
> different focusses.
>
> It was a huge challenge as you have to coordinate the wishes of
> uncountable project-managers, developers and other stakeholders. We
> encountered quite a large number of serious problems. Everyone that has
> worked for a Bank knows you can't just go there and tell them what the
> standard is, cause they'll tell you what their standard is ;-)
>
> So in the end we prohibited (by maven plugin) providing the version of
> third party libraries, enforced the usage of a company-wide
> dependencyManagement pom that is used in every project. Additionally we
> enforced the rules of the dependency plugin to declare used dependencies
> and not to rely on transitive dependencies. With this a lot of our problems
> were solved. Even if the developers complain every now and then, but I
> guess that's the price to pay for giving them the freedom they need and the
> flexibility they want. Introducing a rather strict policy on the process as
> you describe, is completely out of the question. You can't get 40 project
> managers to discuss new versions. This meeting would probably never, ever
> end ;-)
>
> So back to the question none has answered yet (would be cool if maybe
> someone on the dev-team of Maven could respond):
> Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break
> things, and would it be ok to fix up a Pull request implementing that
> functionality?
>
> Chris
>
> 
> Von: Ron Wheeler <rwhee...@artifact-software.com>
> Gesendet: Freitag, 8. Januar 2016 15:58
> An: users@maven.apache.org
> Betreff: Re: AW: AW: How to manage dependency "includes"?
>
> In our setup, each project has its own parent POM and set of aggregated
> third party libraries. Some sharing is done between products for really
> common stuff like Spring, Apache Commons, Tomcat, etc.
> The library com.artifact_software.projectA:reporting-library:1.2 might
> be different from com.artifact_software.projectB:reporting-library:1.2
> if one used BIRT and the other used Jasper Reports.
>
> These should be under the control of the person/team that is responsible
> for deciding what version of the third party libraries are to be allowed.
> The following might be involved in the selection of a new library or a
> request by a developer to upgrade a library.
> - Product Manager - legal/licensing, market acceptance, documentation,
> functionality issues
> - Project manager - scheduling, testing, risk assessment, aggregation
> strategy
> - Lead developer - risk assessment, alternatives, technical analysis,
> aggregation strategy
>
> At the beginning of each development sprint, we review the current
> libraries to see what versions should be updated.
> This does not completely eliminate changes to versions during the
> development process as programmers run into opportunities to use
> features from newer versions or discovery of critical bugs that require
> a library upgrade in mid-sprint.
>
> This review is pretty short and usually involves the entire team so that
> we can estimate the cost of changing a library - what modules will be
> affected and require testing even if they are not being modified as part
> of the sprint.
>
> Once this is done, the developers do not have to worry about
> dependencies. Once the version of
> com.artifact_software.projectA:commons-library:1.2 is set, the
> developers do not have to worry about what version of each of the Apache
> Commons libraries are included and module POMs should not include any
> third party libraries unless there is a good reason not to have it under
> team management.

AW: AW: AW: AW: How to manage dependency "includes"?

[Christofer Dutz]

Well the maven-dependency-plugin has a goal "analyze-only" 
(https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html)
 which reports dependencies, that are used, but not declared and that reports 
unused, but declared dependencies. We are simply using this.

We had problems like if the Application consists of Project A, B and C then 
xml-apis is in version X, if we only use A and B, then it's a different 
version, because a different dependency imported another version transitively. 
We had a lot of problems with code that worked in 10 different Applications, 
but in one it broke. Usually it tuned out to be exactly one of these problems.

Well for an example there is one lib, that references some other lib, that 
contains part of the JMS API 1.0. Unfortunately only part of it. Then in a 
different place we import the real JMS API 1.1. Now we needed to make sure the 
1.1 versions are taken and then all of the API is imported. Without this we 
would have some parts be JMS 1.0 and the other half of the API classes be 1.1. 
We solved the problem by excluding the half JMS 1.0 api artifact and manually 
added the full JMS 1.1 artifact in parallel. This works, but it's ugly. So I 
had the idea that it would be good to have something like this:


 
   
 group-a
 artifact-a
 1.0

 
   
 half-apis
 jms
   
 
 
   
 javax.jms
 jms
 1.1
   
 
   

To actually fully manage the dependencies of "artifact-a"

Hope that's a little clearer.

And I don't quite understand how it would break things. After all, all I'm 
doing is declare ... if you add a dependency to "artifact-a" leave away 
"half-apis:jms" and add "javax.jms:jms:1.1" instead.

Chris


Von: Karl Heinz Marbaise <khmarba...@gmx.de>
Gesendet: Samstag, 9. Januar 2016 13:39
An: Maven Users List
Betreff: Re: AW: AW: AW: How to manage dependency "includes"?

HI,

On 1/9/16 10:59 AM, Christofer Dutz wrote:

> Everyone that has worked for a Bank knows you can't
 >  just go there and tell them what the standard is,
 >  cause they'll tell you what their standard is ;-)

Unfortunately true...

>
> So in the end we prohibited (by maven plugin) providing the version of third 
> party libraries,
 >  enforced the usage of a company-wide dependencyManagement pom
 > that is used in every project.

Sounds like a good idea...

 >  Additionally we enforced the rules of the dependency plugin to
 >  declare used dependencies and not to rely on transitive dependencies.

That is what i don't understand...where is the relationship to
maven-dependency-plugin.May be i missed things here

 >  With this a lot of our problems were solved.
Which kind of problems...may be i missed things here...


> Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break 
> things,
 >and would it be ok to fix up a Pull request implementing that
functionality?

Hm...so you can do things like this (exclusion) single parts...


 
   
 group-a
 artifact-a
 1.0

 
   
 group-c
 excluded-artifact
   
 

   

and since Maven 3.2.1 you exclude all transitive dependencies via:


 
   
 group-a
 artifact-a
 1.0

 
   
 *
 *
   
 

   
...

Apart from that...an include does not make sense from my point of view
cause this could lead to the impression that you you could add
dependencies transitively..which makes no sense..

Furthermore changing the pom structure here would break all things
This kind of changed could only be made (may be ...) in Maven 4???


Kind regards
Karl Heinz Marbaise


-
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: How to manage dependency "includes"?

[Christofer Dutz]

Thanks for that detailed post, but it's still not what I asked for :-(
I just finished the transition of ALL of the projects of a large international 
bank from Ant to Maven. In parallell 
what was initially about 70 more or less separate projects, that were assembled 
to one huge monolithic application was changed in order to create modules and 
the ability to assemble several applications, each with different focusses.

It was a huge challenge as you have to coordinate the wishes of uncountable 
project-managers, developers and other stakeholders. We encountered quite a 
large number of serious problems. Everyone that has worked for a Bank knows you 
can't just go there and tell them what the standard is, cause they'll tell you 
what their standard is ;-)

So in the end we prohibited (by maven plugin) providing the version of third 
party libraries, enforced the usage of a company-wide dependencyManagement pom 
that is used in every project. Additionally we enforced the rules of the 
dependency plugin to declare used dependencies and not to rely on transitive 
dependencies. With this a lot of our problems were solved. Even if the 
developers complain every now and then, but I guess that's the price to pay for 
giving them the freedom they need and the flexibility they want. Introducing a 
rather strict policy on the process as you describe, is completely out of the 
question. You can't get 40 project managers to discuss new versions. This 
meeting would probably never, ever end ;-)

So back to the question none has answered yet (would be cool if maybe someone 
on the dev-team of Maven could respond): 
Would an "EXCLUSION"/"INCLUSION" mechanism in dependencyManagement break 
things, and would it be ok to fix up a Pull request implementing that 
functionality?

Chris


Von: Ron Wheeler <rwhee...@artifact-software.com>
Gesendet: Freitag, 8. Januar 2016 15:58
An: users@maven.apache.org
Betreff: Re: AW: AW: How to manage dependency "includes"?

In our setup, each project has its own parent POM and set of aggregated
third party libraries. Some sharing is done between products for really
common stuff like Spring, Apache Commons, Tomcat, etc.
The library com.artifact_software.projectA:reporting-library:1.2 might
be different from com.artifact_software.projectB:reporting-library:1.2
if one used BIRT and the other used Jasper Reports.

These should be under the control of the person/team that is responsible
for deciding what version of the third party libraries are to be allowed.
The following might be involved in the selection of a new library or a
request by a developer to upgrade a library.
- Product Manager - legal/licensing, market acceptance, documentation,
functionality issues
- Project manager - scheduling, testing, risk assessment, aggregation
strategy
- Lead developer - risk assessment, alternatives, technical analysis,
aggregation strategy

At the beginning of each development sprint, we review the current
libraries to see what versions should be updated.
This does not completely eliminate changes to versions during the
development process as programmers run into opportunities to use
features from newer versions or discovery of critical bugs that require
a library upgrade in mid-sprint.

This review is pretty short and usually involves the entire team so that
we can estimate the cost of changing a library - what modules will be
affected and require testing even if they are not being modified as part
of the sprint.

Once this is done, the developers do not have to worry about
dependencies. Once the version of
com.artifact_software.projectA:commons-library:1.2 is set, the
developers do not have to worry about what version of each of the Apache
Commons libraries are included and module POMs should not include any
third party libraries unless there is a good reason not to have it under
team management.

This also minimizes the changes to POMs.
The parent POM's dependency management sets the versions for the release
being developed so once the reference to the parent POM is changed, all
the right versions of everything is automatically included in the
module. This makes life really easy for developers - change one number
in the module POM and start working.

I hope that this helps.

Ron

On 08/01/2016 5:03 AM, Christofer Dutz wrote:
> I agree, but this only woks as long as there is "THE" project manager. Here 
> there are several ones. The central instance that manages libraries and their 
> versions and handles conflict resolution is simply the one managing the 
> central dependencyManagement pom. All the project POMs are part of the 
> projects and these are responsibility of those teams and even live in 
> separate repos.
>
> But coming back to my initial question:
> Would maven support of "exclusions" and "inclusions" in dependency management 
> break anything? If y

AW: AW: How to manage dependency "includes"?

[Christofer Dutz]

I agree, but this only woks as long as there is "THE" project manager. Here 
there are several ones. The central instance that manages libraries and their 
versions and handles conflict resolution is simply the one managing the central 
dependencyManagement pom. All the project POMs are part of the projects and 
these are responsibility of those teams and even live in separate repos.

But coming back to my initial question:
Would maven support of "exclusions" and "inclusions" in dependency management 
break anything? If yes - what? I still think that this could solve a lot of 
problems we were having and shouldn't have a big impact on Maven itself. If it 
doesn't break anything and I would implement something like that ... what would 
the chances that it gets accepted be?

Chris



Von: Ron Wheeler <rwhee...@artifact-software.com>
Gesendet: Donnerstag, 7. Januar 2016 16:06
An: users@maven.apache.org
Betreff: Re: AW: How to manage dependency "includes"?

If you are using Eclipse with the m2e plug-ins (we use Eclipse/STS which
comes with this), it will tell you what versions are being included as
transitive dependencies.

Our approach removed the decision about library versions from the
developers and put it into the project manager's hand so that:
- Adding a library had some management visibility - license
compatibility, vendor/developer stability, avoiding duplication of
functionality, library testing
- Programmers did not have to worry about incorrect or missing dependencies
- Programmers could move to a new project quickly.
- updating a library version updated automatically updated all projects

It took a bit of work once we decided to get organized but it paid off
very quickly in programmer productivity and improved project schedule
stability

Once you have found the source jar for the library and included it in
one of your libraries, it is available for every module.

Ron


On 07/01/2016 9:25 AM, Christofer Dutz wrote:
> Hi Ron,
>
> Well I guess that's out of the question.
>
> We were thinking about that, but the normal workflow would be:
> - Search in the company nexus which lib provides a given package
> - Include that in the pom
>
> That would work around the "managed-pom" approach. So users would have to 
> look at each dependency, if there is a special pom version in the system. I 
> think that's definitely not going to work.
>
> In this company there are about 200 developers working on 50-60 different 
> projects, that are assembled to about 20 different products. Currently we'll 
> live with excluding stuff and having users add missing dependencies during 
> the unit-, integration- , acceptance-test phases, but it would have been 
> easier with some "exclusions/inclusions" mechanism.
>
> Chris
>
> 
> Von: Ron Wheeler <rwhee...@artifact-software.com>
> Gesendet: Montag, 4. Januar 2016 17:19
> An: users@maven.apache.org
> Betreff: Re: How to manage dependency "includes"?
>
> You can simplify the problem that you are having by making a module that
> includes the correct version of the third party modules and having your
> modules depend on that with a "provided" scope.
> This also makes all of your jars and wars a lot smaller since only one
> copy of each API is included in the whole project rather than having the
> code appear in every one of your modules that needs it.
>
> This speeds your builds by a lot and save individual developers from
> having to think about the "correct" version of each library. They just
> include the aggregated libraries that they need.  For example Apache
> Commons stuff would be supplied by your module
> com.example:myapachecommons:1.0-SNAPSHOT with scope provided.
>
> http://blog.artifact-software.com/tech/?tag=maven might be a useful set
> of articles.
>
>
> Ron
> On 04/01/2016 3:38 AM, Christofer Dutz wrote:
>> Hi,
>>
>>
>> I am currently cleaning up in the dependencies of a quite big set of big 
>> projects. For this I am making a lot of use of dependency management. One 
>> thing I did come across quite a lot of times is this problem:
>>
>>
>> Some libs reference undesired libs, mostly API libs (in most cases they 
>> reference artifacts that contain parts of some API packages). To prevent 
>> them from being used, we exclude them in the dependencyManagement section. 
>> Now the downside is that now the API packages are missing. In order to fix 
>> this, we now have to manually add dependencies to the API modules wherever 
>> the artifact is used. It would be cool, if there was not only an "exclusion" 
>> but also an "inclusion" mechanism in

How to manage dependency "includes"?

[Christofer Dutz]

Hi,


I am currently cleaning up in the dependencies of a quite big set of big 
projects. For this I am making a lot of use of dependency management. One thing 
I did come across quite a lot of times is this problem:


Some libs reference undesired libs, mostly API libs (in most cases they 
reference artifacts that contain parts of some API packages). To prevent them 
from being used, we exclude them in the dependencyManagement section. Now the 
downside is that now the API packages are missing. In order to fix this, we now 
have to manually add dependencies to the API modules wherever the artifact is 
used. It would be cool, if there was not only an "exclusion" but also an 
"inclusion" mechanism in dependencyManagement, so we could actually manage 
situations like this.


Is there a better way of resolving this type of problem? Would adding a feature 
like the "inclusions" to Maven be a good idea? If not, what are the problems 
with it? If yes, what can I do to help get it in (Would be glad to contribute 
something like this)?


Chris

AW: Packaging Maven Core Extensions

[Christofer Dutz]

Ok ... so I invested quite some time in different ways to get the MavenSession 
injected, till I had a look at the other events the EventSpy got and found 
the ExecutionEvent containing an instance of a MavenSession. So I changed my 
code to that and now my Extension seems to be working nicely with Maven 3.1.1 
and above.

Chris


Von: Christofer Dutz christofer.d...@c-ware.de
Gesendet: Samstag, 18. April 2015 22:03
An: Maven Users List; i...@soebes.de
Betreff: AW: Packaging Maven Core Extensions

Hi,

the code is here:
https://github.com/apache/flex-utilities/tree/develop/mavenizer/maven-extension

The provided scope was the tip that got my fat-jar running in lib/ext for 
Maven 3.1.1 ...
Unfortunately it seems to only run in Maven 3.3.1 ... if I try it in 3.2.2 or 
3.1.1 I get errors :-(

Chris


-Ursprüngliche Nachricht-
Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Gesendet: Samstag, 18. April 2015 18:51
An: Maven Users List
Betreff: Re: Packaging Maven Core Extensions

Hi,

are you running from within Jenkins ?

On 4/18/15 6:26 PM, Christofer Dutz wrote:
 Hi,


 I have just finished a small maven core extension containing an EventSpy. 
 It's working nicely if I include it into my build using Maven 3.3.1 and a 
 .mvn/extensions.xml, but I couldn't get it working by copying the jar to 
 the MAVEN_HOME/lib/ext directory (I even tried a shaded jar). All I am 
 getting are these warnings:


 [WARNING] Failed to notify spy 
 org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: 
 java.util.NoSuchElementException
role: org.apache.maven.execution.MavenSession
roleHint:

 ?What is the difference between the two options? What do I have to change in 
 order to have my extension working in older Maven versions (down to 3.1.1) by 
 installing it into the lib/ext directory?

 Chris



Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

B�CB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�PX]�[��\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[�\�\��Z[X]�[��\X�K�ܙ�B

AW: Packaging Maven Core Extensions

[Christofer Dutz]

Hi Jason,

Probably you can't see the injecting, cause while debugging, I found this out 
myself and while trying every option I could think of, that was the first that 
worked :-)

I'm now almost finished. While now my extension works with Maven 3.1.1 up to 
the latest version, now I get some strange classloading issues if I run the 
extension from .mvn/extensions.xml but it works if I install the lib to 
lib/ext ... hopefully I'll be able to find out why this is soon.

java.lang.LinkageError: loader constraint violation: loader (instance of 
org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading 
for a different type with name 
org/apache/maven/artifact/repository/ArtifactRepository

but for now I'll probably simply write the how to install the extension and 
post an by the way if your using 3.3.1-document afterwards ;-)

Chris


-Ursprüngliche Nachricht-
Von: Jason van Zyl [mailto:ja...@takari.io] 
Gesendet: Sonntag, 19. April 2015 14:29
An: Maven Users List
Betreff: Re: Packaging Maven Core Extensions

Not sure what you mean by injected but the code you sent me does not attempt 
to @Inject the session. If you did this is a problem with the spies where you 
can't inject the MavenSession, because the spies are setup in the CLI and you 
can't @Inject the MavenSession until the session scope starts in DefaultMaven. 
So what you're doing is really the only way it can work. We didn't think much 
about spies when creating the session scope. If we moved the setup of the spies 
into DefaultMaven this would likely work as you expected but that's not the way 
it works currently.

On Apr 19, 2015, at 6:09 AM, Christofer Dutz christofer.d...@c-ware.de wrote:

 Ok ... so I invested quite some time in different ways to get the 
 MavenSession injected, till I had a look at the other events the EventSpy 
 got and found the ExecutionEvent containing an instance of a MavenSession. So 
 I changed my code to that and now my Extension seems to be working nicely 
 with Maven 3.1.1 and above.
 
 Chris
 
 
 Von: Christofer Dutz christofer.d...@c-ware.de
 Gesendet: Samstag, 18. April 2015 22:03
 An: Maven Users List; i...@soebes.de
 Betreff: AW: Packaging Maven Core Extensions
 
 Hi,
 
 the code is here:
 https://github.com/apache/flex-utilities/tree/develop/mavenizer/maven-
 extension
 
 The provided scope was the tip that got my fat-jar running in lib/ext for 
 Maven 3.1.1 ...
 Unfortunately it seems to only run in Maven 3.3.1 ... if I try it in 
 3.2.2 or 3.1.1 I get errors :-(
 
 Chris
 
 
 -Ursprüngliche Nachricht-
 Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
 Gesendet: Samstag, 18. April 2015 18:51
 An: Maven Users List
 Betreff: Re: Packaging Maven Core Extensions
 
 Hi,
 
 are you running from within Jenkins ?
 
 On 4/18/15 6:26 PM, Christofer Dutz wrote:
 Hi,
 
 
 I have just finished a small maven core extension containing an EventSpy. 
 It's working nicely if I include it into my build using Maven 3.3.1 and a 
 .mvn/extensions.xml, but I couldn't get it working by copying the jar to 
 the MAVEN_HOME/lib/ext directory (I even tried a shaded jar). All I am 
 getting are these warnings:
 
 
 [WARNING] Failed to notify spy 
 org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: 
 java.util.NoSuchElementException
   role: org.apache.maven.execution.MavenSession
   roleHint:
 
 ?What is the difference between the two options? What do I have to change in 
 order to have my extension working in older Maven versions (down to 3.1.1) 
 by installing it into the lib/ext directory?
 
 Chris
 
 
 
 Kind regards
 Karl Heinz Marbaise
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 B KKK
 KCB  [  X  ܚX KK[XZ[
 \ \  ][  X  ܚX PX] [  \X K ܙ B  ܈Y][
 ۘ[  [X[  K[XZ[
 \ \  Z[X] [  \X K ܙ BB KK
 KKCB  [  X  ܚX KK[
 XZ[
 \ \  ][  X  ܚX PX] [  \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 
 \ \  Z[X] [  \X K ܙ B

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically dedicated 
to political or religious faiths or any other kind of dogmas or goals, it's 
always because these dogmas or goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Packaging Maven Core Extensions

[Christofer Dutz]

Hi,


I have just finished a small maven core extension containing an EventSpy. It's 
working nicely if I include it into my build using Maven 3.3.1 and a 
.mvn/extensions.xml, but I couldn't get it working by copying the jar to the 
MAVEN_HOME/lib/ext directory (I even tried a shaded jar). All I am getting are 
these warnings:


[WARNING] Failed to notify spy 
org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: 
java.util.NoSuchElementException
  role: org.apache.maven.execution.MavenSession
  roleHint:

?What is the difference between the two options? What do I have to change in 
order to have my extension working in older Maven versions (down to 3.1.1) by 
installing it into the lib/ext directory?

Chris

AW: Packaging Maven Core Extensions

[Christofer Dutz]

Hi,

the code is here:
https://github.com/apache/flex-utilities/tree/develop/mavenizer/maven-extension

The provided scope was the tip that got my fat-jar running in lib/ext for 
Maven 3.1.1 ...
Unfortunately it seems to only run in Maven 3.3.1 ... if I try it in 3.2.2 or 
3.1.1 I get errors :-(

Chris


-Ursprüngliche Nachricht-
Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Gesendet: Samstag, 18. April 2015 18:51
An: Maven Users List
Betreff: Re: Packaging Maven Core Extensions

Hi,

are you running from within Jenkins ?

On 4/18/15 6:26 PM, Christofer Dutz wrote:
 Hi,


 I have just finished a small maven core extension containing an EventSpy. 
 It's working nicely if I include it into my build using Maven 3.3.1 and a 
 .mvn/extensions.xml, but I couldn't get it working by copying the jar to 
 the MAVEN_HOME/lib/ext directory (I even tried a shaded jar). All I am 
 getting are these warnings:


 [WARNING] Failed to notify spy 
 org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: 
 java.util.NoSuchElementException
role: org.apache.maven.execution.MavenSession
roleHint:

 ?What is the difference between the two options? What do I have to change in 
 order to have my extension working in older Maven versions (down to 3.1.1) by 
 installing it into the lib/ext directory?

 Chris



Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Looking for a way to visualize dependency structure of my multi-module pom project

[Christofer Dutz]

I used the maven-graph-plugin successfully too but sent the output through an 
XSLT to strip out stuff I didn't want.

Chris


Von: Dan Tran dant...@gmail.com
Gesendet: Mittwoch, 8. April 2015 10:59
An: Maven Users List
Betreff: Re: Looking for a way to visualize dependency structure of my 
multi-module pom project

You may want to take alook

groupIdorg.fusesource.mvnplugins/groupId
artifactIdmaven-graph-plugin/artifactId


I can graph all my internal projects and exclude external dependencies

-D

On Wed, Apr 8, 2015 at 1:46 AM, Pisarev, Vitaliy vitaliy.pisa...@hp.com
wrote:

 I have a pretty large project (~30 modules) and want to visualize module
 inter dependencies, excluding 3rd party.

 It seems that existing tools simply can't handle the maven reactor. The
 maven dependency plugin (dependency:tree goal) knows how to generate
 graphml, but only per module. And if I use the append flag, it simply
 shoves everything to a single file, so the output is a corrupted graphml.

 I also found this tool
 https://github.com/janssk1/maven-graph-plugin/wiki/Manual but it seems
 that there is no way to control module granularity.

 My last resort would be to parse the output of dependency:tree, but I
 thought I'll consult the community before this.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Problems with the release plugin

[Christofer Dutz]

Hi Robert,

Thanks for your reply, but I have encountered numerous situations where this 
restriction resulted in people not using the pulugin at all ... doing each step 
with alternate plugins and unfortunately leaving away some of the steps.

So ususally they use the versions plugin or manually adjust the versions.
Commit
Tag
Build  Deploy
Update to the next version
Comit again

completely skipping some of the usual additional testing steps

I know that handling the commandline is tricky and a lot can go wrong here. 
Thats why I usually have this created by a Jenkins plugin which I created 
(https://github.com/chrisdutz/jenkins-release-plugin). 

Also it sort of feels like I am doing Ant to Maven migration for the last few 
years all the time ... for business, in other Apache Project (Mainly Apache 
Flex) ... and every now and then I come to this point. 

I still don't really see how losening this restriction would really break 
something. Every time this issue comes up, I get responses like don't want to 
break anything but I don't quite understand how this would actually break 
things.

Another route would be to extend the versions plugin tob e able to set multiple 
artifacts versions to given versions. 

Or last but least to create a new plugin, which I would really like to avoid.

Chris





-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Freitag, 28. November 2014 18:42
An: Maven Users List
Betreff: Re: Problems with the release plugin

Op Thu, 27 Nov 2014 14:12:58 +0100 schreef Dutz, Christofer
c.d...@ing-diba.de:

 Hi,

 I just ran into a problem I was having a few times now with the 
 release plugin. This time the usage scenario is different, but the 
 code needed to be changed is still the same.

 This time I am helping migrate a large set of projects from Ant to 
 Maven. As this involves a large amount of training the transition is 
 done project by project.
 Currently as a first step all projects are changed to deploy SNAPSHOT 
 and release versions to Nexus instead of deploying to an Ivy repo. For 
 this all Ant builds were extended to produce and deploy artifacts 
 useable by Maven and the Ant builds are configured to use Nexus 
 instead of Ivy.

 Now whenever a release is done there actually have to be two releases 
 performed. One Ant and one Maven release. For the Maven part we wanted 
 to use the default release plugin. For this we are planning on 
 providing the release and development version for each artifact as 
 described in this article:
 http://maven.apache.org/maven-release/maven-release-plugin/examples/no
 n-interactive-release.html For the Ant part we have created an Ant 
 task that updates the ivy.xml to the correct versions, which 
 understands the same syntax of providing dev and rel versions as that 
 of the Maven release plugin.

 Now the problem is that AbstractRewritePomsPhase only seems to process 
 the version numbers of artifacts that are in the reactor:

 https://github.com/apache/maven-release/blob/trunk/maven-release-manag
 er/src/main/java/org/apache/maven/shared/release/phase/AbstractRewrite
 PomsPhase.java

 Wouldn't it be possible to leave the version map the way it is, 
 without filtering anything out? If a user provides the rel version and 
 the dev version for an artifact I would assume that he actually should 
 have a reason for doing this. This behaviour is causing quite some 
 difficulties here.

This is probably the most tricky part. I'd like to keep the process as simple 
as possible with a minimum of a failing release. Since we only have full 
control over the versions of the current (multimodule) project, these are safe 
to map. *If* we allow versions of other dependencies as well, then these should 
be checked as well, both release and development version.
The maven-release-plugin is just too important to allow these kind of manual 
input where the changes of failure are that big.

I've started with the introduction of a VersionPolicy[1] in the 
maven-release-plugin. It's not yet exposed, so you can't specify your own 
policies yet. But this would give you the opportunity to select the versions 
automatically instead of specifying it from cmdline (which is doomed to fail 
every now and than).

So here you could help and see if this concept works for you as well.

regards,
Robert

[1]
http://maven.apache.org/maven-release/maven-release-api/apidocs/index.html

 I would be glad to assitst in finding a good solution for this, if 
 there is no chance in getting this changed, we will propably have to 
 work on a custom version oft he release plugin, which I would really like to 
 avoid.

 Chris

 --

 ING-DiBa AG, Frankfurt am Main. Registernummer HRB 7727, 
 Handelsregister Amtsgericht Frankfurt am Main. Vorstand: Roland 
 Boekhout (Vorsitzender), Herbert Willius (stellv. Vorsitzender), Bernd 
 Geilen, Katharina Herrmann, Martin Krebs, Remco Nieland.
 Aufsichtsrat: Ben Tellings (Vorsitzender)

 Diese E-Mail 

AW: Problems with the release plugin

[Christofer Dutz]

Unfortunately the world isn't as ideal as I would like it to be. There are 
sometimes constraints that lie outside of the reach of the developer(s) working 
on the projects build.

In one case the company I worked for desperately needed to release parts of a 
multi module build separately. I know that this comes with problems, but as 
long as no other option comes up to reduce the amount of binary data of a new 
release having to be transfered over an Edge mobile connection, they will have 
to do partial releases. 

In my current case the entire company is being switched from Ant to Maven. 
Switching everything in one big step is completely out of the question. The 
amount of simultaneous training needed for this is simply not possible. So we 
have to go a migration path which brings us closer and closer to the final goal 
of having everything in Maven and be able to use the default 
maven-release-plugin. But till we are there it feels like there is no way 
without patching this plugin in order to have an easy transition path.

What about some legacy or quirks mode for the plugin that allows such a 
thing ... it might even output warnings and pages of text explaining why this 
mode sucks and should be avoided. All I am asking for is a way to use the 
plugin without having to hack it which acknowledging that I know this is not 
ideal, but I am willing to accept the consequences.

Chris

-Ursprüngliche Nachricht-
Von: Benson Margulies [mailto:bimargul...@gmail.com] 
Gesendet: Sonntag, 30. November 2014 13:52
An: Maven Users List
Betreff: Re: Problems with the release plugin

I'm going to attempt a summary here.

The release plugin has a requirement. It must be true that you can go to the 
SCM, checkout a brand new copy of the tree rooted at the scm/ element, 
_change the versions_ in the pom(s), and run a build as configured by the 
profiles and goals. If that's not true, the release process will fail, and 
possibly leave you with a manual cleanup in the SCM. There are many ways to set 
up a build that seems just fine but fails this test.

The top of this thread is a plea for a 'dry run' that is a perfect simulation 
of this, so that users can flush this out before it bites them, and that it 
should not be hard to ask for this.

It seems to me that it should not be hard, in a typical automated build system 
(Jenkins, etc.) to set up a build that does exactly this.
Checkout a clean tree, run the maven-versions-plugin to set a dummy version, 
and run a build, with profiles and goals to match the eventual release. Eat one 
of these apples every day, and you won't be visiting the maven doctor so often.

It seems to me that it should also not be terribly hard to make this a feature 
of the maven-release-plugin.

As a further wrinkle, there's the question of tag management, which might be 
seen as interrelated to the lengthy threads here and elsewhere about never, 
ever, deleting a tag. I wonder about yet another m-r-p parameter: a staging SCM 
URL, distinct from the scm/ stock identifiers. m-r-p would pull from scm/ 
but push to this other place. Then, a human could decide if the release is 
real, and, if so, push the commits and tag to the real, immutable, repo. I'm 
not qualifier to judge whether this can work for anything other than git, but 
git sure is popular.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Problems with the release plugin

[Christofer Dutz]

Oh well ... I give up ... so yet another plugin it will be. 

I wasn't talking about changing anything at the workflow, just to have one 
enforced constraint loosended a little if required, but I guess this will never 
happen.

Chris



-Ursprüngliche Nachricht-
Von: Benson Margulies [mailto:bimargul...@gmail.com] 
Gesendet: Sonntag, 30. November 2014 22:22
An: Maven Users List
Betreff: Re: Problems with the release plugin

The release plugin is a tool that does a specified set of steps. It's built out 
of reusable components. Turning it into MS Word with
10,000,000 options is not, in my view, a good plan.

If you can write down a clear spec for an alternative workflow, you can study 
the source and make a plugin. That's what the owners of the 
gitflow-maven-plugin did. It's an alternative release plugin with a different 
workflow.


On Sun, Nov 30, 2014 at 11:44 AM, Christofer Dutz christofer.d...@c-ware.de 
wrote:
 Unfortunately the world isn't as ideal as I would like it to be. There are 
 sometimes constraints that lie outside of the reach of the developer(s) 
 working on the projects build.

 In one case the company I worked for desperately needed to release parts of a 
 multi module build separately. I know that this comes with problems, but as 
 long as no other option comes up to reduce the amount of binary data of a new 
 release having to be transfered over an Edge mobile connection, they will 
 have to do partial releases.

 In my current case the entire company is being switched from Ant to Maven. 
 Switching everything in one big step is completely out of the question. The 
 amount of simultaneous training needed for this is simply not possible. So we 
 have to go a migration path which brings us closer and closer to the final 
 goal of having everything in Maven and be able to use the default 
 maven-release-plugin. But till we are there it feels like there is no way 
 without patching this plugin in order to have an easy transition path.

 What about some legacy or quirks mode for the plugin that allows such a 
 thing ... it might even output warnings and pages of text explaining why this 
 mode sucks and should be avoided. All I am asking for is a way to use the 
 plugin without having to hack it which acknowledging that I know this is not 
 ideal, but I am willing to accept the consequences.

 Chris

 -Ursprüngliche Nachricht-
 Von: Benson Margulies [mailto:bimargul...@gmail.com]
 Gesendet: Sonntag, 30. November 2014 13:52
 An: Maven Users List
 Betreff: Re: Problems with the release plugin

 I'm going to attempt a summary here.

 The release plugin has a requirement. It must be true that you can go to the 
 SCM, checkout a brand new copy of the tree rooted at the scm/ element, 
 _change the versions_ in the pom(s), and run a build as configured by the 
 profiles and goals. If that's not true, the release process will fail, and 
 possibly leave you with a manual cleanup in the SCM. There are many ways to 
 set up a build that seems just fine but fails this test.

 The top of this thread is a plea for a 'dry run' that is a perfect simulation 
 of this, so that users can flush this out before it bites them, and that it 
 should not be hard to ask for this.

 It seems to me that it should not be hard, in a typical automated build 
 system (Jenkins, etc.) to set up a build that does exactly this.
 Checkout a clean tree, run the maven-versions-plugin to set a dummy version, 
 and run a build, with profiles and goals to match the eventual release. Eat 
 one of these apples every day, and you won't be visiting the maven doctor so 
 often.

 It seems to me that it should also not be terribly hard to make this a 
 feature of the maven-release-plugin.

 As a further wrinkle, there's the question of tag management, which might be 
 seen as interrelated to the lengthy threads here and elsewhere about never, 
 ever, deleting a tag. I wonder about yet another m-r-p parameter: a staging 
 SCM URL, distinct from the scm/ stock identifiers. m-r-p would pull from 
 scm/ but push to this other place. Then, a human could decide if the 
 release is real, and, if so, push the commits and tag to the real, immutable, 
 repo. I'm not qualifier to judge whether this can work for anything other 
 than git, but git sure is popular.

 -
 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

Strange Dependency problem after switching to Maven 3.1.1

[Christofer Dutz]

Hi,


I'm currently working on updating the Flexmojos plugin to support newer Maven 
versions. Now I'm having a strange problem:


Flexmojos defines Flex dependencies as type swc for flex libraries and 
rb.swc for resource bundles. Furthermore we have a scope rsl (runtime 
shared library) which sort of turns the default static linking to dynamic 
linking.


So assume I have an artifact A and B of type swc that has one rb.swc 
dependency to its corresponding resource bundle.


In my project I now add one dependency to A with scope rsl and one dependency 
to B with the default compile scope.


In Maven 3.0.5 I can see the MavenProjects.artifacts list containing


A:swc:rsl

A:rb.swc:compile

B:swc:compile

B:rb.swc:compile


In Maven 3.1.1 this however is:


A:swc:rsl

A:rb.swc:runtime

B:swc:compile

B:rb.swc:compile


Why does the scope of the transitive dependencies switch to runtime in Maven 
3.1.1?


Chris

AW: Strange Dependency problem after switching to Maven 3.1.1

[Christofer Dutz]

Actually in MavenProject the resolvedArtifacts variable contains this data 
... not artifacts as the runtime artifacts are stripped out by the 
artifactFilter.

Chris


Von: Christofer Dutz christofer.d...@c-ware.de
Gesendet: Freitag, 17. Oktober 2014 14:20
An: Maven Users List
Betreff: Strange Dependency problem after switching to Maven 3.1.1

Hi,


I'm currently working on updating the Flexmojos plugin to support newer Maven 
versions. Now I'm having a strange problem:


Flexmojos defines Flex dependencies as type swc for flex libraries and 
rb.swc for resource bundles. Furthermore we have a scope rsl (runtime 
shared library) which sort of turns the default static linking to dynamic 
linking.


So assume I have an artifact A and B of type swc that has one rb.swc 
dependency to its corresponding resource bundle.


In my project I now add one dependency to A with scope rsl and one dependency 
to B with the default compile scope.


In Maven 3.0.5 I can see the MavenProjects.artifacts list containing


A:swc:rsl

A:rb.swc:compile

B:swc:compile

B:rb.swc:compile


In Maven 3.1.1 this however is:


A:swc:rsl

A:rb.swc:runtime

B:swc:compile

B:rb.swc:compile


Why does the scope of the transitive dependencies switch to runtime in Maven 
3.1.1?


Chris

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Strange Dependency problem after switching to Maven 3.1.1

[Christofer Dutz]

Ok ... well think I have to answer my own question again :-(

It took me about a day to debug this, but it seems the conflict resolution of 
Maven has changed.
The thing is the framework:swc has the same name and groupId as the 
framework:rb.swc ... so maven thinks there are two identical dependencies but 
with different scope. This causes maven to go into 
JavaScopeDeriver.getDerivedScope  here in the end in the else simply 
RUNTIME is assumed as a default. I think I will have to refactor the structure 
of our artifacts to generate the resource bundles into a different artifact 
(assumably by appending .rb to the group Id.

Chris


Von: Christofer Dutz christofer.d...@c-ware.de
Gesendet: Freitag, 17. Oktober 2014 14:28
An: Maven Users List
Betreff: AW: Strange Dependency problem after switching to Maven 3.1.1

Actually in MavenProject the resolvedArtifacts variable contains this data 
... not artifacts as the runtime artifacts are stripped out by the 
artifactFilter.

Chris


Von: Christofer Dutz christofer.d...@c-ware.de
Gesendet: Freitag, 17. Oktober 2014 14:20
An: Maven Users List
Betreff: Strange Dependency problem after switching to Maven 3.1.1

Hi,


I'm currently working on updating the Flexmojos plugin to support newer Maven 
versions. Now I'm having a strange problem:


Flexmojos defines Flex dependencies as type swc for flex libraries and 
rb.swc for resource bundles. Furthermore we have a scope rsl (runtime 
shared library) which sort of turns the default static linking to dynamic 
linking.


So assume I have an artifact A and B of type swc that has one rb.swc 
dependency to its corresponding resource bundle.


In my project I now add one dependency to A with scope rsl and one dependency 
to B with the default compile scope.


In Maven 3.0.5 I can see the MavenProjects.artifacts list containing


A:swc:rsl

A:rb.swc:compile

B:swc:compile

B:rb.swc:compile


In Maven 3.1.1 this however is:


A:swc:rsl

A:rb.swc:runtime

B:swc:compile

B:rb.swc:compile


Why does the scope of the transitive dependencies switch to runtime in Maven 
3.1.1?


Chris

-
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: Strange Dependency problem after switching to Maven 3.1.1

[Christofer Dutz]

Well it seems that I'm still stuck. As even with different GAV it seems that 
the same rules apply :-(
The parent in this case doesn't seem to the the pom-parent, but the artifact 
having a dependency on the child artifact.
So I guess Maven wants to figgure out what scope it should set for the children 
based upon the scope of the parent.
So if it's a normal compile dependency, it leaves the child scope unchanged, 
if the parent is test or runtime then it forces all children to be the 
same, which makes sense. But in the end there is that dredded runtime if none 
of the others apply :-( I wonder why this wasn't a problem prior to 3.1 ... at 
least with separate GAV I now have the same problem with Maven 3.0.5 ... at 
least I have consistency ;-)

I know that Maven isn't indended on being a pure Java build system, even if it 
is mainly used for that. But I have successfully used it for building Java, 
Flex, C++ and C# projects. Flex and all the C's support different linking types 
while Java effectively supports only one. How would it be to make Maven 
extendable with custom scopes? After all we are able to add custom types. If I 
were to refactor flexmojos to support different types (type=swc = (default) 
statically-linked, type=swc-rsl = dynamicly linked, type=swc-include = 
statically-linked with all classes embedded in the output) ... would a this 
work?

Assuming I have a pom artifact A containing only one dependency:

dependency
groupIdorg.apache.flex.framework/groupId
artifactIdB/artifactId
version4.13.0.20140701/version
typeswc/type
/dependency

And then in my module I have this:

dependency
groupIdorg.apache.flex.framework/groupId
artifactIdB/artifactId
version4.13.0.20140701/version
typeswc-rsl/type
/dependency

dependency
groupIdorg.apache.flex.framework/groupId
artifactIdA/artifactId
version4.13.0.20140701/version
typepom/type
/dependency

Then would the type of B in the first dependency override the type of B 
imported by the pom dependency to A? I doubt it ...
I would expect the resulting module to have dependencies to two artifacts B, 
one of type swc and one of swc-rsl.

I would really really like to sort out this problem and release Flexmojos with 
support of maven 3.1 and above ... currently we're stuck at 3.0.5 :-(

Chris


-Ursprüngliche Nachricht-
Von: Martin Gainty [mailto:mgai...@hotmail.com] 
Gesendet: Freitag, 17. Oktober 2014 18:14
An: users@maven.apache.org
Betreff: RE: AW: Strange Dependency problem after switching to Maven 3.1.1





 From: christofer.d...@c-ware.de
 To: users@maven.apache.org
 Subject: AW: Strange Dependency problem after switching to Maven 3.1.1
 Date: Fri, 17 Oct 2014 15:04:00 +
 
 Ok ... well think I have to answer my own question again :-(
 
 It took me about a day to debug this, but it seems the conflict resolution of 
 Maven has changed.
 The thing is the framework:swc has the same name and groupId as the 
 framework:rb.swc ... so maven thinks there are two identical dependencies but 
 with different scope. This causes maven to go into 
 JavaScopeDeriver.getDerivedScope  here in the end in the else simply 
 RUNTIME is assumed as a default.

MGruntime default scoping is explained somewhat at 
MGhttp://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf
MGclearing up the situation for each dependency to have different GAV 
MGwill resolve

I think I will have to refactor the structure of our artifacts to generate the 
resource bundles into a different artifact (assumably by appending .rb to the 
group Id
MGperhaps the owner of 
MGhttp://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf doc will allow 
documenting this side effect by Chris Dutz...no sense in anyone else being bit 
by Identical GAV default runtime scoping side-effect
 
 Chris
 
 
 Von: Christofer Dutz christofer.d...@c-ware.de
 Gesendet: Freitag, 17. Oktober 2014 14:28
 An: Maven Users List
 Betreff: AW: Strange Dependency problem after switching to Maven 3.1.1
 
 Actually in MavenProject the resolvedArtifacts variable contains this data 
 ... not artifacts as the runtime artifacts are stripped out by the 
 artifactFilter.
 
 Chris
 
 
 Von: Christofer Dutz christofer.d...@c-ware.de
 Gesendet: Freitag, 17. Oktober 2014 14:20
 An: Maven Users List
 Betreff: Strange Dependency problem after switching to Maven 3.1.1
 
 Hi,
 
 
 I'm currently working on updating the Flexmojos plugin to support newer Maven 
 versions. Now I'm having a strange problem:
 
 
 Flexmojos defines Flex dependencies as type swc for flex libraries and 
 rb.swc for resource bundles. Furthermore we have a scope rsl (runtime 
 shared library) which sort of turns the default static linking to dynamic 
 linking.
 
 
 So assume I have an artifact

Releasing Maven Plugins

[Christofer Dutz]

Hi,


I'm currently releasing a new version of Flexmojos. While I sort of found a 
procedure for releasing that maven plugin, it's still sort of a PITA.


The main problem is that the project contains the plugin as well as some 
modules that use the plugin. Now in order to build, I have a minimal profile 
which builds only the plugin and after that I'm good to go with normal 
building. Now when doing a release, I usually do this:


- mvn release:prepare (will fail as the plugin doesn't exist in the release 
version)

- mvn -Pminimal install (Which installs the release version)

- mvn release:rollback

- mvn release:prepare

- mvn release:perform (will fail as the new SNAPSHOT version of the plugin 
doesn't exist yet)

- mvn -Pminimal install (Which installs the SNAPSHOT version)

- mvn release:perform


But to say that's ideal would be a lie ;-)


Using version:set to update to the release version and the new SNAPSHOT version 
and doing a minimal build of each prior to the actual release, sort of doesn't 
sound ideal either :-(


How do you guys do this when releasing maven plugins?


Chris

AW: Releasing Maven Plugins

[Christofer Dutz]

But if I create a plugin using the official maven-plugin archetype the setup is 
almost the same so it can't be that off-track.

Chris


Von: Karl Heinz Marbaise khmarba...@gmx.de
Gesendet: Freitag, 12. September 2014 14:46
An: Maven Users List
Betreff: Re: Releasing Maven Plugins

HI,

 
 I'm currently releasing a new version of Flexmojos. While I sort of found a 
 procedure for releasing
  that maven plugin, it's still sort of a PITA.


 The main problem is that the project contains the plugin as
 well as some modules that use the plugin.

This is the basic mistake in this scenario. If you build a maven-plugin
make a separate project from it and do the release etc. only from the
maven-plugin and afterwards you have the release available and can
continue with the rest which uses the release...


Kind regards
Karl-Heinz Marbaise

-
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: Releasing Maven Plugins

[Christofer Dutz]

Unfortunately not. To me it seems as if the reactor checks if everything is 
available and if it's missing the build fails. The strange thing is that it 
only checks if something is there ... during the build the freshly built 
version of the plugin is used ... it's just that maven gives up before even 
starting :-|

Chris

Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von 
Anders Hammar and...@hammar.net
Gesendet: Freitag, 12. September 2014 15:07
An: Maven Users List
Betreff: Re: Releasing Maven Plugins


 The main problem is that the project contains the plugin as

 well as some modules that use the plugin.

This is the basic mistake in this scenario. If you build a maven-plugin
 make a separate project from it and do the release etc. only from the
 maven-plugin and afterwards you have the release available and can continue
 with the rest which uses the release...


Although I haven't tried it myself, my understanding is that it should be
possible to use a plugin built within a multi-module project in some of the
other modules when using Maven 3.x. This is not possible with Maven 2.x
though. However, it requires the plugin to be built before the modules that
uses it (which the reactor should be able to calculate, unless there are
some circular module dependencies).

/Anders




 Kind regards
 Karl-Heinz Marbaise

 -
 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: Releasing Maven Plugins

[Christofer Dutz]

No I can't build with an empty local repo. I have to build the plugin first 
using the minimal profile.
As i said in the other post, Maven gives up before starting to build.

You can have a look ... the project is publicly available. Unfortunately I 
didn't create it ... I took over development 2 Years ago. 
https://github.com/chrisdutz/flexmojos

Chris


Von: Karl Heinz Marbaise khmarba...@gmx.de
Gesendet: Freitag, 12. September 2014 15:17
An: Maven Users List
Betreff: Re: AW: Releasing Maven Plugins

Hi Chris,


  But if I create a plugin using the official maven-plugin archetype
the setup is almost the same so it can't be that off-track.

Which exactly have you used to do the setup...

Furhtermore i would separate build tools for the build itself from using
them...

Apart from that what Anders is saying it is working but on the other
hand you seemed to be having some problems so there must be problems in
your build...

Can you build on command line with a cleaned local repository without an
issue just by using:

mvn clean package ?




 Chris

 
 Von: Karl Heinz Marbaise khmarba...@gmx.de
 Gesendet: Freitag, 12. September 2014 14:46
 An: Maven Users List
 Betreff: Re: Releasing Maven Plugins

 HI,

   
 I'm currently releasing a new version of Flexmojos. While I sort of found a 
 procedure for releasing
that maven plugin, it's still sort of a PITA.


 The main problem is that the project contains the plugin as
   well as some modules that use the plugin.

 This is the basic mistake in this scenario. If you build a maven-plugin
 make a separate project from it and do the release etc. only from the
 maven-plugin and afterwards you have the release available and can
 continue with the rest which uses the release...


 Kind regards

-
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: Releasing Maven Plugins

[Christofer Dutz]

Unfortunately I've tried that :-( I can't start the build at all if the plugin 
is not already in the repo as soon as a module intending on using the plugin is 
in reactor.

Chris




Von: Robert Scholte rfscho...@apache.org
Gesendet: Freitag, 12. September 2014 17:08
An: Maven Users List
Betreff: Re: AW: Releasing Maven Plugins

Are you sure it's not pulled from the local repository?
To check, remove that SNAPSHOT and run 'mvn verify' and NEVER 'mvn
install'.

Robert

Op Fri, 12 Sep 2014 16:56:05 +0200 schreef Christofer Dutz
christofer.d...@c-ware.de:

 Unfortunately not. To me it seems as if the reactor checks if everything
 is available and if it's missing the build fails. The strange thing is
 that it only checks if something is there ... during the build the
 freshly built version of the plugin is used ... it's just that maven
 gives up before even starting :-|

 Chris
 
 Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag
 von Anders Hammar and...@hammar.net
 Gesendet: Freitag, 12. September 2014 15:07
 An: Maven Users List
 Betreff: Re: Releasing Maven Plugins


 The main problem is that the project contains the plugin as

 well as some modules that use the plugin.

 This is the basic mistake in this scenario. If you build a maven-plugin
 make a separate project from it and do the release etc. only from the
 maven-plugin and afterwards you have the release available and can
 continue
 with the rest which uses the release...


 Although I haven't tried it myself, my understanding is that it should be
 possible to use a plugin built within a multi-module project in some of
 the
 other modules when using Maven 3.x. This is not possible with Maven 2.x
 though. However, it requires the plugin to be built before the modules
 that
 uses it (which the reactor should be able to calculate, unless there are
 some circular module dependencies).

 /Anders




 Kind regards
 Karl-Heinz Marbaise

 -
 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: AW: AW: Artifact with different sets of dependencies switched by profiles

[Christofer Dutz]

Hey ... now that looks promissing :-) 

I'll give that a spin as soon as I have time.

I didn't know that you could use variables in the scope (But I think that's 
just some old info probably stored in my brain ages ago).

Chris



Von: Jörg Schaible joerg.schai...@gmx.de
Gesendet: Sonntag, 29. Juni 2014 15:16
An: users@maven.apache.org
Betreff: Re: AW: AW: Artifact with different sets of dependencies switched by 
profiles

Hi Christoper,

Christofer Dutz wrote:

 Hi Ron,

 I think you got what I'm trying to do a little wrong. It's not two
 different set of dependencies, it's two different ways of linking the same
 set of libraries. If I were to translate this into java, imagine that the
 default way an application was built would be to include all Classes
 needed by the application to be bundled in the application Jar (The
 classes not needed aren't included). Now in modular applications I am able
 to switch to something exactly the same as in Java ... no code is included
 in the Application jar, but the referenced libraries are deployed in
 parallel to the application jar, so the JVM can pull them in as needed (In
 Flex this type is called rsl (runtime shared library).

 So in principal I have the same set of dependencies, but in the
 rsl-linking type these dependencies have an additional scope=rsl
 setting. Up until now there was only one pom with the default set of
 dependencies. If the users wanted to utilize rsl linking they would have
 to manually add each dependency and set that's scope to rsl. I would like
 to make it easier for users to switch.

 So the profiles is bad, the pom with classifier doesn't work ... I would
 really like to avoid to have something like an flramework artifact and
 one framework-rsl for the rsl linking.

What's the default value for the scope? compile? Then you can do all you
need with properties. You might use a profile, but it is not necessary:

Declare your dependencies just like before (either in depMgmt or directly):

== % =
 dependency
   groupIdorg.apache.flex.framework/groupId
   artifactIdspark/artifactId
   version4.12.1.20140427/version
   typeswc/type
   scope${flexmojo.scope}/scope
 /dependency
 ...
 properties
   flexmojo.scopecompile/flexmojo.scope
 /properties
== % =

Then you can simply redefine flexmojo.scope from command line. This will
also affect inherited dependencies, if they are declared in the same way in
the repository or if you delcare them in a common parent with a
dependencyManagement section. You might even overwrite the property in a
profile:

== % =
 profile
   idrsl/id
   properties
 flexmojo.scopersl/flexmojo.scope
   /properties
 profile
== % =

Unfortunately, I don't know nothing about flexmojo. If it works like in the
world of C where I can use the same libraries (.lib files) to link an
application either static or dynamically (then requiring runtime libs as
well), then it is possible to do this. Therefore is is fine for an project
creating such an application at the end of a build chain.

However, if the libraries differ if build with rsl or not, then you will
create a very bad user experience, because - just as Stephen already said -
the build process will use whatever it finds in the local repository, it
cannot separate between artifacts built with rsl or without. Your users
might get a wild mix during build time.

Cheers,
Jörg


-
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: Artifact with different sets of dependencies switched by profiles

[Christofer Dutz]

So the only option I have, is to generate different pom artifacts and I can 
choose the profile by selecing different pom artifacts? There is no other 
option?

Chris



Von: Stephen Connolly stephen.alan.conno...@gmail.com
Gesendet: Dienstag, 1. Juli 2014 15:02
An: Maven Users List
Cc: joerg.schai...@gmx.de
Betreff: Re: AW: AW: Artifact with different sets of dependencies switched by 
profiles

And you are going to have the exact same set of issues as with profiles.

Maven 3 does not re-interpolate the poms of dependencies IIRC... or at
least it is not supposed to... so you only get to control the variables
from the parent pom and any inherited dependencies/dependencyManagement not
from the transitive dependencies of your pom


On 1 July 2014 10:42, Christofer Dutz christofer.d...@c-ware.de wrote:

 Hey ... now that looks promissing :-)

 I'll give that a spin as soon as I have time.

 I didn't know that you could use variables in the scope (But I think
 that's just some old info probably stored in my brain ages ago).

 Chris


 
 Von: Jörg Schaible joerg.schai...@gmx.de
 Gesendet: Sonntag, 29. Juni 2014 15:16
 An: users@maven.apache.org
 Betreff: Re: AW: AW: Artifact with different sets of dependencies switched
 by profiles

 Hi Christoper,

 Christofer Dutz wrote:

  Hi Ron,
 
  I think you got what I'm trying to do a little wrong. It's not two
  different set of dependencies, it's two different ways of linking the
 same
  set of libraries. If I were to translate this into java, imagine that the
  default way an application was built would be to include all Classes
  needed by the application to be bundled in the application Jar (The
  classes not needed aren't included). Now in modular applications I am
 able
  to switch to something exactly the same as in Java ... no code is
 included
  in the Application jar, but the referenced libraries are deployed in
  parallel to the application jar, so the JVM can pull them in as needed
 (In
  Flex this type is called rsl (runtime shared library).
 
  So in principal I have the same set of dependencies, but in the
  rsl-linking type these dependencies have an additional scope=rsl
  setting. Up until now there was only one pom with the default set of
  dependencies. If the users wanted to utilize rsl linking they would have
  to manually add each dependency and set that's scope to rsl. I would like
  to make it easier for users to switch.
 
  So the profiles is bad, the pom with classifier doesn't work ... I would
  really like to avoid to have something like an flramework artifact and
  one framework-rsl for the rsl linking.

 What's the default value for the scope? compile? Then you can do all you
 need with properties. You might use a profile, but it is not necessary:

 Declare your dependencies just like before (either in depMgmt or directly):

 == % =
  dependency
groupIdorg.apache.flex.framework/groupId
artifactIdspark/artifactId
version4.12.1.20140427/version
typeswc/type
scope${flexmojo.scope}/scope
  /dependency
  ...
  properties
flexmojo.scopecompile/flexmojo.scope
  /properties
 == % =

 Then you can simply redefine flexmojo.scope from command line. This will
 also affect inherited dependencies, if they are declared in the same way in
 the repository or if you delcare them in a common parent with a
 dependencyManagement section. You might even overwrite the property in a
 profile:

 == % =
  profile
idrsl/id
properties
  flexmojo.scopersl/flexmojo.scope
/properties
  profile
 == % =

 Unfortunately, I don't know nothing about flexmojo. If it works like in the
 world of C where I can use the same libraries (.lib files) to link an
 application either static or dynamically (then requiring runtime libs as
 well), then it is possible to do this. Therefore is is fine for an project
 creating such an application at the end of a build chain.

 However, if the libraries differ if build with rsl or not, then you will
 create a very bad user experience, because - just as Stephen already said -
 the build process will use whatever it finds in the local repository, it
 cannot separate between artifacts built with rsl or without. Your users
 might get a wild mix during build time.

 Cheers,
 Jörg


 -
 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

AW: AW: Artifact with different sets of dependencies switched by profiles

[Christofer Dutz]

Hi Ron,

I think you got what I'm trying to do a little wrong. It's not two different 
set of dependencies, it's two different ways of linking the same set of 
libraries.
If I were to translate this into java, imagine that the default way an 
application was built would be to include all Classes needed by the application 
to be bundled in the application Jar (The classes not needed aren't included). 
Now in modular applications I am able to switch to something exactly the same 
as in Java ... no code is included in the Application jar, but the referenced 
libraries are deployed in parallel to the application jar, so the JVM can pull 
them in as needed (In Flex this type is called rsl (runtime shared library).

So in principal I have the same set of dependencies, but in the rsl-linking 
type these dependencies have an additional scope=rsl setting. Up until now 
there was only one pom with the default set of dependencies. If the users 
wanted to utilize rsl linking they would have to manually add each dependency 
and set that's scope to rsl. I would like to make it easier for users to 
switch. 

So the profiles is bad, the pom with classifier doesn't work ... I would really 
like to avoid to have something like an flramework artifact and one 
framework-rsl for the rsl linking.

Chris


-Ursprüngliche Nachricht-
Von: Ron Wheeler [mailto:rwhee...@artifact-software.com] 
Gesendet: Sonntag, 29. Juni 2014 03:47
An: users@maven.apache.org
Betreff: Re: AW: Artifact with different sets of dependencies switched by 
profiles

The solution that you suggested at the end of your message is the best.
Separate all the common code into a core project and have 2 projects that 
depend on it for producing the final artifacts for particular envoronments.

This may also help in  organizing your tests so that you clearly separate tests 
for the core software from tests that depend on one environment or the other.

It will certainly simplify your project for other developers who might not be 
familiar with both environments and have trouble sorting through files that do 
not apply to the environment that they know.

Ron

On 28/06/2014 6:26 PM, Christofer Dutz wrote:
 No worries :-)

 I was going through the options and I noticed this myself :-)

 But is there another option?
 I tried the pom dependency with classifier option, but that didn't 
 work (I wasn't really expecting it to)

 Chris

 -Ursprüngliche Nachricht-
 Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Gesendet: Samstag, 28. Juni 2014 22:40
 An: Maven Users List
 Betreff: Re: Artifact with different sets of dependencies switched by 
 profiles

 N!!!

 Allowing people to define dependencies in profiles was one of the biggest 
 mistakes we made in Model Version 4.0.0.

 The activation rules etc are *never* what they think you are once the 
 dependency is resolved from the local repository cache.

 Please do no do this stupid thing just because we were stupid enough to leave 
 it as an option.


 On 28 June 2014 19:24, Christofer Dutz christofer.d...@c-ware.de wrote:

 Hi,

 I am currently working on making the Apache Flex project able to 
 release as Maven artifacts. For that I have created a tool that 
 mavenizes a Flex SDK by generating poms and copying and renaming the 
 libraries it consists of. All is working nicely. In contrast to Java 
 in Flex you can sort of choose to use static linking (default) or 
 dynamic linking (rsl). In Flexmojos this is controlled by having a 
 maven scope of rsl for dynamically linked libraries.

 Static linking:
  dependency
  groupIdorg.apache.flex.framework/groupId
  artifactIdspark/artifactId
  version4.12.1.20140427/version
  typeswc/type
  /dependency

 Dynamic linking:
  dependency
  groupIdorg.apache.flex.framework/groupId
  artifactIdspark/artifactId
  version4.12.1.20140427/version
  typeswc/type
  scopersl/scope
  /dependency

 Now I wanted to make it easier for people using Flex so I generated 
 two profiles in my poms. The default one active by default using 
 static linking and one flex-rsl using dynamic linking wherever possible.
 I was thinking of enabling that second profile by setting a property:

 ?xml version=1.0 encoding=UTF-8 standalone=no? project 
 xmlns=http://maven.apache.org/POM/4.0.0;
  modelVersion4.0.0/modelVersion

  groupIdorg.apache.flex/groupId
  artifactIdframework/artifactId
  version4.12.1.20140427/version
  packagingpom/packaging

  profiles
  profile
  iddefault/id

  activation
  activeByDefaulttrue/activeByDefault
  /activation

  dependencies

  ... A lot of dependencies ...

  /dependencies

Artifact with different sets of dependencies switched by profiles

[Christofer Dutz]

Hi,

I am currently working on making the Apache Flex project able to release as 
Maven artifacts. For that I have created a tool that mavenizes a Flex SDK by 
generating poms and copying and renaming the libraries it consists of. All is 
working nicely. In contrast to Java in Flex you can sort of choose to use 
static linking (default) or dynamic linking (rsl). In Flexmojos this is 
controlled by having a maven scope of rsl for dynamically linked libraries.

Static linking:
dependency
groupIdorg.apache.flex.framework/groupId
artifactIdspark/artifactId
version4.12.1.20140427/version
typeswc/type
/dependency

Dynamic linking:
dependency
groupIdorg.apache.flex.framework/groupId
artifactIdspark/artifactId
version4.12.1.20140427/version
typeswc/type
scopersl/scope
/dependency

Now I wanted to make it easier for people using Flex so I generated two 
profiles in my poms. The default one active by default using static linking and 
one flex-rsl using dynamic linking wherever possible.
I was thinking of enabling that second profile by setting a property:

?xml version=1.0 encoding=UTF-8 standalone=no?
project xmlns=http://maven.apache.org/POM/4.0.0;
modelVersion4.0.0/modelVersion

groupIdorg.apache.flex/groupId
artifactIdframework/artifactId
version4.12.1.20140427/version
packagingpom/packaging

profiles
profile
iddefault/id

activation
activeByDefaulttrue/activeByDefault
/activation

dependencies

... A lot of dependencies ...

/dependencies
/profile

profile
idflex-rsl/id

activation
property
nameflex.framework.scope/name
valuersl/value
/property
/activation

dependencies

... A lot of dependencies ...

/dependencies
/profile
/profiles
/project

Now I tried activating that second profile by setting that property in the 
module referencing that pom artifact:

properties
flex.version4.12.1.20140427/flex.version
!-- Turn on rsl linking of swc dependencies --
flex.framework.scopersl/flex.framework.scope
/properties

dependencies
dependency
groupIdorg.apache.flex/groupId
artifactIdframework/artifactId
version${flex.version}/version
typepom/type
/dependency
/dependencies

But it seems this doesn't work ... so my question is ... is it possible to do 
what I want? If not ... is there a way I could achieve this? After all it seems 
classifiers for pom modules don't seem to exist.
Or am I wrong here and I could simply generate several pom files 
framework-4.12.1.20140427.pom and framework-4.12.1.20140427-rsl.pom?

Chris

AW: Artifact with different sets of dependencies switched by profiles

[Christofer Dutz]

No worries :-) 

I was going through the options and I noticed this myself :-)

But is there another option? 
I tried the pom dependency with classifier option, but that didn't work (I 
wasn't really expecting it to)

Chris

-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Gesendet: Samstag, 28. Juni 2014 22:40
An: Maven Users List
Betreff: Re: Artifact with different sets of dependencies switched by profiles

N!!!

Allowing people to define dependencies in profiles was one of the biggest 
mistakes we made in Model Version 4.0.0.

The activation rules etc are *never* what they think you are once the 
dependency is resolved from the local repository cache.

Please do no do this stupid thing just because we were stupid enough to leave 
it as an option.


On 28 June 2014 19:24, Christofer Dutz christofer.d...@c-ware.de wrote:

 Hi,

 I am currently working on making the Apache Flex project able to 
 release as Maven artifacts. For that I have created a tool that 
 mavenizes a Flex SDK by generating poms and copying and renaming the 
 libraries it consists of. All is working nicely. In contrast to Java 
 in Flex you can sort of choose to use static linking (default) or 
 dynamic linking (rsl). In Flexmojos this is controlled by having a 
 maven scope of rsl for dynamically linked libraries.

 Static linking:
 dependency
 groupIdorg.apache.flex.framework/groupId
 artifactIdspark/artifactId
 version4.12.1.20140427/version
 typeswc/type
 /dependency

 Dynamic linking:
 dependency
 groupIdorg.apache.flex.framework/groupId
 artifactIdspark/artifactId
 version4.12.1.20140427/version
 typeswc/type
 scopersl/scope
 /dependency

 Now I wanted to make it easier for people using Flex so I generated 
 two profiles in my poms. The default one active by default using 
 static linking and one flex-rsl using dynamic linking wherever possible.
 I was thinking of enabling that second profile by setting a property:

 ?xml version=1.0 encoding=UTF-8 standalone=no? project 
 xmlns=http://maven.apache.org/POM/4.0.0;
 modelVersion4.0.0/modelVersion

 groupIdorg.apache.flex/groupId
 artifactIdframework/artifactId
 version4.12.1.20140427/version
 packagingpom/packaging

 profiles
 profile
 iddefault/id

 activation
 activeByDefaulttrue/activeByDefault
 /activation

 dependencies

 ... A lot of dependencies ...

 /dependencies
 /profile

 profile
 idflex-rsl/id

 activation
 property
 nameflex.framework.scope/name
 valuersl/value
 /property
 /activation

 dependencies

 ... A lot of dependencies ...

 /dependencies
 /profile
 /profiles
 /project

 Now I tried activating that second profile by setting that property in 
 the module referencing that pom artifact:

 properties
 flex.version4.12.1.20140427/flex.version
 !-- Turn on rsl linking of swc dependencies --
 flex.framework.scopersl/flex.framework.scope
 /properties

 dependencies
 dependency
 groupIdorg.apache.flex/groupId
 artifactIdframework/artifactId
 version${flex.version}/version
 typepom/type
 /dependency
 /dependencies

 But it seems this doesn't work ... so my question is ... is it 
 possible to do what I want? If not ... is there a way I could achieve 
 this? After all it seems classifiers for pom modules don't seem to exist.
 Or am I wrong here and I could simply generate several pom files 
 framework-4.12.1.20140427.pom and framework-4.12.1.20140427-rsl.pom?

 Chris

ApacheCon 2014 = FlexCon 2014 ;-)

[Christofer Dutz]

Hi Guys,



I just wanted to remind you that this year we are planing on doing some Major 
Flexing on the anual ApacheCon 2014 in Denver.

There will be 3 Talks on Flex and even one day of Tutorials:



Talks:

- Tue 8th of April 16:45 : Building Enterprise Level Applications with Apache 
Flex and Java (Me)

- Wed 9th of April 10:00 : What's Happening in the Apache Flex Project (Alex)

- Wed 9th of April 11:15 : FlexJS: Flex for JavaScript (Alex)



Tutorials:

- Thu 10th of April: 13:30 : Apache Flex Mobile Developer Lab - Learning How 
to Buils iOS and Android Apps (Jun)



Hackathon Proposals:

- Coding, Bug Fixing, Fins out about it! (Unknown)

- Tuesday Morning: Making Flexmojos Support Falcon and FlexJS (?Alex and Me)

- Firday: Adding Features for mobile packaging to Flexmojos (Jun and Me)

So we are planning on doing som serious flexing and eventually we will even 
manage to implement some really cool stuff Features in order to be able to 
build FlexJS applications in Maven handling IDEs.



It seems there is still time to get tickets to the normal rate, but the rate 
will probably go up shortly before the conference. So if you are thinking about 
comming, be sure to Register as soon as possible.



http://www.apachecon.comhttp://www.apachecon.com/



Looking Forward to seeing some of you guys :-)



Chris

AW: ApacheCon 2014 = FlexCon 2014 ;-)

[Christofer Dutz]

Sorry for this ... wrong user-list :-( 

... but hey ... It's Maven releated (Flexmojos) and Apache too so don't be mad 
at me ;-)


Von: Christofer Dutz christofer.d...@c-ware.de
Gesendet: Mittwoch, 12. März 2014 16:59
An: Maven Users List
Betreff: ApacheCon 2014 = FlexCon 2014 ;-)

Hi Guys,



I just wanted to remind you that this year we are planing on doing some Major 
Flexing on the anual ApacheCon 2014 in Denver.

There will be 3 Talks on Flex and even one day of Tutorials:



Talks:

- Tue 8th of April 16:45 : Building Enterprise Level Applications with Apache 
Flex and Java (Me)

- Wed 9th of April 10:00 : What's Happening in the Apache Flex Project (Alex)

- Wed 9th of April 11:15 : FlexJS: Flex for JavaScript (Alex)



Tutorials:

- Thu 10th of April: 13:30 : Apache Flex Mobile Developer Lab - Learning How 
to Buils iOS and Android Apps (Jun)



Hackathon Proposals:

- Coding, Bug Fixing, Fins out about it! (Unknown)

- Tuesday Morning: Making Flexmojos Support Falcon and FlexJS (?Alex and Me)

- Firday: Adding Features for mobile packaging to Flexmojos (Jun and Me)

So we are planning on doing som serious flexing and eventually we will even 
manage to implement some really cool stuff Features in order to be able to 
build FlexJS applications in Maven handling IDEs.



It seems there is still time to get tickets to the normal rate, but the rate 
will probably go up shortly before the conference. So if you are thinking about 
comming, be sure to Register as soon as possible.



http://www.apachecon.comhttp://www.apachecon.com/



Looking Forward to seeing some of you guys :-)



Chris

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Need advice automating a Java test suite.

[Christofer Dutz]

Hi Todd,

we use a combination of the cargo, antrun and surefire plugin for this. 

I dumped the pom for one of our Projects in my Confluence, so feel free to have 
a look:
https://dev.c-ware.de/confluence/display/PUBLIC/Maven+setup+for+Integrationtesting

In general we use:
- Cargo to install/configure/deploy/start/stop the application.
- Antrun is used to Setup the Database with Default values.
- Surefire is configured to run tests ending with IT after starting the 
Container and before stopping it again.

Perhaps this helps.

Chris


Von: Todd Chapman t...@chaka.net
Gesendet: Mittwoch, 8. Januar 2014 23:08
An: users@maven.apache.org
Betreff: Need advice automating a Java test suite.

Hello,

We have a java multi-module project that has a somewhat painful to run test
suite that I would like to get under control using Maven.

Currently it takes 5 separate Maven commands to setup, run, and teardown
all the tests and test databases. I'd like to get this down to one command.
Also I would like this structured so that individual parts of the process
can be run separately to aid in debugging problems.

The pom has 1 profile for each part of the task, all bound to the test
goal:

mvn clean test -P test-setup-1,local-enterprise-test-db  (exec:java plugin
to setup up a database)
mvn test -P test-setup-2,local-enterprise-test-db   (exec:java
plugin to setup up a 2nd database)
mvn test -P test-design,local-enterprise-test-db(surefire
plugin to run a subset of the tests with maven properties set)
mvn test -P test-transactional,local-enterprise-test-db   (surefire plugin
to run a different subset of the tests with different maven properties set)
mvn test -P test-tear-down,local-enterprise-test-db(exec:java
plugin to teardown the databases)


The problem I am running into is how to get this organized so that it all
happens with 1 command. It seems nearly unpossible.

Can anyone offer any advice on how to accomplish this? Pointer to relevant
articles, blog posts, stackoverflow questions would be most appreciated.

Thanks!

-Todd

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Fine versioning on multi-modules project ?...

[Christofer Dutz]

Hi Benoît,

Hope I'm not going to be flammed for freshing up that old discussion we had a 
little more than a year ago :-)

I had a customer that had a similar requirement (And no ... there was no way to 
work around the requirement to release modules with separate versions). I 
actually did implement a maven-based release system, that allowed fine-grained 
maven releases just the way you described it. The major problem was that with 
this the commandline command for triggering the build was so insanely long, 
that I created a Jenkins plugin to assist.

Here I wrote down what the concept behind everything was:
https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers
Here I summed up how to build the Jenkins Plugin for performing the release:
https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin
Here I published the code for that plugin:
https://github.com/chrisdutz/jenkins-release-plugin

Hope this helps :-)

Chris


-Ursprüngliche Nachricht-
Von: Russell Gold [mailto:r...@gold-family.us] 
Gesendet: Sonntag, 22. Dezember 2013 01:13
An: Maven Users List
Betreff: Re: Fine versioning on multi-modules project ?...

HI Benoit,

Given you scenario, it really sounds as though your project is essentially a 
single project, and your modules should just inherit the version from the 
parent. Maven tools, especially the release plugin, make this easy.

If not, I would regard what you are creating is a set of interrelated projects 
rather than a single multi-module project, and I would suggest dispensing with 
keeping the versions in the parent. Instead, as long as the apis for module A 
are unchanged, leave B and C dependent on the previous version. They should be 
able to function with the old API, and you simply install the latest version of 
A. If you add an API to A that B needs, you simply update B to recognize the 
new version, while C remains unaware. The only time you would need to update a 
dependency version would be if you actually have to change or remove an API, or 
rely on changed functionality.

But the multi-module project with a single shared version is the simplest 
approach, IMHO.

Regards,
Russ

On Dec 20, 2013, at 3:06 PM, Benoît Berthonneau ben...@berthonneau.com wrote:

 Hi all,
 
 
 
 I need your point of view/opinion/help on the way to version modules 
 on multi-modules Maven project. My question: is it really possible ?
 
 
 
 I've the following (simplified) Maven project:
 
  Parent (version 1.0)
 
  |__ module A (version 1.0)
 
  |__ module B (version 1.0, that depends on module A)
 
  |__ module C (version 1.0, that depends on module B and A)
 
  |__ module packaging (which create an archive with all needed 
 libraries/modules to start my application)
 
 
 
 All modules have their own version number (that's the key of my 
 question)
 
 Since all modules are executed in the same JVM, I need to be sure that 
 modules B  C are using the same version of module A. For this reason, 
 the version is specified in the dependencyManagement section of the parent.
 
 
 
 Now, I've updated module A (a minor modification, with no impact on 
 interfaces, or API), so I need to update the version to 1.1
 
 This new version have to be also specified on the parent. This update 
 force me to update the parent to 1.1
 
 This new parent version needs to be taken into account on all other 
 modules (B, C, packaging)
 
 So, I need to update B, C, packaging version to something like 1.0.1
 
 
 
 At the end, all modules version have been changed ?!...
 
 
 
 How could I avoid this ? (I think that I have already the answer.)
 
 
 
 Thanks !
 
 Benoît.
 

-
Author, Getting Started with Apache Maven 
http://www.packtpub.com/getting-started-with-apache-maven/video

Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to 
the Misfile radio play http://www.fuzzyfacetheater.com/misfile/!








-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: AW: Painless way to update a frameworks group id?

[Christofer Dutz]

Ah ... I think I know where you are going.

So my Mavenizer would generate the correct artifacts and additionally would 
generate relocation poms for the old group id ... I think I'll have to look at 
that option.

Thanks for that.

Chris

-Ursprüngliche Nachricht-
Von: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com] 
Gesendet: Samstag, 14. Dezember 2013 07:40
An: Maven Users List
Betreff: Re: AW: Painless way to update a frameworks group id?

Christofer,

this depends on your definition of we :-). In a company context with an 
internal repository manager you might deploy a vendor release into your 
patched thirdparty repository. Or tell your users to manually install the 
patched version. I did similar stuff for this strange 
m2e-maven-plugin-configuration-holder ( 
http://stackoverflow.com/questions/7905501/get-rid-of-pom-not-found-warning-for-org-eclipse-m2elifecycle-mapping
)

Regards Mirko
--
Sent from my mobile
On Dec 13, 2013 10:13 PM, Christofer Dutz christofer.d...@c-ware.de
wrote:

 Good Idea ...

 Unfortunately as we are not allowed to publish the Adobe artifacts 
 (Flash Player / Air libs) we decided not to publish the Flex artifacts at all.
 Then a redirect seems rather problematic. Currently each user has to 
 locally deploy the Flex SDK using a special tool in order to be on the 
 safe side :-(

 Chris

 -Ursprüngliche Nachricht-
 Von: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com]
 Gesendet: Freitag, 13. Dezember 2013 21:26
 An: Maven Users List
 Betreff: Re: Painless way to update a frameworks group id?

 Just a guess:

 * Deploy a new relocation pom at the old coordinates with a bigger version.
 * Include this new relocation version.

 Regards Mirko
 --
 Sent from my mobile
 On Dec 12, 2013 1:26 PM, Anders Hammar and...@hammar.net wrote:

   Think some sort of artifact-transformer mechanism in Maven would 
   be
   really cool (Map the following groupId to otherGroupId).
  
  
   There is some discussion around this feature for a future POM model.
   Any year now. :-)
  
 
  Oh, I should prabably stress that this discussion is no promise 
  for this feature. It might require a change to the Maven repository
 structure.
 
  /Anders
 
 
  
   /Anders
  
  
  
   But I guess something like that would fit into the same drawer as 
   the which to hace a configuration-check mechanism that allows a 
   plugin to validate the configuration used (Would really like to 
   implement some validator and best-practice validator component 
   guiding users on how
  to
   use the plugin)
  
   Chris
  
  
   
   Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im 
   Auftrag von Anders Hammar and...@hammar.net
   Gesendet: Donnerstag, 12. Dezember 2013 11:37
   An: Maven Users List
   Betreff: Re: Painless way to update a frameworks group id?
  
   I don't think that will work. The bad deps are still used in 
   compile time and only not used in runtime.
  
   The correct solution (until there are new releases that don't 
   pull in
  the
   bad transitive deps) is to excluded them. And that probably 
   can't be automated in any other way than providing means to 
   detect them (the enforcer rule).
  
   What you could do is try this and release a beta or something and 
   see
  what
   sort of problems people run into. Changing coordinates is always 
   a problem.
  
   My two cents,
   /Anders
  
  
   On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz  
   christofer.d...@c-ware.de
wrote:
  
What do you think about this Option?
   
I created a tool that mavenizes a non-maven Flex SDK and 
genereates
  all
sorts of maven artifacts ... one artifact that is generated is 
a
  Special
pom that contains only a dependency Management section that can 
be
  used
   to
automatically configure the Versions of dependencies in the 
Flex SDK
   ... I
could automatically generate dependency manangement entries for 
the
  old
Group id that set the dependencies to provided. So as soon as
  someone
imports that pom containing the dependencyManagement entries 
for the
   good
artifacts, the exclude entries are automatically in place.
   
Chris
   
   

Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im 
Auftrag
   von
Anders Hammar and...@hammar.net
Gesendet: Donnerstag, 12. Dezember 2013 11:07
An: Maven Users List
Betreff: Re: Painless way to update a frameworks group id?
   
AFAIK there is not painless way to solve this.
   
What you could add to the docs is instructions on how to use an
  enforcer
rule to ensure that no bad libs are pulled in by accident (if 
the
  miss
some exclusion). Use the banned deps [1] rule.
   
/Anders
   
[1]
   
  http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.h
  tm
  l
   
   
On Wed, Dec 11, 2013 at 9:01 AM, Christofer

AW: Multi-modules projects

[Christofer Dutz]

I have similar Projects consisting of Java, Flex and .Net artifacts.
I usually configure the plugins in the root of the maven Project and use 
self-activating maven profiles.

Flex is active if a Directory src/main/flex exists, Npanday is used if i have 
src/main/csharp and so on.

profile
idjava-project/id
activation
file
existssrc/main/java/exists
/file
/activation
...
/profile
profile
idflex-project/id
activation
file
existssrc/main/flex/exists
/file
/activation
...
/profile
profile
idcsharp-project/id
activation
file
existssrc/main/csharp/exists
/file
/activation
...
/profile

Hope this helps.

Chris



Von: Michael Priess digitalover...@googlemail.com
Gesendet: Freitag, 13. Dezember 2013 13:24
An: users@maven.apache.org
Betreff: Multi-modules projects

Hi,

our projects have the following structure:

- parent pom
-- pom.xml
cpp--pom.xml
java--pom.xml

To build a project like this we must invoke different build steps. For the
CPP build we like to invoke gcc for the java build we like to invoke javac
and many other steps. In our enviroment we have a lot of builds which are
similar.

Is there a way to define the builds steps in one place to avoid
duplications of the javac and gcc build configuration. I like to inherite
or get the build steps from one central place and use this steps in a multi
module project. Any idea howto resolve this?

Cheerrs,

Michael

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Painless way to update a frameworks group id?

[Christofer Dutz]

Good Idea ...

Unfortunately as we are not allowed to publish the Adobe artifacts (Flash 
Player / Air libs) we decided not to publish the Flex artifacts at all. Then a 
redirect seems rather problematic. Currently each user has to locally deploy 
the Flex SDK using a special tool in order to be on the safe side :-(

Chris

-Ursprüngliche Nachricht-
Von: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com] 
Gesendet: Freitag, 13. Dezember 2013 21:26
An: Maven Users List
Betreff: Re: Painless way to update a frameworks group id?

Just a guess:

* Deploy a new relocation pom at the old coordinates with a bigger version.
* Include this new relocation version.

Regards Mirko
--
Sent from my mobile
On Dec 12, 2013 1:26 PM, Anders Hammar and...@hammar.net wrote:

  Think some sort of artifact-transformer mechanism in Maven would 
  be
  really cool (Map the following groupId to otherGroupId).
 
 
  There is some discussion around this feature for a future POM model. 
  Any year now. :-)
 

 Oh, I should prabably stress that this discussion is no promise for 
 this feature. It might require a change to the Maven repository structure.

 /Anders


 
  /Anders
 
 
 
  But I guess something like that would fit into the same drawer as 
  the which to hace a configuration-check mechanism that allows a 
  plugin to validate the configuration used (Would really like to 
  implement some validator and best-practice validator component 
  guiding users on how
 to
  use the plugin)
 
  Chris
 
 
  
  Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im 
  Auftrag von Anders Hammar and...@hammar.net
  Gesendet: Donnerstag, 12. Dezember 2013 11:37
  An: Maven Users List
  Betreff: Re: Painless way to update a frameworks group id?
 
  I don't think that will work. The bad deps are still used in 
  compile time and only not used in runtime.
 
  The correct solution (until there are new releases that don't pull 
  in
 the
  bad transitive deps) is to excluded them. And that probably can't 
  be automated in any other way than providing means to detect them 
  (the enforcer rule).
 
  What you could do is try this and release a beta or something and 
  see
 what
  sort of problems people run into. Changing coordinates is always a 
  problem.
 
  My two cents,
  /Anders
 
 
  On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz  
  christofer.d...@c-ware.de
   wrote:
 
   What do you think about this Option?
  
   I created a tool that mavenizes a non-maven Flex SDK and 
   genereates
 all
   sorts of maven artifacts ... one artifact that is generated is a
 Special
   pom that contains only a dependency Management section that can 
   be
 used
  to
   automatically configure the Versions of dependencies in the Flex 
   SDK
  ... I
   could automatically generate dependency manangement entries for 
   the
 old
   Group id that set the dependencies to provided. So as soon as
 someone
   imports that pom containing the dependencyManagement entries for 
   the
  good
   artifacts, the exclude entries are automatically in place.
  
   Chris
  
  
   
   Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im 
   Auftrag
  von
   Anders Hammar and...@hammar.net
   Gesendet: Donnerstag, 12. Dezember 2013 11:07
   An: Maven Users List
   Betreff: Re: Painless way to update a frameworks group id?
  
   AFAIK there is not painless way to solve this.
  
   What you could add to the docs is instructions on how to use an
 enforcer
   rule to ensure that no bad libs are pulled in by accident (if 
   the
 miss
   some exclusion). Use the banned deps [1] rule.
  
   /Anders
  
   [1]
  
 http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.htm
 l
  
  
   On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
   christofer.d...@c-ware.dewrote:
  
Hi,
   
   
   
I am the current maintainer of the Flexmojos Maven Plugin and
  contributor
to the Apache Flex Project.
   
Currently I am working on a new Version of Flexmojos which is 
able
 to
   work
with Flex SDKs that have a groupId of org.apache.flex instead 
of the
  old
com.adobe.flex. While building applications with the new 
groupId was
  no
   big
Problem, we are now facing a Problem, that I don't quite know 
how to elegantly solve it.
   
   
   
Assuming I am building a Project and I switched the groupId of 
the
  Flex
Framework to org.apache.flex. As Long as I am building all
  artifacts in
the Project this is fine. But as soon as I am using a Flex 
library
  that
   was
built for com.apache.flex Maven correctly adds that artifacts
   dependencies
to the build. Unfortunately this way I have several artifacts 
in my
  build
twice ... once with com.adobe.flex and once with 
org.apache.flex
  groupId.
   
   
   
Now I was suggesting to manually exclude Framework artifacts 
when
  using

AW: Painless way to update a frameworks group id?

[Christofer Dutz]

What do you think about this Option?

I created a tool that mavenizes a non-maven Flex SDK and genereates all sorts 
of maven artifacts ... one artifact that is generated is a Special pom that 
contains only a dependency Management section that can be used to automatically 
configure the Versions of dependencies in the Flex SDK ... I could 
automatically generate dependency manangement entries for the old Group id that 
set the dependencies to provided. So as soon as someone imports that pom 
containing the dependencyManagement entries for the good artifacts, the 
exclude entries are automatically in place.

Chris



Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von 
Anders Hammar and...@hammar.net
Gesendet: Donnerstag, 12. Dezember 2013 11:07
An: Maven Users List
Betreff: Re: Painless way to update a frameworks group id?

AFAIK there is not painless way to solve this.

What you could add to the docs is instructions on how to use an enforcer
rule to ensure that no bad libs are pulled in by accident (if the miss
some exclusion). Use the banned deps [1] rule.

/Anders

[1] http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html


On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
christofer.d...@c-ware.dewrote:

 Hi,



 I am the current maintainer of the Flexmojos Maven Plugin and contributor
 to the Apache Flex Project.

 Currently I am working on a new Version of Flexmojos which is able to work
 with Flex SDKs that have a groupId of org.apache.flex instead of the old
 com.adobe.flex. While building applications with the new groupId was no big
 Problem, we are now facing a Problem, that I don't quite know how to
 elegantly solve it.



 Assuming I am building a Project and I switched the groupId of the Flex
 Framework to org.apache.flex. As Long as I am building all artifacts in
 the Project this is fine. But as soon as I am using a Flex library that was
 built for com.apache.flex Maven correctly adds that artifacts dependencies
 to the build. Unfortunately this way I have several artifacts in my build
 twice ... once with com.adobe.flex and once with org.apache.flex groupId.



 Now I was suggesting to manually exclude Framework artifacts when using an
 external lib, but I would like to automate this. Therefore I suggested to
 add all the org.apache.flex artifacts as com.adobe.flex artifacts, but to
 set the scope on These to provided. But it still sort of doesn't feel
 right.



 Any suggestions? Would be really happy to sort this out and make it less
 painfull for my users.



 Chris


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Painless way to update a frameworks group id?

[Christofer Dutz]

Well I guess the enforcer Thing should be a good Option.

I was already telling the People to exclude and manually include the new 
artifacts. So I guess I'll still stick to that and extend my Suggestion to add 
an enforcer rule to notify users of such Problems. 

Also I knew that changing the groupId would not be completely painless, but I 
didn't want to force People to continue to call Flex artifacts com.adobe.flex 
as the guys at Apache are doing the good and hard work. It's more a Thing of 
ideals than technical neccessity :-)

Think some sort of artifact-transformer mechanism in Maven would be really 
cool (Map the following groupId to otherGroupId). But I guess something like 
that would fit into the same drawer as the which to hace a 
configuration-check mechanism that allows a plugin to validate the 
configuration used (Would really like to implement some validator and 
best-practice validator component guiding users on how to use the plugin)

Chris



Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von 
Anders Hammar and...@hammar.net
Gesendet: Donnerstag, 12. Dezember 2013 11:37
An: Maven Users List
Betreff: Re: Painless way to update a frameworks group id?

I don't think that will work. The bad deps are still used in compile time
and only not used in runtime.

The correct solution (until there are new releases that don't pull in the
bad transitive deps) is to excluded them. And that probably can't be
automated in any other way than providing means to detect them (the
enforcer rule).

What you could do is try this and release a beta or something and see what
sort of problems people run into. Changing coordinates is always a problem.

My two cents,
/Anders


On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz christofer.d...@c-ware.de
 wrote:

 What do you think about this Option?

 I created a tool that mavenizes a non-maven Flex SDK and genereates all
 sorts of maven artifacts ... one artifact that is generated is a Special
 pom that contains only a dependency Management section that can be used to
 automatically configure the Versions of dependencies in the Flex SDK ... I
 could automatically generate dependency manangement entries for the old
 Group id that set the dependencies to provided. So as soon as someone
 imports that pom containing the dependencyManagement entries for the good
 artifacts, the exclude entries are automatically in place.

 Chris


 
 Von: anders.g.ham...@gmail.com anders.g.ham...@gmail.com im Auftrag von
 Anders Hammar and...@hammar.net
 Gesendet: Donnerstag, 12. Dezember 2013 11:07
 An: Maven Users List
 Betreff: Re: Painless way to update a frameworks group id?

 AFAIK there is not painless way to solve this.

 What you could add to the docs is instructions on how to use an enforcer
 rule to ensure that no bad libs are pulled in by accident (if the miss
 some exclusion). Use the banned deps [1] rule.

 /Anders

 [1]
 http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html


 On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
 christofer.d...@c-ware.dewrote:

  Hi,
 
 
 
  I am the current maintainer of the Flexmojos Maven Plugin and contributor
  to the Apache Flex Project.
 
  Currently I am working on a new Version of Flexmojos which is able to
 work
  with Flex SDKs that have a groupId of org.apache.flex instead of the old
  com.adobe.flex. While building applications with the new groupId was no
 big
  Problem, we are now facing a Problem, that I don't quite know how to
  elegantly solve it.
 
 
 
  Assuming I am building a Project and I switched the groupId of the Flex
  Framework to org.apache.flex. As Long as I am building all artifacts in
  the Project this is fine. But as soon as I am using a Flex library that
 was
  built for com.apache.flex Maven correctly adds that artifacts
 dependencies
  to the build. Unfortunately this way I have several artifacts in my build
  twice ... once with com.adobe.flex and once with org.apache.flex groupId.
 
 
 
  Now I was suggesting to manually exclude Framework artifacts when using
 an
  external lib, but I would like to automate this. Therefore I suggested to
  add all the org.apache.flex artifacts as com.adobe.flex artifacts, but to
  set the scope on These to provided. But it still sort of doesn't feel
  right.
 
 
 
  Any suggestions? Would be really happy to sort this out and make it less
  painfull for my users.
 
 
 
  Chris
 

 -
 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

Painless way to update a frameworks group id?

[Christofer Dutz]

Hi,



I am the current maintainer of the Flexmojos Maven Plugin and contributor to 
the Apache Flex Project.

Currently I am working on a new Version of Flexmojos which is able to work with 
Flex SDKs that have a groupId of org.apache.flex instead of the old 
com.adobe.flex. While building applications with the new groupId was no big 
Problem, we are now facing a Problem, that I don't quite know how to elegantly 
solve it.



Assuming I am building a Project and I switched the groupId of the Flex 
Framework to org.apache.flex. As Long as I am building all artifacts in the 
Project this is fine. But as soon as I am using a Flex library that was built 
for com.apache.flex Maven correctly adds that artifacts dependencies to the 
build. Unfortunately this way I have several artifacts in my build twice ... 
once with com.adobe.flex and once with org.apache.flex groupId.



Now I was suggesting to manually exclude Framework artifacts when using an 
external lib, but I would like to automate this. Therefore I suggested to add 
all the org.apache.flex artifacts as com.adobe.flex artifacts, but to set the 
scope on These to provided. But it still sort of doesn't feel right.



Any suggestions? Would be really happy to sort this out and make it less 
painfull for my users.



Chris