| plugin classpath util jars [message #144931] |
Thu, 16 October 2003 10:42  |
Eclipse User |
|
|
|
Hi,
What is the (correct) way to include utility jar files into the plugin. And,
ofcourse, ship them with the deployable jar for the update site.
My project has a src folder (default)
My project has also a lib folder where several util jars reside.
I put these jar file in the java build path on the properties page of the
java plugin project.
Doing so does make the code compile. But when i run the plugin using the
runtime workbench these jar files are not in the classpath.
I tried to put them in the build.properties like this:
source.<project>.jar=src/
bin.includes=plugin.xml,\
*.jar,\
icons,\
<project>.jar,\
lib/*.jar
I also tried to add the jar files to the runtime tab of the plugin.xml like
lib/util.jar which results in:
<library name="lib/util.jar"><export name="*"/></library>
This doesn't work. Does anybody have a solution?
Is there a difference in how this must be configured using runtime workbench
and the actual export for the update site?
|
|
|
| Re: plugin classpath util jars [message #144965 is a reply to message #144931] |
Thu, 16 October 2003 11:13  |
| Eclipse User |
|
|
|
Hi,
S.Witte wrote:
> What is the (correct) way to include utility jar files into the
> plugin. And, of course, ship them with the deployable jar for
> the update site.
Recently I've gone down the path of creating a separate plugin for each
utility jar that I need to ship (setting the plugin version number to
match the release number of the wrapped jar file). In this way I'm able
to set library dependencies based on the eclipse model, and not
re-package the same libraries for every different feature variant I want
to ship.
Aside: I've started to wonder about the merit of a central Eclipse
repository for jar's that have been wrapped, and the possibility of an
automated lookup in cases where a class is not found... then download on
demand.
> I tried to put them in the build.properties like this:
> source.<project>.jar = src/
> bin.includes = plugin.xml,\
> *.jar,\
> icons,\
> <project>.jar,\
> lib/*.jar
A cautionary tale - if you're using wildcards in your bin.includes, be
sure not to include the directory where your output jar file will end up
- if you do, subsequent builds will recursively include the old output
jar from the previous build, eventually making it huge.
i.e. lose the first "*.jar".
source.<project>.jar = src/
bin.includes = plugin.xml,\
icons,\
<project>.jar,\
lib/*.jar
As for your error: this is a long-shot, but since everything else seems
normal... your problem *may* be in your build.xml file - did you
generate it before or after you populated the build.properties file?
(you have to do it after)
To be sure, try unzipping your output jar file and seeing if all the
expected content is there.
HTH
rich
--
|
|
|
|
|
|
|
|
|
|
| Re: plugin classpath util jars [message #146409 is a reply to message #145938] |
Mon, 20 October 2003 04:09 |
| Eclipse User |
|
|
|
:-)
It works now!
I had a hard time figuring out what the problem was but after some testing i
found that i cannot
package prefix any of the jars, not the project jar and not the util jars!
As soon as one package prefix is defined the class path gets confused.
This is strange isn't it?
Rich, thanks a lot!
"rich boakes" <rich.boakes@port.ac.uk> wrote in message
news:bmpdi3$fja$1@eclipse.org...
> Lets take a step back to ensure we're answering the right questions :)
>
> The original post had two questions - one involved how to package for
> deployment and one involved a problem with runtime testing.
>
> 1: For deployment, there are two jars that you need to build.
>
> Jar 1: contains class files plus anything "non-java"
> in your source directory - this is the jar that
> becomes <project>.jar.
>
> Jar 2: contains <project>.jar, plus any files you list in
> the build.properties file. This is the jar which can then be
> packaged up in a feature and distributed.
>
> Both these jars are created automatically by Ant.
>
> 2: For development, you don't need to build any jars - painful
> experience taught me that it's 99.9% down to the plugin.xml file
> (perhaps someone can confirm this). I've had a poke around
> in the runtime-workspace .registry file and it's contained a
> reference to the root my original projects, rather than copying
> them over.
>
> So the error you're getting in development is more likely to
> do with some other problem.
>
> Idea:
>
> Are you *sure* the classes you mention really are in util.jar?
> i.e. Could they be being picked up from somewhere else at compile
> time, meaning you don't see the problem until you have your
> runtime failure?
>
>
> To be sure, I worked a quick example through.
>
> 1. create a java plugin with a view (Test2Plugin)
> 2. add "lib" directory
> 3. add "lib/stuff.jar"
> 4. look in stuff.jar and find an instantiable class.
> 5. edit Test2Plugin.java to contain an instance of that class
> 6. notice the red wiggly line because stuff.jar is not
> yet on the classpath
> 7. add stuff.jar to the classpath (using properties wizard)
> 8. in Test2Plugin.java do an "Organise Imports".
> 9. No more red sea - class compiles successfully.
> 10. Run the plugin.
> 11. Plugin errors (NoClassDefFoundException) - yay!
> 12. Edit plugin.xml. In the runtime tab there is "Test2.jar"
> so add the run-time library "lib/Stuff.jar"
> (the xml now looks like this)
> <runtime>
> <library name="Test2.jar"/>
> <library name="lib/Stuff.jar"/>
> </runtime>
> 13. Unlucky for some - run it again - it works.
>
> Can you go through this process and get the same result?
>
> Rich
>
|
|
|
Powered by
FUDForum. Page generated in 0.04294 seconds
Home