PUBLIC - Liferay Portal Community Edition

taglibdoc target fails if spaces in path when called from maven install-local-snapshots target

Details

  • Similar Issues:
    Show 5 results 

Description

When trying to get the 6.2.0-SNAPSHOT maven artifacts installed locally, when spaces are in the source path, you get the following error:

liferay-portal/
ant -f build-maven.xml install-snapshot-artifacts

....
taglibdoc:
[mkdir] Created dir: d:\dev java\github\liferay\liferay-portal\api\taglibs
[java] Loading and translating 8 Tag Libraries...
[java] com.sun.tlddoc.GeneratorException: javax.xml.transform.TransformerException: java.io.FileNotFoundException:
d:\dev%20java\github\liferay\liferay-portal\util-taglib\..\api\taglibs\index.html (The system cannot find the path speci
fied)
[java] at com.sun.tlddoc.TLDDocGenerator.generate(TLDDocGenerator.java:458)
[java] at com.sun.tlddoc.TLDDoc.main(TLDDoc.java:217)
[java] Caused by: javax.xml.transform.TransformerException: java.io.FileNotFoundException: d:\dev%20java\github\lif
eray\liferay-portal\util-taglib\..\api\taglibs\index.html (The system cannot find the path specified)
[java] at org.apache.xalan.transformer.TransformerImpl.createSerializationHandler(TransformerImpl.java:1218)
[java] at org.apache.xalan.transformer.TransformerImpl.createSerializationHandler(TransformerImpl.java:1060)
[java] at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1268)
[java] at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1251)
[java] at com.sun.tlddoc.TLDDocGenerator.generatePage(TLDDocGenerator.java:1193)
[java] at com.sun.tlddoc.TLDDocGenerator.generatePage(TLDDocGenerator.java:1166)
[java] at com.sun.tlddoc.TLDDocGenerator.generateOverview(TLDDocGenerator.java:1016)
[java] at com.sun.tlddoc.TLDDocGenerator.generate(TLDDocGenerator.java:441)
[java] ... 1 more
[java] Caused by: java.io.FileNotFoundException: d:\dev%20java\github\liferay\liferay-portal\util-taglib\..\api\tag
libs\index.html (The system cannot find the path specified)
[java] at java.io.FileOutputStream.open(Native Method)
[java] at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
[java] at java.io.FileOutputStream.<init>(FileOutputStream.java:84)
[java] at org.apache.xalan.transformer.TransformerImpl.createSerializationHandler(TransformerImpl.java:1197)
[java] ... 8 more

BUILD FAILED
d:\dev java\github\liferay\liferay-portal\build-maven.xml:90: The following error occurred while executing this line:
d:\dev java\github\liferay\liferay-portal\build-maven.xml:72: The following error occurred while executing this line:
d:\dev java\github\liferay\liferay-portal\build-maven.xml:134: The following error occurred while executing this line:
d:\dev java\github\liferay\liferay-portal\util-taglib\build.xml:77: Java returned: 1

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Gregory Amerson added a comment -

I verified that if I move my liferay-portal source to a install path that has no spaces, this command will not fail.

I've done some research and there doesn't seem to be a way for us to santize paths on our end. It appears to be a bug in the TLDDoc class itself. I'm proposing that we fix this by copying taglibs to a system temp dir (which don't have spaces in path generally) and then performing the TLDDoc command and then copying it back to original output directory and deleting the temp folder.

Show
Gregory Amerson added a comment - I verified that if I move my liferay-portal source to a install path that has no spaces, this command will not fail. I've done some research and there doesn't seem to be a way for us to santize paths on our end. It appears to be a bug in the TLDDoc class itself. I'm proposing that we fix this by copying taglibs to a system temp dir (which don't have spaces in path generally) and then performing the TLDDoc command and then copying it back to original output directory and deleting the temp folder.
Hide
Permalink
Gregory Amerson added a comment -

Also the <delete .../> at the end of the install-snapshot-artifacts task always fails for windows. I'm proposing to just add a failonerror="false" so that the script doesn't end with error.

