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: | jaxb-osgi.jar and webservices-osgi.jar added to the v3 library when creating a shared project | ||
---|---|---|---|
Product: | serverplugins | Reporter: | Petr Jiricka <pjiricka> |
Component: | GlassFish | Assignee: | Milan Kuchtiak <mkuchtiak> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | dkonecny, mkuchtiak, phejl, vkraemer |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Petr Jiricka
2009-07-21 18:49:43 UTC
It looks like this is due to http://hg.netbeans.org/web-main/rev/7227c77db315... mkuchtiak: please advise or correct This is due to shared library mechanism, where all jars specified in J2eePlatformImpl implementation (J2EE Server plugin), getToolClasspathEntries method (for all tools) are added to "dedicated" library folder. This is done, regardless the tool is ever used in project or not. In this particular case, there are jar files needed for wsgen tool and wsimport tool. The mechanism isn't good. In fact the dedicated library folder contains the superclass of all jar files specified for all tools. Reassigning to dkonecny to evaluate. So if I understand it correctly, these jar files *may* be needed sometimes to build the project, right? In such a case,
they actually *should* be in the server library - otherwise the project would not be buildable from commandline. The
question is, do we really need 14.6 MB of jar files just to run wsgen and wsimport? I don't believe all these classes
are needed. I would say the right solution should be to divide the two jar files into "dev" and "rt" parts. Only the
"dev" would be needed at build time, and "rt" would be used at runtime. I suspect these "dev" jars would be much smaller
than the current big jars.
> library folder contains the superclass
I think you meant to say "superset".
Yes, I meant superset of course. This is one solution for web services, though this will not solve the generic problem. But anyway, who can split webservices.jar and jaxb.jar to smaller parts ? I doubt GlassFish team has motivation for that. I don't have anything to add - preferably jars should be smaller. I've got an idea how to solve this for wsimport, wsgen : - clean up the library list from J2eePlatformImpl:getToolClasspathEntries() method - use JAX-WS stack framework - create programmaticaly, on demand (e.g. when WS Client is generated) a specific Netbeans library(e.g. ServerJaxWsLib) - use this specific library in ant tasks, instead of jar list specified in J2eePlatformImpl:getToolClasspathEntries() Hopefully this will work Reassigning back to myself. I cannot do much with this issue. Did some improvements : used WSStack instead of J2eePlatformImpl:getToolClasspathEntries(). My idea of creating JaxWS_GlassFish library (JAX-WS library taken from server jars) is not good because of shareability. |