Extensible Builders
Locked
 
|
Hi all,
Let me start by saying that this is a mostly theoretical question. It is unlikely that (at the moment) I have either the skill or the time to work on any of this... I've been looking at the old GroovySWT SwtBuilder. This component turns out to be quite tricky to build, due to the dependencies on various Eclipse libraries, and the fact that the build system seems to be set up to use maven. Specifically, the SwtBuilder has the following dependencies: - org.eclipse.swt - found an up-to-date repo for this at http://swt-repo.googlecode.com/svn/repo/ - also available as a standalone download from eclipse.org - org.eclipse.jface, http://swt-repo.googlecode.com/svn/repo/, no standalone download from eclipse.org - org.eclipse.jface.databinding, can't find a repo, no standalone download from eclipse.org - org.eclipse.core.commands, repo available, no standalone download from eclipse.org - org.eclipse.core.databinding - org.eclipse.core.databinding.*, no repo, no standalone download from eclipse.org - org.eclipse.osgi, repo available, no standalone download from eclipse.org - org.eclipse.equinox.common, repo available, no standalone download from eclipse.org - org.eclipse.ui.forms, no repo, no standalone download from eclipse.org This list isn't complete I know, but I hope it illustrates the problem in setting up a good build environment *and distribution*. You basically need a full Eclipse install, then find the relevant jars and copy them out of the eclipse installation directory in order to make a standalone distribution for SwtBuilder, or include complex installation instructions so users can do that extraction themselves. The current SwtBuilder source tree seems to solve this by including its own local maven repository *inside the eclipse project* that has copies of the relevant libraries, but from a very old Eclipse version (<=2009). No, as I see it, there is a use case for an SwtBuilder that only depends on SWT, not on most of the rest of the dependencies. Most of those other dependencies are introduced because of the separate JFace and Forms functionality in SwtBuilder. So it would be nice if we could refactor SwtBuilder somehow so that it can be build to only have a run-time dependency on SWT, and have JFace and Forms functionality only 'switched' on when the other relevant libraries are actually available in the classpath. That "switch on" could be done dynamically (eg some check to see if the relevant jars are available at runtime and otherwise throw a RuntimeException), or require some explicit enablement in the SwtBuilder API to tell groovy "JFace should be available", possibly with some static type-checking thrown in so that groovy can complain at compile time if you try to use JFace but you haven't switched it on and you haven't included the relevant jars in your classpath. Is something like this possible with a FactoryBuilderSupport based Builder? On a side note, it appears that Groovy is now completely build using Gradle, so would it make sense to update SwtBuilder as well to move from maven to gradle? (I only know the theory behind maven & gradle, have no practical experience with either of them, so....) Maarten --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
I feel your pain! Here's a short answer: 2) Moving to Gradle, yes, good idea. Guillaume On Tue, Jan 15, 2013 at 8:39 AM, Maarten Boekhold <[hidden email]> wrote: Hi all, Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
|
|
Hi Guillaume,
On 01/15/2013 12:20 PM, Guillaume Laforge wrote:
So, again purely theoretically, how would one go about that? Are there any specific features of FactoryBuilderSupport that one would need to look at to conditionally enable certain parts of the DSL?
Probably would need feedback from Andres (aalmiray) on this this, as he still seems to use this code in griffon... Maarten ps. odd, I have not received my own original mail on the mailing list yet...
|
|
|
On Tue, Jan 15, 2013 at 9:30 AM, Maarten Boekhold <[hidden email]> wrote:
Andres will be your man here for the details and the best approach :-)
+1
At least, I've seen it, otherwise I wouldn't have been able to answer you ;-) Guillaume
Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
|
|
The mailing list seems to avoid sending emails to the author, so you don't get 2 copies of everything you reply to.
Alan
On Tue, Jan 15, 2013 at 12:42 AM, Guillaume Laforge <[hidden email]> wrote:
|
|
|
In reply to this post by Maarten Boekhold-2
We had a similar situation in GfxBuilder, where some nodes would become active if and only if some JARs were available in the classpath. FBS does not provide any facilities for this out of the box, however you can build your own. In GfxBuilder we decided to go with ServiceLoader, as shown in lines 101 - 118 https://github.com/griffon/gfxbuilder/blob/master/gfxbuilder-core/src/main/groovy/griffon/builder/gfx/GfxBuilder.groovy That code loads builder plugins available int he classpath, such as gfxbuilder-swing https://github.com/griffon/gfxbuilder/blob/master/gfxbuilder-swingx/src/main/groovy/griffon/builder/gfx/SwingxGfxBuilderPlugin.groovy GfxBuilder sports a multi-project Gradle build with some local dependencies, which I think may match what you want to accomplish https://github.com/griffon/gfxbuilder/ |
«
Return to Groovy Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |