I have a GUI form with strings coming from a ResourceBundle ("set text property using" -> Resource Bundle).
Every time I edit my form graphically, the bundle name is lost. Key and value properties are retained, but the
initComponents() method doesn't mention them.
Sorry but I cannot reproduce it. Tested on RC2 candidate.
I need more information like which project do you use (simple j2se, or Java Desktop Application). Did you switch on auto
i18n in form or you just set resource management manually for each component?
Please provide exact steps how to reproduce it. Thanks
It's a simple j2se project; i'm not aware of auto-i18n so it has its default value (inactive, I suppose?). I have
manually set each component to use a resource bundle in the execution classpath for the project (out of rhe source
tree). I have two language files for the resource bundle, default and italian; the os is english, so the default file is
The resource setting is lost when I open the form for editing.
I can reproduce the behaviour in a new project (still using RC1) - I will create an attachment.
Created attachment 60338 [details]
nb project missing resource bundle
It seems that package with resource bundle is not on classpath therefore bundle "string" is not found. You have to add
"res" directory as a source in project's properties. Does it work for you ?
I tested it on RC2 and everything works.
Yes, it does work if I add the 'res' folder to the project sources, but it seems a bit strange to me: why does it have
to be in the source tree? I had added it to the runtime classpath of the application (via Properties/Libraries/Run)
which seemed more logical.
The property editor for the "text" property of the label lets the user choose from the execution classpath (as I
expected), so it seems a bit incongruous that the form editor searches only the source tree when opening a form.
firstly, when I open your project, I have to resolve problem that the file was not found. Seems that there is filled
absolute path which is no more valid in my workspace.
secondly, bundle is not library so why did you add it there
Finally Bundle should be set as source otherwise form is not able to work with it. Therefore I have to close this bug
I think that the problem with the absolute path is due to the fact that I have mistakingly included the
nbproject/private folder in the sample project I have attached - deleteing it before opening the project removes the
I have used the Libraries tab in the project properties because I wanted to configure the runtime classpath - even if it
says "Libraries", that's what it does.
The fact that the resource bundle has to be set as source is precisely what I consider to be a bug: if this is
necessary, then the IDE shouldn't allow to choose properties files from elsewhere. The whole runtime classpath is
available when the user chooses the file: this is not coherent.
I'm 90% sure this used to work just fine in 5.0 and 5.5, but not in 6.0 or 6.1
GUI editor will not allow me to select text properties from anything under Libraries.
However, it will let me select other resources, eg images/icons.
Created attachment 61334 [details]
First two screens show selecting an image which allows Library paths, second two show selecting a string, library paths are not included.
First of all, there is an important difference between name/value pairs in
a resource bundle and icons. Icons (e.g. individual graphic files) are not
editable in GUI builder. Hence, there is no problem to load them from
read-only locations (like JARs on classpath). The internationalized strings
are editable in GUI builder e.g. if the text is modified then
the corresponding name/value pair is updated. This is not possible,
if the resource bundle is not among sources.
There are several issues mixed in this report.
The GUI builder doesn't support setting of internationalized
strings from resource bundles in JARs on execution classpath
(e.g. from read-only locations). This is hardly ever needed,
but it may be a valid request in some special cases.
This is definitely an enhancement - the GUI builder
was never designed to support that, but it would be nice.
In your case, the resource bundle is not in a JAR file,
but in a separate directory. It doesn't have a sense
to put this directory on execution classpath instead
of source path. Where do you expect to deploy files
from this directory? Note that they are not packed
into the resulting JAR file when the project is built
e.g. you cannot execute the built project using
java -jar your.jar Hence, I believe that your project
is not configured correctly.
The last issue is that the GUI builder allowed you to specify
'strings' resource bundle from your 'res' directory,
but is unable to work with it. This is a defect, of course.
But the root of the defect is the fact that the GUI builder
offered you the 'strings' bundle in 'res' directory
(the corresponding dialog should offer resource bundles
on source path only). The lost assignment (you mentioned
in this report) is just a consequence of this fact.
Summary: leaving this issue as a defect that is about
not offering resource bundles outside source path. Feel
free to file an additional enhancement about support
of resource bundles in JARs on execution classpath.
The considerations about resource bundles in jar files followed this thread on the nbusers maling list:
I agree with your comments and with your summary, with a few observations that
might lead to some enhancement requests.
I would prefer the ide to handle correctly resources (icons, .properties
files, etc.) outside the source tree: properties defined in read-only
locations might be simply shown as read-only in the ide.
Putting a resource directory on the execution classpath instead of source path
can be useful in some situations: in my case I want to let my users edit
these files, so I don't want to pack them in a jar archive.
Another small observation: in the future an icon-editing plugin might let
users modify the icons: that would raise for image files the same problems
you are pointing out about resource bundles. I think that treating all types
of resource files in an uniform way would add more flexibility.
In general, I think it should be more clear to users which files are visible
during editing in Matisse: source tree only? runtime classpath? some of both
depending on the file type?