Tests fails after switching to maven-surefire-plugin 3.0.0-M1
Hello, At Apache Wicket we hit issue described here https://stackoverflow.com/a/53016532/1676516 (tests fails when OpenJDK 8u181 is used) To fix it we have tried to update maven-surefire-plugin (2.20 -> 3.0.0-M1) Tests for one module (CDI-1.1) fails for both OpenJDK and OracleJDK I tried to fix these tests - no luck Then I have added false to surefire-plugin configuration and tests become green So I guess this should be maven-surefire-plugin issue The issue can be checked using Apache Wicket sources available here https://github.com/apache/wicket/tree/wicket-8.x (please NOTE `wicket-8.x` branch) Please let me know if any additional details are required -- WBR Maxim aka solomax
AW: AW: Strange Dependency problem after switching to Maven 3.1.1
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:
org.apache.flex.framework
B
4.13.0.20140701
swc
And then in my module I have this:
org.apache.flex.framework
B
4.13.0.20140701
swc-rsl
org.apache.flex.framework
A
4.13.0.20140701
pom
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.
MG>"runtime default scoping" is explained somewhat at
MG>http://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf
MG>clearing up the situation for each dependency to have different GAV
MG>will 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
MG>perhaps the owner of
MG>http://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
> 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
> 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
&
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. MG>"runtime default scoping" is explained somewhat at http://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf MG>clearing up the situation for each dependency to have different GAV will 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 MG>perhaps the owner of http://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf doc will allow documenting MG>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 > 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 > 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: Strange Dependency problem after switching to Maven 3.1.1
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 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 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: 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 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
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
Re: switching to maven?
That's what we did as well. -K On Aug 15, 2008, at 11:40 PM, Chad La Joie wrote: I had a series of projects that had different directory structures than what Maven uses by default. When we mad the conversion we changed our local copy around until it was what we wanted and then just did a commit. Wasn't much to it really. Rusty Wright wrote: I have an existing eclipse project, a "dynamic web application", which I've been working on. I'm also using subversion (subclipse). My problem is that my directory/folder structure is significantly different than the maven convention, and I would prefer to switch to the maven convention. I'm not sure how I should proceed. For example, could I simply reorganize my directory structure in subversion to match the maven convention and then import it into a new eclipse project that's been set up to play nicely with maven? I guess I'm looking for suggestions on the best way to proceed, for long term happiness, and not some hack method that I may regret later on. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- SWITCH Serving Swiss Universities -- Chad La Joie, Software Engineer, Net Services Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 [EMAIL PROTECTED], http://www.switch.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: switching to maven?
On Sat, Aug 16, 2008 at 9:41 AM, Rusty Wright <[EMAIL PROTECTED]> wrote: > Ok, thanks. What I've done so far is a "final" commit from my development > machine, and then I renamed the project in svn, moving it into branches, so > that it's no longer in trunk. (I realized just now that I should have > disconnected the project from svn before I moved it, but no matter since > that's just a simple job of removing all of the .svn directories on my > development machine.) I've started a new eclipse project using the eclipse > maven plugin and will move the pieces into it into their "correct" > locations, and then do a commit from the new project. You'll lose the history by doing it this way. (Well, it will still be there on the branch, but 'svn log' on the new trunk won't show it.) Do you need a branch? (Are you planning to do any additional work in the old project layout?) I would svn mv it back from the branch to trunk, tag it, and then do svn mv commands on trunk to rearrange it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: switching to maven?
Ok, thanks. What I've done so far is a "final" commit from my development machine, and then I renamed the project in svn, moving it into branches, so that it's no longer in trunk. (I realized just now that I should have disconnected the project from svn before I moved it, but no matter since that's just a simple job of removing all of the .svn directories on my development machine.) I've started a new eclipse project using the eclipse maven plugin and will move the pieces into it into their "correct" locations, and then do a commit from the new project. Chad La Joie wrote: I had a series of projects that had different directory structures than what Maven uses by default. When we mad the conversion we changed our local copy around until it was what we wanted and then just did a commit. Wasn't much to it really. Rusty Wright wrote: I have an existing eclipse project, a "dynamic web application", which I've been working on. I'm also using subversion (subclipse). My problem is that my directory/folder structure is significantly different than the maven convention, and I would prefer to switch to the maven convention. I'm not sure how I should proceed. For example, could I simply reorganize my directory structure in subversion to match the maven convention and then import it into a new eclipse project that's been set up to play nicely with maven? I guess I'm looking for suggestions on the best way to proceed, for long term happiness, and not some hack method that I may regret later on. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
switching to maven?
I have an existing eclipse project, a "dynamic web application", which I've been working on. I'm also using subversion (subclipse). My problem is that my directory/folder structure is significantly different than the maven convention, and I would prefer to switch to the maven convention. I'm not sure how I should proceed. For example, could I simply reorganize my directory structure in subversion to match the maven convention and then import it into a new eclipse project that's been set up to play nicely with maven? I guess I'm looking for suggestions on the best way to proceed, for long term happiness, and not some hack method that I may regret later on. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: switching to maven?
I had a series of projects that had different directory structures than what Maven uses by default. When we mad the conversion we changed our local copy around until it was what we wanted and then just did a commit. Wasn't much to it really. Rusty Wright wrote: I have an existing eclipse project, a "dynamic web application", which I've been working on. I'm also using subversion (subclipse). My problem is that my directory/folder structure is significantly different than the maven convention, and I would prefer to switch to the maven convention. I'm not sure how I should proceed. For example, could I simply reorganize my directory structure in subversion to match the maven convention and then import it into a new eclipse project that's been set up to play nicely with maven? I guess I'm looking for suggestions on the best way to proceed, for long term happiness, and not some hack method that I may regret later on. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- SWITCH Serving Swiss Universities -- Chad La Joie, Software Engineer, Net Services Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 [EMAIL PROTECTED], http://www.switch.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
switching to maven?
I have an existing eclipse project, a "dynamic web application", which I've been working on. I'm also using subversion (subclipse). My problem is that my directory/folder structure is significantly different than the maven convention, and I would prefer to switch to the maven convention. I'm not sure how I should proceed. For example, could I simply reorganize my directory structure in subversion to match the maven convention and then import it into a new eclipse project that's been set up to play nicely with maven? I guess I'm looking for suggestions on the best way to proceed, for long term happiness, and not some hack method that I may regret later on. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
