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.

Bug 65769 - Do not allow duplicate bundle file for wrapper module
Summary: Do not allow duplicate bundle file for wrapper module
Status: RESOLVED WONTFIX
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: rmichalsky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-03 22:09 UTC by Rochelle Raccah
Modified: 2009-11-23 13:58 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rochelle Raccah 2005-10-03 22:09:59 UTC
From a post on the alias:
Say I have a jar file and want to create a library wrapper module for it.  Say
there is just one package in the module:

mycompany.mypackage.mymainpackage

This is the default module name that is suggested to me in the library wrapper
module wizard - great.  The bundle is set up to be:
mycompany.mypackage.mymainpackage.Bundle and that's where the name of the module
is stored.  There will be a mycompany/mypackage/mymainpackage/Bundle.properties
created with this project.  Fine so far.

My question is, what if the original jar already has a Bundle file in this
location?  Is this a problem?  If so, shouldn't the wizard suggest something
else (or warn that there will be a conflict)? 

Jesse's response:
Yes, it should probably suggest a different Bundle.properties path. Feel free to
file a bug for it.
Comment 1 Milos Kleint 2005-10-04 07:21:46 UTC
The wizards are there to generate code quickly, help people get going. IMHO
these cannot and should not handle all real life setups that can possibly
happen. Given that the chance of this usecase to happen is rather small in my
opinion, I suggest lowering the priority to P4 or P5.


Comment 2 Jesse Glick 2005-10-04 17:48:51 UTC
Should handle situations which are well-defined, though - if the wizard
generates something which is demonstrably not going to work, that's a bug (of
some priority).

P4 is reasonable given that it is not likely an existing lib will in fact
Bundle.properties in that location, since this naming convention is from NB
modules, and it is a pretty odd case to have something which looks like a NB
module in terms of filenames yet isn't one.
Comment 3 Rochelle Raccah 2005-10-07 00:12:17 UTC
What is odd/NB specific about having a jar file which contains code and a 
Bundle.properties in the same package?
Comment 4 Jesse Glick 2005-10-07 22:06:26 UTC
The name "Bundle.properties" is a NB-specific convention, not in general use
that I know of.
Comment 5 Rochelle Raccah 2005-10-07 22:10:06 UTC
It is used in glassfish as well -  I don't think it's an NB convention.
Comment 6 Jesse Glick 2005-10-07 22:11:57 UTC
Used in glassfish by people who used to work on NB modules, perhaps?
Comment 7 Rochelle Raccah 2005-10-07 23:05:04 UTC
Maybe - I'll ask.  But if NB itself suggests this as a properties file name in
j2seprojects, then my point is still valid.  Does it?  How about in i18n of forms?
Comment 8 Jesse Glick 2005-10-07 23:23:35 UTC
j2seproject does not do anything special with *.properties files. If the i18n or
i18n-form modules specifically suggest "Bundle" as a filename, please file a bug
report in the i18n component (since it's not really a great convention to begin
with), but I do not believe they do.
Comment 9 Martin Krauskopf 2008-02-07 17:50:35 UTC
I'm not working on APISupport anymore. Reassigning to owner of the component, so
the issue is not 'forgotten' forever.
Comment 10 rmichalsky 2008-11-24 15:10:41 UTC
Not into 7.0 or next release. Feel free to reopen if more important than it seems.
Comment 11 Quality Engineering 2009-11-02 10:57:16 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX
Comment 12 Jesse Glick 2009-11-23 13:58:14 UTC
Probably still valid, but too low priority to bother with.