Message-ID: <1864607740.4585.1369459485801.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4584_873696097.1369459485801" ------=_Part_4584_873696097.1369459485801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Griffon 0.9 =E2=80=93 "Aquila chrysaetos" - is the fifth major= release of Griffon.
This release represents a huge leap in behavior and bug fixes, which war= ranted a bigger jump in version number. There's still room for improvement = but the feature set for 1.0 is almost complete. Additional features may be = delivered via plugins rather than having them in core.
Perhaps the biggest improvement at buildtime is the synchronization of t= he codebase with Grails 1.3.2, which brings the following benefits:
Griffon 0.9 comes with the recently released 1.7.3 version of the Groovy= language
Griffon 0.9 now uses JUnit 4 to run tests. JUnit 4 features a richer ass= ertion API and many features like timeouts, ignores, class level before and= after methods, hamcrest matchers, assumptions, theories and more.
Pre Griffon 0.9 tests are fully backwards compatible.
griffon-app/conf/BuildConfig.groovy file is available=
that allows you to configure different aspects of the Griffon build includ=
ing output paths and servers used for resolution of plugins:
This file replaces
griffon-app/conf/Config.groovy as the so=
urce of buildtime configuration.
Config.groovy has been promot=
ed to runtime. Configuration set in
BuildConfig.groovy (which =
is per application/plugin) can be merged with global settings if
R_HOME/.griffon/settings.groovy is available.
You can now configure secure plugin repositories in
The same documentation engine that powers the Griffon reference documentation is now available in your projects. Si= mply create your documentation inside the src/doc/ref and src/doc/guide dir= ectories of your project. See the Gri= ffon documentation source for an example.
The order of invocation of build event handlers now honors the dependenc=
y order of the plugin that provides them. For example the
t event handler defined by the lang-bridge plugin will be called bef=
ore the same event handler provided by the clojure plugin, because the late=
r depends of the former. Previous behavior was to invoke event handlers in =
alphaetical order of discovery.
Griffon now supports the ability to configure multiple plugin repositori=
es by providing a
$USER_HOME/.griffon/settings.groovy file or =
griffon-app/conf/BuildConfig.groovy file that contains the c=
onfigured repository details:
The Griffon plugin discovery commands like list-plugin and install-plugi= n will then automatically work against all configured repositories. To rele= ase a plugin to a specific repository you can use the repository argument:<= /p>
Plugins no longer need to be checked into SVN and will automatically be = installed via a plugins metadata when the application is first loaded.
In addition, plugin dependencies are now resolved transitively.
An application can now load plugins from anywhere on the file system, ev=
en if they have not been installed. Simply add the location of the (unpacke=
d) plugin to you
This is particularly useful in two cases:
A LICENSE.txt file is now mandatory if you intend to release a plugin. A= ny LICENSE* and README* files located at the basedir of the plugin files wi= ll be automatically added to the generated zip file.
A source jar will generated for a plugin/addon if any of the following i= s true:
src/main) are present =09
griffon-app/conf/Bui= ldConfig.groovy. The value must be a list of directories relative to= the plugin's basedir.
src/test) are available
A test jar will contain all compiled classes that may have been generate=
d by test sources from
src/test, including test resources from=
A javadoc jar will be generated from all sources (artifacts, regular, te= st and additional).
If you prefer to use Git/Mercurial/etc. to version control your plugin y= ou can now distribute only the zipped release of the plugin in the central = repository and continue to manage the actual sources outside of SVN:
Previously to Griffon 0.9 running integration tests on a plugin/addon re=
sulted in an error (missing a
GriffonApplication instance). Ho=
wever with the availability of a default
MockGriffonApplication integration testing is now possible.
Griffon 0.9 features a new DSL for configuring JAR dependencies that can= be resolved against Maven repositories:
Built on Apache Ivy, users can now explicitly control how Griffon resolv= es all of its dependencies without needing to use Maven or Apache Ivy direc= tly.
There is also a new command to easily install dependencies into your loc= al cache for use with the DSL:
Griffon now has full support for publishing plugins to (using the Maven Publisher plugin) an= d reading plugins from Maven compatible repositories.
You can easily configure additional plugin repositories in
nfig.groovy using the Ivy DSL:
The central Griffon repository can also now be easily enabled and disabl= ed by including using the griffonCentral method:
Alongside the new Maven repository support you can now declare plugin de= pendencies using the Ivy DSL:
Which allows you to easily control plugin exclusions:
And the scope of a plugin:
The test running mechanics have been completely overhauled, opening the = door to all kinds of testing possibilities for Griffon applications. Previo= usly it was very difficult for non JUnit based tests to be deeply integrate= d into Griffon (e.g griffon-easyb). Expect to see testing plugins taking ad= vantage of this new infrastructure.
There is now a more sophisticated mechanism for targeting the exact test= you wish to run. Previously, it was only possible to target test phases bu= t it is now also possible to target test types .
You target particular test phases and/or types by using the following sy= ntax:
Either side is optional, and it's absence implies all =E2=80=A6
It can be used in conjunction with test targeting=E2=80=A6
And is additive=E2=80=A6
Legacy phase targeting syntax is supported for backwards compatibility= p>
You can can force a clean before testing by passing -clean to test-app:<= /p>
By default, griffon does not show the output from your tests. You can ma= ke it do so by passing -echoOut and/or -echoErr to test-app:
griffon.test.mock.MockGriffonApplication is a fully functio=
nal GriffonApplication with the advantage that it lets you override the loc=
ation of all configuration classes: Application, Builder, Config and Events=
If you choose to change the default UIThreadHandler then you must do it = so right after the application has been instantiated and no other operation= that requires multi-thread access has been called, otherwise you won't be = able to change it's value.
By default, a MockGriffonApplication defines the following:
The remaining classes have these settings:
Both applications and plugins/addons now support defining resources that=
should be packaged inside their respective jar's META_INF directory. the d=
griffon-app/conf/metainf is where all these resources=
should be placed.
Targets coming from the In=
staller plugin can be used with the
package command if the=
plugin is installed, for example
Results in the same output as running
Additional targets are: rpm, deb, mac, windows, jsmooth
Intellij IDEA 9 comes with Groovy DSL support (Mr. Haki explains it well= here). Griffon's buil= time jar (griffon-cli) includes a GDSL file for all MVC dynamic methods, th= reading methods and SwingBuilder nodes. Expect additional GDSL files to bec= ome available in plugins as new versions are released.
The gradle command supports camel case expansion of a target, this means= you can type
and it will be expanded to 'createPackage' for instance. The Griffon com= mand now sports a similar feature. Creating a new application is as simple = as
You'll get a list of options when the expanded script is ambiguous, for =
cA resolves to
create-archetype, so be sure to write enough c=
haracters to let the expansion be resolved unambiguously.
Another interesting feature of gradle is that it ships with a command wr=
apper (gradlew) that enables a developer to build a project that requires g=
radle but without having a preinstalled version of gradle. This means the p=
roject is self contained in terms of its build. Griffon 0.9 provides a
This command will download Griffon from a predefined location and run it= , thus enabling developers to ship an application in source form to their f= riends and let their friends build the application without needing to insta= lling Griffon in the typical way.
While it's true that artifact templates can be provided by plugins it si= mply was not possible to configure how an application is created. Applicati= on Archetypes fill this gap by providing a hook into the application creati= on process. Archetypes can do the following:
So, if your company requires all applications to be built following the = same template and basic behavior then you can create an archetype that enfo= rces those constraints. Archetypes are simple zip files with an application= descriptor and templates. Despite this, Griffon provides a few scripts tha= t let you manage archetypes
Archetypes are installed per Griffon location under
iffon/<version>/archetypes. Archetypes are registered with an =
application's metadata when creating an application. You can either manuall=
y modify the value of 'app.archetype' to a known archetype name or specify =
-archetype=3D<archetypeName> flag when creating a new=
If no valid archetype is found then the
default archetype w=
ill be used.
It is now possible to contribute nodes, methods and properties to artifa= cts other than views using the '*' notation, for example:
results in all explicit methods from MyCustomAddon being added to contro= llers; all methods, props and nodes being added to actions (if actions is c= onfigured as an MVC member).
The following additional qualifiers are available too: '*:methods', '*:f= actories', '*:props'.
The global event handlers defined in
y are now loaded before any event are fired, including addon events.=
You can call all of UIThreadHelper's methods on a life-cycle script usin=
g the short notation, the same one available to the application instance an=
d MVC members, i.e.
execFuture(). Refer to the Griffon Guide to know more about the threading options prov=
ided by UIThreadHelper.
All applications have the same life-cycle phases. You can inspect in whi=
ch phase the application is currently on by calling the
getPhase() method on an application instance. Valid values are defined by the enum : INITIALIZE, STARTUP, READY, =
MAIN and SHUTDOWN.
All applications sport a bound
java.util.Locale property wh=
ose value is initially the default Locale. You can change this property to =
let other components be aware of Locale changes as long as they are registe=
red as PropertyChangeListeners on the application instance.
There's a new AST transformation (
that enables you to write PropertyChangeListeners without all the boilerpla=
te code. The @Listener annotation can be applied to both properties and cla=
sses, and it accepts single closures or a List of closures as value. The fo=
llowing example registers two PropertyChangeListeners, the first using a di=
rect closure definition, the second using a property reference found in the=
WindowManager class is responsible for keeping track of=
all the windows managed by the application. It also controls how these win=
dows are displayed (via a pair of methods: show, hide). WindowManager relie=
s on an instance of
WindowDisplayHandler to actually show or h=
ide a window. The default implementation simple shows and hide windows dire=
ctly, however you can change this behavior by setting a different implement=
WindowDisplayHandler on the application instance.
The following example shows how you can animate windows using a dropIn e= ffect for show() and a dropOut effect for hide(). This code assumes you hav= e installed the Effects plugin.
Notice that the effects are executed outside of the UI thread because we= need to wait for them to finish before continuing, otherwise we'll hog the= UI thread.
The second step to get this example to work is to inform the application=
it should use Dropper to display/hide windows. This a task that can be eas=
ily achieved by adding an application event handler, for example in
Rationale: Classes under packages
griffon.*form part of the s= upported API and are visible to application developers. Classes under packa= ges
org.codehaus.griffon.*are considered internal details, th= ey may change in the future without notice.
griffon.swingprepare Griffon core fo= r a future Swing plugin. Classes under
org.codehaus.griffon.runtime.u= tilshould be used by the application's runtime only. Also, classes = under packages
griffon.*form part of the supported API and ar= e visible to application developers. Classes under packages
org.codeh= aus.griffon.*are considered internal details, they may change in th= e future without notice.
app.appFramesis no longer available. Use
Griffon 0.9 ships with sample applications of varying levels of complexi= ty demonstrating various parts of the framework. In order of complexity th= ey are:
File View is a simple demonstration of creating new MVCGroups on the fly= .
To run the sample from source, change into the source directory and run =
griffon run-app from the command prompt.
Font Picker demonstrates form based data binding to adjust the sample re= ndering of system fonts.
To run the sample from source, change into the source directory and run =
griffon run-app from the command prompt.
Greet, a full featured Griffon Application, is a Twitter client. It sho= ws Joint Java/Groovy compilation, richer MVCGroup interactions, and network= service based data delivery.
To run the sample from source, change into the source directory and run =
griffon run-webstart from the command prompt. Because Greet u=
ses JNLP APIs for browser integration using
run-app will preve=
nt web links from working.
SwingPad, a full featured Griffon Application, is a scripting console fo= r rendering Groovy SwingBuilder views.
|The JIRA server does not support trus=
t requests. Issues have been retrieved anonymously.You can set the macro to=
always use an anonymous request by setting the |
|Griffon 0.9 Re= solved Issues (51 issues)|
|=20||=20 GRIFFON-207||=20 "griffon run-app" gives java.lan= g.UnsatisfiedLinkError after a fresh install and creation of app|
|=20||=20 GRIFFON-216||=20 Can't run an application on Linux|
|=20||=20 GRIFFON-121||=20 Rearrange config files|
|=20||=20 GRIFFON-215||=20 Sample apps do not run with 0.9-SNAPSHOT= a>|
|=20||=20 GRIFFON-83||=20 Integration tests do not initialize the app= lication fully|
|=20||=20 GRIFFON-89||=20 Update core dependencies|
|=20||=20 GRIFFON-107||=20 Upgrade to JUnit 4|
|=20||=20 GRIFFON-133||=20 Desktop icons look really ugly on Ubuntu= a>|
|=20||=20 GRIFFON-141||=20 Port AntBuildListener from Grails|
|=20||=20 GRIFFON-142||=20 Upgrade testing facilities|
|=20||=20 GRIFFON-143||=20 Allow plugins to be released with zip-only= flag|
|=20||=20 GRIFFON-145||=20 Remove dead code copied from Grails|
|=20||=20 GRIFFON-148||=20 Events scripts provided by plugins should = honor plugin dependency order|
|=20||=20 GRIFFON-155||=20 Command-line takes, but does not honor, --= non-interactive|
|=20||=20 GRIFFON-159||=20 Allow addons to contribute methods/propert= ies to other artifacts|
|=20||=20 GRIFFON-172||=20 Dock icon looks ugly|
|=20||=20 GRIFFON-174||=20 Add a GDSL for all Swing, Threading and MV= C nodes and methods|
|=20||=20 GRIFFON-177||=20 Allow javaOpts to be specified on the comm= and line when executing run-app|
|=20||=20 GRIFFON-181||=20 Include LICENSE and README files when pack= aging plugins|
|=20||=20 GRIFFON-182||=20 Exclude *GriffonPlugin.class from applicat= ion jar file|
|=20||=20 GRIFFON-183||=20 Better integration of the Installer plugin= with core packaging options|
|=20||=20 GRIFFON-185||=20 Allow files to pe placed on the main jar= 39;s META-INF directory|
|=20||=20 GRIFFON-186||=20 Should read the application's configur= ation using the current environment|
|=20||=20 GRIFFON-187||=20 Expose UIThreadHelper methods to life cycl= e scripts|
|=20||=20 GRIFFON-188||=20 CreateMVC scripts throws an error when inv= oked on a plugin project|
|=20||=20 GRIFFON-190||=20 Allow central event handler to responde to= Initialize phase|
|=20||=20 GRIFFON-191||=20 Addon resources are not included in their = jar file|
|=20||=20 GRIFFON-192||=20 Add command target expansion on the comman= d line|
|=20||=20 GRIFFON-193||=20 Add license information to plugins|
|=20||=20 GRIFFON-194||=20 Allow a plugin to share base test code|
|=20||=20 GRIFFON-195||=20 Allow plugins to specify test only resourc= es|
|=20||=20 GRIFFON-196||=20 Plugin-info fails to display plugin descri= ption|
|=20||=20 GRIFFON-197||=20 Invoking test-app on a plugin results in e= rror|
|=20||=20 GRIFFON-199||=20 Create source and javadoc jars on plugin p= rojects|
|=20||=20 GRIFFON-200||=20 Griffon Guide: API links are broken|
|=20||=20 GRIFFON-201||=20 Javadoc: missing methods and properties on= some classes even though they have javadocs in source|
|=20||=20 GRIFFON-202||=20 Refactor API with better separation of pub= lic vs private|
|=20||=20 GRIFFON-205||=20 Installing a plugin does not uninstall oth= er versions|
|=20||=20 GRIFFON-209||=20 Add a griffonw command wrapper (like Gradl= e's)|
|=20||=20 GRIFFON-210||=20 Add a @Listener AST transform to register = PropertyChangeListeners|
|=20||=20 GRIFFON-211||=20 Add a mock version of GriffonApplication t= o be used on integration testing|
|=20||=20 GRIFFON-212||=20 Let applications know in which lifecycle p= hase thay currently are|
|=20||=20 GRIFFON-213||=20 Let applications be created with a custom = template|
|=20||=20 GRIFFON-217||=20 Can't run Griffon if JAVA_HOME is not = set|
|=20||=20 GRIFFON-218||=20 BuildConfig.groovy is not created on runni= ng create-app and upgrade scripts|
|=20||=20 GRIFFON-221||=20 Can't run FileViewer sample|
|=20||=20 GRIFFON-27||=20 Add shortcut generation to Installer plugin= izPack mode|
|=20||=20 GRIFFON-178||=20 Using custom environment in Environment.ex= ecuteForCurrentEnvironment doesn't work: MissingMethodException|
|=20||=20 GRIFFON-189||=20 Db4oHelper throws exception on startup whe= n deploying as java web start application|
|=20||=20 GRIFFON-208||=20 Installer creates a useless value in PATH = environment variable in windows when PATH does not exists at time of instal= lation|
|=20||=20 GRIFFON-214||=20 Remove redundant artifact suffixes when us= ing the scripts "griffon create-xxxxx"|