Community
Participate
Working Groups
I think that Eclipse should make a clear distinction between: classpath dependancies - Things not provided by the application/project but expected of the runtime by the application/project at deployment. This has the same meaning for non-container projects and the build path is already geared up this way as it stands. J2EE dependancies - Things that are needed by the application/project to copy inside the J2EE component to create the project in deployable form. So to remove any confusion everything under the Properties -> J2EE dependancies should only be related to J2EE dependancies never classpath dependancies. The reason why I think its confusing is that the "Add External JARs" and "Add Variable" buttons under "J2EE Module Dependancies" -> "Web Libraries" actually configure the "classpath dependancies" not the "J2EE dependancies" as per my definions above. Related bug reports: bug #116783 bug #116489
I think the whole UI needs some kind of rework. Currently it is difficult to setup. There should be a better editor for this (maybe as part of bug 133359). People should not need to think different when using WTP. WTP should adapt to them. For example, let them continue to use the Build Path property page for configuring the classpath of their projects. Then, provide an editor for selecting which JARs or projects of the classpath should be deployed to the server. This editor could also allow to define additional elements to deploy. The editor will track changes to the classpath and as soon as a user adds a new classpath element, it will attach a warning or error marker to the project telling the developer that he still has to configure if this element should be deployed to the server.
Some review/consolidation of the J2EE module dependencies/Java build path may be motivated for 2.0 Chuck: would be good to get your thoughts here given scope/impact and overlap with other bugzillas
*** Bug 126825 has been marked as a duplicate of this bug. ***
Note: the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=128851 gets things started down this path and will ultimately a full detangling of the .classpath and component files.
The changes for https://bugs.eclipse.org/bugs/show_bug.cgi?id=128851 are in 2.0 M6; so, you can now manage library, var and cp container entries via the Java Build Path UI and then use the J2EE Module Dependencies UI to select the subset that should be published/exported. Project and src path entries are still mananged entirely via the component file/J2EE Module Dependencies UI so I'll leave this open and set the target to 3.0 as a tentative timeframe during which we can attempt to rationalize handling of these other items.
I still think there is a need for both properties, but the J2EE Dep page needs to be more transparent to any classpath changes that may occur when adding/removing dependencies. Need to remove any overlap in function (MANIFEST changes do nake classpath entries dynamicaly with the new dynamic containers)
See discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=138648
Please see the following wiki page (http://wiki.eclipse.org/Web_Tools_Platform_Release_3.0_Requirements/JavaCPvsJavaEEModDeps) for initial design thoughts on how we can leverage the new (in 2.0) classpath entry publish/export support to overhaul the management of the Java classpath and Java EE module dependencies in the 3.0 timeframe. This is also linked into the WTP 3.0 reqs wiki and I'll post something on the dev list soon as well - once folks have a chance to digest, we can try to schedule a call to gather feedback/discuss and refine.
*** Bug 138648 has been marked as a duplicate of this bug. ***
There's a lot of discussion in this bug, bug 138648 and the WIKI on this issue, I would like to clarify if this RFE is intended to cover the following scenarios: - When a Web project that depends on a Java utility projects is published on a server, would there be a programmatic way to specify which additonal JARs on the Java utility project's build path need to be deployed with the WAR?
(In reply to comment #10) > There's a lot of discussion in this bug, bug 138648 and the WIKI on this issue, > I would like to clarify if this RFE is intended to cover the following > scenarios: > > - When a Web project that depends on a Java utility projects is published on a > server, would there be a programmatic way to specify which additonal JARs on > the Java utility project's build path need to be deployed with the WAR? > hi Kathy, That can be accomplished now (i.e. in 2.0) by adding the publish/export classpath attribute to the library cp entries in the utility project that are associated with the JARs you want deployed. Adding the attribute programmatically can be accomplished via API in the org.eclipse.jst.j2ee.classpathdep package (see UpdateClasspathAttributeUtil.addDependencyAttribute()). Adding the attribute via the UI is a bit awkward in 2.0.x/3.0 since the J2EE Module Dependencies UI is not displayed for utility projects that are referenced just by dynamic web projects; the way to accomplish this now via the UI is by using the QuickFix on the warning that is generated for that cp entry in the utility project (https://bugs.eclipse.org/bugs/show_bug.cgi?id=184094 covers adding full UI support). For standalone dynamic web projects or projects referenced by an EAR, the valid cp entries are listed in the J2EE Module Dependencies UI as potential dependencies (w/ a different icon) and one can simply select/deselect the entry to add/remove the attribute. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=185176 for more details on how this all works currently. -Rob
The required support for project cp entries is not going to make 3.0 (due to a number of risk/complexity issues) so need to push this enhancement out of the committed set as well.
removed plan from keywords.... future enhancement
Assigning to Carl for evaluation
