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: | Target not supported in readers | ||
|---|---|---|---|
| Product: | obsolete | Reporter: | Petr Jiricka <pjiricka> |
| Component: | jarpackager | Assignee: | issues@obsolete <issues> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | CC: | mbalin |
| Priority: | P1 | ||
| Version: | -FFJ- | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 20387 | ||
JarCreater creates a member set from the jar content's content list. It loops through the content member set, and sees if the members are data folders and recurses to add the children. It wasn't allowing multiple names to be created because of a hash map. Now it is allowed. Need to test and verify that this is now working correctly. Verified in main trunk Verified in orion_fcs Resolved for 3.4 or earlier, no new info since then -> closing. Resolved for 3.4 or earlier, no new info since then -> closing. |
This was originally submitted as issue 20387. in recent revisions to the jar packager, support for ContentMember.{s,g}etTargetName was added. The tag library jar creation functionality relies on this feature, since it must place a tag library jar into both META-INF/<filename>.tld and META-INF/taglib.tld, so it must set the target name on the content member. However, ContentMember's saveDataObject and restoreDataObject methods do not do anything with the target name. They will need to save and restore the target name as well.