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 49113 - [40cat] select resource bundle in Internationalize... not showing code bases
Summary: [40cat] select resource bundle in Internationalize... not showing code bases
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: RELNOTE
Depends on:
Blocks:
 
Reported: 2004-09-15 17:25 UTC by shemnon
Modified: 2004-09-17 15:49 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
patch proposal (1.99 KB, patch)
2004-09-16 12:00 UTC, David Konecny
Details | Diff
Better patch (8.68 KB, patch)
2004-09-16 19:50 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description shemnon 2004-09-15 17:25:54 UTC
[ BUILD # : q2040910 ]
[ JDK VERSION : J2SE 1.5.0 ]

In the tools>Internationalize>internationize... dialog, the browse... button for bundle name does not show the acutual code bases for the project, but instead shows the classpath for the project.  This is a break since Beta 1, and makes the internationalization dialog completely useless.

Project is a free-form project, that seems to matter a lot.

Either fix it or add it to the "not implemented for this release" list and remove it.
Comment 1 pfelenda 2004-09-16 08:41:46 UTC
I tried reproduce it and it doesn't work for me too.
I play with config files and now it works for me.

Workaround is :
Add the source directory to classpath.

Steps:
- Open project properties in Project tab
- Select "Classpath" item from Project properties dialog
- Add folder - your source directory
The browse button for bundle name shows the source tree with bundles.
Comment 2 Marian Mirilovic 2004-09-16 11:13:49 UTC
Danno thanks for report, it seems like you are right.

Just to be sure steps to reproduce: 
- open freeform project
- don't add source root at the classpath
- try to Internationalize some java class from the source folder
-> there is no source root on the I18N Resource wizard 

As David mentioned, it seems like something is broken on freeform
project side...

David, please look at this, thanks in advance.
Comment 3 David Konecny 2004-09-16 11:31:03 UTC
This worked for Beta1 because it had been built before issue 47206 was
fixed.

Now it is broken because EXECUTION classpath (when not explicitly
specified in project.xml what is usual case) is equal to COMPILATION
classpath which does not contains sources (line 393 in
org.netbeans.modules.ant.freeform.Classpaths.java). Fix I guess should
be matter of adding all source roots to the classpath. I will look at
that.
Comment 4 David Konecny 2004-09-16 12:00:02 UTC
Created attachment 17684 [details]
patch proposal
Comment 5 David Konecny 2004-09-16 12:03:59 UTC
Attached is patch which solves the problem. I wait for Jesse to hear
his opinion.

Re. "// XXX but add built-to dirs" comment in the
createExecuteClasspath() method: once this is implemented and there is
a built-to file specified, the source packages can be omitted from the
EXECUTION classpath, right?
Comment 6 Marian Mirilovic 2004-09-16 12:15:52 UTC
Ok, 
David thanks .

Do we want fix for Beta2 ?
- it's regression against Beta 1
- reported as P1 by one of the NetCAT participant
Comment 7 David Konecny 2004-09-16 12:21:32 UTC
The patch is trivial and should not have any sideeffect, but this part
of freeform was implemented mainly by Jesse so he has the last word.
Comment 8 Jesse Glick 2004-09-16 16:03:25 UTC
The patch is wrong. EXECUTE should not contain sources, it should
contain built-to dirs as mentioned in the comment. The
internationalize dialog should be mapping these back to the sources
indirectly. I don't have a strong opinion about putting the current
patch into beta2 - if it solves the problem easily, may be OK - but it
is not correct and should be fixed properly in the trunk.

I will see if I can fix it in conjunction with issue #47807.
Comment 9 David Konecny 2004-09-16 16:34:01 UTC
"EXECUTE should not contain sources, it should contain built-to dirs
as mentioned in the comment." - technically this is more correct. But
practically if you do not specify output jars (which is optional step)
the I18N will not work. 

Can it have a negative sideeffect having sources on the EXECUTE
classpath? AFAIK, this classpath is not used by Freeform for anything.
Also we talk about case when there is no explicit EXECUTE classpath
specified in project.xml and we are trying to guess some. From this
point of view some incorrectness seemed acceptable to me. One
improvement I had been thinking about (for trunk) was to check
<built-to> and if something is presented return it instead of sources. 
Comment 10 Jesse Glick 2004-09-16 18:02:22 UTC
Yes, I would probably include the source dir in case no <built-to> was
specified, as a fallback.
Comment 11 Jesse Glick 2004-09-16 19:09:53 UTC
Sorry, this is unrelated to issue #47807, I was confused.
Comment 12 Jesse Glick 2004-09-16 19:49:25 UTC
I have a better patch that also uses <built-to> if available. Not too
complicated, seems to work.
Comment 13 Jesse Glick 2004-09-16 19:50:41 UTC
Created attachment 17700 [details]
Better patch
Comment 14 shemnon 2004-09-16 21:53:44 UTC
Ok, I don't know much about the internals of the project source, but
should we be looking for the soruce folders and not the runtime
folders?  Internatnionalize... will need to change the _sources_ for
those messages, it's not reading the value from the results.

I.e. data from project/configuration/general-data
/folders/source-folder/location or
/project/configuration/java-data/compilation-unit/package-root, and
not data from class-path or build to, which are not source files but
output files.  

Also, this breaks the text editor in resource bundle mode for setting
fields in the form editor.  looks like they use the same panel.  This
is a very signifigant regression now, internationalize... may have
been used by very few but this dialog is seen a lot more often in
internationalizing GUIs.

I don't want any of the junk from execute classpath, or other class
paths.  IMHO the only folders that should be shown (as was the case in
beta 1) are the source folders listed in the create wizard and the
customizer as source folders.  My look at the patch #2 seems to
indicate that I will see all of the classpath entries (which won't be
editable anyway).
Comment 15 shemnon 2004-09-16 22:13:46 UTC
Ok, I read BUG 47206 and now see that some people want to mount random
jars, but this was done at the expense of source jars.  The rationae
was quite myoptic, because at my company, and at several open soruce
projects resource files are kept in the java source trees.  The more
appropriate fix for that would have been in my opinion to have the
user add the resources tree to the source.

Perhaps the solution should be for the resource bundle to look at
source classpath and execute classpath, with source classpath first
(since this is the more common usage pattern).  Trying to find the
source dir for imported jars doesn't seem right to me, the sorce dirs
as specified in the project should be first class citizens since one
of the essential features of that panel is the ability to create new
resource keys and values into the properties file.
Comment 16 Jesse Glick 2004-09-17 03:46:07 UTC
Danno - I think you misunderstand. The internationalize dialog takes
the execute classpath, then tries to map entries back to source dirs
where possible. When you have the built-to dirs/JARs listed in the
execute CP, then it maps them back to the source dir, as desired. This
is used by other things too, like the background error compiler, etc.
This patch simply makes the freeform project behave like the other
project types do already.

committed   * Up-To-Date  1.10       
ant/freeform/src/org/netbeans/modules/ant/freeform/Classpaths.java
committed   * Up-To-Date  1.10       
ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/ClasspathsTest.java
Comment 17 Marian Mirilovic 2004-09-17 06:57:48 UTC
Jesse, 
is the fix safe ?  What do you think about fixing this for Beta 2 ?
Comment 18 David Konecny 2004-09-17 08:43:59 UTC
I reviewed new patch and it looks OK.
Comment 19 Jan Chalupa 2004-09-17 12:37:13 UTC
Don't fix for Beta 2. Too late, no time to verify the fix. It's
already in trunk, so the final relase will get it.

For Beta 2 workaround exists: "Add the source directory to classpath."

We may want to release note this. Is it just the I18N feature? Are
there any other scenarios where this bug can manifest itself?
Comment 20 shemnon 2004-09-17 15:27:17 UTC
It also affects at least the String customizer and int customizer in
the  form.  For String it's the ResourceBundle mode and int the two
Internationalized modes.

So this will be in the Sep 21 Q build once promoted?
Comment 21 Jan Chalupa 2004-09-17 15:49:41 UTC
There won't be a Q-build on Sep 21. We're in the Beta 2 stabilization
mode now and all test cycles are spent on that.

Unfortunately, Beta 2 was branched before Jesse's fix, so it won't
include it. The fix will be available in the daily dev builds.