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.

Bug 129316 - Cannor import VWP app developed in netbeans 6.0 to 6.1 nightly builds
Summary: Cannor import VWP app developed in netbeans 6.0 to 6.1 nightly builds
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 6.x
Hardware: Macintosh All
: P2 blocker (vote)
Assignee: David Konecny
URL:
Keywords:
: 129351 129499 (view as bug list)
Depends on:
Blocks: 129499
  Show dependency tree
 
Reported: 2008-03-05 16:24 UTC by bhatt246
Modified: 2008-11-24 15:30 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
VisualWeb windows project (24.75 KB, application/x-compressed)
2008-03-06 03:01 UTC, _ krystyna
Details
Visual Web solaris project (9.87 MB, application/x-compressed)
2008-03-06 03:02 UTC, _ krystyna
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bhatt246 2008-03-05 16:24:09 UTC
I have a VWP project that was created using NB 6.0. I am trying to install and run it from a newer version of netbeans
that I installed recently.  I can open the project but when I try running it the following error is thrown:

Copying 12 files to /Users/deepMac/auto/build/web
library-inclusion-in-archive:
/Users/deepMac/auto/nbproject/build-impl.xml:509: Warning: Could not find file /Users/deepMac/auto/C:/Program
Files/NetBeans 6.0 200710241200/enterprise4/modules/ext/jsf-1_2/jsf-impl.jar to copy.
BUILD FAILED (total time: 0 seconds)

Looking inside the nbproject/build files I can see that the path to jars in nbproject/private/private.properties still
points to the old Netbeans instance (in which it was created):

libs.jsf12-support.classpath.libfile.1=C:\\Program Files\\NetBeans 6.0 200710241200\\visualweb1\\modules\\ext\\jsfcl.jar
libs.jsf12-support.classpath.libfile.2=C:\\Program Files\\NetBeans 6.0 200710241200\\visualweb1\\modules\\ext\\appbase.jar
libs.jsf12-support.classpath.libfile.3=C:\\Program Files\\NetBeans 6.0
200710241200\\visualweb1\\modules\\ext\\dataprovider.jar
libs.jsf12-support.classpath.libfile.4=C:\\Program Files\\NetBeans 6.0 200710241200\\visualweb1\\modules\\ext\\sqlx.jar
libs.jsf12.classpath.libfile.1=C:\\Program Files\\NetBeans 6.0
200710241200\\enterprise4\\modules\\ext\\jsf-1_2\\commons-beanutils.jar
libs.jsf12.classpath.libfile.2=C:\\Program Files\\NetBeans 6.0
200710241200\\enterprise4\\modules\\ext\\jsf-1_2\\commons-collections.jar
libs.jsf12.classpath.libfile.3=C:\\Program Files\\NetBeans 6.0
200710241200\\enterprise4\\modules\\ext\\jsf-1_2\\commons-digester.jar
libs.jsf12.classpath.libfile.4=C:\\Program Files\\NetBeans 6.0
200710241200\\enterprise4\\modules\\ext\\jsf-1_2\\commons-logging.jar
libs.jsf12.classpath.libfile.5=C:\\Program Files\\NetBeans 6.0 200710241200\\enterprise4\\modules\\ext\\jsf-1_2\\jsf-api.jar
libs.jsf12.classpath.libfile.6=C:\\Program Files\\NetBeans 6.0
200710241200\\enterprise4\\modules\\ext\\jsf-1_2\\jsf-impl.jar
libs.jstl11.classpath.libfile.1=C:\\Program Files\\NetBeans 6.0 200710241200\\enterprise4\\modules\\ext\\standard.jar
libs.jstl11.classpath.libfile.2=C:\\Program Files\\NetBeans 6.0 200710241200\\enterprise4\\modules\\ext\\jstl.jar

The path to the new Netbeans instance is present in other files though. For instance, nbproject/project.xml has the
correct path:

libs.jsf12-support.classpath.libfile.1=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/visualweb2/modules/ext/jsfcl.jar
libs.jsf12-support.classpath.libfile.2=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/visualweb2/modules/ext/appbase.jar
libs.jsf12-support.classpath.libfile.3=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/visualweb2/modules/ext/dataprovider.jar
libs.jsf12-support.classpath.libfile.4=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/visualweb2/modules/ext/sqlx.jar
libs.jsf12.classpath.libfile.1=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/enterprise5/modules/ext/jsf-1_2/commons-beanutils.jar
libs.jsf12.classpath.libfile.2=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/enterprise5/modules/ext/jsf-1_2/commons-collections.jar
libs.jsf12.classpath.libfile.3=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/enterprise5/modules/ext/jsf-1_2/commons-digester.jar
libs.jsf12.classpath.libfile.4=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/enterprise5/modules/ext/jsf-1_2/commons-logging.jar
libs.jsf12.classpath.libfile.5=/Applications/NetBeans/NetBeans 6.1 Dev
200802270005.app/Contents/Resources/NetBeans/enterprise5/modules/ext/jsf-1_2/

