1. Open a command prompt and navigate to the directory where the Maven source code is. This is usually indicated by the presence of a pom.xml file in that directory.

   
   > cd dev\projects\myproject
   

2. Once in the maven project folder, there are a number of different commands you can use to install the project depending on what you need. The simplest form will compile, test, and install the artifacts into Maven.

   
   >mvn install
   

In some cases, you want to install the source and java doc files as well as the main jar file. This can be done by adding it onto the command line.

>mvn javadoc:jar source:jar install

There may be times you want to make sure your build is completely clean before you start. You can do this by adding the clean target onto the command. This deletes any current compiled sources so they will be regenerated from scratch.

>mvn clean javadoc:jar source:jar install

While we added it at the start of the command, you don’t need to, you can put it at the end and it will still be executed first.

Skipping Tests

If you need to skip tests, you can do so by setting a command line parameter on the command line depending on how you want to skip the tests. While skipping tests is not advised, there are many cases where you might need to do so.

-Dmaven.test.skip=true

This will skip the compilation and execution of the tests.

-DskipTests=true

This will compile the tests, but skip the execution of them.

See here for more information on controlling test skipping in the pom.xml file.

1. First, download the DataValve framework and unzip it into a temporary folder of your choice.
2. Open a command prompt and change directory to the <install-dir>\modules\ folder
3. in the modules folder, type the command :

   mvn clean javadoc:jar source:jar install
   

4. This will compile the code, source and javadocs and install them into the local maven repository for use in your local maven applications.

Once installed, to use DataValve in a Maven project you will need to add the necessary DataValvel modules as dependencies :

		<dependency>
			<groupId>org.fluttercode.datavalve</groupId>
			<artifactId>datavalve-dataset</artifactId>
			<version>0.9.0.CR2</version>
		</dependency>

Typically, adding the datavalve-dataset artifact pulls in the core module also. From there, you just need to add modules that your development environment will be dependent on (Wicket, JSF, Swing etc).

JEE, JSF, JPA and CDI demo

The archetypes are based on the Weld Maven Archetypes and have been extended to contain a project that comes complete with a sandbox data model and pre-populated data, and also a full demo application that makes use of a number of Java EE 6 features. The projects have been tested and works with Glassfish (with a Weld update) and JBoss 6 Milestone 3.

(Edit : I renamed this post so it doesn’t seem like Spigot is just for Seam, Spigot can be used with different frameworks or without any at all. However, I wrote this post since Spigot is so familiar to the Seam EntityQuery that it should be easy for Seam users to get the idea)

Seam developers should become familiar with Spigot concepts fairly quickly since they are very similar to those found in the Seam EntityQuery which was one of the main inspirations for the framework. If you imagine taking the entity query class and splitting it in two, one part to keep hold of state and the other to actually fetch the data. The stateful part is the Paginator that keeps track of what the current ordering of the data is, what is the current page and how big the pages are. The stateless part takes the Ejbql and the pagination information and returns a subset of the data. Now imaging that the data provider has the JPA pieces taken out and replaced with an abstract fetchResults method. This method is implemented in subclasses for specific data providers for text files, sql queries, jpa queries, native jpa queries, xml files, comma delimited or just an in memory dataset.

I also abstracted the concepts of parameterization and parameter resolution so you can have parameters on data providers that are no t query based and your parameters can be resolved using different mechanisms such as EL, reflection, a map, or using custom parameter resolution.
So really, for Seam developers, its like a Seam EntityQuery that doesn’t just use JPA, but uses any kind of data source you want but still returns just a list of objects.

Spigot works nicely with CDI and there is even a demo of it in the distribution that uses JSF and was generated using the Weld maven archetypes. Also, there is a Seam Jpa Dataset Adapter that you can use as a direct replacement for the EntityQuery which will adapt the entity query calls to the underlying data provider calls so you can have a seam-less transition if you want to switch over. This is still a little in-progress, but works. The one area that isn’t implemented is the sorting, which may not be possible, but I still need to add in the methods to the adapter even if they don’t do anything. The other issue is of course the configuration of the query from components.xml using the Seam Framework tags. However, you can define the query using regular component xml tags to define the Ejbql, restrictions and page sizes.

Two things to note if you start using Spigot in place of the entity query. All rows are returned by default, and you need to specify both a select statement and a count statement. I separated those two out so you can put join fetch phrases in the select statement without it breaking the count statement. There is an init method that you can use to set both of these statements for a class type.

It’s been a while since I’ve posted anything new as I’ve been busy with a new Open Source software project called Spigot. It’s a java library that sits between your application code and your data sources (Hibernate, JPA, JDBC or any arbitrary source of data) and helps with things like pagination and sorting using a common interface so you can switch out data providers and use alternatives.

For query language data providers, Spigot also facilitates excluding restrictions from WHERE clauses when parameters are resolved to null. Parameters are handled using parameter resolvers so there is more than one way to parameterize the query including EL expressions, reflection or a value map on the data provider.

Spigot also provides a few other add-ins like converting any dataset into an in-memory dataset that can itself be paginated and sorted and shared across an application (such as commonly used data in a web application). The IndexedDataProviderCache can give you random access into a dataset with caching and look ahead loading. This lets you hook a dataset with thousands of rows up to a Swing JTable with an instant response and a very small memory footprint since it doesn’t need to load all the objects at once as the provider will load the records as needed and cache the results. This is demonstrated in the Swing Demo in the download. There are also demos for Wicket and CDI with JSF.

