Question for everyone about building a jar

H

Harpstein

Here's the deal...

I have a jar file that I'm using to develop integration into various Java
IDE's. Specifically JBuilder and Eclipse.

I'm pretty new to Java, so I'm not really sure how to handle building the
jar for each of these.

Should I maintain two seperate jar files or should I combine them all into
one jar, seperated by namespaces?

Using one jar would simplify the maintenance and I'm already using
namespaces so I could just tack on an extra name for eclipse (like
com.harpstein.eclipse) and one for JBuilder. However, is it lame to have
code in a jar that can't be used by an app loading it (ie. OpenTools code
when the Eclipse IDE is being used), or is this going to cause problems when
Eclipse loads my jar? I'm leaning toward going with one jar, seperated with
namespaces, but was hoping people here could shed light on the various
pros/cons of going this route compared with the seperate jars route.

Any feedback you can give would be greatly appreciated.

Thanks,

harpstein
 
B

Brian J. Sayatovic

One JAR sounds like it would be ideal, because users of any IDE could
refer to the same download and use it in either IDE. You certainly
want to separate by name space (i.e. package structure), as you
indicated.

However, there may be other issues. I developed a plugin for JBuilder
long ago, so I don't recall, but I know it, and probably eclipse, have
to "find" the plugins by relying on certain naming conventions of
files in the JAR that point to the plugin class. Just make sure the
requirements for this of each IDE do not conflict.

And, furthermore, I'm reccommending sharing the JAR under the
assumption that the meat of the plugin is truly identical for each
IDE, and it is just the GUI facade and/or the plugin hooks that
differ, so that 90% of them are overlapping anyways.

Regards,
Brian.
 
L

Lee Peterson

Hi Harp,

Brian J. Sayatovic wrote in message
One JAR sounds like it would be ideal, because users of any IDE could
refer to the same download and use it in either IDE. You certainly
want to separate by name space (i.e. package structure), as you
indicated.

However, there may be other issues. I developed a plugin for JBuilder
long ago, so I don't recall, but I know it, and probably eclipse, have
to "find" the plugins by relying on certain naming conventions of
files in the JAR that point to the plugin class. Just make sure the
requirements for this of each IDE do not conflict.

And, furthermore, I'm reccommending sharing the JAR under the
assumption that the meat of the plugin is truly identical for each
IDE, and it is just the GUI facade and/or the plugin hooks that
differ, so that 90% of them are overlapping anyways.

What he said. Plus, you asked "is it lame". No.

Your concern that the JVM will be overburdened
"when Eclipse loads my jar" is unfounded. The class loader will
only load what it needs. The so-called 'extra' stuff only is taking up
some disk space.


Lee
 
T

Thomas G. Marshall

Lee Peterson said:
Hi Harp,

Brian J. Sayatovic wrote in message


What he said. Plus, you asked "is it lame". No.

Your concern that the JVM will be overburdened
"when Eclipse loads my jar" is unfounded. The class loader will
only load what it needs. The so-called 'extra' stuff only is taking
up some disk space.


What he said.

.....errrr...

What if the application sniffs through the pluggin, grabbing the information
there, and places it into a GUI table for someone to pick and chose which
plugin to activate?

In other words, what if eclipse or jbuilder, actually read through the jar
file, find all the packages installed, and get confused by the "other"
non-conforming packages?
 
B

Brian J. Sayatovic

If JBuilder/eclipse load their plugins in that manner, I would be
shocked. Must plugin-loading systems I use look for a specific class
in a specific package, or a descriptor under META-INF. If two
disparate systems (JBuilder and eclipse) use the exact same manner for
detecting plugins, I would be surprised.

And if they just happen to scan through every class in every package
in the jar, looking for a class that implements some interface, even
that would be safe.

eclipse, for example, looks for some sort of plugin.xml file to find
out information about the plugin.

Regards,
Brian.
 
T

Thomas G. Marshall

Brian J. Sayatovic said:
If JBuilder/eclipse load their plugins in that manner, I would be
shocked. Must plugin-loading systems I use look for a specific class
in a specific package, or a descriptor under META-INF.

If it's a value within META-INF, than there had better either be
eclipse-specific values in there. If JBuilder assumed that /all/ the values
in META-INF belonged to it (why not, it is assuming you are giving it a
JBuilder pluggin) then the eclipse information would confuse it. No?
If two
disparate systems (JBuilder and eclipse) use the exact same manner for
detecting plugins, I would be surprised.

And if they just happen to scan through every class in every package
in the jar, looking for a class that implements some interface, even
that would be safe.

eclipse, for example, looks for some sort of plugin.xml file to find
out information about the plugin.

I'm missing something here: What if others tried to look at plugin.xml,
following eclipse's standard, and get confused?

I suppose that I'm postulating about something extremely unlikely then...
 
H

Harpstein

Thanks for all the feedback.

Eclipse scans the plugin.xml file you provide with your plugin (but this
file is not part of the jar.) for certain tags. In those tags you tell it
the package to look for.

JBuilder uses a manifest file, which you build into your jar file. Here you
also specify a certain package.

I tried it, and everything seems to be working just fine. At least on the
JBuilder side. I'm still in the early phases of my Eclipse integration but
so far that's working.


One person mentioned that they will probably share 90% of code... That's not
the case, since Eclipse doesn't use the OT api, and I have to inherit from a
lot of OT api classes for the JB integration.

Another issue, and maybe no one here has used Eclipse alot but... It seems
like they comletely reinvented the wheel as far as GUI classes go. Instead
of using stuff like JButton, JTree, etc.. they created their own classes to
do this and didn't even inherit off of the JDK base-class. This seems really
goofy to me...

-harpstein
 
T

Thomas G. Marshall

Harpstein said:
Thanks for all the feedback.

Eclipse scans the plugin.xml file you provide with your plugin (but
this file is not part of the jar.) for certain tags. In those tags
you tell it the package to look for.

JBuilder uses a manifest file, which you build into your jar file.
Here you also specify a certain package.

I tried it, and everything seems to be working just fine. At least on
the JBuilder side. I'm still in the early phases of my Eclipse
integration but so far that's working.


One person mentioned that they will probably share 90% of code...
That's not the case, since Eclipse doesn't use the OT api, and I have
to inherit from a lot of OT api classes for the JB integration.

Another issue, and maybe no one here has used Eclipse alot but... It
seems like they comletely reinvented the wheel as far as GUI classes
go. Instead of using stuff like JButton, JTree, etc.. they created
their own classes to do this and didn't even inherit off of the JDK
base-class. This seems really goofy to me...


Yes, and it's a HUGE argument as to whether or not they @#$%ed up.

They developed something called the SWT. It is a native-gui toolkit,
similar to the AWT, albeit better behaved, and somehow more "pc" looking, at
least on pc's.

But I still argue that "peer"ing over to native components is /still/ the
wrong approach and drawing everything from scratch is the right way to do
things.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top