|
Thanks
for pointing this out Konstantin. Perhaps publishTask isn't the way
to go. I should not have to worry about the staging directory
mechanism for deploying my jars with a module. Should we be
looking at J2EE Module Dependencies instead?
GK
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 userinteracts 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.
|
