| doc name | jEdit plugin development HOW-TO |
| author/editor | Andy Streich |
| version | 3 |
| length | 5 pages (including this one) |
| date | 7 July 2006 |
| version | released for review |
| 3 | 7 July 2006 |
| 2 | 18 June 2006 |
| 1 | 9 June 2006 |
Review comments and responses:
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.
> 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.
done
> First steps – perferences should be preferences
done
> 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.
done
> build.properties – Under the code box, I'd add a note that any and all
> build.properties 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.
done
> 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'
done
> 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 ..."
done
> Lastly, I like the shameless plug.
cool.
> 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 PluginJAR.java is changed to reflect this.
