Hi James,
Looks like this is what you are looking for (I hit across this by searching
for "getRawClasspath" in plug-in source):
"processJavaProject() method of
org.apache.geronimo.st.core.operations.SharedLibEntryCreationOperation.javain
plugins/org.apache.geronimo.st.core"
Now seeing if changing this to getResolvedClasspath (as you suggest), would
lead to any side effects.
- Shiva
On 8/9/07, James Ervin <[EMAIL PROTECTED]> wrote:
>
>
>
> On 8/8/07, Tim McConnell <[EMAIL PROTECTED]> wrote:
> >
> > 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....
>
>
> Thanks for the reply, I actually am using a Publish Operation to set the
> shared library support, so yes I am using some of that support. The issue I
> am having is the fact that when the Geronimo plugin is computing the
> <Project-Name>.eclipse.jar manifest for the ${GERONIMO_HOME}/shared/lib
> directory, it seems to only consider the raw classpath from the Eclipse
> JDT. In other words, it appears almost as though its using
> org.eclipse.jdt.core.IJavaProject.getRawClasspath() instead of
> org.eclipse.jdt.core.IJavaProject.getResolvedClasspath(). I say almost,
> because it will resolve Classpath Variable entries. The net effect is that
> I have to hard code entries in the .classpath file for each jar file I want
> in that manifest, but that is what classpath containers are supposed to help
> you with.
>
> I have considered it, but the circumstances are such that I have to use
> what I am given so far. I will look at version 2.0 and the latest from
> the plugin, but that leads me to one of my earlier questions in my first
> post. Where in the plugin do I look for where it is computing the manifest
> for the <Project-Name>.eclipse.jar? I have to admit I am a bit of a newbie
> when it comes to EMF (I'm not sure that I hate it, but I have yet to see
> what I really like about it. The idea seems very interesting, but I am not
> crazy about the results I have seen so far) and well the Geronimo Plugin
> source tree seems almost as big as WTP's at this point, so any pointers
> would be most appreciated.
>
> Thanks,
> James
>
> 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
> >
>
>
>
> --
> 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
>
