Question for everyone about building a jar

Discussion in 'Java' started by Harpstein, Sep 18, 2003.

  1. Harpstein

    Harpstein Guest

    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.


    Harpstein, Sep 18, 2003
    1. Advertisements

  2. 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

    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.

    Brian J. Sayatovic, Sep 18, 2003
    1. Advertisements

  3. Harpstein

    Lee Peterson Guest

    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.

    Lee Peterson, Sep 19, 2003

  4. What he said.


    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?
    Thomas G. Marshall, Sep 19, 2003
  5. 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.

    Brian J. Sayatovic, Sep 19, 2003
  6. 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?
    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...
    Thomas G. Marshall, Sep 19, 2003
  7. Harpstein

    Harpstein Guest

    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, Sep 19, 2003

  8. 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
    Thomas G. Marshall, Sep 19, 2003
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.