Skip to content

isisaddons-legacy/isis-metamodel-paraname8

Repository files navigation

isis-metamodel-paraname8

Build Status

This extension for Apache Isis' metamodel support means that the name of action parameters can be inferred from the parameter name itself; that is, there is no need to annotate the parameter.

Background

Prior to Java 8 it was not possible to obtain the parameter names of methods using reflection. Since Isis builds the UI from the code features, this required the parameters to be annotated with @ParameterLayout(named=...) or @Named(...).

In Java 8 the Reflections API has been extended so that the parameter name is available (with the proviso that the code must also be compiled with a new -parameters compile flag).

This module provides an implemenation of Apache Isis' FacetFactory for Apache Isis so that this parameter name can be used, thereby avoiding the need to annotate action parameters.

Screenshot and Corresponding Code

From the demo app, here's the screenshot of an action to create a new object:

which renders the following prompt:

The corresponding code is simply:

public Paraname8DemoObject create(final String name) {
    ...
}

Compare this to the "normal" way, which required using either the @ParameterLayout(named=...) annotation:

public Paraname8DemoObject create(
        final @ParameterLayout(named="Name") String name) {
    ...
}

or alternatively the older @Named(...) annotation:

public Paraname8DemoObject create(
        final @Named("Name") String name) {
    ...
}

How to run the Demo App

The prerequisite software is:

  • Java JDK 8 (8.0.5 or later is required; -parameters was broken in very early builds of Java 8)
  • maven 3 (3.2.1 or later is recommended).

To build the demo app:

git clone https://github.com/isisaddons/isis-metamodel-paraname8.git
mvn clean install

To run the demo app:

mvn antrun:run -P self-host

Then log on using user: sven, password: pass

How to Configure/Use

To use "out-of-the-box":

  • in your project's root pom.xml, update the maven-compiler-plugin definition (in <build>/<pluginManagement>/<plugins>) to compile with JDK8, and specify the -parameters argument:
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.1</version>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
            <compilerArgument>-parameters</compilerArgument>
        </configuration>
        <executions>
            <execution>
                <id>source</id>
                <phase>compile</phase>
            </execution>
            <execution>
                <id>test</id>
                <phase>test-compile</phase>
            </execution>
        </executions>
    </plugin>
  • update your classpath in the pom.xml of your project's integtests module and also its webapp module:
    <dependency>
        <groupId>org.isisaddons.metamodel.paraname8</groupId>
        <artifactId>isis-metamodel-paraname8-dom</artifactId>
        <version>1.14.0</version>        
    </dependency>
  • in your project's webapp module, update your WEB-INF/isis.properties:
    isis.reflector.facets.include=\
                org.isisaddons.metamodel.paraname8.NamedFacetOnParameterParaname8Factory
  • in your project's integtest module, update your bootstrapping code to also install this facet factory:
    private static IsisConfiguration testConfiguration() {
        final IsisConfigurationForJdoIntegTests testConfiguration = 
            new IsisConfigurationForJdoIntegTests();
        
        ...

        testConfiguration.put(
                "isis.reflector.facets.include",
                "org.isisaddons.metamodel.paraname8.NamedFacetOnParameterParaname8Factory");

        return testConfiguration;
    }

Notes:

Configuring your IDE

Most IDEs compile the Java source code independently of Maven; this is certainly the case with both IntelliJ IDEA and Eclipse. You will therefore need to ensure that the IDE is set up to build using the -parameters flag.

For IntelliJ IDEA, for example, this can be found under the "Settings" dialog:

Other IDEs should have similar dialogues.

You'll also need to make sure that the IDE is set up to build and run with JDK8. In IntelliJ, this can be found under the "Project Structure" dialog.

Change Log

  • 1.14.0 - released against Isis 1.14.0
  • 1.13.0 - released against Isis 1.13.0
  • 1.12.0 - released against Isis 1.12.0
  • 1.11.0 - released against Isis 1.11.0
  • 1.10.0 - released against Isis 1.10.0
  • 1.9.0 - released against Isis 1.9.0

Legal Stuff

License

Copyright 2015-2016 Dan Haywood

Licensed under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

Dependencies

There are no third-party dependencies.

Maven deploy notes

Only the dom module is deployed, and is done so using Sonatype's OSS support (see user guide).

Release to Sonatype's Snapshot Repo

To deploy a snapshot, use:

pushd dom
mvn clean deploy
popd

The artifacts should be available in Sonatype's Snapshot Repo.

Release an Interim Build

If you have commit access to this project (or a fork of your own) then you can create interim releases using the interim-release.sh script.

The idea is that this will - in a new branch - update the dom/pom.xml with a timestamped version (eg 1.14.0.20170227-0738). It then pushes the branch (and a tag) to the specified remote.

A CI server such as Jenkins can monitor the branches matching the wildcard origin/interim/* and create a build. These artifacts can then be published to a snapshot repository.

For example:

sh interim-release.sh 1.14.0 origin

where

  • 1.14.0 is the base release
  • origin is the name of the remote to which you have permissions to write to.

Release to Maven Central

The release.sh script automates the release process. It performs the following:

  • performs a sanity check (mvn clean install -o) that everything builds ok
  • bumps the pom.xml to a specified release version, and tag
  • performs a double check (mvn clean install -o) that everything still builds ok
  • releases the code using mvn clean deploy
  • bumps the pom.xml to a specified release version

For example:

sh release.sh 1.14.0 \
              1.15.0-SNAPSHOT \
              dan@haywood-associates.co.uk \
              "this is not really my passphrase"

where

  • $1 is the release version
  • $2 is the snapshot version
  • $3 is the email of the secret key (~/.gnupg/secring.gpg) to use for signing
  • $4 is the corresponding passphrase for that secret key.

Other ways of specifying the key and passphrase are available, see the pgp-maven-plugin's documentation).

If the script completes successfully, then push changes:

git push origin master && git push origin 1.14.0

If the script fails to complete, then identify the cause, perform a git reset --hard to start over and fix the issue before trying again. Note that in the dom's pom.xml the nexus-staging-maven-plugin has the autoReleaseAfterClose setting set to true (to automatically stage, close and the release the repo). You may want to set this to false if debugging an issue.

According to Sonatype's guide, it takes about 10 minutes to sync, but up to 2 hours to update search.