Note that project was created on a Windows machine and is now being ported to a newer version of Netbeans running on
Mac. Since the application is platform independent it should be importable to 6.1 on a mac or on any other platform.
This would not have worked on Windows either as the path to some of the jars shown above is wrong.


Suggestions to remove the app/nbproject/private dir and rebuild did not help either.

I tested this on NB 6.1 Dev 200802270005
Comment 1 Winston Prakash 2008-03-05 17:52:13 UTC
Try removing the <project-dir>/nbproject/private folder before opening
the project else where.
Comment 2 _ potingwu 2008-03-05 18:12:47 UTC
This is a known general NetBeans issue for "NB6 to NB6.1" and the fix is removing the private directory before opening
the project. BTW, if you are not moving the project to other system, the IDE will automatically regenerate the private
directory. But if you do, you may need to do it manually. Under this condition, it's not a P2.

As I known, there is already some bug filed against the NetBeans general project IDE. It's not specific to visualweb.

Krys, did you file one or found there is already one bug filed?
Comment 3 _ potingwu 2008-03-05 18:18:54 UTC
> /Users/deepMac/auto/nbproject/build-impl.xml:509: Warning: Could not find file
> /Users/deepMac/auto/C:/Program Files/NetBeans 6.0 200710241200/enterprise4/modules/ext/jsf-1_2/jsf-impl.jar to copy.

The new 'sharable' function here may have some issue for changing the path from Unix to Windows. Milos, could you please
take a look? I think it's a global NetBeans project issue.
Comment 4 Milos Kleint 2008-03-05 21:17:03 UTC
having nbproject/private/private.properties originating on a windows machine to be used on mac is definitely wrong. It's
been an issue since 4.0+. That's why it's not put into version control systems by the IDE. People who add it manually to
VCS, get into trouble.

I'm wondering if you still have the old window based project sources intact and could perform 2 experiments.
1. move the project to mac like you did before and open in 6.0
2. move the project to mac, remove the nbproject/private folder and open in 6.1 (You pointed out you did it and still
have problems, but please describe these problems in detail as they possibly cannot be the ones from description and the
windows file paths are only stored in the private files)

Thanks a lot.

Comment 5 _ krystyna 2008-03-06 02:55:06 UTC
Po-Ting, I could not find  any issue regarding nbprivate, but I also found problems building if importing
from 6.0:  Solaris 6.0.1 -> Windows 6.1 (attaching project) and also a build
error migrating Windows 6.0.1 ->  Windows 6.1 (attaching). 
Removing the nbproject/private had no effect.

Note: the Solaris to Windows complained of a sqlx.jar not found.
The windows to Windows, could not find ${libs.woodstock-components.classpath.libfile.7} to copy.
Comment 6 _ krystyna 2008-03-06 03:01:28 UTC
Created attachment 57842 [details]
VisualWeb windows project
Comment 7 _ krystyna 2008-03-06 03:02:40 UTC
Created attachment 57843 [details]
Visual Web solaris project
Comment 8 bhatt246 2008-03-06 16:06:47 UTC
Since removing the <appp>/nbproject/private directory and reloading the project does not help I really think this bug
should be changed back to a P2. Once NB 6.1 ships a lot of users will try to import their old netbeans apps' to the new
release and things will not work for them. This will be bad publicity for Netbeans 6.1 and Sun. 
Comment 9 _ potingwu 2008-03-06 17:15:37 UTC
> Since removing the <appp>/nbproject/private directory and reloading the project does not help

If you can attach your project into this issue, I believe that will help the further investigation a lot. I'm wondering
what is the contents in your project now! Does it have something like "/Users/deepMac/auto/C:/Program Files/NetBeans 6.0
200710241200/enterprise4/modules/ext/jsf-1_2/jsf-impl.jar" baked inside?
Comment 10 Milos Kleint 2008-03-06 18:14:05 UTC
->P2  backward compatibility is indeed important.
Comment 11 Milos Kleint 2008-03-07 13:35:55 UTC
it seems to be something web project specific.
in the case of removed nbproject/private properties, the classpath is correct. What's wrong are the 

