JIRA GERONIMODEVTOOLS-185 created to track this.
- Shiva
On 8/18/07, Shiva Kumar H R <[EMAIL PROTECTED] > wrote:
That's great. I will create a JIRA for this on Monday.
- Shiva
On 8/16/07, James Ervin < [EMAIL PROTECTED] > wrote:
I modified the part of the processJavaProject() method that deals with
containers like so:
SharedLibEntryCreationOperation.java:
processJavaProject()
<--- Begin code snippet --->
if( kind == IClasspathEntry.CPE_CONTAINER )
{
if( entry.getPath().segment( 0 ).startsWith(
"org.eclipse.jdt.launching" ) )
continue;
if( entry.getPath().segment( 0 ).startsWith(
"org.eclipse.jst." ) )
continue;
if( entry.getPath().segment( 0 ).startsWith(
"org.eclipse.wst" ) )
continue;
// if(
"org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER
".equals(
entry.getPath().toString() ) )
// {
final IClasspathContainer container =
JavaCore.getClasspathContainer(entry.getPath(), javaProject);
final IClasspathEntry[] containerEntries =
container.getClasspathEntries();
for( int j = 0; j < containerEntries.length; j++ )
addEntry( entries, resolveVarOrLibEntry(
containerEntries[ j ] ) );
// }
}
<--- End Code Snippet --->
This seems to work for me. I am checking for the JDT JRE container,
any WTP containers and then ignoring those entries.
Can anyone see any side-effects to this?
James
On 8/16/07, Shiva Kumar H R <[EMAIL PROTECTED]> wrote:
Looks like I won't be able to resolve this with my current code
knowledge. Will dig into this more tomorrow.
- Shiva
On 8/15/07, James Ervin < [EMAIL PROTECTED]> wrote:
I was thinking about this and I believe the reason that the full
resolved class path is not considered is because it would include entries
from both the JRE classpath container and the Web-App Libraries classpath
container. Is this correct? If it is, it would seem easier to just exclude
those classpath containers and then resolve the rest?
Thanks,
James
On 8/15/07, James Ervin < [EMAIL PROTECTED]> wrote:
I was just following up to see if anyone saw any side effects
from considering the resolved classpath of a java project instead of just
the raw classpath?
Thanks,
James
On 8/13/07, James Ervin < [EMAIL PROTECTED] > wrote:
I was looking at the method a bit and it seems as though the
only classpath container that is recognized is the maven classpath
container. Perhaps by using the resolved classpath or by removing the if
statement that checks for the maven classpath container exclusively would be
enough. Maybe the code could be simplified by using getResolvedClasspath()
since I don' t think you would need to call a resolveVarOrLibEntry() method
anymore.
Thanks for pointer btw... You brightened my morning....
Thanks,
James
On 8/13/07, James Ervin < [EMAIL PROTECTED]> wrote:
Oh that would be awesome.... thanks.... please let me know of
your results ASAP.
Thanks,
James
On 8/13/07, Shiva Kumar H R < [EMAIL PROTECTED]> wrote:
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.java
in 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
--
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
--
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
--
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
--
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
--
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
