[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-dev] server architecture discussion
|
Hi
Tim,
Thanks
for the response. Here is a little more detail on JSF Libaries
and why we think we need this.
JSF
Libraries can be either user or plugin specified and will be used to package up
JSF implementations (Sun RI, MyFaces, etc.) and/or component
libraries. Sometimes the jars will be available in the server
at runtime so we want to avoid copying these jars to WEB-INF/lib whenever
possible. In J2EE 1.5, some will become part of the
platform. The user will have the control to specify whether the
library should be deployed or not. We are also considering
putting the "deployme" flag on each individual jar in a
library.
We
will be providing a property sheet UI so that the user can add and remove these
libraries from a project post JSF facet install. By using CP
containers, it will be much easier to cleanup when the user removes a library
that that had been marked for deployment. In order to use a
container we will need a hook to copy the files when
marked.
Thanks,
Gerry
Kessler
-----Original Message-----
From:
Timothy Deboer [mailto:deboer@xxxxxxxxxx]
Sent: Monday, February 27,
2006 5:57 AM
To: gerry.kessler@xxxxxxxxxx; General discussion of
project-wide or architectural issues.
Subject: RE: [wtp-dev] server
architecture discussion
Hi Gerry,
I would be
willing to support "*" for the typeIds in publish tasks, but I don't see what
that gets you. I think the real question is how the user interacts with these
jars and where they will be picked up on the classpath of the final published
module. If the jars are going to end up in WEB-INF/lib, then you can manually
place them there when the user starts using your tools. Using a classpath
container and having them picked up in a more dynamic way is just a cleaner
way to do the same thing. If the jars should be on the server's classpath or
outside of the module instead, then facets are probably the answer. However,
then you've got server specific code and need to deal with cases where the
server doesn't ship with the jars.
Hope this helps - we can discuss more at the call today.
Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503
(tieline 969)
deboer@xxxxxxxxxx
"Gerry Kessler"
<gerry.kessler@xxxxxxxxxx> Sent by: wtp-dev-bounces@xxxxxxxxxxx
24/02/2006 06:30 PM
Please respond
to "gerry.kessler@xxxxxxxxxx" and "General discussion of
project-wide or architectural
issues." |
|
To
| "General discussion of
project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [wtp-dev] server
architecture discussion |
|
Hi Ted,
Thanks for hosting this event and I
will be there. I would like to bring up a question/issue now that I
hope can be responded to either on the call or here in the mailing list if
possible.
The JSF Tools project has a concept we call JSF
Libraries. For now, this is really just a named collection of jars that
a user can add or remove from a JSF faceted project. When we orignally
conceived the idea, pre-R0.7, we intended them to become classpath containers
in the project for build time and, if the library was specified to be
deployed, we would use the extension that had existed at the time to copy the
jars. Unfortunately that hook dissappeared and so for M1 of the JSF
tools, we were forced to copy the jars to WEB-INF/lib in the project at facet
installation time.
With the "External JARs not copied to correct
module folder in deployable" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=116783) we had hoped that we would be getting that hook
back. Instead, external jars can be made "J2EE Module Dependencies"
which puts the jar on the build time classpath and if checked, deployed as
well. However this feature doesn't yet deal with CP containers.
We have entered an enhancement request for this, "To support classpath
containers in J2EE Module dependency" (https://bugs.eclipse.org/bugs/show_bug.cgi?id=128851) . We were asked to propose a patch for
this.
However, I was hoping to get clarity on whether this feature
was intended to support folks like ourselves who want to participate in
deployment but may not be ServerRuntime specific. We see publishTasks
ext-pt as being almost what we want, except that it requires a specific (or
list of) ServerRuntime typeid which doesn't apply for us necessarily.
So before we start proposing a patch to support CP
containers as J2EE module dependencies so that we can get the deploy-time file
copying, would proposing to create a extension point that is server runtime
agnostic be better? Would changing publishTasks to accept "*" in
typeIds and always be called for any server work? Are there others out
there who are looking for something like this?
Best
regards,
Gerry Kessler
JSF Tools Team
-----Original Message-----
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]On Behalf
Of Ted Bashor
Sent: Thursday, February 23, 2006 6:36
PM
To: wtp-dev@xxxxxxxxxxx
Subject: [wtp-dev] server
architecture discussion
Would like to
invite interested parties to participate in a WTP server tools architecture
call on Monday.
This is an opportunity to discuss any outstanding
architecture issues and to design solutions -- perhaps temporarily setting
aside annoying practicalities like schedule and api changes :-)
I’ll try
to send out an agenda doc Monday morning with some topics. The primary
one for us is the facet runtime bridge. But please feel free to send me
any other items you’d like to discuss.
Time: Monday, 2/27 11
AM PST / 2 PM EST
Toll free:
866-214-3176
Passcode:
8870689
Thanks, Ted
tbashor@xxxxxxx
_______________________________________________________________________
Notice:
This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its
subsidiaries and affiliated
entities, that may be
confidential, proprietary, copyrighted and/or
legally
privileged, and is intended solely for the use of the individual
or entity
named in this message. If you are not the intended recipient,
and have
received this message in error, please immediately return this
by email and
then delete it.
_______________________________________________
wtp-dev mailing
list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev