Community
Participate
Working Groups
From an UI point of view it is unacceptable to manage the build path of your workspace and multiple different locations. Long time Eclipse users are used to manage their build path in exactly ONE location: the JDT build path preference page. WTP should be enhanced to recognize JDT classpath changes and transparently update its own J2EE dependencies model. This should be the default to simplify the user experience especially for new users. I learned that it's already a long process for new users to understand the JDT build path page and all its power (eg. variable, containers, etc.) Ideally, the J2EE dependencies page should be dropped and become a class path container page so that it can be customized by advanced users using the same pattern available in Eclipse.
See bug 118622 comment 17 for an example. The problem is that there is a difference between development and runtime. This is caused by two separate class path management concepts the user is confronted with. The two concepts don't integrate very well with each other. Concept A (.classpath) doesn't know that concept B exists (J2EE dependencies). Thus, concept B has to do all the necessary integration and validation work. However, this integration needs manually work. Thus, a user has to understand both concepts upfront before he can use Eclipse effective to develop J2EE applications. It would be much better to reduce that learning curve but hiding concept B until he is experienced enough. For this particular case I see multiple solution ideas. 1. Use access rules to hide the classes defined in B 2. Add a project marker indicating the gab between deploy and runtime 3. Include B into the J2EE dependency tree Solution 1 sounds good but is for advanced users only. It will confuse new users if they did not get into the full JDT build path power yet. Solution 2 needs a quick fix to assist new users. But presenting the user with an error is very bad in this case because we can do better. It just means that we know the problem but are to lazy to fix it. Thus, we would point the user to the "workaround". Solution 3 is adoptiong the concept behind this bug. The users just manages the build path using the JDT build path page. WTP would do everyting transparently in the background to make sure that the development/project build path == the runtime class path. Advanced uses would still have the option to control that magic, i.e. by turning it off and managing the J2EE dependencies manually (like they do today).
see bug 118622 for a complete history on this problem.
But it's not limited to bug 118622. For example, the same problems happens to JARs. If I add jars to the classpath of a utility project I still have to add them manually to the J2EE dependencies page in a second step.
Assigning to Kiril for evaluation
Rob, you refactored the old J2EE Module Dependencies page to the new Module Assembly page. Do you think further integration could be done with the Build Path preferences, so the issue described here is addressed?
