Deploying a snapshot

To allow snapshots to be used for testing they need to be placed in a public place. Assuming that the distributionManagement/snapshotRepository settings in pom/pom.xml are correct a module, or set of modules, can be deployed to the snapshot repository using

$ mvn deploy

providing that the module's POM's version is for a snapshot, eg 1.0.1-SNAPSHOT.

You can check in our repository ( http://nakedobjects.sourceforge.net/m2-repo/snapshot/org/nakedobjects/) to ensure it has been uploaded.

Using a snapshot

To use a snapshot in your build change the referenced version element to the snaphot's version number (ie 1.0.1-SNAPSHOT) and ensure that public repository is being accessed otherwise you will get the usual "Missing" message:

Missing:
----------
1) org.nakedobjects.plugins:html-viewer:jar:1.0.1-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
      mvn install:install-file -DgroupId=org.nakedobjects.plugins -DartifactId=html-viewer -Dversion=1.0.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
      mvn deploy:deploy-file -DgroupId=org.nakedobjects.plugins -DartifactId=html-viewer -Dversion=1.0.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
  	1) org.test:myapp-commandline:jar:1.0-SNAPSHOT
  	2) org.nakedobjects.plugins:html-viewer:jar:1.0.1-SNAPSHOT

----------
1 required artifact is missing.

for artifact: 
  org.test:myapp-commandline:jar:1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

To use our repository add the following to your project pom.xml or your settings.

  <repositories>
    <repository>
      <id>no-snapshotsd</id>
      <url>http://nakedobjects.sourceforge.net/m2-repo/snapshot/</url>
    </repository>
  </repositories>

I need to release a bug fix. As the full release is not ready we are going to tr releasing just the necessary components. In this case it is the runtime module, and we should release a new release pom to provide the dependency.

Here's what I did:-

1. Created a branch for the fixes to made in
2. Check out the new branch - by using the not recursive flag (-N) I avoided having to check out the whole tree
3. Made the changes - fixed the problem and updated the version in the POM
4. Changed the version referenced in the release POM and updated its version as well
5. Checked it by referring to the new version of the release module.
6. Committed the changes
7. Created a tag
8. deployed the changed modules (mvn deploy)

I came across a problem when subclasses add helper methods to an action or property. Essentially this would not work and the helper methods in the subclass would be added as its own action. To clarify:

public abstract class Customer {
    public String getName() {
        return name;
    }
}

public class CustomerSubclass extends Customer {
    public String disableName() {
        return "No names please";
    }
}

Would have been seen as one property (Name) and one action (Disable Name).

The problem was that in the facet factories the searching for helper methods was done on the class that the property or action method was declared in. So in this example it would be the Customer class even though the CustomerSubclass? was the one being reflected upon.

To resolve this the process method is now called with the original class and the method, rather than just the method. The new signature is:

    boolean process(Class<?> cls, Method method, MethodRemover methodRemover, FacetHolder holder);

The release date for version 4.0 has been set for August 10th.

1. The examples currently have the hibernate, client and server dist projects temporarily remove. As is the hibernate plugin itself.

2. Have removed the webapp directory and files as these are provided by the html viewer. Will ensure the css is copied to the resource directory so there is a template to replace it with.

webapp/
|-- default.css
`-- images
    |-- banner-bg.png
    `-- banner.png

3. The archetype-template has been replace by the archetype itself as it requires too much processing to create the archetype from the template and install the archetype. In future any major changes should probably follow the pattern of recreating the archetype template from the archetype, modifying it and then using create-from-project to recreate the new archetype ready for installing. So now the building of the distribution module include the installing of the archetype.

4. The applib creates a JavaDoc? jar (for that project only) and the tarball module then includes the extracted contents in the distribution file. The full JavaDocs? is not generated and added due to its enormous size (for the core it was about 60MB uncompressed and this would quadruple the maven download size).

5. The ant based projects (as included with the for-ant distrbution) have been updated and fixed.

I have got profiling working so the core and plugins can be built in isolation. To build just the core and plugins use:

$ mvn install

while to build everything, including archetypes, documentation and a distribution use:

$ mvn install -P all

I decided to do it this way round as the id for a complete build was more obvious than one for a partial one (ie core and plugins).

Currently working on the release process.

First I am fixing things:-

• Added nakedobjects.sh/bat script
• Fixing unreferenced jar in scripts
• Fixing failure to start default viewer

Now these are working I will work through the release process (see ReleaseProcess) and create alpha-5 as a testing release (ie it will not be deployed).