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.
For example in Japanese env, jsfcl_ja.jar is registered in Library as
But, it should be relative path like as follows:
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,
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
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.
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:
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
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.
> 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,
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:
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.