libs.woodstock-components.classpath.libfile.7 -like properties.

These props are not related to shared libraries or libraries in general. It seems to be generated by the web project.
The reason why it's failing in 6.1 is because the woodstock-components library now contains just 5 jars. The projects
properties file correctly contains just five *.libfile.[1-5] files, but for some reason the build-impl.xml file doesn't
update and still lists 7 props in it's targets..


reassigning to web project for evaluation.
Comment 12 Milos Kleint 2008-03-07 13:37:13 UTC
tmysik claims it could be related to #126119
Comment 13 _ potingwu 2008-03-07 18:29:23 UTC
The current available workaround is:
1. remove nbproject/private/private.properties
2. remove all lines in nbproject/build-impl.xml that contain the following instances:
    ${libs.woodstock-components.classpath.libfile.6}
    ${libs.woodstock-components.classpath.libfile.7}

I think the IDE (web/project) should automatically regenerate private.properties and build-impl.xml when the project has
been opened by different version of IDE.
Comment 14 David Konecny 2008-03-09 02:10:22 UTC
This problem exists in all web project types; could have been experienced in previous versions (e.g. 5.5 -> 6.0); is not
related to project sharability and is not related to issue 126119.

A bit of explanation first:

Ant does not natively support copying list of files. NetBeans Library jars are defined as list of jars, e.g.
libs.woodstock-components.classpath=a/path/webui-jsf.jar;a/path/commons-fileupload-1.0.jar;a/path/json-2.jar;... . In
order to copy these jars to build directory (and consequently to WAR) and without requiring custom Ant task following
solution was implemented for a while:

* individual Ant properties are gerenated for each classpath item, eg project.properties or private.properties will contain:
  libs.woodstock-components.classpath.libfile.1=a/path/webui-jsf.jar
  libs.woodstock-components.classpath.libfile.2=a/path/commons-fileupload-1.0.jar
  libs.woodstock-components.classpath.libfile.3=a/path/json-2.jar
  ...

* project.xml file lists name of library and total count of library jars:
    <library files="7">
      <file>${libs.woodstock-components.classpath}</file>
    </library>

* build-impl.xsl generates <copy> Ant tasks based on the total number from project.xml so resulting build-impl.xml for
above project.xml will simply list seven times:
  <copy-ear-war file="${libs.woodstock-components.classpath.libfile.1}" propname="..."/>
  <copy-ear-war file="${libs.woodstock-components.classpath.libfile.2}" propname="..."/>
  <copy-ear-war file="${libs.woodstock-components.classpath.libfile.3}" propname="..."/>
  ...


Now, back to this issue. The woodstock-components library consist of 5 jars now but it used to have 7. Any library
change like this would result into this problem. Opening old 6.0 project there is infrastructure in place which updates
project/private properties. There is one problem that entries from private.properties were not removed when new entries
were added to project.properties. Second issue is that so far there is no support for automatic updating of project.xml
- the total number of library files needs to be updated from 7 to 5 and as a result of that build-impl.xml will get
regenerated and fixed. I'm going to fix both of these issues.

Temporary wokraround is:
* close IDE
* delete nbproject/private/private.properties - fixes first problems
* start IDE and open project
* open project customizer and press OK - fixes second problem
Comment 15 bhatt246 2008-03-09 16:34:19 UTC
Thanks for the great explanation. In future if the number of Woodstock jars change your proposed fix would still work,
right?
Comment 16 David Konecny 2008-03-10 02:10:17 UTC
Re. "if in future the number of Woodstock jars changes" - everything should just work.

Re. "problem could have been experienced in previous versions (e.g. 5.5 -> 6.0)" - more thorough testing shows me that
web and appclient project types perform update of project.xml

Fixed for all project types in 
http://hg.netbeans.org/main?cmd=changeset;node=56420c6aed50

One negative aspect of current implementation of handling required jars is that user's project files (project.xml,
build-impl.xml and project.properties) are changed when opening 6.0 project in 6.1.
Comment 17 David Konecny 2008-03-10 02:11:14 UTC
*** Issue 129499 has been marked as a duplicate of this issue. ***
Comment 18 _ krystyna 2008-03-11 03:10:02 UTC
*** Issue 129351 has been marked as a duplicate of this issue. ***
Comment 19 martin_zmrhal 2008-11-24 15:30:31 UTC
Verified

Product Version: NetBeans IDE Dev (Build 200811240201)
Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15
System: Linux version 2.6.27-7-generic running on i386; UTF-8; en_US (nb)