Bug 369296 - [nls tooling] Externalize Strings cannot use src/main/resources
Summary: [nls tooling] Externalize Strings cannot use src/main/resources
Status: CLOSED MOVED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: m2e (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate, needinfo
Depends on:
Blocks:
 
Reported: 2012-01-20 16:39 EST by Stephen Cooper CLA
Modified: 2021-04-19 13:26 EDT (History)
10 users (show)

See Also:


Attachments
I was able to re-create the issue using this non-maven project (4.12 KB, application/zip)
2012-01-21 12:24 EST, Stephen Cooper CLA
no flags Details
Maven managed project which demonstrates the issue (12.86 KB, application/zip)
2012-01-21 13:22 EST, Stephen Cooper CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Cooper CLA 2012-01-20 16:39:58 EST
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149

I have a maven project which uses standard directory structures of src/main/java and src/main/resources.

I want my messages.properties file to be generated in src/main/resources instead of the default src/main/java.

When I press "Configure..." and try to change the source folder for the property file location to src/main/resources, I get the message "The specified package for the resource bundle is invalid".

Yes, there are work-arounds which involve moving the messages.properties file back and forth between the src/main/java and src/main/resources directories, but I feel that this is something Eclipse should support out of the box.

I'm using the m2e plugin to manage my project configuration.

Reproducible: Always

Steps to Reproduce:
1. Select a project which is managed by maven/m2e plugin.
2. Select Source->Externalize Strings...
3. Select a class with strings to externalize
4. press Externalize...
5. press Configure...
6. Change the source folder for the property file location to src/main/resources
7. Get the message "The specified package for the resource bundle is invalid".
Comment 1 Olivier Thomann CLA 2012-01-20 16:55:13 EST
Move to JDT/UI
Comment 2 Stephen Cooper CLA 2012-01-20 17:13:30 EST
I created a non-maven project with two source folders - src/main/java and src/main/resources - and was able to re-create the issue. So it has nothing to do with the m2e plugin.
Comment 3 Deepak Azad CLA 2012-01-21 10:38:39 EST
(In reply to comment #2)
> I created a non-maven project with two source folders - src/main/java and
> src/main/resources - and was able to re-create the issue. So it has nothing to
> do with the m2e plugin.

I am unable to reproduce the issue. Can you please attach your non-maven project here. Thanks!
Comment 4 Stephen Cooper CLA 2012-01-21 12:24:36 EST
Created attachment 209872 [details]
I was able to re-create the issue using this non-maven project
Comment 5 Stephen Cooper CLA 2012-01-21 13:17:52 EST
I have some additional information which may be of use.

* Using the supplied non-maven project, if the package does not already exist under src/main/resources, then I get the error.
* Using the supplied non-maven project, if I first create the package org.eclipse.externalization under src/main/resources, then I do *not* get the error.
* Using my maven controlled projects, I *always* get the error.
* If I create a package under src/main/resources in my maven project, it appears as a nested set of folders.
* If I create a package in the supplied test case project, it appears as a single line with a package icon next to the name.

These are my thoughts on the issue, and I may be way off base since I haven't looked at the Eclipse code for this other than one or two classes.

* I believe that one key aspect is that with maven controlled projects, the packages appear as folders, not as packages in the UI. So Eclipse doesn't view them as being packages and the externalization doesn't work. 
* I believe that for the non-maven projects, I could file a feature request that if the package doesn't already exist under the chosen source folder, it should create one.

I'll try to attach a sample maven project which has this issue.
Comment 6 Stephen Cooper CLA 2012-01-21 13:22:58 EST
Created attachment 209873 [details]
Maven managed project which demonstrates the issue

I have created a maven project which consistently demonstrates the inability to customize the externalization of strings to src/main/resources.

Notice in the Eclipse UI that the src/main/resources/org/eclipse/externalization package appears as a nested set of folders under src/main/eclipse. I believe this is important to resolving the issue.
Comment 7 Stephen Cooper CLA 2012-01-21 13:25:28 EST
Sorry - minor correction to above:
"... appears as a nested set of folders under src/main/resources."
Comment 8 Stephen Cooper CLA 2012-01-21 13:39:26 EST
I believe I have found the root cause of the issue.

* Maven controlled projects put an exclusion pattern of "**" on the resource directories. This is intentional according to https://issues.sonatype.org/browse/MNGECLIPSE-784
* With the supplied non-maven test project, I am able to reliably re-create the issue by adding an exclusion pattern of ** to the src/main/resources folder.
* With the supplied maven test project, I am able to work around the bug by removing the exclusion pattern to the src/main/resources folder.

So, there is a work-around but I still feel that this should work, even with maven projects.

Please let me know if you would like me to create a separate enhancement request to address creating a package if none exists under the chosen source folder.
Comment 9 Stephen Cooper CLA 2012-01-21 13:41:43 EST
See also: 
https://docs.sonatype.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-WhyresourcefoldersinJavaprojecthaveexcluded%3D%22%22

for why resource folders have a ** exclusion.
Comment 10 Samrat Dhillon CLA 2012-02-21 19:57:08 EST
(In reply to comment #2)
> I created a non-maven project with two source folders - src/main/java and
> src/main/resources - and was able to re-create the issue. So it has nothing to
> do with the m2e plugin.

If I have understood correctly I do not think there is any issue here. I used the non-maven project the was attached. I think this is what is happening here:
1. Click on Externalize Strings opens Externalize Stirngs Dialog.
2. Click on configure to open the
Comment 11 Samrat Dhillon CLA 2012-02-21 20:01:56 EST
(In reply to comment #10)
> (In reply to comment #2)
> > I created a non-maven project with two source folders - src/main/java and
> > src/main/resources - and was able to re-create the issue. So it has nothing to
> > do with the m2e plugin.
> 
If I have understood correctly I do not think there is any issue here. I used
 the non-maven project that was attached. I think this is what is happening here:
 1. Click on Externalize Strings opens Externalize Stirngs Dialog.
 2. Click on configure to open the configure Accessor class
3. Change the property file location name to "/src/main/resources" source folder
Note: The package for the property file is already defaulted to org.eclipse.externalization. 

This package "org.eclipse.externalization" does not exists in "/src/main/resources" and hence eclipse complains about package for the resource bundle being invalid. If you create a package "org.eclipse.externalization" in "/src/main/resources" source folder, you wont get this message.
Comment 12 Stephen Cooper CLA 2012-02-21 22:56:16 EST
Unfortunately, you are incorrect in assuming that creating the package folder beforehand resolves the issue.

I made a Quicktime movie/screencast which demonstrates the issue I'm having. I hope that this helps. The movie includes sound of me talking & explaining what I'm doing. Download the movie from here: http://dl.dropbox.com/u/45460700/EclipseScreenSnapz001.mov

If needed, you can download Quicktime from http://apple.com/quicktime - however it is included with iTunes on Windows, or if you're running a Mac it's in the OS already.
Comment 13 Stephen Cooper CLA 2012-05-04 14:27:41 EDT
Any update on this issue? It is still a problem.
Comment 14 Dani Megert CLA 2012-05-07 04:39:19 EDT
I looked at your movie and the test project. What you see is expected. The wizard (and plain Java) expects that one specifies a valid Java package. One cannot specify a folder which is not on the build/class path. Since you excluded everything below 'src/main/resources' from the Java build path, nothing in there will be a valid Java package and hence you can't point to it. If we'd allow such a setup/generation, then the resulting project would not work with pure Java.

Comment 4 and comment 5 indicate what could be considered an enhancement i.e. we could allow to specify a not-yet existing package and generate it when running the wizard. We could also improve the error/warning messages (e.g. package 'xyz' does not yet exist and will be generated). Filed bug 378629 to track that. This however, would still not fix your Maven case, because no valid package can be created in that setup.
Comment 15 Stephen Cooper CLA 2012-05-07 10:38:59 EDT
It is the Eclipse Foundation provided m2e plugin (which allows for Maven projects to work nicely in eclipse) which adds the exclusion filter to the resources source folders.

It is *not* the end user. In fact, it took me about a year to find out what was the root cause of this.

What we have here is two different Eclipse Foundation projects (NLS and Maven support) which are incompatible, and the end-user is left scratching his or her head and is stuck with a rather poor workaround.

If the NLS team and the Maven team were to talk about this issue then perhaps a simple solution could be found.

This is an incompatibility between two Eclipse Foundation plugins, not a user error. Please fix this.
Comment 16 Dani Megert CLA 2012-05-07 10:41:09 EDT
As said, JDT knows nothing about Maven. Moving the M2E can change something in how they setup things, or provide special tooling to NLSing.
Comment 17 Igor Fedorenko CLA 2012-05-07 12:10:04 EDT
Just to confirm observations from comment #14 -- src/main/resources is NOT a 'true' java source folder and therefore java-specific tools are not expected to work there. This is the case for command-line build and inside Eclipse workspace.

I also think it is a fair enhancement request to provide Maven-specific NLS tooling, but m2e development teams does not have immediate plans to work on this unless somebody contributes a quality patch.
Comment 18 Stephen Cooper CLA 2012-05-07 12:26:47 EDT
Another possible solution would be to find a different way to accomplish the goals outlined in https://issues.sonatype.org/browse/MNGECLIPSE-784

I.e. provide maven-like resource filtering in a fashion other than with a ** excludes pattern for resource folders.
Comment 19 Dani Megert CLA 2012-05-08 02:28:33 EDT
(In reply to comment #18)
> Another possible solution would be to find a different way to accomplish the
> goals outlined in https://issues.sonatype.org/browse/MNGECLIPSE-784
> 
> I.e. provide maven-like resource filtering in a fashion other than with a **
> excludes pattern for resource folders.

Is it dictated by Maven that the NLS files are in 'src/main/resources'? If not, just put them into the real packages.
Comment 20 Ondrej Medek CLA 2013-02-20 09:10:01 EST
I think the solution would be to allow Eclipse NLS to set any resource bundle file location, even if it's not an Eclipse resource. That's for string externalization and for hints, too. (For hints it would be nice to have more file locations.)

E.g. we have a Maven build which merges multiple resource bundle files into one file in the target/merged_rb.properties directory. So, when a developer starts String externalization, she would choose a properties file for her class. But we would like to have a per project setting where we set the file target/merged_rb.properties for hints and code assistant.

BTW. 3rd party PropertiesEditor plugin handles hints and code assistant well - it reads all *.properties files.
Comment 21 Corneliud Dirmeier CLA 2018-01-05 10:42:53 EST
Just had the same issue and cannot believe that nobody seems to use the external String tool with maven.

@Dani Megert: seems like you do not know maven very vell so: yes maven does "in some way" dicated that the resources are *NOT* located in the same directory because it gets very ugly to mix java files and other resources. That's why there are dedicated folders for src/main/java and src/main/resources. Maven by default compiles everything in src/main/java and copies every resource from src/main/resources. But it is not useful to configure maven that it also copies resoruces from src/main/java.

I did not read all the reasons why m2e needs to configure the exclusion of ** in src/main/resources. But why just implement a warning that the selected resource seems to be not in build path and let the user deside wether he want to select a folder that is excluded from java build path. In the end the folder does exists on the specified location and the error "The specified package for the resource bundle is invalid" is not clear (yes it is no package, its a folder - but what is technically the difference between package and folder)
Comment 22 Mickael Istria CLA 2021-03-30 05:33:36 EDT
Eclipse m2e is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse-m2e/m2e-core/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest Eclipse Platform and m2e release
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present when latest release:
* Create a new issue at https://github.com/eclipse-m2e/m2e-core/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed next week or so. Then the m2e component for m2e will be made read-only.
Comment 23 Mickael Istria CLA 2021-03-30 05:39:17 EDT
Eclipse m2e is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse-m2e/m2e-core/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest Eclipse Platform and m2e release
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present when latest release:
* Create a new issue at https://github.com/eclipse-m2e/m2e-core/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed next week or so. Then the m2e component for m2e will be made read-only.
Comment 24 Daniel Schwering CLA 2021-03-31 02:53:08 EDT
Migrated to https://github.com/eclipse-m2e/m2e-core/issues/139
Comment 25 Denis Roy CLA 2021-04-19 13:26:58 EDT
Moved to https://github.com/eclipse-m2e/m2e-core/issues/