[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-dev] Components: Required libraries, projects and classes
|
Chuck,
Thanks for the response ... a couple of follow ups
...
As of last weeks IBuild, the move is towards one component
per project. Is a "reference" component a different thing and hence there will
be an exception?
And I couldn't get as to what you mean by a reference
type .... just libraries and jars?
And similarly a "shared java" component is just another
reference component which happens to have some java source or is it a special
kinda component?
If you would like one more pair of eyes, I can take a
look at the reference component if you could point me to a discussion
thread or other architectural documentation you may have on
this.
Also, I noticed that the Web Services wizards copy the
jars into <component>/lib instead of the reference model .... but I will
follow up with Chris on a seperate post.
Regards
Ravi
Hi Ravi, 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
