All of the requirements you mentioned
are currently supported or in the M5 plan, although tooling is lacking
in many areas.
My responses are below.
- Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
"Ravi Kumar"
<Ravi.Kumar@xxxxxxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx
05/20/2005 11:07 PM
Please respond to
"General discussion of project-wide or architectural issues."
To
<wtp-dev@xxxxxxxxxxx>
cc
Subject
[wtp-dev] Components: Required
libraries, projects and classes
There appear to be some serious limitations
with respect to component dependencies on external jars and classes. Here
are a few typical use cases and the current solutions.
1) If a component uses
a library, the jar needs to be copied into the component library directory
by the user ... for instance component/web-inf/lib.
<cdb>We don't have the ability yet
to create external classpath entries as referenced components, but this
support is in plan for M5, and is considered very high priority</cdb>
2) If a component uses
some classes from a "required project", the classes need to be
copied in the by the user ... for instance component/web-inf/classes
<cdb>This scenario is supported by
creating adding a "referenced" component with the "consumes"
reference type. The requirement does exist that the referenced project
define components around the shared class files</cdb>
3) And lastly, flexible
projects don't work with source folders which are project wide and are
shared / used by the components
<cdb>Like above, source folders can
be defined within a "shared" java utility component, that can
either reffered by many other components within the workspace.</cdb>
My guess is that it will be reasonably straight
forward to do the following
1) Allow libraries /
jar references to be added to components
2) Allow "required
projects" to components
3) Allow shared sources
in flexible projects and include them in all component .deployables **
<cdb>Some changes are coming soon for
the .deployables folder. We are pushing all assembly tasks minus
the essential java compilation to the publish task. This will eliminate
server specific behavior at development time, and will only assemble the
required metadata needed at publish depending on server type. We
also intend to assemble these files in the server metadata area outside
the workspace.</cdb>
The solution I am proposing is whenever one
of these (libraries, jars or projects) or added to a component, automatically
add it to the project build path. Adding it to the project build path will
use the exact same mechanism as when the user set's it from the project
properties dialog.
So, the work involved is
1) Updating WtpModules
model to accommodate the new elements
2) Some UI to add these
(libraries, jars or projects) to components. Possibly component properties
similar to project properties
<cdb>Thanks for these suggestions,
and we understand the need for minimal dependency configuration support
in R1, we are considering a property sheet like you suggest.
Ultimately, a feature rich editor for editing
resource layout, and deployment options is our goal, but for R1.1</cdb>
thoughts?
-Ravi
** Optional, dependency aware filtering would
be nice as well.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev