Where is Griffon 2.16.0?

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

Where is Griffon 2.16.0?

aalmiray
Administrator
Hello everyone,

For the past 5 years we've had a release every 3 months or so. Griffon 2.15.0 was releases back in June 2018 which means 2.16.0 should had been released by now. So, where is it?

The answer is, there won't be more releases in the 2.x series _unless_ a critical bug needs fixing. All our efforts are currently concentrated in getting 3.0.0 out of the door. This release will bring the following changes:

 - Java 8 as a minimum.
 - Jigsaw compatibility, i.e, ability to run applications in the module classpath.
 - JSR377 integration. Griffon is the Reference Implementation for JSR377.
 - (Possible) Merge Basilisk with Griffon, allowing a single framework to be used to write desktop/mobile applications.

The work for 3.0.0 is currently posted to the jsr377 branch, which you can see at https://github.com/griffon/griffon/tree/jsr377

Please bear with us for the next couple of months as we need the extra time to get JSR377 and Griffon aligned. If you have any questions regarding the future of Griffon, or need additional support in 2.x, do let us know ;-)

Feedback welcome.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Where is Griffon 2.16.0?

mecorusfc
I don't know how many people are using Griffon.  One thing I've noticed is backward compatibility is a low priority for this framework.  I've enjoyed using it since 2010 (actually a little in 2009) but I've found that it is very heavy on cool guru stuff and upgrades are always a chore.  Simplicity would be a better goal than any of the goals for 3.0 except for the Java 8 and above goal.

Here's an example.  The @TestFor annotation requires that the service or controller under test extend GriffonArtifact.  This is accomplished through guru tricks such as the @ArtifactProviderFor.  My IDE (IntelliJ IDEA Ultimate 2018) lights up all my tests because of this.  I tried going without @TestFor and that didn't work with the rule.  I tried putting the GriffonArtifact on directly and that breaks other stuff.  I'm stuck with my IDE lit up all red and I am now being trained to distinguish between "good errors" and "bad errors" by this framework.  That's not healthy and all that trickery is not really that valuable.  It's making something you do for 5% of your project time really fast but the 95% is slower because of it.

In addition, all the annotations tend to defeat code coverage tools so I'm stuck running both Cobertura (so I can see which lines in the class are not covered when it sees that correctly) and JaCoCo which seems to capture more of the coverage but doesn't show me which lines aren't covered so it is only useful as an overview of my progress.  I was able to do true Test-Driven Development in the very early versions but it (Griffon) really dissuades me from that best practice these days.

As I say, I don't know who is asking for these things (Jigsaw, JSR377, Basilisk) but I'd like to put in a vote that 3.0.0 change nothing other than Java 8/10/11 support and that it move towards a simpler and more usable framework.  More focus on testability would be great.  The integration testing support is definitely a step in the right direction.  A focus on backward compatibility would be awesome.  The current path is really hard to stick with.

Reply | Threaded
Open this post in threaded view
|

Re: Where is Griffon 2.16.0?

aalmiray
Administrator
Hi Mike,

It looks to me you're having trouble with a Groovy codebase, isn't it?

The short-hand notation for writing any Griffon artifact (Controller, Service, Model, View) with Groovy looks like this

    @ArtifactProviderFor(GriffonController)
    class SampleController { ... }

whereas in Java it looks like this

    @ArtifactProviderFor(GriffonController.class)
    public class SampleController extends AbstractGriffonController { ... }

Remember that almost all Java code is valid Groovy code, thus the second snippet can be used with Groovy too. You can turn that snippet of code into more idiomatic Groovy with this form

    @ArtifactProviderFor(GriffonController)
    class SampleController extends AbstractGriffonController { ... }

In other words, you can dial up or down how much idiomatic your Groovy code looks like. The framework does not force you to go full idiomatic 100% Groovy; artifacts created using the Lazybones templates/Maven archetypes suggest some idioms but you can change them at any time.

Usages of the @TestFor annotation will certainly be marked with red squiggles if the artifact under test does not explicitly extend a base Griffon artifact type (such Controller, Service, etc). the @ArtifactProviderFor annotation serves 2 purposes:

 1. create an entry under META-INF/griffon/<artifact_type> with the fully qualified class name of the annotated class.
 2. inject the corresponding artifact behavior if the annotated class does not explicitly extend an specific artifact class.

