Extensible Builders

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Extensible Builders

Maarten Boekhold-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Extensible Builders

Guillaume Laforge-4
I feel your pain!
Here's a short answer:

1) FactoryBuilderSupport should be up to the task, as its purpose was to offer an extensible builder approach.

2) Moving to Gradle, yes, good idea.

Guillaume


On Tue, Jan 15, 2013 at 8:39 AM, Maarten Boekhold <[hidden email]> wrote:
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





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: Extensible Builders

Maarten Boekhold-2
Hi Guillaume,

On 01/15/2013 12:20 PM, Guillaume Laforge wrote:
I feel your pain!
Here's a short answer:

1) FactoryBuilderSupport should be up to the task, as its purpose was to offer an extensible builder approach.


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?

2) Moving to Gradle, yes, good idea.


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...

Guillaume


On Tue, Jan 15, 2013 at 8:39 AM, Maarten Boekhold <[hidden email]> wrote:
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





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Reply | Threaded
Open this post in threaded view
|

Re: Extensible Builders

Guillaume Laforge-4

On Tue, Jan 15, 2013 at 9:30 AM, Maarten Boekhold <[hidden email]> wrote:
Hi Guillaume,


On 01/15/2013 12:20 PM, Guillaume Laforge wrote:
I feel your pain!
Here's a short answer:

1) FactoryBuilderSupport should be up to the task, as its purpose was to offer an extensible builder approach.


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?

Andres will be your man here for the details and the best approach :-)
 
2) Moving to Gradle, yes, good idea.


Probably would need feedback from Andres (aalmiray) on this this, as he still seems to use this code in griffon...

+1
 
Maarten

ps. odd, I have not received my own original mail on the mailing list yet...

At least, I've seen it, otherwise I wouldn't have been able to answer you ;-)

Guillaume

 


Guillaume


On Tue, Jan 15, 2013 at 8:39 AM, Maarten Boekhold <[hidden email]> wrote:
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





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one




--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: Extensible Builders

catalan42
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:

On Tue, Jan 15, 2013 at 9:30 AM, Maarten Boekhold <[hidden email]> wrote:
Hi Guillaume,


On 01/15/2013 12:20 PM, Guillaume Laforge wrote:
I feel your pain!
Here's a short answer:

1) FactoryBuilderSupport should be up to the task, as its purpose was to offer an extensible builder approach.


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?

Andres will be your man here for the details and the best approach :-)
 
2) Moving to Gradle, yes, good idea.


Probably would need feedback from Andres (aalmiray) on this this, as he still seems to use this code in griffon...

+1
 
Maarten

ps. odd, I have not received my own original mail on the mailing list yet...

At least, I've seen it, otherwise I wouldn't have been able to answer you ;-)

Guillaume

 


Guillaume


On Tue, Jan 15, 2013 at 8:39 AM, Maarten Boekhold <[hidden email]> wrote:
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





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one




--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Reply | Threaded
Open this post in threaded view
|

Re: Extensible Builders

aalmiray
In reply to this post by Maarten Boekhold-2
Maarten Boekhold-2 wrote
On 01/15/2013 12:20 PM, Guillaume Laforge wrote:
> 1) FactoryBuilderSupport should be up to the task, as its purpose was
> to offer an extensible builder approach.

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?
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

Maarten Boekhold-2 wrote
> 2) Moving to Gradle, yes, good idea.

Probably would need feedback from Andres (aalmiray) on this this, as he
still seems to use this code in griffon...
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/