Hi Falko,
I regularly work with OpenJ9 and encountered such issues. Sometimes it
is a coding error which does not lead to an error in Hotspot,
sometimes it is a J9 problem (e.g. JIT problems, class loading, etc.).
If you want to dig in, there are a few things you can try:
The JVM option -verbose:
Hi everyone,
with AdoptOpenJDK 11.0.10, I'm getting three test failures/errors with
current masters of maven and maven-integration-testing, but only with
the OpenJ9 variant, not with HotSpot.
Is this a known problem?
[ERROR] Failures:
[ERROR]
MavenITmng5482AetherNotFoundTest>AbstractMavenIntegr
I just finished checking generated plugin.xml: apart from ordering of goals,
there are only updates of default values as expected, and sometimes addition
of empty description
so I'm completely confident now
and I found that maven-it-plugin-dependency-collection has annotations, but it
has a pl
+1 to Barrie's note.
On Mon, Feb 10, 2014 at 9:55 AM, Barrie Treloar wrote:
> On 10 February 2014 14:50, jieryn wrote:
> > Don't mess with existing tests. It's always wrong to do it. You're
> > lazy and stupid if you do it.
>
> Can you chill with the attitude.
> Its not helpful, or appreciat
On Feb 10, 2014, at 7:07 PM, Hervé BOUTEMY wrote:
> I understand the value of core ITs and fear about such changes
> I both think such a change has a value to keep existing ITs written a long
> time ago easier for newcomers to understand
>
> But yes, I see my update wasn't careful enough
>
I understand the value of core ITs and fear about such changes
I both think such a change has a value to keep existing ITs written a long
time ago easier for newcomers to understand
But yes, I see my update wasn't careful enough
In the next days, I'll check that generated plugin.xml is exactly
Use clojure as test parameter, pass it to the test project with
-Dclojure-version=... from the test. You'll need to use junit4 and
Verifier, but I don't like invoker-plugin, so it's not an issue for me :-)
--
Regards,
Igor
On 2/9/2014, 23:29, Mark Derricutt wrote:
Yep,
My use-case should proba
It's extremely unhelpful to change existing tests.
You're quite a naive person if you think this is acceptable in any way
to change an existing, passing, IT in this way.
You may not like my language, but quite frankly, you're a fool to
change an existing, passing test. It's really dumb.
But, alas
Yep,
My use-case should probably be moved to user@ tho, but in this instance,
my IT tests pom.xml has a dependency on a clojure version, and I want to
assert the same test runs against 1.3, 1.4, 1.5, 1.6 etc. As I add more
and more IT tests, I don't really want to make 6 duplicates of every
One of us must have misread the question :-)
I thought Mark asked if it was possible to run the same
clojure-maven-plugin IT with multiple versions of clojure compiler.
Assuming the point of the IT is to test clojure-maven-plugin, I don't
see anything wrong with this request and believe junit4 pa
On 10 February 2014 14:50, jieryn wrote:
> Don't mess with existing tests. It's always wrong to do it. You're
> lazy and stupid if you do it.
Can you chill with the attitude.
Its not helpful, or appreciated.
-
To unsubscribe, e-
This is totally different than changing the version of xx-maven-plugin
used by the ITs. I appreciate testing with a new version of JUnit, or
whatever. That is totally different than changing the version of a
maven plugin used by an IT.
Don't mess with existing tests. It's always wrong to do it. Yo
I successfully used junit4 parametrized tests with Invoker to run plugin
ITs against multiple versions of Maven. Didn't really need to do
anything special, everything just worked. The only minor inconvenience
was, IIRC, I had to use system properties to tell Invoker maven home.
Should be trivial t
Just create a new IT. I can not stress how EASY this is for the
developer, and how much WIN is for the end user. Just create a new IT.
You want a new version of xx-m-p? Just create a new IP. SVN COPY is so
cheap and easy to type, just do it. What is stopping you??? Seriously.
Just create a new IT f
Is it feasible to somehow change the IT test infrastructure to run
against multiple versions? So that the best of both worlds is available
( at the expense of longer build times ).
Thats one thing I'd love to have with the invoker plugin ( not sure if
these IT tests use that ) for things like
+9000
Please don't change existing ITs. Create new ITs with the new versions.
This is relatively easy for you to do, and it means a huge amount for
downstream users.
Please. Once an IT is created and is passing, LEAVE IT ALONE.
If you want to update versions used in an IT, create a new IT.
PLE
On Feb 9, 2014, at 2:45 PM, Hervé BOUTEMY wrote:
> I ran the ITs before comitting, it was ok
> I'm running them once again on my machine, to check if something is now
> failing
>
> ITs need maintenance like every piece of code, old "expression" field of
> plugin-tools is now part of past and
I can now reproduce the failure: strange that it worked once...
I'm working on fixing this IT
Regards,
Hervé
Le dimanche 9 février 2014 20:45:29 Hervé BOUTEMY a écrit :
> I ran the ITs before comitting, it was ok
> I'm running them once again on my machine, to check if something is now
> failin
I ran the ITs before comitting, it was ok
I'm running them once again on my machine, to check if something is now
failing
ITs need maintenance like every piece of code, old "expression" field of
plugin-tools is now part of past and is every day harder to understand
Regards,
Hervé
Le dimanche
Hervé,
The following IT fails after your changes:
Tests run: 732, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 450.697 sec
<<< FAILURE!
testit0064(org.apache.maven.it.MavenIT0064MojoConfigViaSettersTest) Time
elapsed: 0.547 sec <<< FAILURE!
junit.framework.AssertionFailedError: Expected
On Mar 30, 2013, at 10:00 AM, Hervé BOUTEMY wrote:
> yes, the ITs will be modified after the m-site-p release, ie just use
> m-site-p
> 3.3
>
Cool. Just wanted to make sure.
> I didn't have time for the moment to try m-dependency-p:tree and work on a
> fix,
> but that will be the same: the
yes, the ITs will be modified after the m-site-p release, ie just use m-site-p
3.3
I didn't have time for the moment to try m-dependency-p:tree and work on a fix,
but that will be the same: the IT will just need to use the next version,
which will be improved to use the new Maven core API
no p
Hervé,
I don't see any adjustment in the ITs for the site/dependency plugin. I'm going
to cut the release today if I can so are you fine with the release? If you're
fine I'm fine because I haven't tried the site or dependency plugin.
On Mar 27, 2013, at 3:10 AM, Hervé BOUTEMY wrote:
> I just
Cool.
On Mar 27, 2013, at 3:10 AM, Hervé BOUTEMY wrote:
> I just fixed
> http://jira.codehaus.org/browse/MSITE-683 /
> http://jira.codehaus.org/browse/MSHARED-280
>
> Any tests from others are welcome
>
> Regards,
>
> Hervé
>
> Le mardi 19 mars 2013 01:49:08 Hervé BOUTEMY a écrit :
>> I j
I just fixed
http://jira.codehaus.org/browse/MSITE-683 /
http://jira.codehaus.org/browse/MSHARED-280
Any tests from others are welcome
Regards,
Hervé
Le mardi 19 mars 2013 01:49:08 Hervé BOUTEMY a écrit :
> I just had a look at the failures: they are caused by
> DefaultMavenReportExecutor usi
fixed, thanks for the report
Regards,
Hervé
Le mardi 19 mars 2013 00:59:03 Stuart McCulloch a écrit :
> BTW, the following files appear to contain merge conflicts:
>
> maven-embedder/src/site/apt/logging.apt
> maven-plugin-api/src/site/apt/index.apt
>
> On 19 Mar 2013, at 00:53, Ja
BTW, the following files appear to contain merge conflicts:
maven-embedder/src/site/apt/logging.apt
maven-plugin-api/src/site/apt/index.apt
On 19 Mar 2013, at 00:53, Jason van Zyl wrote:
> On Mar 18, 2013, at 5:49 PM, Hervé BOUTEMY wrote:
>
>> I just had a look at the failures:
On Mar 18, 2013, at 5:49 PM, Hervé BOUTEMY wrote:
> I just had a look at the failures: they are caused by
> DefaultMavenReportExecutor using Sonatype Aether ExclusionsDependencyFilter
> [1] for MavenPluginManager.setupPluginRealm(...) API call [2] which is
> affected
> by switching to Eclips
I just had a look at the failures: they are caused by
DefaultMavenReportExecutor using Sonatype Aether ExclusionsDependencyFilter
[1] for MavenPluginManager.setupPluginRealm(...) API call [2] which is affected
by switching to Eclipse Aether
We will need some tweaks in maven-reporting-exec to d
In the ITs I have changed the ranges to accommodate these ITs not running with
Eclipse Aether:
MavenITmng3743ForkWithPluginManagementTest: Site plugin
MavenITmng3703ExecutionProjectWithRelativePathsTest: Site plugin
MavenITmng3684BuildPluginParameterTest: Site plugin
MavenITmng3372DirectInvocatio
Hervé, Olivier,
There are two failures due to the SLF4J Simple changes made which only affect
the embedded mode but it's really nice having those clean because they are so
much faster. Hervé, maybe these worked for you locally and you still have some
more work to do? This I can take a looked in
On Dec 10, 2011, at 9:47 AM, Benson Margulies wrote:
> On Sat, Dec 10, 2011 at 9:03 AM, Jason van Zyl wrote:
>>
>> On Dec 10, 2011, at 8:24 AM, Benson Margulies wrote:
>>
>>> However, in 3043, the consumer leaves out the classifier from the
>>> dependency specification. Is anyone willing to ex
On Sat, Dec 10, 2011 at 9:03 AM, Jason van Zyl wrote:
>
> On Dec 10, 2011, at 8:24 AM, Benson Margulies wrote:
>
>> However, in 3043, the consumer leaves out the classifier from the
>> dependency specification. Is anyone willing to explain why that bit of
>> relaxation was considered a good idea?
On Dec 10, 2011, at 8:24 AM, Benson Margulies wrote:
> However, in 3043, the consumer leaves out the classifier from the
> dependency specification. Is anyone willing to explain why that bit of
> relaxation was considered a good idea? My inclination would be to
> change the test to specify the cl
5214 notes that Maven will incorrectly resolve type=wsdl to
target/classes of a project of type jar.
Fixing that broke 3 integration tests.
Reading the JIRAs for those tests (3043, 4065, 2871), the upshot is
that decisions were made to relax the matching rules for cases where
the bug authors and
I'm working on it. Next time i'll run them locally before I commit.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Milos Kleint wrote:
is there something I set up on the grid to have myself notified of failures?
IIRC, you can just sign up for an account on Hudson and then configure
your mail address.
Besides, I just updated the job to send mails to
notificati...@maven.apache.org
as well.
Benjamin
-
this should fix it, passed for me locally..
http://fisheye.codehaus.org/changelog/plexus/?cs=8655
I suppose the grid gets back to normal once new plexus-compiler snapshot
gets uploaded. does the compiler-plugin hudson job need manual poking?
milos
On Thu, Feb 25, 2010 at 9:29 PM, Milos Kleint wr
is there something I set up on the grid to have myself notified of failures?
"Failed to send e-mail to mkleint because no e-mail address is known, and no
default e-mail domain is configured Sending e-mails to: ol...@apache.org
pg...@apache.org bentm...@apache.org Finished: FAILURE "
thanks
Milos
yes, looking into it..
Milos
On Thu, Feb 25, 2010 at 12:00 PM, Benjamin Bentmann <
benjamin.bentm...@udo.edu> wrote:
> Hi Milos,
>
> it seems r911840 broke the Maven Compiler Plugin on JRE 1.5- [0], can you
> please have a closer look? Thanks.
>
>
> Benjamin
>
>
> [0] https://grid.sonatype.org/c
Hi Milos,
it seems r911840 broke the Maven Compiler Plugin on JRE 1.5- [0], can
you please have a closer look? Thanks.
Benjamin
[0] https://grid.sonatype.org/ci/job/maven-plugins-ITs/changes
-
To unsubscribe, e-mail: dev-u
41 matches
Mail list logo
