You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Karl Heinz Marbaise <kh...@gmx.de> on 2017/12/26 19:01:02 UTC
maven-archiver build on Jenkins - Test Failures
Hi,
currently I'm observing a strange thing..cause the build on Jenkins
produces test failure with JDK 9
https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/5/consoleFull
The problem I'm currently having is that I can't reproduce this..
I have tested with Maven 3.5.2 and JDK 9.0.1 without any problem on my
Mac ...
Is someone out there who can check the current state of maven-archiver
git repo on Windows and can reproduce the issue ?
It would be great..Thanks in advance.
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
I have found a line of code which I might misunderstand...
https://gitbox.apache.org/repos/asf?p=maven-archiver.git;a=blob;f=src/main/java/org/apache/maven/archiver/MavenArchiver.java;h=66d93536d8c77fef66194841362cfca18a460e0c;hb=HEAD#l124
if ( hasManifestEntries )
{
for ( Map.Entry<String, String> entry : entries.entrySet() )
{
String key = entry.getKey();
String value = entry.getValue();
Manifest.Attribute attr =
manifest.getMainSection().getAttribute( key );
if ( key.equals( "ClassPath" ) && attr != null )
{
// Merge the user-supplied Class-Path value with
the programmatically
// created Class-Path. Note that the user-supplied
value goes first
// so that resources there will override any in the
standard Class-Path.
attr.setValue( value + " " + attr.getValue() );
}
else
{
addManifestAttribute( manifest, key, value );
}
}
}
The line "key.equals( "ClassPath" )" which from my point of view should
contain "Class-Path" instead of "ClassPath" ?
WDYT ?
Kind regards
Karl Heinz Marbaise
On 28/12/17 00:48, Sylwester Lachiewicz wrote:
> Ok, after more tests i found that error exists when project was executed in
> path with @ char that was encoded to %402 -
> https://issues.apache.org/jira/browse/SUREFIRE-1312
>
> Sylwester
>
> śr., 27 gru 2017 o 13:31 użytkownik Karl Heinz Marbaise <kh...@gmx.de>
> napisał:
>
>> Hi,
>>
>> On 27/12/17 13:01, Sylwester Lachiewicz wrote:
>>> Build fails with long directory name - also on windows.
>>> Upgrade maven-surefire-plugin to 2.20.1 fixes test error.
>>
>> Hm..this is a little bit confusing, cause the length for windows are
>> about 141 characters (already thought about something similar) but the
>> upgrade changes the situation completely ...Thanks for that hint..
>>
>>
>> Just one test cases is failing...
>>
>> Kidn regards
>> Karl Heinz Marbaise
>>
>>>
>>>
>>> śr., 27 gru 2017 o 08:49 użytkownik Plamen Totev <
>> plamen.iv.totev@gmail.com>
>>> napisał:
>>>
>>>> And if this could help (I know it's obvious but may safe time) it
>>>> looks the reason for the failing tests is the same. The following code
>>>> fails with assertion error:
>>>>
>>>> final Manifest manifest = getJarFileManifest( jarFile );
>>>> String classPath = manifest.getMainAttributes().getValue(
>>>> Attributes.Name.CLASS_PATH );
>>>> assertNotNull( classPath );
>>>>
>>>> The NullPointerExceptions from the rest of the tests are coming from
>>>> the same expression (`manifest.getMainAttributes().getValue(
>>>> "Class-Path" ).getBytes()`).
>>>>
>>>> On Wed, Dec 27, 2017 at 9:39 AM, Plamen Totev <
>> plamen.iv.totev@gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <
>> khmarbaise@gmx.de>
>>>> wrote:
>>>>>
>>>>>> Is someone out there who can check the current state of maven-archiver
>>>> git
>>>>>> repo on Windows and can reproduce the issue ?
>>>>>
>>>>> I ran the build a couple of times(just in case) on Windows 10, Maven
>>>>> 3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
>>>>> failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
>>>>> (and not a problem with the build) then it is probably not a Windows
>>>>> or JDK 9 related.
>>>>>
>>>>> Regards,
>>>>> Plamen Totev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: plexus-archiver / plexus-util Issue
Posted by Stephen Connolly <st...@gmail.com>.
On Thu 11 Jan 2018 at 18:47, Plamen Totev <pl...@gmail.com> wrote:
> Hi,
>
> On 12/28/2017 10:16 PM, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > On 28/12/17 20:46, Stephen Connolly wrote:
> >> But shouldn’t we be copying the last modified time stamp always anyway
> >
> > I'm the same opinion...but that means in consequence that the test in
> > plexus-archiver is not correct...cause it's waiting for a change in the
> > last-modified time ...
> >
> > Hm...
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
>
> Plexus Archiver tests are using file copy operation to change the
> "last modified" timestamp of a file. This of course is not a perfect
> approach but I don't think there was better one pre-Java 7. But now as
> Java 7 is the minimum required version, there is
> Files#setLastModifiedTime that does better job. I've created a PR that
> changes the incompatible code[1]. It will allow the update of Plexus
> Utils to 3.1.0 as well.
>
> > After I have changed that and only use
> >
> > public static File copy( File source, File target )
> > throws IOException
> > {
> > Path copy = Files.copy( source.toPath(), target.toPath(),
> > StandardCopyOption.REPLACE_EXISTING,
> > LinkOption.NOFOLLOW_LINKS );
> > return copy.toFile();
> > }
> >
> > it looks like working (see branch issue-fix):
> >
> > What Do you think?
>
> The Plexus Archiver tests were not using `copy` for its intended
> purpose so the decision if the file attributes are copied should not
> be based on their usage. To me it makes more sense to copy the
> attributes, although copying the last modified timestamp may surprise
> some evelopers (like me for example) as `cp` on Linux updates the last
> modified timestamp of the copy.
Ahh but extraction from an archive should preserve the archive time stamp...
And dir-to-dir copy is really just archive-unarchive without the
intermediate archive file ;-)
>
> Regards,
> Plamen Totev
>
> [1] https://github.com/codehaus-plexus/plexus-archiver/pull/77
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: plexus-archiver / plexus-util Issue
Posted by Plamen Totev <pl...@gmail.com>.
Hi,
On 12/28/2017 10:16 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> On 28/12/17 20:46, Stephen Connolly wrote:
>> But shouldn’t we be copying the last modified time stamp always anyway
>
> I'm the same opinion...but that means in consequence that the test in
> plexus-archiver is not correct...cause it's waiting for a change in the
> last-modified time ...
>
> Hm...
>
> Kind regards
> Karl Heinz Marbaise
>
>
Plexus Archiver tests are using file copy operation to change the
"last modified" timestamp of a file. This of course is not a perfect
approach but I don't think there was better one pre-Java 7. But now as
Java 7 is the minimum required version, there is
Files#setLastModifiedTime that does better job. I've created a PR that
changes the incompatible code[1]. It will allow the update of Plexus
Utils to 3.1.0 as well.
> After I have changed that and only use
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
> StandardCopyOption.REPLACE_EXISTING,
> LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> it looks like working (see branch issue-fix):
>
> What Do you think?
The Plexus Archiver tests were not using `copy` for its intended
purpose so the decision if the file attributes are copied should not
be based on their usage. To me it makes more sense to copy the
attributes, although copying the last modified timestamp may surprise
some evelopers (like me for example) as `cp` on Linux updates the last
modified timestamp of the copy.
Regards,
Plamen Totev
[1] https://github.com/codehaus-plexus/plexus-archiver/pull/77
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: plexus-archiver / plexus-util Issue
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 28/12/17 20:46, Stephen Connolly wrote:
> But shouldn’t we be copying the last modified time stamp always anyway
I'm the same opinion...but that means in consequence that the test in
plexus-archiver is not correct...cause it's waiting for a change in the
last-modified time ...
Hm...
Kind regards
Karl Heinz Marbaise
>
> On Thu 28 Dec 2017 at 14:52, Karl Heinz Marbaise <khmarbaise@gmx.de
> <ma...@gmx.de>> wrote:
>
> Hi,
>
> after diving more into this..
>
> I found that if I upgrade plexus-utils to 3.1.0 in plexus-archiver the
> tests in plexus-archiver stuck completely...as I already observed (which
> I though was another cause)...
>
> https://travis-ci.org/codehaus-plexus/plexus-archiver/jobs/321821294
>
> So more diving into the details I realized that the following code in
> plexus-utils causes the issue:
>
> FileUtils.java:
>
> private static void doCopyFile( File source, File destination )
> throws IOException
> {
> // offload to operating system if supported
> if ( Java7Detector.isJava7() )
> {
> doCopyFileUsingNewIO( source, destination );
> }
> else
> {
> doCopyFileUsingLegacyIO( source, destination );
> }
> }
>
> The real issue is located in the implementation of doCopyFileUsingNewIO
> which uses:
>
>
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
> StandardCopyOption.REPLACE_EXISTING,
> StandardCopyOption.COPY_ATTRIBUTES,
> LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> and If I correctly understand the whole thing is the real cause of that
> based on the usage of StandardCopyOption.COPY_ATTRIBUTES which includes
> copying of the last-modified of the file...which means not to change the
> last-modified entry of the file and in result that is the reason of not
> changing it and the stucking of the unit test in plexus-archiver...(see
> travis build above)..
>
>
> After I have changed that and only use
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
> StandardCopyOption.REPLACE_EXISTING,
> LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> it looks like working (see branch issue-fix):
>
> What Do you think?
>
> Kind regards
> Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: plexus-archiver / plexus-util Issue
Posted by Stephen Connolly <st...@gmail.com>.
But shouldn’t we be copying the last modified time stamp always anyway
On Thu 28 Dec 2017 at 14:52, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> Hi,
>
> after diving more into this..
>
> I found that if I upgrade plexus-utils to 3.1.0 in plexus-archiver the
> tests in plexus-archiver stuck completely...as I already observed (which
> I though was another cause)...
>
> https://travis-ci.org/codehaus-plexus/plexus-archiver/jobs/321821294
>
> So more diving into the details I realized that the following code in
> plexus-utils causes the issue:
>
> FileUtils.java:
>
> private static void doCopyFile( File source, File destination )
> throws IOException
> {
> // offload to operating system if supported
> if ( Java7Detector.isJava7() )
> {
> doCopyFileUsingNewIO( source, destination );
> }
> else
> {
> doCopyFileUsingLegacyIO( source, destination );
> }
> }
>
> The real issue is located in the implementation of doCopyFileUsingNewIO
> which uses:
>
>
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
> StandardCopyOption.REPLACE_EXISTING,
> StandardCopyOption.COPY_ATTRIBUTES,
> LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> and If I correctly understand the whole thing is the real cause of that
> based on the usage of StandardCopyOption.COPY_ATTRIBUTES which includes
> copying of the last-modified of the file...which means not to change the
> last-modified entry of the file and in result that is the reason of not
> changing it and the stucking of the unit test in plexus-archiver...(see
> travis build above)..
>
>
> After I have changed that and only use
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
> StandardCopyOption.REPLACE_EXISTING,
> LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> it looks like working (see branch issue-fix):
>
> What Do you think?
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
plexus-archiver / plexus-util Issue
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
after diving more into this..
I found that if I upgrade plexus-utils to 3.1.0 in plexus-archiver the
tests in plexus-archiver stuck completely...as I already observed (which
I though was another cause)...
https://travis-ci.org/codehaus-plexus/plexus-archiver/jobs/321821294
So more diving into the details I realized that the following code in
plexus-utils causes the issue:
FileUtils.java:
private static void doCopyFile( File source, File destination )
throws IOException
{
// offload to operating system if supported
if ( Java7Detector.isJava7() )
{
doCopyFileUsingNewIO( source, destination );
}
else
{
doCopyFileUsingLegacyIO( source, destination );
}
}
The real issue is located in the implementation of doCopyFileUsingNewIO
which uses:
public static File copy( File source, File target )
throws IOException
{
Path copy = Files.copy( source.toPath(), target.toPath(),
StandardCopyOption.REPLACE_EXISTING,
StandardCopyOption.COPY_ATTRIBUTES,
LinkOption.NOFOLLOW_LINKS );
return copy.toFile();
}
and If I correctly understand the whole thing is the real cause of that
based on the usage of StandardCopyOption.COPY_ATTRIBUTES which includes
copying of the last-modified of the file...which means not to change the
last-modified entry of the file and in result that is the reason of not
changing it and the stucking of the unit test in plexus-archiver...(see
travis build above)..
After I have changed that and only use
public static File copy( File source, File target )
throws IOException
{
Path copy = Files.copy( source.toPath(), target.toPath(),
StandardCopyOption.REPLACE_EXISTING,
LinkOption.NOFOLLOW_LINKS );
return copy.toFile();
}
it looks like working (see branch issue-fix):
What Do you think?
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
Ok, after more tests i found that error exists when project was executed in
path with @ char that was encoded to %402 -
https://issues.apache.org/jira/browse/SUREFIRE-1312
Sylwester
śr., 27 gru 2017 o 13:31 użytkownik Karl Heinz Marbaise <kh...@gmx.de>
napisał:
> Hi,
>
> On 27/12/17 13:01, Sylwester Lachiewicz wrote:
> > Build fails with long directory name - also on windows.
> > Upgrade maven-surefire-plugin to 2.20.1 fixes test error.
>
> Hm..this is a little bit confusing, cause the length for windows are
> about 141 characters (already thought about something similar) but the
> upgrade changes the situation completely ...Thanks for that hint..
>
>
> Just one test cases is failing...
>
> Kidn regards
> Karl Heinz Marbaise
>
> >
> >
> > śr., 27 gru 2017 o 08:49 użytkownik Plamen Totev <
> plamen.iv.totev@gmail.com>
> > napisał:
> >
> >> And if this could help (I know it's obvious but may safe time) it
> >> looks the reason for the failing tests is the same. The following code
> >> fails with assertion error:
> >>
> >> final Manifest manifest = getJarFileManifest( jarFile );
> >> String classPath = manifest.getMainAttributes().getValue(
> >> Attributes.Name.CLASS_PATH );
> >> assertNotNull( classPath );
> >>
> >> The NullPointerExceptions from the rest of the tests are coming from
> >> the same expression (`manifest.getMainAttributes().getValue(
> >> "Class-Path" ).getBytes()`).
> >>
> >> On Wed, Dec 27, 2017 at 9:39 AM, Plamen Totev <
> plamen.iv.totev@gmail.com>
> >> wrote:
> >>> Hi,
> >>>
> >>> On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <
> khmarbaise@gmx.de>
> >> wrote:
> >>>
> >>>> Is someone out there who can check the current state of maven-archiver
> >> git
> >>>> repo on Windows and can reproduce the issue ?
> >>>
> >>> I ran the build a couple of times(just in case) on Windows 10, Maven
> >>> 3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
> >>> failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
> >>> (and not a problem with the build) then it is probably not a Windows
> >>> or JDK 9 related.
> >>>
> >>> Regards,
> >>> Plamen Totev
>
Re: maven-archiver build on Jenkins - Test Failures
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 27/12/17 13:01, Sylwester Lachiewicz wrote:
> Build fails with long directory name - also on windows.
> Upgrade maven-surefire-plugin to 2.20.1 fixes test error.
Hm..this is a little bit confusing, cause the length for windows are
about 141 characters (already thought about something similar) but the
upgrade changes the situation completely ...Thanks for that hint..
Just one test cases is failing...
Kidn regards
Karl Heinz Marbaise
>
>
> śr., 27 gru 2017 o 08:49 użytkownik Plamen Totev <pl...@gmail.com>
> napisał:
>
>> And if this could help (I know it's obvious but may safe time) it
>> looks the reason for the failing tests is the same. The following code
>> fails with assertion error:
>>
>> final Manifest manifest = getJarFileManifest( jarFile );
>> String classPath = manifest.getMainAttributes().getValue(
>> Attributes.Name.CLASS_PATH );
>> assertNotNull( classPath );
>>
>> The NullPointerExceptions from the rest of the tests are coming from
>> the same expression (`manifest.getMainAttributes().getValue(
>> "Class-Path" ).getBytes()`).
>>
>> On Wed, Dec 27, 2017 at 9:39 AM, Plamen Totev <pl...@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <kh...@gmx.de>
>> wrote:
>>>
>>>> Is someone out there who can check the current state of maven-archiver
>> git
>>>> repo on Windows and can reproduce the issue ?
>>>
>>> I ran the build a couple of times(just in case) on Windows 10, Maven
>>> 3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
>>> failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
>>> (and not a problem with the build) then it is probably not a Windows
>>> or JDK 9 related.
>>>
>>> Regards,
>>> Plamen Totev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
Build fails with long directory name - also on windows.
Upgrade maven-surefire-plugin to 2.20.1 fixes test error.
śr., 27 gru 2017 o 08:49 użytkownik Plamen Totev <pl...@gmail.com>
napisał:
> And if this could help (I know it's obvious but may safe time) it
> looks the reason for the failing tests is the same. The following code
> fails with assertion error:
>
> final Manifest manifest = getJarFileManifest( jarFile );
> String classPath = manifest.getMainAttributes().getValue(
> Attributes.Name.CLASS_PATH );
> assertNotNull( classPath );
>
> The NullPointerExceptions from the rest of the tests are coming from
> the same expression (`manifest.getMainAttributes().getValue(
> "Class-Path" ).getBytes()`).
>
> On Wed, Dec 27, 2017 at 9:39 AM, Plamen Totev <pl...@gmail.com>
> wrote:
> > Hi,
> >
> > On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
> >
> >> Is someone out there who can check the current state of maven-archiver
> git
> >> repo on Windows and can reproduce the issue ?
> >
> > I ran the build a couple of times(just in case) on Windows 10, Maven
> > 3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
> > failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
> > (and not a problem with the build) then it is probably not a Windows
> > or JDK 9 related.
> >
> > Regards,
> > Plamen Totev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: maven-archiver build on Jenkins - Test Failures
Posted by Plamen Totev <pl...@gmail.com>.
And if this could help (I know it's obvious but may safe time) it
looks the reason for the failing tests is the same. The following code
fails with assertion error:
final Manifest manifest = getJarFileManifest( jarFile );
String classPath = manifest.getMainAttributes().getValue(
Attributes.Name.CLASS_PATH );
assertNotNull( classPath );
The NullPointerExceptions from the rest of the tests are coming from
the same expression (`manifest.getMainAttributes().getValue(
"Class-Path" ).getBytes()`).
On Wed, Dec 27, 2017 at 9:39 AM, Plamen Totev <pl...@gmail.com> wrote:
> Hi,
>
> On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
>> Is someone out there who can check the current state of maven-archiver git
>> repo on Windows and can reproduce the issue ?
>
> I ran the build a couple of times(just in case) on Windows 10, Maven
> 3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
> failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
> (and not a problem with the build) then it is probably not a Windows
> or JDK 9 related.
>
> Regards,
> Plamen Totev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Plamen Totev <pl...@gmail.com>.
Hi,
On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> Is someone out there who can check the current state of maven-archiver git
> repo on Windows and can reproduce the issue ?
I ran the build a couple of times(just in case) on Windows 10, Maven
3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
(and not a problem with the build) then it is probably not a Windows
or JDK 9 related.
Regards,
Plamen Totev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Stephen Connolly <st...@gmail.com>.
[6]:
https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/testReport/
On Tue 26 Dec 2017 at 22:45, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Yes, I have set the command line to ignore failing tests, then the junit
> reporter marks the build as unstable based on the test results
>
> You should be able to see the 27 failing tests from [6]
>
> On Tue 26 Dec 2017 at 21:59, Robert Scholte <rf...@apache.org> wrote:
>
>> Interesting...
>>
>> The pipeline steps[1] say all succeeded, however #6 overview[2] complaints
>> about failing tests.
>>
>> Robert
>>
>> [1]
>>
>> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/flowGraphTable/
>> [2]
>> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/
>>
>> On Tue, 26 Dec 2017 20:44:35 +0100, Karl Heinz Marbaise
>> <kh...@gmx.de> wrote:
>>
>> > Hi Robert,
>> >
>> > I will try and see the result..
>> >
>> > Thanks.
>> >
>> > Kind regards
>> > Karl Heinz
>> >
>> >
>> > On 26/12/17 20:27, Robert Scholte wrote:
>> >> The job starting quite some time ago. Maybe better to kill the it and
>> >> start over again.
>> >> I had trouble visiting builds.apache.org this afternoon, could be
>> >> related.
>> >> thanks,
>> >> Robert
>> >> On Tue, 26 Dec 2017 20:01:02 +0100, Karl Heinz Marbaise
>> >> <kh...@gmx.de> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> currently I'm observing a strange thing..cause the build on Jenkins
>> >>> produces test failure with JDK 9
>> >>>
>> >>>
>> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/5/consoleFull
>> >>> The problem I'm currently having is that I can't reproduce this..
>> >>>
>> >>> I have tested with Maven 3.5.2 and JDK 9.0.1 without any problem on my
>> >>> Mac ...
>> >>>
>> >>> Is someone out there who can check the current state of maven-archiver
>> >>> git repo on Windows and can reproduce the issue ?
>> >>>
>> >>> It would be great..Thanks in advance.
>> >>>
>> >>> Kind regards
>> >>> Karl Heinz Marbaise
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
> Sent from my phone
>
--
Sent from my phone
Re: maven-archiver build on Jenkins - Test Failures
Posted by Stephen Connolly <st...@gmail.com>.
Yes, I have set the command line to ignore failing tests, then the junit
reporter marks the build as unstable based on the test results
You should be able to see the 27 failing tests from [6]
On Tue 26 Dec 2017 at 21:59, Robert Scholte <rf...@apache.org> wrote:
> Interesting...
>
> The pipeline steps[1] say all succeeded, however #6 overview[2] complaints
> about failing tests.
>
> Robert
>
> [1]
>
> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/flowGraphTable/
> [2]
> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/
>
> On Tue, 26 Dec 2017 20:44:35 +0100, Karl Heinz Marbaise
> <kh...@gmx.de> wrote:
>
> > Hi Robert,
> >
> > I will try and see the result..
> >
> > Thanks.
> >
> > Kind regards
> > Karl Heinz
> >
> >
> > On 26/12/17 20:27, Robert Scholte wrote:
> >> The job starting quite some time ago. Maybe better to kill the it and
> >> start over again.
> >> I had trouble visiting builds.apache.org this afternoon, could be
> >> related.
> >> thanks,
> >> Robert
> >> On Tue, 26 Dec 2017 20:01:02 +0100, Karl Heinz Marbaise
> >> <kh...@gmx.de> wrote:
> >>
> >>> Hi,
> >>>
> >>> currently I'm observing a strange thing..cause the build on Jenkins
> >>> produces test failure with JDK 9
> >>>
> >>>
> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/5/consoleFull
> >>> The problem I'm currently having is that I can't reproduce this..
> >>>
> >>> I have tested with Maven 3.5.2 and JDK 9.0.1 without any problem on my
> >>> Mac ...
> >>>
> >>> Is someone out there who can check the current state of maven-archiver
> >>> git repo on Windows and can reproduce the issue ?
> >>>
> >>> It would be great..Thanks in advance.
> >>>
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: maven-archiver build on Jenkins - Test Failures
Posted by Robert Scholte <rf...@apache.org>.
Interesting...
The pipeline steps[1] say all succeeded, however #6 overview[2] complaints
about failing tests.
Robert
[1]
https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/flowGraphTable/
[2]
https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/6/
On Tue, 26 Dec 2017 20:44:35 +0100, Karl Heinz Marbaise
<kh...@gmx.de> wrote:
> Hi Robert,
>
> I will try and see the result..
>
> Thanks.
>
> Kind regards
> Karl Heinz
>
>
> On 26/12/17 20:27, Robert Scholte wrote:
>> The job starting quite some time ago. Maybe better to kill the it and
>> start over again.
>> I had trouble visiting builds.apache.org this afternoon, could be
>> related.
>> thanks,
>> Robert
>> On Tue, 26 Dec 2017 20:01:02 +0100, Karl Heinz Marbaise
>> <kh...@gmx.de> wrote:
>>
>>> Hi,
>>>
>>> currently I'm observing a strange thing..cause the build on Jenkins
>>> produces test failure with JDK 9
>>>
>>> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/5/consoleFull
>>> The problem I'm currently having is that I can't reproduce this..
>>>
>>> I have tested with Maven 3.5.2 and JDK 9.0.1 without any problem on my
>>> Mac ...
>>>
>>> Is someone out there who can check the current state of maven-archiver
>>> git repo on Windows and can reproduce the issue ?
>>>
>>> It would be great..Thanks in advance.
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Robert,
I will try and see the result..
Thanks.
Kind regards
Karl Heinz
On 26/12/17 20:27, Robert Scholte wrote:
> The job starting quite some time ago. Maybe better to kill the it and
> start over again.
> I had trouble visiting builds.apache.org this afternoon, could be related.
>
> thanks,
> Robert
>
> On Tue, 26 Dec 2017 20:01:02 +0100, Karl Heinz Marbaise
> <kh...@gmx.de> wrote:
>
>> Hi,
>>
>> currently I'm observing a strange thing..cause the build on Jenkins
>> produces test failure with JDK 9
>>
>> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/5/consoleFull
>>
>>
>> The problem I'm currently having is that I can't reproduce this..
>>
>> I have tested with Maven 3.5.2 and JDK 9.0.1 without any problem on my
>> Mac ...
>>
>> Is someone out there who can check the current state of maven-archiver
>> git repo on Windows and can reproduce the issue ?
>>
>> It would be great..Thanks in advance.
>>
>> Kind regards
>> Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-archiver build on Jenkins - Test Failures
Posted by Robert Scholte <rf...@apache.org>.
The job starting quite some time ago. Maybe better to kill the it and
start over again.
I had trouble visiting builds.apache.org this afternoon, could be related.
thanks,
Robert
On Tue, 26 Dec 2017 20:01:02 +0100, Karl Heinz Marbaise
<kh...@gmx.de> wrote:
> Hi,
>
> currently I'm observing a strange thing..cause the build on Jenkins
> produces test failure with JDK 9
>
> https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/5/consoleFull
>
> The problem I'm currently having is that I can't reproduce this..
>
> I have tested with Maven 3.5.2 and JDK 9.0.1 without any problem on my
> Mac ...
>
> Is someone out there who can check the current state of maven-archiver
> git repo on Windows and can reproduce the issue ?
>
> It would be great..Thanks in advance.
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org