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.

    Thanks,

    harpstein
     
    Harpstein, Sep 18, 2003
    #1
    1. Advertising

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

    "Harpstein" <> wrote in message news:<>...
    > 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
     
    Brian J. Sayatovic, Sep 18, 2003
    #2
    1. Advertising

  3. Harpstein

    Lee Peterson Guest

    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
     
    Lee Peterson, Sep 19, 2003
    #3
  4. Lee Peterson <> horrified us with:

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



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

    Regards,
    Brian.

    "Thomas G. Marshall" <> wrote in message news:<AFtab.12877$>...
    > Lee Peterson <> horrified us with:
    >
    > 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?
     
    Brian J. Sayatovic, Sep 19, 2003
    #5
  6. Brian J. Sayatovic <> horrified us with:

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


    "Thomas G. Marshall" <>
    wrote in message news:7XEab.43$...
    > Brian J. Sayatovic <> horrified us with:
    >
    > > 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...
    >
    >
    >
    >
     
    Harpstein, Sep 19, 2003
    #7
  8. Harpstein <> horrified us with:

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

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    494
    Ralf Hildebrandt
    May 2, 2005
  2. Arnold Peters
    Replies:
    0
    Views:
    630
    Arnold Peters
    Jan 5, 2005
  3. muttley
    Replies:
    0
    Views:
    2,788
    muttley
    Oct 20, 2005
  4. cyberco
    Replies:
    4
    Views:
    3,864
    Roedy Green
    Feb 14, 2006
  5. Arnold Peters
    Replies:
    0
    Views:
    699
    Arnold Peters
    Jan 5, 2005
Loading...

Share This Page