You can ready about why I created Spigot in the documentation

Spigot is currently hosted on Project Kenai, where you can download the release, view documentation online or read about 10 ways Spigot helps developers.

(note This post relates to both the milestone 2 and beta versions of Netbeans 6.8 which I have been tinkering with over the duration of this article being written.)

The download for Netbeans 6.8 comes with Glassfish v3 which implements JEE 6 including JSF 2.0 and JPA 2.0.

Glassfish now has really fast hot deployment so you can change a line of code, save it, and it re-deploys instantly which in my opinion, this is a huge productivity booster. This isn’t limited to Netbeans, the eclipse plugins also provide this feature, and it works with pretty much any framework. I tried it with Wicket and Spring MVC and it was fantastic to get a wicket error where I had forgotten to add a component, so I go back to the java page code, add the component, refresh my browser and it works. Glassfish now has support for JEE 6 so you can make a pojo a local EJB just by adding the @stateless annotation to it. You can also deploy EJBs in war files as well without needing the whole EAR setup. One problem I did see was that when you used the EAR project setup with an EJB and War project, the hot deploy didn’t appear to work as well. Changes to the war file didn’t appear to redeploy, maybe because it is the EAR file that is deployed and not the war. However, still fantastic stuff.

Netbeans 6.8 beta was released in the last week or so. Feature-wise it is a great product with better tooling for JSF, including JSF 2.0, facelets support, and auto-completion for JSF backing beans in the JSF page. It also includes support for JEE 6, EJB 3.1, JPA 2.0 and development with Glassfish v3. It also improves upon the existing Maven support by providing for mavenized Ear projects.

While the features are impressive, Netbeans still seems hindered by performance issues and some minor bugs (although it is a milestone/beta release). Personally, I found this release no more sluggish that other releases although some people in the forums have had worse experiences. Netbeans strength has always been that it offers one standard solution without the plugin nightmares that eclipse has. While Netbeans has plugins they are more like installable features, they have a higher granularity than Eclipse plugins which is more like DLL hell. That said, I use Eclipse at work and it is always hard to shift from one keyboard mapping to another, and Eclipse does seem faster without the intermittent pauses. However, right now, Netbeans is a superior product in terms of features, especially for a JSF developer. I’d keep an eye out for the 6.8 final release to see how it comes out, and give 6.8 milestone 2 a go just to enjoy the experience if you are interested in using a standards based stack because thats obviously where the Netbeans folks are focused.

One big issue I have with Netbeans is the oddness of some of the key mappings. I think in nearly every application I use I press Alt+F and then C to close the currently edited document. Whether is it in MS Office, Borland Delphi, Eclipse, Firefox, while in the file menu, the C key always closes the currently open document you are editing. In Netbeans, it closes the currently edited project which means suddenly my project disappears when I want to close an edited file. Another is the use of Ctrl+Space for invoking auto completion which in Netbeans sends focus to the project manager or something like that. Sure, I can change the keymappings, such as to the Eclipse profile, but then I’m using some arbitrary weird key mapping which isn’t Netbeans and it isn’t completely the same as Eclipse. It is probably this way for legacy reasons, but some of these key presses are de facto standards.

Lastly, we come to JSF 2.0 which was forged from JSF 1.2 and the litany of complaints about it. The JSR group looked at the solutions out in the wild that already work around those problems (many of which were written by people in that very group) and incorporates those fixes in a standard JSF API type of way. Primarily we have the dropping of JSP as the default view in exchange for the Facelets / JSF templating solution. This also lent itself very well to easier component creation including no-code components. There is now zero configuration required except for the servlet in web.xml and managed beans can now be defined using annotations. Navigation which also used to be in the faces-config.xml is also more convention of configuration. Another big request was the inclusion of AJAX awareness in the JSF lifecycle . It provides the bare minimum features that 3rd party developers can build upon using the standard API instead of their own AJAX solutions. There is better support for GET requests and page parameters as well as invoking actions on page requests which is a feature often used in Seam.
There is also some performance boosts with regards to re-working state saving and the resource access mechanisms have been improved a great deal.

Also noteworthy is the inclusion of Weld CR 1 which is the reference implementation of JSR 299 – Java Contexts and Dependency Injection from JBoss. Admittedly, I haven’t really gotten round to taking a look at it, but from what I have seen and read so far, it looks like it fills some gaps in the JEE 6 platform and is up to par with the new found simplicity and strength that JEE 6 is promoting right now.

Overall, this is a pretty exciting set of tools and framworks and well worth a look if you are interested in adopting a standards based stack.

Granted, source control and build management should have been done early on but this is a small project where I already make regular informal backups and the IDE handles building the single jar so I didn’t bother. Also, I wasn’t planning on making it open source originally but since I did, I wanted to get everything tidied away.

On top of that, I’ve had to produce documentation, more so than if I was just using the library myself, and produce wiki pages, provide uploads, test the downloads to make sure they work, check that the download will work when installed to a maven repository, and provide instruction on how to use it from a maven repository etc. It’s a lot of work all for the sake of sharing a project with the world. I wouldn’t have to do most of that if I were keeping it to myself!

However, it has taught me two things. One is to appreciate all the extra work that goes into managing an open source project above and beyond just putting a jar file on a web page for download. The other is a reminder to always start out with good practices (build processes and source control) from scratch if you even think the project might go public. This is a no-brainer if you know the project will be open source in advance, but probably should be followed just in case you decide to open source it later on.