The magic of #2 allows developers to write short-hand code but confuses IDEs because they do not have all the information ahead of time, however the generated bytecode is 100% functional. This means that if you want to dial the magic up to 11 you must pay the price of your IDE getting confused, but the build tool (Gradle or Maven) will do the right thing. If you add more Java-ism to your Groovy code (dial down the magic) then your IDE will be happier as it will have access to types and other implicit magic that you made explicit.

It's expected of developers to pick how much magic they want to see applied, depending on how comfortable they are with certain idioms. Going forward, with JSR377 other magic conventions that currently exist with Griffon will become more explicit, for example:

 - all event handlers must be annotated with @EventHandler instead of using a naming convention.
 - all actions must be annotated with @ActionHandler instead of using a naming convention.
 - usage of @ServiceProviderFor (or event Google's AutoService) for all artifacts (this means @ArtifactProviderFor goes the way of the Dodo).
 - PropertyEditors (and @PropertyEditorFor) disappear in favor of JSR377's Converter and ConverterProvider registered using @ServiceProviderFor or AutoServirce (or manual registration, your choice).
 
On the other features

 - Jigsaw support is required for running in the module path. Griffon applications should continue to work on the classpath.
 - Basilisk was a test to figure out how Griffon could work with mobile environments (iOS and Android). There are some changes such as a different version of Guice (no-aop), an alternative to the java.beans package (via openbeans), and others. All these changes are viable for Griffon 3.0 and do not constitute big changes as opposed to integrating with JSR377.

I'm sorry you've had a bad experience so far migrating from version to version, we've tried to keep compatibility as much as possible, yet we know some changes were needed. On every release we published warnings for such changes in the Release Notes, as well as a link to a compatibility report.

We're always open to critique and feedback, that's how we can make the framework better and easier to use.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Where is Griffon 2.16.0?

mecorusfc
This explanation was helpful.  The piece that I needed was to extend AbstractGriffonService in my services and AbstractGriffonController in my controllers.  That helped IntelliJ to be more calm.  As far as backward compatibility, I still think this framework does more breaking changes than some others.  For me the trick is going to be upgrading more often to lessen the affect of that.
Reply | Threaded
Open this post in threaded view
|

Re: Where is Griffon 2.16.0?

aalmiray
Administrator
Hi Mike,

Could you give us a bit more of details regarding the binary compatibility issues you faced. Most changes in the framework have been tracked using Clirr.

Every release announcement publishes a compatibility report (for example http://griffon-framework.org/reports/2.9.0/compatibility-report.html when upgrading to 2.9.0/2.9.1/ from 2.8.0). Even if a break is made (such as additions to interfaces as seen in 2.11.0 http://griffon-framework.org/reports/2.11.0/compatibility-report.html) most changes are made in such a way there are sensible defaults and base implementations in place.

I just recently tried the following experiment:

 - create a Griffon application targeting version 2.0.0 using the Lazybones griffon-javafx-java 1.0.0 template (app1)
 - create a Griffon application targeting version 2.15.0 using the Lazybones griffon-javafx-java 1.15.0 template (app2)
 - copy the javafx-plugin.gradle file from app2 into app1.
 - comment usages of all gradle plugins except for `stats` and `javafx`.
 - launch app1 by invoking `./gradlew run`.

There were no code changes needed, even the deprecated constructors for AppController, AppModel, and AppView are honored; no problem with missing @MVCMember, @ControllerAction, @Nonnull and other annotations. Of course, this is a trivial application.

Have you had the need to inject custom implementations of core Griffon types, such as MVCManager, UIThreadHandler, and others (found in griffon.core.*)? If so, did you base your implementations in the base classes provided in the org.codehaus.griffon.runtime package? If this is the case then most of the added functionality that resulted in a binary breakage should had been covered. If not (which is OK not to use these base classes too) then you definitely would have suffered from class change errors and be forced to implement the new contracts.

Cheers,
Andres