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.
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.
Created attachment 55184 [details] snapshot for added localied library
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.
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.
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.
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.
I think this is an expected NetBeans IDE project classpath restriction! But I will reassign to the API owner for further evaluation.
I will look at it.
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.
> 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.
> 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.
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.
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.