This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Project sharing is too aggressive wrt. javadoc | ||
---|---|---|---|
Product: | javaee | Reporter: | Petr Jiricka <pjiricka> |
Component: | Web Project | Assignee: | Trey Spiva <tspiva> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | phejl |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Petr Jiricka
2008-03-19 18:58:52 UTC
I would say "as designed" for 6.1. It's a trade off: size is bigger but everything just works. By just works I mean in NetBeans now; in NetBeans 9.0 in two years time; it is easy to import such a project to different IDE. In theory we could keep Javadoc inside IDE and provide it both for global and sharable libraries. Technical problem is that current libraries do not have any versioning so it is difficult to know what version shared library is without misc heuristics. JSTL should not distribute whole javaee5-doc-api.zip - that should be fixed. Regarding the technical problem - are you saying that the problem is that in NetBeans 9, this library will be bound to Javadoc for Java EE 7 (which will surely be supported by NetBeans 9), thus the documentation will be incorrect? I guess this is true, but I'd say that's a minor problem, because: - Java EE is backward compatible, so the user will still get at least the Javadoc for Java EE 5 (plus maybe some extras, but they can be filtered out if the user pays attention to the @since tags) - We already have this problem now, because when you create a J2EE 1.4 project, you get code completion for Java EE 5. We don't bundle J2EE 1.4 Javadoc in addition to Java EE 5 - it just isn't worth it. Or is there some other problem I don't see? Regarding the fix for JSTL - this would require splitting JavaEE5 javadoc, or extracting a part of it to a separate zip (thus duplicating the contents). phejl, does each server plugin provides their own Javadoc? pjiricka, I can see what you mean. My understanding is that server plugin implementation provides a Javadoc and we copy it as it is. Therefore we should not assume that is always just javaee5-doc-api and perform some heuristics and copy everything apart from javaee5-doc-api perhaps? JavadocForBinaryQuery impl for j2eeshared library type would have to be enhanced to add global javaee5-doc-api to result. It looks doable, I'm still not sure though it is worth the effort. Re. "JSTL" - it is already duplicating the content. Are you saying that it should not have any Javadoc? That would break the IDE and no Javadoc would be shown fopr JSTL stuff. What's the problem with packing content of <http://java.sun.com/products/jsp/jstl/1.1/docs/api/index.html> in zip file and distributing it with the library? I think that should be done regardless of this issue. Or are you saying that in IDE there is physically just one javaee5-doc-api.zip file which is used by both JSTL library and Glassfish server plugin and ... Yes, usually serverplugin provides the javaee5-doc-api (stored in the ide folder, however this fact is hidden and client of the server can't tell where is it taken from - in theory serverplugin can provide its own/modified javadoc). The user can also add its own javadoc to the registered server. When server library is created javadoc and sources (if any) are copied as well as they are part of the library. > When server library is created javadoc and sources (if any) are copied as well as they are part of the library.
This is exactly the questionable part - should they be copied to the shared location or not? Both solutions have pros
and cons, there is no clear answer.
I don't feel as strongly about this any more, downgrading to P3.
moving opened issues from TM <= 6.1 to TM=Dev There is no clear approach to resolve this issue. NetBeans.org Migration: changing resolution from LATER to WONTFIX |