(I have to work this out later)

• check out what you want to release
• mvn release:branch -DbranchName=<release name>
• checkout the branch that was made
• release:prepare
• release:perform

coming soon

I often run teams doing projects. Sometimes the projects only last 2 or 2 weeks, sometimes they last a few months or a year. Everytime I seem to have to instill the same rules I have for all teams. It's a set of rules that has grown or developed of the years I have been running teams or have been part of teams.

You will be able to read a lot of these rules some way or another everywhere on the web. My rules are not earthshattering new or different. But they are my rules, my way of trying to have at least the basics taken care of. I find that having the basics taken care of makes it easier to work on the real problem namely the reason the project needed to be done in the first place.

Documentation

Write the documentation while coding

Coders hate to document and at the same time, they are the ones moaning the most when a project is not well documented. The question remains ''when is a project well documented?''.

Documenting is not hard, but you need to do it while the project is going on. Take some time during the day to document what you coded. It does not take long to write the javadoc. For the larger, more in depth documentation? Personally I dont believe in office documents, whether they are written with MsOffice or OpenOffice. I see those documents as dead and out of date the minute they are emailed. Instead of mailing a document that might or might not have been changed since you mailed it, write it on a wiki and mail the link. How often have you seen that people have three or four different versions of the same document?
Wiki's are easy to maintain, no need to think about styling it's all done for you by the wiki you use.

super DRY

Recycle, recycle, recycle

Trust me, you do not have to write most of the frameworks yourself. For just about any problem you might encounter somebody has already written a solution. Every line of code you write must be tested, documented and maintained. Build up a list of frameworks and pieces of code. Use what you have used before.

check in

Everyday a clean workspace

You do not work alone on a project. Your teammembers need your code (and your documentation). Write small pieces and check in often. The best of course is to check in a working piece of code with a junit test. At the end of the day check everything in. If that means stopping with coding a bit earlier to make sure your code compiles then do so. Going on a bit longer to make the code compile is good too of course. Not only does this help your team mates, it guarantees against sudden sickness, laptop problems, accidents and so on and so on. It would be a shame losing a weeks work because your laptop crashes.

Standards

You may like them or not, but they exist for a reason. Leverage the power of your IDE. Use checkstyle or indent. Make sure the standards are known in your team (see documentation).
Several good standards to use:

• maven for that easy setup and dependency maintenance
• the Java coding guide from SunOracle

You dont need many, But the few you need and adopt use them consistently.

I have always been a great believer in CoC. The less you deviate from a convention the easier other people will pick it up.

I see the reasons for CoC being:

• best practices implemented
• everybody knows them (or should)
• superfast starting a new project, you dont have to think about how to set stuff up, just use the convention

So picture my suprise when this morning a teammember just blatantly broke convention, because "it was easier to read, the files belonged together".
Maven project layouts are very well thought out. The convention of having resources in a different tree then sources, makes it easier to switch resources like spring application files or persistence information between profiles or even more common between main and test runs. This is something one cannot do when the resources live next to the sources.

Now the argument could be made that "these files are always needed whatever profile or test you are running". But that means we have to start thinking about which files need to be replaced when running tests or profiles. And the whole idea of CoC was so we dont have to think about that mundane stuff. Also look at what you have to do to change the convention. From "no configuration" we suddenly go to a lot of configuration. to get all this setup. Just from the top of my head:

1. change the resource plugin
2. make a filter to not copy the source files when running the resources:resources plugin
3. if we want to work with profiles or special files for tests, we will need to write more filters.

Before you know it you are writing a really big pom file.

So writing this, I realise that "dont break convention unless you really have to" is a core rule of mine.

Do you know relations like this?

We encountered this one in a current project, one of the engineers had some problems with it, so I made a nice little demo project. the code is here the source I branched the jpatest project for this.

Especially note the testcases where the relations are saved and tested.

What I want to achieve is to have the dao's and the persistencecontext inserted automagically. A lot of blogposts and articles tell you part of the story it took me some 4 hours to get this to finally work.

First the spring configuration

Only three beans are defined. Standard beans, no magic there. The magic is in these two configurations:

<context:component-scan base-package="org.ronsmits.model" />
 <context:annotation-config/>
 <tx:annotation-driven />

The first one orders Spring to scan all classes starting from the "org.ronsmits.model" package looking for @Annotations like "@Component", "@Repository" and the like. The second one orders Spring to scan for JSR250 annotations like "@Resource". The last one will order Spring to look for the annotation "@Transaction".

Here is the complete file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
                        http://www.springframework.org/schema/beans/spring-beans.xsd
                        http://www.springframework.org/schema/context
                        http://www.springframework.org/schema/context/spring-context.xsd
                        http://www.springframework.org/schema/tx
                        http://www.springframework.org/schema/tx/spring-tx.xsd">

    <context:component-scan base-package="org.ronsmits.budget"/>
    <context:annotation-config/>
    <tx:annotation-driven />

    <bean id="transactionManager"
          class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>

      <bean id="dataSource"
     class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName" value="org.apache.derby.jdbc.EmbeddedDriver" />
        <property name="url" value="jdbc:derby:/home/ron/db/derbyDBTEST;create=true" />
        <property name="username" value="app" />
        <property name="password" value="app" />
  </bean>

    <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="persistenceUnitName" value="simple-jpa" />
        <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" />
        </property>
    </bean>
</beans>

The persistence.xml file

Also nothing really special here, because of the entityManagerFactoryBean this file gets picked up by Spring.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
                                 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">

    <persistence-unit name="simple-jpa">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>

        <class>org.ronsmits.model.Category</class>
        <exclude-unlisted-classes/>

        <properties>
            <property name="hibernate.dialect" value="org.hibernate.dialect.DerbyDialect" />
            <property name="hibernate.show_sql" value="true" />
            <property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider" />
            <property name="hibernate.hbm2ddl.auto" value="update" />
            <!-- <property name="hibernate.format_sql" value="true"/> -->
        </properties>

    </persistence-unit>
</persistence>

The coding

Define your entity classes the normal way, then the dao implementation should start with :

@Repository
@Transactional(read-only=true)
public class CategoryDaoImpl implements CategoryDao {
    @PersistenceContext protected EntityManager em;
...

Using it

Now this is the fun part. Annotate the class where you want to use the dao with "@Component" and then "@Autowired" the dao into it:

@Component(name="categoryManager") // the name is optional
public class AserviceBean {

@Autowired public CategoryDao theDao;
...

}

Using it from JSF

You need to add the following to the faces-config.xml file

<application>
   <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
</application>

The code for this can be found here Done, enjoy.

Recipes or 'patterns' I want to keep handy and are accessible through the net. I will add code if I think it warrants that.

Comments are disabled. Its not that I dont want them, its all the cleaning up after the losers and spammers I dont like. I am playing with using openid as login ability but I am not satisfied with that yet.