Show
Gregory Amerson added a comment - Also the <delete .../> at the end of the install-snapshot-artifacts task always fails for windows. I'm proposing to just add a failonerror="false" so that the script doesn't end with error.
Hide
Permalink
Brian Chan added a comment -

Hey Greg,

Can you resend this, and see if we can use the trick in

http://ant.1045680.n5.nabble.com/Problem-with-Ant-pathconvert-and-paths-with-spaces-td1843377.html

to fix the issue?

See build-common.xml where we define "doc.dir"

We also do lots of manipulation to create dirs for unix, windows, etc. See ".dir.unix" and ".dir.location.absolute"

So I'd like to fix it in that area if possible. Thx.

Show
Brian Chan added a comment - Hey Greg, Can you resend this, and see if we can use the trick in http://ant.1045680.n5.nabble.com/Problem-with-Ant-pathconvert-and-paths-with-spaces-td1843377.html to fix the issue? See build-common.xml where we define "doc.dir" We also do lots of manipulation to create dirs for unix, windows, etc. See ".dir.unix" and ".dir.location.absolute" So I'd like to fix it in that area if possible. Thx.
Hide
Permalink
Brian Chan added a comment -

also, I'm fine with the failonerror="false" fix, but I want to know why it's always failing in Windows before using that fix. Thx.

Show
Brian Chan added a comment - also, I'm fine with the failonerror="false" fix, but I want to know why it's always failing in Windows before using that fix. Thx.
Hide
Permalink
Gregory Amerson added a comment -

Hey Brian,

I tried the solution in the link you sent, converting the %20 to " ". However, that doesn't seem to fix the problem. I have checked and the value of the path that we are TLDDoc application does not have any %20 but just one space. I think the problem is that internal to TLDDoc it is creating a string representation of the path and converting it and that is putting the %20 back before it creates a new File() object. I can't verify that unless I have the source for the TLDDoc or TransformerImpl.

I have confirmed that this same problem happens on linux as well. Thoughts?

Show
Gregory Amerson added a comment - Hey Brian, I tried the solution in the link you sent, converting the %20 to " ". However, that doesn't seem to fix the problem. I have checked and the value of the path that we are TLDDoc application does not have any %20 but just one space. I think the problem is that internal to TLDDoc it is creating a string representation of the path and converting it and that is putting the %20 back before it creates a new File() object. I can't verify that unless I have the source for the TLDDoc or TransformerImpl. I have confirmed that this same problem happens on linux as well. Thoughts?
Hide
Permalink
Randy Zhu added a comment -

In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”.

This ticket has been converted to story ticket type for you; so that the ticket may continue to progress through the workflow properly.

However these tickets were not writing in the proper story format. Please format this ticket to story standards.

Show
Randy Zhu added a comment - In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. This ticket has been converted to story ticket type for you; so that the ticket may continue to progress through the workflow properly. However these tickets were not writing in the proper story format. Please format this ticket to story standards.
Hide
Permalink
Gregory Amerson added a comment -

Closing this as it doesn't fail if you dont' have spaces in the path, no need for us to fix this.

Show
Gregory Amerson added a comment - Closing this as it doesn't fail if you dont' have spaces in the path, no need for us to fix this.
Hide
Permalink
Edward Gonzales added a comment -

Hello everyone! We are in the process of removing component "Liferay TagLib" from LPS issues that contain more than one component. For issues that only have "Liferay TagLib", we plan to move to them to "Tools > Portal Taglibs". In the end, "Liferay TagLib" will be deprecated. Please make the necessary adjustments to your filters. Thanks!

Show
Edward Gonzales added a comment - Hello everyone! We are in the process of removing component "Liferay TagLib" from LPS issues that contain more than one component. For issues that only have "Liferay TagLib", we plan to move to them to "Tools > Portal Taglibs". In the end, "Liferay TagLib" will be deprecated. Please make the necessary adjustments to your filters. Thanks!

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
    Days since last comment:
    4 weeks, 6 days ago