[GRADLE-3176] eclipseClasspath chokes on Javadoc in archive with platform: in URI Created: 30/Sep/14 Updated: 10/Feb/17 Resolved: 10/Feb/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Task | ||
Reporter: | Gradle Forums | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 2 |
Description |
In Eclipse in the Java Build Path, I assigned a javadoc jar to a library by selecting "Javadoc in archive", then giving the path in my project like myProject/lib/doc/spring-framework-3.1.3-RELEASE-javadoc.jar. With this, the eclipse task chokes: robert@pferdeapfel:~/pmc/1808/powermta> gradlew eclipse -s FAILURE: Build failed with an exception.
... Looking at .classpath in an editor, the entry in question is <classpathentry kind="lib" path="lib/org.springframework.core-3.1.3.RELEASE.jar"> Is that expected? Even if I change the Eclipse setting from Workspace File to External File, Eclipse does not put a file: URI in. In my example I got <attribute name="javadoc_location" value="jar:file:/Users/robert/myProject/lib/doc/spring-framework-3.1.3-RELEASE-javadoc.jar!/"/> Of course I don't want to use this cause the absolute path would break the location for everybody else on the team. What do I need to change to make both Eclipse and Gradle happy? Thanks, Robert |
Comments |
Comment by Gradle Forums [ 30/Sep/14 ] |
Just realized that Eclipse will put absolute paths in .classpath for jars and javadoc jars. Guess I need to change my project setup and not have .classpath in version control. Makes sense. That said, it would still be nice if Gradle could handle an existing project's jar:resource: Javadoc locations. Or am I missing something else? |
Comment by Gradle Forums [ 30/Sep/14 ] |
Can you tell us what Eclipse version you use and how did you create that classpath entry definition? I guess there are some ways how to fix this in Gradle: probably we need to add URL handler for 'platform:' protocol or parse this as simple String. In the meantime: my first choice would be to use a repository like Artifactory or Nexus for your binary dependencies rather than adding them to your project (and possibly to SCM). This will take care of the association with sources and javadoc in most cases too. |
Comment by Gradle Forums [ 30/Sep/14 ] |
This is Eclipse Kepler, Build id: 20130614-0229. To add a javadoc jar, go to Java build path settings, then the Libraries tab. Open any library, click the Javadoc location, then click Edit... Select Javadoc in archive, select Workspace file, select the docjar in Archive path. I agree that jars should not be in the SCM. This is an ant-based project and I want to get it working with Gradle without breaking ant. I'll have a hard time selling gradle in the company if it breaks the current build. |
Comment by Radim Kubacki [ 30/Sep/14 ] |
Although we do not support generating jar:platform:/resources/path/../file-javadoc.jar!/ we should be able to read a classpath file with this content and preserve it. A problem here is that our FileReference is not flexible enough and also our model in ToolingAPI only uses Files. To fix it we would need to extend these places to read those values and export them again. Optionally we can try to use this kind of URI for all javadoc files inside workspace as this would make .classpath file more portable. |
Comment by Dominik Stadler [ 22/Jun/15 ] |
FYI, this also fails for maven packages which do not provide javadoc jars when you try to add a web-URL as javadoc setting, either manually or via something like discussed at http://stackoverflow.com/questions/18518020/gradle-how-to-specify-javadoc-location-jar-file-for-maven-dependency |
Comment by Benjamin Muschko [ 15/Nov/16 ] |
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
Comment by Benjamin Muschko [ 10/Feb/17 ] |
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved. |