Bug 3092 - Using $nl$ path in fragment (1GHHAH4)
Summary: Using $nl$ path in fragment (1GHHAH4)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.0   Edit
Hardware: All Windows NT
: P3 normal (vote)
Target Milestone: 2.0 M3   Edit
Assignee: Jeff McAffer CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-10 22:49 EDT by Vlad Klicnik CLA
Modified: 2002-02-06 22:02 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vlad Klicnik CLA 2001-10-10 22:49:18 EDT 
I am not 100% sure what the desired behavior should be, but have noticed that if I specify $nl$/ as my path in a fragment,
	and am running en_US locale, and have both nl/en/ plus nl/en_US/ directories with content, I only get a loader classpath
	entry for the nl/en_US/ directory (ie. the full locale specification). Should we not be constructing a search path that includes
	all the valid locale variations for my current locale?

NOTES:
Comment 1 Debbie Wilson CLA 2002-01-29 09:00:54 EST 
If you have $nl$/ specified as a path in your fragment, and the current locale 
is en_US we will now look for this library in the following locations:
<plugin root directory>/nl/en/US/
<fragment1 root directory>/nl/en/US/
<fragment2 root directory>/nl/en/US/
<fragment3 root directory>/nl/en/US/
...
<plugin root directory>/nl/en/
<fragment1 root directory>/nl/en/
<fragment2 root directory>/nl/en/
<fragment3 root directory>/nl/en/
...
<plugin root directory>/
<fragment1 root directory>/
<fragment2 root directory>/
<fragment3 root directory>/
...

where the fragments are in no particular order.