UPDATE: I fixed it by doing the following in order to get the reconfigure to run

Code:

export LANGUAGE=en_US.UTF-8
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
locale-gen en_US.UTF-8
sudo dpkg-reconfigure locales

CREATE TRIGGER story_creation_timestamp BEFORE INSERT ON story
FOR EACH ROW
SET NEW.createdOn = NOW();

CREATE TRIGGER story_update_timestamp BEFORE INSERT ON story
FOR EACH ROW
SET NEW.modifiedOn = NOW();

stay salty my friends…

gnome-desktop-item-edit ~/Desktop/ –create-new

Once you have customized the item on your Desktop, drag it to the Launcher.

Reference:

http://askubuntu.com/questions/78730/how-do-i-add-a-custom-launcher

The process is very much like creating view pages in Wicket, and is also analagous to a JSf page where the HTML is a template file and the JSF tags replace components such as Input, Select, etc.

The steps required to produce an HTML template to act as a Vaadin view is as follows:

1. Create a Form class instance and assign it a BeanItem datasource containing the POJO that the form fields will map to and from.
2. Create an HTML file containing the complex form layout required by the business entities (do not add the FORM tag to the html file).
3. Use DIV as the placeholders for the html file’s html component tags (Text Input, Selects, etc.).
4. Use the customLayout.addComponent(, ) method to bind the Vaadin components to the html template file fields.
5.Bind a Vaadin Button to the HTML file’s submit button and create an anon listener that contains the method to call for data persistence or updates.
6. Use a FormFIeldFactory class to assign Ajaxable behaviour to html field components (remember to set fieldFactory on Form instance).

Things to consider and/or remember:
1. You still have to set the fields that you want to be visable using a collection or object array.
2. You still need to add a submit button with an “addListener(…) ” listener attached.
3. Basically you have just replaced the normal FormLayout class with an CustomLayout class and provided an external template file.

In most cases this is a very simple process, and again if you have Wicket exposure or experience you will find it strikingly similar to wicket development (for the most part).

Stay salty my friends.

After googling around I came across lots of old threads (2007 – 2009) that did not work for me before I found something more current
(2010) http://it-essence.xs4all.nl/roller/technology/entry/configuration_of_multiple_jpa_persistence, however I also found another link
with a slightly different approach that I chose to use (unfortunately I cannot find the link again so I writing down the steps here).

– persistence.xml –
1. Create several persistent units

2. Create 2 entityManagerFactory stanzas(1 per persistenceUnit) and specify a different PU for each

3. Create two transactionManager(s)
Since I am using AspectJ I also have to add multiple tx:annotation-driven stanzas

Add the appropriate the EntityManagerFactory to the DAO bean

4. Add both persistenceManagerFactory variables to my DAO base class:
private EntityManagerFactory entityManagerFactorySC;
private EntityManagerFactory entityManagerFactoryKH;

Explicitly specify the persistentUnit name for each EntityManager:
@PersistenceContext (unitName = “stacyPU”)
private EntityManager emStacy;

@PersistenceContext (unitName = “keyhealthPU”)
private EntityManager emKeyhealth;

5. Since I am using OpenEntityManagerInViewFilter in web.xml I have to create 1 for
each EntityManagerFactory:

This approach is a little more involved than the 2010 approach above but it works really well.
I may try the 2010 approach on another test project to determine if it would work as well as the one I have chosen.

For this reason I have deleted all previously registered users so that those who wish too may re-register and receive an email with the proper password assignments.

For those reading this post who do not know what Vaadin is, its a Java and JavaScript framework that is fully ajaxable out-of-the-box. Anyway, while Vaadin doc is really outstanding most of the time there are some places where the doc does not go far enough, although to be honest in this case its not Vaadin at fault as I am using a 3rd party add-on (TwinColSelect). Below is a snippet of code for using the add-on in a Vaadin Form (via a FieldFactory subclass):

@Override
public Field createField(Item item, Object propertyId, Component uiComponent) {
Field field = super.createField(item, propertyId, uiComponent);
if(“stories”.equals(propertyId)) {
TwinColSelect tselect = new TwinColSelect(“Sprint Story Selection”);
tselect.setLeftColumnCaption(“Available”);
tselect.setRightColumnCaption(“Assigned”);
tselect.setWidth(“500px”);
// This is how we set the fields to display in our twin combo boxes
tselect.setItemCaptionMode(tselect.ITEM_CAPTION_MODE_PROPERTY);
tselect.setItemCaptionPropertyId(“title”);
// get the data we want to show in the left combo box
List stories = persistenceHelper.getStoryDAO().findAll();
// set the left (available) combo box
BeanItemContainer container = new BeanItemContainer(Story.class, stories);
tselect.setContainerDataSource(container);
// now set the right (assigned) combo box
BeanItem bi = (BeanItem)item;
Sprint bean = (Sprint) bi.getBean();
tselect.setValue(bean.getStories());

field = tselect;
}
return field;
}

The above code was taken from a class that subclasses the Vaadin DefaultFieldFactory class. The DefaultFieldFactory is a class that allows the developer to specify the kind of UI widget Vaadin should create for the properties of Java POJO assigned to the Vaadin Form class created for the view under construction. Within the createField(…) method (show above) the developer tells Vaadin to create a UI component other than its default (which is a TextField) by overriding he Vaadin choice based on the field name (propertyId) of the POJO. Since I have a JPA many-to-many property (its a Set of stories I want to assign to a Sprint) I chose to implement the TwinColSelect combo boxes.

In order for this code to work the Sprint and Story entity classes need to correctly implement the hashCode() and equals() methods.

Another point is that when persisting the user selections the stories selected need to be iterated over and the opposite side (the Sprint) needs to be inserted into each selected Story’s sprint collection.

-

Further complications arise as I am developing with Vaadin and using AspectJ for load-time weaving of the J2EE components. Strangely in some cases the JPA DAO’s accept annotations such as @Transactional and in this recent case attempts to deploy the App would causes many different exceptions to be thrown (as I constantly tweaked the code moving the annotations from DAO to Service Layer all to no avail).
To solve the problem I removed the JpaDaoSupport subclassing from my DAOs and injected the EntityManager directly into each DAO using:

@PersistenceContext
private EntityManager em;

Now I can use the “@Transactional” annotation with errors being thrown.

However, there was still one more mountain to climb:
Upon deployment I began receiving an error somthing like “Post-processor tried to replace bean instance of type [Blah] with (proxy) object of type [org.springframework.beans.factory.aspectj.$Proxy52] – not supported for aspect-configured classes!”.

After a little creative “googling” I found the fix was to simply change my Spring applicationContext.xml stanza
from:
tx:annotation-driven transaction-manager=”transactionManager”
to:
tx:annotation-driven transaction-manager=”transactionManager” mode=”aspectj”

Its a relief to have that out of the way so I can get back to Vaadin development!

Basically, it lists how to move your svn repository from one remote server to another.
From a command prompt start your terminal console, then enter the following linux commands:

$ svnadmin dump /path/to/your/repo > yourreporname.dump
$ scp yourreponame.dump username@new.machine.ip:/path/to/your/new/repo
Now your SVN dump file should be in new machine
Login to your new machine

cd /path/to/your/new/repo

svnadmin create reponame

svnadmin load reponame < yourreponame.dump

Done, you just just migrated your svn repository

* If you dump file is too big for transfer, you can compress it using tar before sending over thru network.