This module, intended for use within Apache Isis, provides the ability to add multiple tags (or labels) to any entity.
For example, an Email
entity could be associated with a priority
tag of 'urgent', 'normal' or 'low', and could also
have a category
tag of 'work', 'family', 'friends'.
The idea is to allow a user to label an entity by offering a choice of other existing tags associated with other
entities of the same type and also tag type. That is, the combination of the entity type (eg com.mycompany.myapp.Email
) and the tag type
(eg priority
) creates a named set of available tags (eg 'urgent', 'normal', low').
As well as listing existing tags, new tags can of course also be created, and existing tags updated or removed.
The following screenshots show an example app's usage of the module with some sample fixture data:
... returning an example entity "Bip". The class of this entity is not of interest, what is of interest is that it
has two properties, brand
and sector
, that correspond to Tag
s:
Using the action, can update tag. The Tags
service provides a list of available tag (names) for this entity type
and tag name ("brand"):
The tag can then be saved:
If the tag is updated once more, note that the original tag ("Coca Cola") is no longer listed. This is because there are no other entities that have this label:
New tags can also be created. Enter the tag name:
The tag is saved:
... and is available as a choice for this or any other entity of the same type:
The prerequisite software is:
- Java JDK 8 (>= 1.9.0) or Java JDK 7 (<= 1.8.0) ** note that the compile source and target remains at JDK 7
- maven 3 (3.2.x is recommended).
To build the demo app:
git clone https://github.com/isisaddons/isis-module-tags.git
mvn clean install
To run the demo app:
mvn antrun:run -P self-host
Then log on using user: sven
, password: pass
You can either use this module "out-of-the-box", or you can fork this repo and extend to your own requirements.
To use "out-of-the-box":
- update your classpath by adding this dependency in your dom project's
pom.xml
:
<dependency> <groupId>org.isisaddons.module.tags</groupId> <artifactId>isis-module-tags-dom</artifactId> <version>1.13.0</version> </dependency>
-
if using
AppManifest
, then update itsgetModules()
method:@Override public List<Class<?>> getModules() { return Arrays.asList( ... org.isisaddons.module.tags.TagsModule.class, ... ); }
-
otherwise, update your
WEB-INF/isis.properties
:
isis.services-installer=configuration-and-annotation isis.services.ServicesInstallerFromAnnotation.packagePrefix= ...,\ org.isisaddons.module.tags.dom,\ ...
Check for later releases by searching Maven Central Repo.
If you want to use the current -SNAPSHOT
, then the steps are the same as above, except:
- when updating the classpath, specify the appropriate -SNAPSHOT version:
<version>1.14.0-SNAPSHOT</version>
- add the repository definition to pick up the most recent snapshot (we use the Cloudbees continuous integration service). We suggest defining the repository in a
<profile>
:
<profile> <id>cloudbees-snapshots</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>snapshots-repo</id> <url>http://repository-estatio.forge.cloudbees.com/snapshot/</url> <releases> <enabled>false</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> </profile>
If instead you want to extend this module's functionality, then we recommend that you fork this repo. The repo is structured as follows:
pom.xml
// parent pomdom
// the module implementation, depends on Isis applibfixture
// fixtures, holding a sample domain objects and fixture scripts; depends ondom
integtests
// integration tests for the module; depends onfixture
webapp
// demo webapp (see above screenshots); depends ondom
andfixture
Only the dom
project is released to Maven Central Repo. The versions of the other modules are purposely left at
0.0.1-SNAPSHOT
because they are not intended to be released.
The main functionality is exposed through the Tags
domain service, which provides two methods:
public class Tags {
@Programmatic
public List<String> choices(final Object taggedObject, final String tagKey) { ... }
@Programmatic
public Tag tagFor(
final Object taggedObject,
final Tag existingTag,
final String tagKey, final String tagValue) { ... }
}
where:
-
choices(...)
returns a list of tags as strings for the object being tagged (egEmail
) and for the tag key (egpriority
) -
tagFor(...)
will create/update a tag for the object being tagged (egEmail
), the tag key (egpriority
) and the tag value (eg 'urgent'). The existing tag (if any) is passed in so that it can be removed if the tag value is left as null.
1.13.0
- released against Isis 1.13.01.12.0
- released against Isis 1.12.01.11.0
- released against Isis 1.11.01.10.0
- released against Isis 1.10.01.9.0
- released against Isis 1.9.01.8.0
- released against Isis 1.8.01.7.0
- released against Isis 1.7.01.6.0
- first release, with classes under packageorg.isisaddons.module.tags
Copyright 2014-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.
There are no third-party dependencies.
Only the dom
module is deployed, and is done so using Sonatype's OSS support (see
user guide).
To deploy a snapshot, use:
pushd dom
mvn clean deploy
popd
The artifacts should be available in Sonatype's Snapshot Repo.
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.13.0.20161017-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 releaseorigin
is the name of the remote to which you have permissions to write to.
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.13.0 \
1.14.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.13.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.