Community
Participate
Working Groups
Build Identifier: Version: Helios Release (3.6.0) Build id: 20100527-0614 Workspace layout: * One project containing only third party jar files. Let's say it's name is 'Libraries'. * Define a User Library with some JAR files from such project (no absolute paths, but relative to workspace). For example, say I use 'commons-logging.jar', so the relative path is 'Libraries/commons-logging.jar'. * One dynamic web project using this library for it's 'Java build path'. * Add the library to the "Deployment assembly" option (using 'Classpath container' option). * NOTE: I believe 'Deployment assembly' replaces old 'JavaEE Module Dependecies' of former Eclipse versions. * Deploy the project on a server (I use Tomcat). ERROR: Deployment fails stating it cannot find user librarie's JAR files. In out example, it says: Publishing failed with multiple errors Error reading file C:\Libraries\commons-logging.jar Seems it doesn't assume the path to be relative to workspace on deployment. It compiles fine though, so it correctly finds jar during development. Thanks in advance! Reproducible: Always
Nobody cares about this bug? In WTP 3.1's "JavaEE Module Dependecies" it worked just fine. Furthermore, it detected when one of such workspace relative jar files were modified from within the IDE (I create JAR files from source projects and store those JAR files into workspace relative locations). In WTP 3.2 I've tried to fix the bug by using absolute paths (it compiles and deploys fine), but then, Eclipse does not notice when I modify one of such files... Should I open a separate bug for this issue. Thanks a lot.
Hello. I confirm that described behaviour has place. It's very annoying, workaround like making hard link from libraries directory to disk c: (under windows) works, but it just ugly. Any comments from dev-team?
Assigning to Rob for initial investigation.
Pushing to maintenance
I'm not sure if "invalid" is technically correct, but, wtp 3.3 does not include any "Classpath container" module assembly option, and so this usecase is no longer valid. That was a feature that snuck in for a short while and was removed.
