[
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}
> 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)
