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.
The current form I18N support in 4.0 assumes all the resources (property files) are placed together with the java files in Sources and Test Sources. Even though it's the case for netbeans.org sources, generally it's not that way and resources are kept in other directory structures as well. the current ui doesn't support that usecase and renders the whole form internationalization support unusable. In my former job it was like that, there are voices on the nbusers describing the same problem and maven based projects for example, keep resources separate by default.
wrong way around.
P2 as is in form.
This belongs to i18n.
The modules should simply use ClassPath.EXECUTE. Whether that looks in another source tree or not is up to the project. *** This issue has been marked as a duplicate of 46354 ***
reopening, I don't believe these are duplicates. ClassPath.EXECUTE is fine to figure out if the prop file will end up in the jar and will be available on execution. However in the UI I believe one doens't deal with ClassPath instances. But rather Sources and SourceGroups.. IMHO resources should have thier own SourceGroup (not the curent ones - java nor generic)
I don't think I agree. CP.EXECUTE is specifically intended for this purpose. And JavaProjectConstants.SOURCE_TYPE_JAVA is intended for package-structured source roots, whether or not they happen to contain Java source files.
Created attachment 16868 [details] Sources or classpath?
In the attached png of the Bundle selection dialog, there are 3 roots. 1. are there really taken from Classpath? or rather Sources? I think Sources/SourceGroups but I haven't checked the code. 2. Shall the resources roots appear here as well? I think yes. that's what the bug is about. I agree that the resources should show up in the classpath for execution, so that they are accessible when running the app, but it's unrelated here IMHO. Maybe it's important for referencing the bundle using the NbBundle.getMessage() though.. raising to P2 again because I belive it needs to be addressed for 4.0.
The impl. for finding the roots now looks as ProjectUtils.getSources(prj).getSourceGroups("java"); The other type we might use is "generic". But would that make practically any difference? AFAIK there is no "resource" type of source roots. If there is no project type supporting it then this is hardly i18n issue - but rather something like issue 46354. ClassPath.EXECUTE would be also usable - it would allow to browse also to other things on classpath than sources (external JARs), which might be also desirable.
"generic" would be even more wrong than "java" since it doesn't reflect the actual location of the bundle file in the jar and it also would show too much unuseful stuff. (as far as I understand, it "generic" equals the project's root folder) IMHO if "resources" is not a supported sourcegroup then those needing this SG should drive it's adoption (eg. I18N), however I don't really care where this issue ends up, as long as it gets done. the jars on classpath idea is interesting however I'm not sure there's a real world usecase scenario. Unless one has all the bundles in a special separate place. But in general it would make the view cluttered, especially in projects that heavily rely on 3rd party libraries. (almost any webproject)
Milos, I don't understand what is the *fundamental* (defining) difference between, resouce-roots that you require and source-roots that are available, although not as freely as required by issue 46354. IMHO, resouce bundle is essentially a source, no matter that it's not in Java syntax. It's the same with images used in dialogs. In NB, they are stored in the same source tree, in some other project they aren't, but this does not influence their role in the project. They are just sources. Thus, I believe that this is a duplicate of issue 46354.
sources are processed at compile time, be it through java compilation, xdoclet or xslt processing etc. the result of these is used at runtime, not the sources themselves. resources are used at runtime and are not necessary at compile time nor processed in any way. These can be thought of as data for the program created from the sources. issue #46354 is not a duplicate because it deals with multiple source roots and compilation units, which has nothing to do with resource placement.
Well, yes to some extend. But they, besides being data, have to be created/edited by the user, so they can be alternatively thought of as sources (files created by users) processed by an identity compilation step. And as some people like to keep resources with sources, they have to be handled this way with the sources anyway (filetered, passed through). So I guess it's cheeper and more general (covering both use-cases) to conceptually unify sources and resources rather then separate them. To be more concrete, I understood that your problem is a directory structure like the following, where resources are in a separate branch. project src org ..... res icons bundles .... Right? If yes and provided that issue 46354 was resolved, what's wrong with making another source root named "Resources" rooted at directory res, where resources would be kept? Then such resources would be automatically accessible in the i18n's dialog and all other places dealing with files to be edited.
the problem is that the "java" Sources are used in other contexts in a different way, IMHO non-compatible with the I18N usecase. Eg. when creating a new Java file, one is offered the the Java Sources in the Wizard. For non-java files (eg. properties files that are also used by your I18N module) the generic Sources are used. 1. I don't want Resources to appear when I'm creating my java file, it's garbage at that time. 2. If my team's policy is to put resources in separate trees I don't want the IDE to offer me the Java sources trees when doing I18N. I want to be able to configure that for myself. So when reusing the "java" sources, in both cases the IDE is offering me unadaquate options. Plus one can have multiple resource trees. Eg. for local jboss testing deploy on a local machine and then different for a company wide deployment on a websphere server. Of course the bundles are kept in a yet another resources tree which is common for both. -> Both 1+2 can get quite cluttered that way with unrelevant information.
It depends on how percise you want the project infrastructure to be. You cannot make it such that it always offers what you want and hides what you don't. There are many users and many usecases. I'm forwarding this to projects and changing to RFE. This is not a bug, i18n behaves correctly with respect to the current project architecture.
I don't agree. Obviously you don't want to deal with it, but not being able to deal with property files in other places than Java Sources is a major deficiency and is crippling the product and usefulness of I18N.
and btw: this is hardly an enhancement. for users with existing forms originated from 3.6 where it was possible to have bundle files separately, it will not be possible to load the bundles (maybe after the classpath.EXECUTE change, it will) -> most probably a data loss. (I haven't tried) plus it will not be possible to further work with the bundles in original locations because the dialog shows just sources. the only known workaround is to copy everything into a single location.
So, what's the place you store resources in in a project , that isn't accessible from the i18n's dialog?
well, anywhere else than the Sources or Test Sources tree structures. Both Browse and New dialogs allow only these. Your suggestion to have another "java" source for the resources could be a solution (IMHO not ideal), but it's not in place yet. Or at least I have no idea how to do it. Jessy offers a build system solution for multiple source roots for the ant buildsystem, but also claims that UI will come later, I wonder if that has any implication on I18N UI then.
Is it within the project (and where) or just somewhere on the disc? I18n, as a client module cannot offer anything that isn't handled by the project.
yup, inside the project tree but not inside the java sources. your layout picture in one of the comments describes it quite well.
There is currently AFAIK no way i18n (or users) could access these files if they are not known to the project, i.e. located on source path, class path, or anywhere.
Jesse please, do something with that. Thanks.
As I said before, the i18n module should examine ClassPath.EXECUTE to determine which bundles will be available to the code at run time. That is what it is for. It should also try to use SourceForBinaryQuery to map some entries back to source folders (if they refer to build folders). What Java source groups are in the same project is irrelevant, though it may produce the same result as EXECUTE + SFBQ. The i18n module could decide to restrict the roots it displays to those which are in the same project as the source, or more simply (and probably more correctly) it could show only roots which are disk folders (not JAR folders), acc. to FileUtil.toFile, and (just in case) which are not marked as unsharable by SharabilityQuery. Re. having a "resources" type of source root - could be useful, so that templates for properties files etc. could be restricted to those roots. However in practice you also want to be able to make properties files, XML files, etc. in other places in a project (not package-structured). The current state is that you see generic roots for such files, which is probably best. I don't see any compelling need for this type of source root at the moment. (If you do, file separately.) Re. multiple source roots being hypothetical - not at all, you can do this right now with a freeform project. It is not supported for j2seproject's and won't be for 4.0.
*** Issue 47205 has been marked as a duplicate of this issue. ***
fixed according to Jesse's description. Now it's possible to add a directory or jar with resources bundles to the execution class path and these are accessible from i18n dialogs. CVS logs: http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/wizard/Util.java.diff?r1=1.11&r2=1.12 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/wizard/ResourceWizardPanel.java.diff?r1=1.25&r2=1.26 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/Util.java.diff?r1=1.6&r2=1.7 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/SelectorUtils.java.diff?r1=1.6&r2=1.7 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/ResourcePanel.java.diff?r1=1.14&r2=1.15 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/I18nUtil.java.diff?r1=1.33&r2=1.34 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/I18nString.java.diff?r1=1.6&r2=1.7 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/I18nPanel.java.diff?r1=1.24&r2=1.25 http://i18n.netbeans.org/source/browse/i18n/src/org/netbeans/modules/i18n/I18nManager.java.diff?r1=1.27&r2=1.28
verified. opened a separate issue #47828 for form I18N related problems.
reopening, I tried verifying the #47828 in build 20040826 and figured the UI changed. Jars on the execute classpath stay but the folders disappeared. It was working in build 20040823. A nice thing that I noticed is the replacement of subproject jars with their appropriate sources, however a more descriptive annotation for these is necessary (see attached picture showing the problem) While it's a good and correct idea to present the sources rather then built artifacts, it IMHO doesn't represent the true state of the the execute classpath, because the subprojects can also have bundles in non-source directory trees.
Created attachment 17199 [details] picture showing non-descriptive directory entries.
> Jars on the execute classpath stay but the folders disappeared. > It was working in build 20040823. I'm not aware of that. I still see both jars and folders (included as libraries). Could you describe precisely what folders you don't see? > While it's a good and correct idea to present the sources rather then > built artifacts, it IMHO doesn't represent the true state of the the > execute classpath, because the subprojects can also have bundles in > non-source directory trees. Even if not 100% accurate, in this way it's possible to edit bundles in subprojects, even create new ones, without leaving the dialog. This works very well with separate projects (JARs) for resources. And also in general the sub-projects needn't be built yet, so there's no jar to show. Showing JARs sometime and sources other times is not IMHO good. I'll try to fix the problem with sub-project source nodes.
...give them more descriptive names , I mean.
I don't see folders added to the project's classpath.EXECUTE that are not Sources.JAVA. the sources for subprojects is the recursive aspect of the same problem. The buproject can have folders on the classpath wich ar enot Sources.JAVA.
I see additional folders on execution classpath in the same project (see attached screenshots). It's true that such additional directories in subprojects are not accessible. But once again - showing created jars is not possible, as they in general don't exist. The problem here is that the SourceForBinaryQuery is not accurate. Currently, it returns just the java source directory of the project while it should return everything that contributes to the binary.
Created attachment 17216 [details] execution classpath in app1 - the master app.
Created attachment 17217 [details] bundle selection dialog correctly showing the "res" folder on execution classpath and incorrectly not showing the "res" folder on App2's execution classpath
ok, I'll double check my project's settings however I did run the exactly same project setup in 20040826 and then in 20040823 and the old one worked correctly. So something must have changed in the 3 days. Anyway, I let you know.
made inherited directory names more descriptive by annotating them with names of the projects they belong to and using source groups names instead of plain folder names if available.
Created attachment 17225 [details] screenshot with descriptive names