Susan Cline wrote:
Hi Dan,
I'll look into this. There are a few items I want to sort out with
the plug-ins. I'd like to automate the build, possibly create an
Eclipse update site at Apache and also ask folks about the current
packaging of the plug-ins. We've had a few queries about packaging
the core plug-in a little bit differently.
Susan
*/Daniel John Debrunner <[EMAIL PROTECTED]>/* wrote:
Andrew McIntyre wrote:
> I've been including the Eclipse plugins as part of the official
> release and posted on the downloads page, since the code for the
> plugins lives in the Derby code tree and is straightforward to
build,
> though the UI plugin build not automated.
I guess that was the part I was missing, the not automated build.
I hope
someone will scratch that itch one day.
Thanks,
Dan.
Hi,
Building the Derby 'ui' plug-in outside Eclipse PDE is desirable, but I
wish to point out that it depends on many of the Eclipse APIs.
org.eclipse.core.resources
org.eclipse.ui
org.apache.derby.core
org.eclipse.jdt.launching
org.eclipse.jdt.core
org.eclipse.core.runtime
org.eclipse.ui.console
etc... to name a few, for providing the pop-up menu, extension and
launching mechanisms in Eclipse. These come in separate jars or
as directories within Eclipse.
Automating the build means these Eclipse APIs should be available for
the build mechanim (Ant). Maybe we can add a property like 'eclipse.home'
in the ant.properties, and access the needed Eclipse jars for building.
Users can point this 'eclipse.home' to their respective Eclipse
environment, while
building the Derby 'ui' plug-in. This needs to be tested, though.
The current way (directory stucture + docs to build) was provided based
on what other Eclipse plug-in projects have done (Forrest, dbEdit
etc.). Building
the plug-ins is also simple, since all one needs to do is import the
plugin project into their Eclipse environment.
Setting up an update site for the Derby plug-ins will be very useful,
now since Derby has graduated and have a permanent url at Apache.
-Rajesh
