Hi again James, Sorry for the delay but I've been trying to fully understand
what you're trying to accomplish. Have you considered using the shared lib
support that is already provided by the Geronimo plugin publish/deploy
functionality ?? If I correctly understand what you're trying to accomplish the
shared lib support should work for you. It's not obvious to me though why you
are so adverse to using the built-in publish/deploy capabilities of the plugin.
Finally, have you considered upgrading to the latest versions of Geronimo and
the plugin ?? Geronimo 2.0 is currently being voted on for release, and the
plugin will be voted on for release shortly thereafter. Just curious. Thanks
much....
James Ervin wrote:
Tim,
Thanks for the reply. Reviewing the plugins installed it looks as
though the plugin is at version 1.0.0 with the
org.apache.geronimo.runtime.v1 plugin at version 1.0.1. Hmm I don't see
a feature. I am not quite sure the version of geronimo. It comes
bundled and is installed by a script so I am not entirely sure of the
version. My educated guess is that it is at version 1.2. The version
of WTP is 1.5.x.
Its not straightforward to offer a sample app, since I can't really
offer up my plugin, so I will describe it.
When you add a project dependency for a web app, I noticed that the
Geronimo Eclipse plugin will generate a jar file in the
${GERONIMO_HOME}/shared/lib directory with the name
${PROJECT_NAME}.eclipse.jar. In that jar there is a manifest that is
pointing at the java source output directories for the web app project
and the output directories for any project dependencies. It would be
nice to customize that, but that is just fine for now. The shared/lib
directory is also where I generate a jar file that contains a manifest
describing the set of shared libraries that all deployed web apps will
share.
If I add a classpath entry directly in the .classpath file for a library
jar dependency, it will show in the ${PROJECT_NAME}.eclipse.jar just
fine. The problem comes in that I want to use a classpath container to
resolve library dependencies and not have to manage entries directly in
the .classpath file. Even when the container resolves down to a set of
flat jar files, it does not matter. It seems that the plugin does not
check the resolved classpath of a java project and only checks the raw
classpath. Shouldn't it construct the classpath by checking all project
dependencies and by using the resolved, and not raw, classpath?
I am faced with a significant rewrite right now if I cannot figure out a
solution, any help would be really appreciated.
Thanks,
James
On 8/7/07, * Tim McConnell* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi James, which version of Geronimo and the Geronimo plugin are you
using ??
Also, do you have an example test app that you could attach that
demonstrates
the failure ??
James Ervin wrote:
> Hello,
> I am a developer working on an Eclipse plugin attempting to use
WTP to
> help ppl write Service Based web apps. Why am I asking a question on
> the geronimo user group? Well because I am attempting to use Apache
> Geronimo as the primary J2EE container.
>
> My problem is this, I need to be able to deploy libraries (yes I
know
> about the PublishOperation and that I can generate a jar with a big
> manifest file enumerating all shared libraries) that are only used by
> one particular web app or dependent web app. So I have a classpath
> container, the trouble is that the Apache Geronimo plugin that I have
> access to does not seem to care about entries in classpath
containers,
> only those that are directly enumerated in a .classpath file (bad
form
> IMHO).
>
> I have attempted to deploy libs into WebContent/WEB-INF/lib, but on
> windows WTP ( or some plugin ) keeps the bloody file lock and
will not
> let me update or delete it. I even attempted to deploy the libs
to a
> separate directory and then told WTP via a <wb-resource/> tag in
the WST
> common component configuration file where to find it. The lib
showed up
> in the list of WebApp Libraries, but then when deployed to
Geronimo it
> was not recognized.
>
> I have tried this and a few other combinations. The only one
that has
> worked is if I create a new shared lib entry jar (bad form since
not all
> web apps on the container will want the given set of libraries)
or if I
> enumerate the libraries one by one directly in the .classpath
(classpath
> containers anyone?).
>
> Is there anyway to make the plugin respect the classpath
container? Or
> at least give me a clue through the bloody EMF wilderness as to
where in
> the plugin the deployment configuration is determined so that I can
> consider my options (you know like a patch...)? I am at my wits end,
> any help would be most appreciated.
>
> Thanks,
> --
> James E. Ervin
>
> A human being should be able to change a diaper, plan an invasion,
> butcher a hog, conn a ship, design a building, write a sonnet,
balance
> accounts, build a wall, set a bone, comfort the dying, take
orders, give
> orders, cooperate, act alone, solve equations, analyze a new problem,
> pitch manure, program a computer, cook a tasty meal, fight
efficiently,
> die gallantly. Specialization is for insects.
> -Robert A. Heinlein
>
> Blog: http://iacobus.blogspot.com
--
Thanks,
Tim McConnell
--
James E. Ervin, IV
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
-Robert A. Heinlein
Blog: http://iacobus.blogspot.com
--
Thanks,
Tim McConnell
