Gerry,
One thing to be aware of is that you will
not be able to handle all servers generically when it comes to “deploying”
these libraries. You can certainly write a single implementation for the
servers that use the default staging directory mechanism, but that’s not
universally true. In order to make sure that your code does not break when it
encounters one of the servers that does not use the default staging directory
mechanism, you will have to enumerate all the ones that you know work that way.
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Gerry Kessler
Sent: Monday, February 27, 2006
9:21 AM
To: Timothy Deboer; General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] server
architecture discussion
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.
-----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
_______________________________________________________________________
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.
|
