reviewer's feedback

document details

doc name jEdit plugin development HOW-TO
author/editor Andy Streich
version 3
length 5 pages (including this one)
date 7 July 2006

version history

version released for review
3 7 July 2006
2 18 June 2006
1 9 June 2006

Review comments and responses:

comments on v2

19 June Marcelo V

Responding to a question bouncing between Dale A. and me:

> Re: plugin HOW-TO v2 for review
> 2006-06-19 19:28
> Since I wrote plugin-build.xml I'll chime in with my two bits. :-)
> Andy Streich wrote:
>> Looking at plugin-build.xml, it seems to be carefully constructed to not
>> complain as long as you do not define the ant-contrib.jar property. That is,
>> the taskdef that loads it has onerror="ignore" and the two targets that use it
>> are dependent on ant-contrib.jar being defined.
> You're right, you don't need ant-contrib.jar to use plugin-build.xml
> (and Dale, I just tested it, Ant 1.6.5). That jar file is used only for
> the code that deals with plugin dependencies and cvs access.
> Now what's that?
> That's some code I wrote because some people wanted a feature to build
> dependencies plugins from other build files. So, let's say,
> ProjectViewer depends on CommonControls, so I'd tell PV's build file
> "build your dependencies!" and it would build CommonControls.jar.
> The code is there in the build file but I've actually never tried it, so
> I wouldn't be surprised if it didn't work at all. It's supposed to "cvs
> update" the dependencies and call "ant build" on their build.xml. And of
> course, you'de have to say your prayers and hope it worked.
> Which brings me to another comment about your notes: in your guide
> (pluginBuildFiles.html#pb), you say that build.xml has to define the
> "plugin.dependencies" property for it to work. That's not true; that
> property is used only by this "dependency building" code which is not
> necessary to build the plugin at all. Other than that, it's not used
> anywhere else in the regular build process performed by the packagers.

Removed material related to "plugin.dependencies" property.

comments on v1

15 June 2006 Jeffrey H

> This is excellent work. I think you have the correctness down pat

Let's see if this revision alters that conclusion. ;-)

> Page 1:
> First steps – I would add somewhere here where the source files go
> when you download plugins with source code.  I know its in there
> later, but it'd be good to specify it here.


> First steps – perferences should be preferences


> Page 2:
> Plugin directory structure – Does the tree represent how jEdit does
> it, or how an example plugin is laid out.  I'm pretty sure it's the
> former.  If so, add an example tree for your Xilize plugin so we can
> see an actual example.


> – Under the code box, I'd add a note that any and all
> files found in any location will be loaded in that
> order.  Also, per the Ant convention, the first file to set a property
> wins and subsequent attempts to reset a property will fail.


> build.xml – Change the project name to NameOfYourPlugin.  Please
> explicitly state that the name of the jar file from the example in the
> box would be NameOfYourPlugin.jar  This helps reinforce the point that
> the name of the jar file should be the name of the plugin.

done — I think. Please check.

> plugin-bulid.xml – Right at the top, 'Note: to' should be 'Note: two'


> plugin configuration files – In the first box, the number of .props
> files should be exactly one.  I may be wrong about this, but I think
> jEdit can get confused if it loads more than one .props file.  I KNOW
> the plugin scripts can.  I think we should limit the number of .props
> files in a plugin to one and only one.  You may want to confirm this
> with Slave or Alan.

okay, I asked Slava and Alan and am waiting for an answer.

> ant-contirb – The packaging process doesn't acutally automatically get
> the source code and build dependencies.  We have a script that will go
> and download the correct binary version, but we have to manually move
> them to the correct location to be found during the build process.

corrected, the section now says less.

> Page 3:
> special requirements – under special jar directory, I think you want
> to change "The sources for these files are must be ..." to "The
> sources for these files must be ..."


> Lastly, I like the shameless plug.


18 June 2006 Alan E

> There should be a single plugin properties file, in the ROOT directory
> of the plugin file tree, same name as the plugin, to make it easier
> for human packagers as well as automated scripts to find. This is a
> file that is looked at many more times than it is edited, but is also
> frequently edited by plugin packagers, once it is submitted to CVS.

Got it. I trust you will see that the javadoc for is changed to reflect this.