[jira] [Commented] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-19 Thread Emanuele Lombardi (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290915#comment-15290915
 ] 

Emanuele Lombardi commented on SLING-5712:
--

Double checked, everything is ok.

Thanks

> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
> Attachments: SanitizeResourceNameTest.patch, 
> TEST-org.apache.sling.repoinit.it.RepoInitIT.xml, 
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml, 
> TEST-org.apache.sling.testing.teleporter.client.SanitizeResourceNameTest.xml, 
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
> tests on Teleporter module .
> See attachment 
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a 
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests 
> code like
> {code:java}
>  assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of 
> {code:java}
>  assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This was a good fix for the failing tests under Teleporter module but 
> unfortunately this fix causes RepoInitIT integration test failure because the 
> resource name returned by Teleporter ClassResourceVisitor used to create test 
> bundles inside ClientSideTeleporter#buildTestBundle must use '/' style 
> slashes, not '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name 
> like "\name" will create a jar containing a folder with an empty name 
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile 
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
> also by what is expected to have in resourcePath parameter of method 
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
> regardless of operating system.
> See "windows.patch"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-15 Thread Emanuele Lombardi (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emanuele Lombardi updated SLING-5712:
-
Attachment: 
TEST-org.apache.sling.testing.teleporter.client.SanitizeResourceNameTest.xml

> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
> Attachments: SanitizeResourceNameTest.patch, 
> TEST-org.apache.sling.repoinit.it.RepoInitIT.xml, 
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml, 
> TEST-org.apache.sling.testing.teleporter.client.SanitizeResourceNameTest.xml, 
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
> tests on Teleporter module .
> See attachment 
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a 
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests 
> code like
> {code:java}
>  assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of 
> {code:java}
>  assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This was a good fix for the failing tests under Teleporter module but 
> unfortunately this fix causes RepoInitIT integration test failure because the 
> resource name returned by Teleporter ClassResourceVisitor used to create test 
> bundles inside ClientSideTeleporter#buildTestBundle must use '/' style 
> slashes, not '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name 
> like "\name" will create a jar containing a folder with an empty name 
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile 
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
> also by what is expected to have in resourcePath parameter of method 
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
> regardless of operating system.
> See "windows.patch"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-15 Thread Emanuele Lombardi (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emanuele Lombardi updated SLING-5712:
-
Attachment: SanitizeResourceNameTest.patch

Hi,
Thanks to having applied the patch.
I did a cross-check and there is a problem into SanitizeResourceNameTest.
At line 46 
{code:java}this.basePath = File.separator + basePath
{code} should be 
{code:java}this.basePath = new File(File.separator + basePath).getAbsolutePath()
{code}
This because in Windows when a File starts with root and the 
methodgetAbsolutePath() is invoked the root is replaced by C:\ (C or your drive 
letter)

In the method ClassResourceVisitor#sanitizeResourceName if basePath is 
"\something" instead of "C:\something" we will miss 2 characters to be deleted 
when substring method is invoked on resource.getAbsolutePath() that will be 
something like C:\resourceabsolutepath.

Attached a new patch.


> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.8
>
> Attachments: SanitizeResourceNameTest.patch, 
> TEST-org.apache.sling.repoinit.it.RepoInitIT.xml, 
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml, 
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
> tests on Teleporter module .
> See attachment 
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a 
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests 
> code like
> {code:java}
>  assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of 
> {code:java}
>  assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This was a good fix for the failing tests under Teleporter module but 
> unfortunately this fix causes RepoInitIT integration test failure because the 
> resource name returned by Teleporter ClassResourceVisitor used to create test 
> bundles inside ClientSideTeleporter#buildTestBundle must use '/' style 
> slashes, not '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name 
> like "\name" will create a jar containing a folder with an empty name 
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile 
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
> also by what is expected to have in resourcePath parameter of method 
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
> regardless of operating system.
> See "windows.patch"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-05 Thread Emanuele Lombardi (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emanuele Lombardi updated SLING-5712:
-
Description: 
Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
tests on Teleporter module .
See attachment 
"TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"

This happens because the tests expectation is to find the resources with a path 
unix like.
Originally I tried to fix the issue by putting as expectation in the tests code 
like

{code:java}
 assertResource(new File("/somepath/two.txt").getPath(), "two");
{code}
instead of 
{code:java}
 assertResource("/somepath/two.txt", "two");
{code}
to have the expectation not OS dependent.

This was a good fix for the failing tests under Teleporter module but 
unfortunately this fix causes RepoInitIT integration test failure because the 
resource name returned by Teleporter ClassResourceVisitor used to create test 
bundles inside ClientSideTeleporter#buildTestBundle must use '/' style slashes, 
not '\' because of undocumented quirks of JDK:
see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
adding one entry into jars using class java.util.jar.JarEntry with entry name 
like "\name" will create a jar containing a folder with an empty name 
containing the resource.
Unfortunately resources in Windows are returned with a path with backslashes.

see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
"tinybundle-bundle-with-back-slash-as-resource-name.jar"

So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile all 
"\" with "/".
Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
also by what is expected to have in resourcePath parameter of method 
ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
regardless of operating system.

See "windows.patch"




  was:
Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
tests on Teleporter module .
See attachment 
"TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"

This happens because the tests expectation is to find the resources with a path 
unix like.
Originally I tried to fix the issue by putting as expectation in the tests code 
like

{code:java}
 assertResource(new File("/somepath/two.txt").getPath(), "two");
{code}
instead of 
{code:java}
 assertResource("/somepath/two.txt", "two");
{code}
to have the expectation not OS dependent.

This is a fix for the failing tests under Teleporter module but unfortunately 
this fix causes RepoInitIT integration test failure because the resource name 
returned by Teleporter ClassResourceVisitor used to create test bundles inside 
ClientSideTeleporter#buildTestBundle must use '/' style slashes, not '\' 
because of undocumented quirks of JDK:
see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
adding one entry into jars using class java.util.jar.JarEntry with entry name 
like "\name" will create a jar containing a folder with an empty name 
containing the resource.
Unfortunately resources in Windows are returned with a path with backslashes.

see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
"tinybundle-bundle-with-back-slash-as-resource-name.jar"

So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile all 
"\" with "/".
Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
also by what is expected to have in resourcePath parameter of method 
ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
regardless of operating system.

See "windows.patch"





> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Priority: Minor
> Attachments: TEST-org.apache.sling.repoinit.it.RepoInitIT.xml, 
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml, 
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
> tests on Teleporter module .
> See attachment 
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a 
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests 
> code like
> {code:java}
>  assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of 
> {code:java}
>

[jira] [Updated] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-05 Thread Emanuele Lombardi (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emanuele Lombardi updated SLING-5712:
-
Attachment: tinybundle-bundle-with-back-slash-as-resource-name.jar

TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml
TEST-org.apache.sling.repoinit.it.RepoInitIT.xml

> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Priority: Minor
> Attachments: TEST-org.apache.sling.repoinit.it.RepoInitIT.xml, 
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml, 
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
> tests on Teleporter module .
> See attachment 
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a 
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests 
> code like
> {code:java}
>  assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of 
> {code:java}
>  assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This is a fix for the failing tests under Teleporter module but unfortunately 
> this fix causes RepoInitIT integration test failure because the resource name 
> returned by Teleporter ClassResourceVisitor used to create test bundles 
> inside ClientSideTeleporter#buildTestBundle must use '/' style slashes, not 
> '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name 
> like "\name" will create a jar containing a folder with an empty name 
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile 
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
> also by what is expected to have in resourcePath parameter of method 
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
> regardless of operating system.
> See "windows.patch"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-05 Thread Emanuele Lombardi (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Emanuele Lombardi updated SLING-5712:
-
Attachment: windows.patch

> JUnit Tests Teleporter does not (compile) work on Windows as expected
> -
>
> Key: SLING-5712
> URL: https://issues.apache.org/jira/browse/SLING-5712
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.6
> Environment: Windows 7 + Cygwin
>Reporter: Emanuele Lombardi
>Priority: Minor
> Attachments: TEST-org.apache.sling.repoinit.it.RepoInitIT.xml, 
> TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml, 
> tinybundle-bundle-with-back-slash-as-resource-name.jar, windows.patch
>
>
> Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
> tests on Teleporter module .
> See attachment 
> "TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"
> This happens because the tests expectation is to find the resources with a 
> path unix like.
> Originally I tried to fix the issue by putting as expectation in the tests 
> code like
> {code:java}
>  assertResource(new File("/somepath/two.txt").getPath(), "two");
> {code}
> instead of 
> {code:java}
>  assertResource("/somepath/two.txt", "two");
> {code}
> to have the expectation not OS dependent.
> This is a fix for the failing tests under Teleporter module but unfortunately 
> this fix causes RepoInitIT integration test failure because the resource name 
> returned by Teleporter ClassResourceVisitor used to create test bundles 
> inside ClientSideTeleporter#buildTestBundle must use '/' style slashes, not 
> '\' because of undocumented quirks of JDK:
> see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
> adding one entry into jars using class java.util.jar.JarEntry with entry name 
> like "\name" will create a jar containing a folder with an empty name 
> containing the resource.
> Unfortunately resources in Windows are returned with a path with backslashes.
> see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
> "tinybundle-bundle-with-back-slash-as-resource-name.jar"
> So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile 
> all "\" with "/".
> Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
> also by what is expected to have in resourcePath parameter of method 
> ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
> regardless of operating system.
> See "windows.patch"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (SLING-5712) JUnit Tests Teleporter does not (compile) work on Windows as expected

2016-05-05 Thread Emanuele Lombardi (JIRA)
Emanuele Lombardi created SLING-5712:


 Summary: JUnit Tests Teleporter does not (compile) work on Windows 
as expected
 Key: SLING-5712
 URL: https://issues.apache.org/jira/browse/SLING-5712
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Tests Teleporter 1.0.6
 Environment: Windows 7 + Cygwin
Reporter: Emanuele Lombardi
Priority: Minor


Checked out sling trunk, the build fails on Windows 7 because of 3 failing 
tests on Teleporter module .
See attachment 
"TEST-org.apache.sling.testing.teleporter.client.ClassResourceVisitorTest.xml"

This happens because the tests expectation is to find the resources with a path 
unix like.
Originally I tried to fix the issue by putting as expectation in the tests code 
like

{code:java}
 assertResource(new File("/somepath/two.txt").getPath(), "two");
{code}
instead of 
{code:java}
 assertResource("/somepath/two.txt", "two");
{code}
to have the expectation not OS dependent.

This is a fix for the failing tests under Teleporter module but unfortunately 
this fix causes RepoInitIT integration test failure because the resource name 
returned by Teleporter ClassResourceVisitor used to create test bundles inside 
ClientSideTeleporter#buildTestBundle must use '/' style slashes, not '\' 
because of undocumented quirks of JDK:
see org.ops4j.pax.tinybundles.core.intern.RawBuilder#build
adding one entry into jars using class java.util.jar.JarEntry with entry name 
like "\name" will create a jar containing a folder with an empty name 
containing the resource.
Unfortunately resources in Windows are returned with a path with backslashes.

see attachments: "TEST-org.apache.sling.repoinit.it.RepoInitIT.xml" 
"tinybundle-bundle-with-back-slash-as-resource-name.jar"

So I had to do a dirty fix: replace inside ClassResourceVisitor#processFile all 
"\" with "/".
Will be correct to do a fix inside JDK or TinyBundles library, but it depends 
also by what is expected to have in resourcePath parameter of method 
ClassResourceVisitor.Processor#process; a resource name with "\" or "/" 
regardless of operating system.

See "windows.patch"






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)