Re: maven-archiver build on Jenkins - Test Failures

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: maven-archiver build on Jenkins - Test Failures

Plamen Totev-2
Hi,

On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: maven-archiver build on Jenkins - Test Failures

Sylwester Lachiewicz
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 <[hidden email]>
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 <[hidden email]>
> wrote:
> > Hi,
> >
> > On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: maven-archiver build on Jenkins - Test Failures

Karl Heinz Marbaise-3
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 <[hidden email]>
> 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 <
>> [hidden email]>
>>> 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 <
>> [hidden email]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <
>> [hidden email]>
>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: plexus-archiver / plexus-util Issue

Plamen Totev-2
In reply to this post by Sylwester Lachiewicz
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: [hidden email]
For additional commands, e-mail: [hidden email]