Bug 125454 - I18N - Absolute path localzed jar files are registered in library.
I18N - Absolute path localzed jar files are registered in library.
Status: STARTED
Product: obsolete
Classification: Unclassified
Component: visualweb
6.x
All All
: P3 (vote)
: 6.x
Assigned To: _ potingwu
issues@obsolete
JA_COMMUNITY
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-17 08:34 UTC by Kenji Tachibana
Modified: 2008-03-31 08:23 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
snapshot for added localied library (13.72 KB, image/png)
2008-01-17 08:39 UTC, Kenji Tachibana
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kenji Tachibana 2008-01-17 08:34:30 UTC
When I create the Visual Web JSF project by using 6.0.1 ML version, 
following localized jar files are included in 'Library' with 
absolute path. But, it's should be the relative path from installation root dir,
the same as the other included jar files.

jsfcl_<LANG>.jar
dataprovider_<LANG>.jar
sqlx_<LANG>.jar
webui-jsf_<LANG>.jar
webui-jsf-suntheme_<LANG>.jar

For example in Japanese env, jsfcl_ja.jar is registered in Library as
    /opt/netbeans-6.0.1/visualweb1/modules/ext/locale/jsfcl_ja.ja.

But, it should be relative path like as follows:
    jar:nbinst:///modules/ext/locale/jsfcl.jar!/

To reproduce:

1. Create Visual Web JSF project in Japanese locale.
2. Check 'Library' in left pane. 
3. jsfcl_ja.jar, dataprovider_ja.jar, sqlx_ja.jar,
   webui-jsf_ja.jar, webui-jsf-suntheme_ja.jar
   is included in Library, with absolute path.
Comment 1 Kenji Tachibana 2008-01-17 08:39:41 UTC
Created attachment 55184 [details]
snapshot for added localied library
Comment 2 _ potingwu 2008-01-18 17:35:15 UTC
Visual Web is using API from the web core for adding these jar files. The API should handle this instead of the caller.
I will investigate this further.
Comment 3 _ potingwu 2008-01-18 21:24:28 UTC
It's an invalid bug! When you see the absolute path under the Libraries panel, they are presented by the IDE how it
found them. But you can check the project files, project.properties/project.xml/build-impl.xml, all use 
${file.reference.*_ja.jar}.

BTW, you will never see 'jar:nbinst:///*' from the Libraries tab. The IDE will only show the real absolute paths it found.
Comment 4 Kenji Tachibana 2008-01-21 04:48:47 UTC
Thank you for your evaluation. 
I could understand the root cause.

As you said, the setting for _ja.jar is the same as the other libraries. 
So, if I removed private/private.properties in the project and re-open it,
it seems that private.properties re-generated properly.


Comment 5 Kenji Tachibana 2008-01-21 09:33:03 UTC
Hello Again,

I would like to re-open this issue, because the issue is that private/private.properties
are not updated only for localized jar files, like *_ja.jar.

I've tried following things, and found localized jar files 
are not updated in private/private.properties.

1. Create a VW JSF project in following settings:
   - NetBeans installation dir: /export/home/nbtest/netbeans-6.0.1
   - Project created dir: /export/home/nbtest/WebApplication1

2. Setup the other machine with following settings:
   - NetBeans installation dir: /opt/netbeans-6.0.1

3. Copy #1 created project to /tmp/WebApplication1 on   #2 machine.

4. Open #3 project, from /opt/netbeans-6.0.1 installed netbeans.

5. Only '*_ja.jar' path in private.properties are not update and have reference issues, but
   the base jar path is updated, and will not have reference issues.
   For example, in updated private.properties:
      file.reference.jsfcl_ja.jar=/export/home/nbtest/netbeans-6.0.1/visualweb1/modules/ext/locale/jsfcl_ja.jar
      libs.jsf12-support.classpath.libfile.1=/opt/netbeans-6.0.1/visualweb1/modules/ext/jsfcl.jar

This will case the reference issue, when copy the project.
For example, if a user create some project in company's machine, save the created project in memory stick, 
bring it to his/her home, and open it in his/her own compute to continue the project. 


Comment 6 _ potingwu 2008-01-21 19:13:32 UTC
I think this is an expected NetBeans IDE project classpath restriction! But I will reassign to the API owner for further
evaluation.
Comment 7 Tomas Mysik 2008-01-21 21:43:06 UTC
I will look at it.
Comment 8 Tomas Mysik 2008-02-22 16:24:56 UTC
One question to:
> 3. Copy #1 created project to /tmp/WebApplication1 on   #2 machine.

How do you do this? Directory 'nbproject/private' should not be copied. This directory is neither stored in any VCS 
because it's specific for each computer.
Comment 9 Kenji Tachibana 2008-02-26 11:33:27 UTC
> How do you do this? Directory 'nbproject/private' should not be copied. This directory is neither stored in any VCS 
> because it's specific for each computer.

Well, just copy it, like cp -r.
I appreciate if you know the document/FAQ or something which described 
how to copy the project to the other computer.
And if it has  'nbproject/private' should not be copied, I think it's enough.
Comment 10 Tomas Mysik 2008-02-26 12:02:24 UTC
> I appreciate if you know the document/FAQ or something which described 
> how to copy the project to the other computer.

No, unfortuantely.

> And if it has  'nbproject/private' should not be copied, I think it's enough.

I think so, as I wrote - that directory is not under any VCS and/because it contains absolute paths to libraries, 
servers etc.
Comment 11 David Konecny 2008-03-30 23:54:18 UTC
The core of this problem lies in visualweb component domain and the way it handles localized jars. See
visualweb.project.jsf.libraries.JsfProjectLibrary.updateLocalizedRoots() - this method adds localized jars of well-known
libraries directly to project classpath. So in drivevolley's case this results in:

  [...]in updated private.properties:
    file.reference.jsfcl_ja.jar=/export/home/nbtest/netbeans-6.0.1/visualweb1/modules/ext/locale/jsfcl_ja.jar
    libs.jsf12-support.classpath.libfile.1=/opt/netbeans-6.0.1/visualweb1/modules/ext/jsfcl.jar

where jsfcl.jar belongs to some visualweb NetBeans Library and jsfcl_ja.jar does not. That's the cause of the problem.

With "Sharable Libraries" feature in NB6.1 the situation unfortunately remains the same - while library entry jar files
will be copied in Libraries Folder and will be accessed via relative paths any localized jars will be added as fully
qualified paths pointing directly to NetBeans installation.
Comment 12 _ potingwu 2008-03-31 05:28:43 UTC
The way visualweb.project.jsf.libraries.JsfProjectLibrary.updateLocalizedRoots() does is to support ONLY the bundled JSF
component libraries. There was never a plan for customized I18N support for this type. Before visualweb has this kind of
support, I guess the developer needs to manually setup their own I18N classpath.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo