#403 JavaSideKick 2.3.5 ready for release

closed
Alan Ezust
None
9
2007-08-08
2007-08-02
Dale Anson
No

JavaSideKick 2.3.5
Source: Source code is in SVN with the tag javasidekick-2-3-5 (https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/JavaSideKick/tags/javasidekick-2-3-5)
Announcement: Bug fix release:

1. fix for bug 1691416, some annotations cause parser to fail.
2. updated tiger.jj with updates to the java grammar posted on the javacc mailing list.
3. fixes for check imports for named nodes.
4. parser updates to better handle annotations.
5. improved ProjectViewer integration.
6. update to property file parser for \# in a key name so things like mode.c\#.sidekick-tree.auto-expand-tree-depth=4 are handled correctly.
7. fix for 1732337, Project Viewer is optional dependency, not a required one.
8. fix for potential NPE in VariableDeclaratorId.

Requires Java 1.5.0
Requires jEdit 04.03.03.00
Required plugins:
sidekick.SideKickPlugin 0.7.3
errorlist.ErrorListPlugin 1.4.2
Optional plugins:
projectviewer.ProjectPlugin 2.1.3

Short Description: SideKick to browse java, javacc, and property files.

Long Description: <html>
<p>
The JavaSideKick plug-in provides a highly customizable tool for navigating
through Java source code. Using Sidekick, you can see a tree view for the
hierarchy of classes, interfaces, and methods for the file in the current
buffer. In addition, attributes, extends, implements and method exception
information can be displayed.
</p>
<p>
In addition to java files, JavaSideKick also handles javacc files (.jj and .jjt)
and java property files.
</p>
</html>

Discussion

1 2 > >> (Page 1 of 2)
  • Jeffrey Hoyt
    Jeffrey Hoyt
    2007-08-05

    • assigned_to: nobody --> jchoyt
     
  • Jeffrey Hoyt
    Jeffrey Hoyt
    2007-08-05

    Logged In: YES
    user_id=396194
    Originator: NO

    Dale,

    That version of SideKick requires 4.3pre8. Should I lower the SideKick version or up the jEdit version? Also, if you could, please add CommonControls 0.9.0 to the dependencies list - the ProjectViewer requires it.

     
  • Dale Anson
    Dale Anson
    2007-08-05

    Logged In: YES
    user_id=187628
    Originator: YES

    Hi Jeff, up the jEdit version, please. I can make the change in the morning if that's easier. I'll add CommonControls too. I didn't know that's the way it worked, I didn't think I needed to specify all dependencies of what ever other plugins my plugin is dependent on? Same with dependencies of those dependencies?

    Thanks,

    Dale

     
  • Dale Anson
    Dale Anson
    2007-08-05

    Logged In: YES
    user_id=187628
    Originator: YES

    I bumped up the jEdit version, did a little code clean up, and fixed 1755930 while I was at it. Same tag name.

    I'm not clear on the CommonControls thing. JavaSideKick doesn't directly use it. ProjectViewer does, and JavaSideKick has an optional dependency on ProjectViewer. Does that mean I should specify an optional dependency for CommonControls? Has something changed where I need to declare this dependency? I added the optional dependency on ProjectViewer about a year ago.

     
  • Alan Ezust
    Alan Ezust
    2007-08-05

    Logged In: YES
    user_id=935841
    Originator: NO

    I would think that if PV is an optional depend, then so too should CommonControls be.

     
  • Marcelo Vanzin
    Marcelo Vanzin
    2007-08-05

    Logged In: YES
    user_id=75113
    Originator: NO

    If JavaSideKick doesn't use CommonControls directly I don't see why it should be a dependency. The PV dependency should take care of that.

    If I change PV's dependencies for any reason, that doesn't mean every plugin that depends on PV has to be re-released with an updated dependency list.

     
  • Alan Ezust
    Alan Ezust
    2007-08-06

    Logged In: YES
    user_id=935841
    Originator: NO

    I would think that if PV is an optional depend, then so too should CommonControls be.

     
  • Jeffrey Hoyt
    Jeffrey Hoyt
    2007-08-06

    Logged In: YES
    user_id=396194
    Originator: NO

    Vanza,

    Two reasons, neither terribly outstanding. 1) It makes sure the plugin author is aware of all the things their plugin is dependent on and 2) I try to do the build and run jEdit with only the dependencies listed. This is good because it makes sure all the necessary dependencies are listed. This is bad because it won't find conflicts with other plugins and it makes the me or the plugin author do more work tracking down the secondary dependencies. If the plugin author does it, they only have to do it once. I have to do it every time I package the plugin.

    Alan,

    You're right, of course.

    Jeff

     
  • Marcelo Vanzin
    Marcelo Vanzin
    2007-08-06

    Logged In: YES
    user_id=75113
    Originator: NO

    Jeffrey,

    Sorry if I'm blunt in this message, but:

    (1) if plugin A depends on plugin B, A's developer doesn't need to know what B depends on, since B's depencies may change. If A uses one of those dependencies directly, then yes, it should list it.

    (2) If your scripts rely on this to happen, they're broken.

    What if tomorrow I decide ProjectViewer should depend on Console? Are you gonna go and re-release all the plugins that depend on ProjectViewer so that they list the new dependency? That doesn't make any sense to me.

     
  • Jeffrey Hoyt
    Jeffrey Hoyt
    2007-08-06

    Logged In: YES
    user_id=396194
    Originator: NO

    No worries Marcelo. If I had skin this thin, I couldn't do this ;o).

    1) It's more of a matter of the author knowing the impact of adding a dependency. Some people (myself included) try to keep a relatively low footprint, so as a plugin author myself, I always try to figure out the impact of adding a plugin to my dependency list. For instance, I don't care for ProjectViewer because it doesn't support the way I work and it brings along a lot of baggage. I have passed on a plugin or two in my time because installing a 25kb brings with it 800kb of ProjectViewer. (DISCLAIMER - this is my opinion - others love ProjectViewer. Also, I have it installed currently - some plugin that required it was shiny enough that I bit the bullet.)

    2) Yup. The scripts I use are ignorant of dependencies. I have neither the time nor expertise to fix that (they are in PHP).

    And, no, of course I wouldn't re-release all the plugins - it's not necessary. The plugin manager will take care of it. Truthfully, if everything else were perfect, I wouldn't even have brought it up, but if the author is going to be modifying the file anyway, why not ask? This is about making my life easier and getting the plugin packaged faster for the author.

    Bottom line, it helps me get the thing released faster, makes the author aware of the true footprint of their plugin, and doesn't hurt anything.

     
1 2 > >> (Page 1 of 2)