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: | mobility/ant-ext includes Ant classes in the module JAR | ||
---|---|---|---|
Product: | javame | Reporter: | Jesse Glick <jglick> |
Component: | Build System | Assignee: | Adam Sotona <asotona> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | Keywords: | ARCH |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jesse Glick
2007-06-08 19:09:45 UTC
I can fix it this way but does it help when the module will still reference the Ant library in its classpath? Mobility-AntExt is a library used in other modules as well as headless Ant extension. What module references Ant in its classpath? (None should, since the user can pick an alternate Ant installation.) How do other modules use it as a library when its classes cannot even be resolved? The requred classes can be resolved and it works. Split into a library, an Ant task library and module would complicate headless usage. The library is designed to be used headless outside IDE. Simply by copying the module jar everything works. The same approach is for example used in ProGuard obfuscator library. It is a bundle of obfuscator libarary and its Ant tasks. After the split user would need to copy multiple library files and arrange on a new possitions. BTW what is netbeans.preresolve.classes=true good for? netbeans.preresolve.classes=true attempts to load every class in every module to see if it can really be resolved. It is correctly reporting that the Ant tasks in org-netbeans-modules-mobility-antext.jar cannot be resolved when loaded from the module class loader, because ant.jar is not visible to any module. That is, any attempt to refer to or load these task classes normally (from the module) would fail with a linkage error. The flag cannot, and does not attempt to, verify that classes are resolvable when referred to in other ways, such as from Ant or from manually constructed class loaders. I would still advise you to split apart the task classes into a separate JAR, as is done for every other collection of Ant tasks distributed with the IDE, but if you feel strongly that they must be present inside the module JAR then it would be possible to add an explicit exclude for classes matching a certain pattern. The split requires to create three jars instead of one. Headless build configuration requires two of them + one optional jar to arrange on the classpath manually. I recommend to ignore this small architectural exception as it cause no harm. |