Summary: | [j2ee properties] Simplify build path management | ||
---|---|---|---|
Product: | [WebTools] WTP Java EE Tools | Reporter: | Gunnar Wagenknecht <gunnar> |
Component: | jst.j2ee | Assignee: | Kaloyan Raev <kaloyan> |
Status: | NEW --- | QA Contact: | Chuck Bridgham <cbridgha> |
Severity: | enhancement | ||
Priority: | P3 | CC: | eclipse-bugzilla.20.mvonballmo, kaloyan, stryker |
Version: | 1.5 | Keywords: | helpwanted |
Target Milestone: | Future | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | ProjectStructure | ||
Bug Depends on: | 118622 | ||
Bug Blocks: |
Description
Gunnar Wagenknecht
2006-09-27 03:57:30 EDT
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? |