« Using Guiding Goals in Agile Transformations | Main | Cynefin is taking over the World »



Feed You can follow this conversation by subscribing to the comment feed for this post.


Thanks for (very!) quick reply, must be because we're both in Norway/Oslo;)Some bcngkrouad info:My current project is a web application (plain war) which integrates with a database through Hibernate and is built using Maven. We have some custom maven plugins, one for the creation of the database and one for the deployment of the war to an application server (JBoss at the moment). We have created an installer using the maven-assembly-plugin which is used to setup the application in other environments like test,stage,production. The installer bundles a build.xml with a few targets to achieve the same things we do in Maven in our development environment. The home-grown utilities for creating the database and deploying to the appserver is used in all environments, from Maven in dev-env, from Ant in all other envs.I want to replace our custom utilities for database creation/migration AND deployment with some more standard things, where the DBDeploy (or c5-db-migration) could be used for the database-related stuff.Challenges:1. Database-related tasks: Is there a tool that can be utilised from both Maven and Ant to accomplish the database creation/migration? Right now it seems that DBDeploy would be the primary tool, since we can execute ant tasks from Maven. Input?2. Appserver/deployment related tasks: Currently we have a home-grown maven plugin which takes care of creating a JBoss directory structure and deploying the war file, as well as starting it in our development environment. In test/stage/production we have Ant targets in the installer which does the same. I've looked at maven-cargo-plugin and finds it interesting, since it can both download an app-server and deploy/redeploy war files to it by configuration in pom.xml. Well, I would like to have a common approach for installing/configuration/deployment of an appserver in dev-env/test/stage/prod. The installer which is deployed to the maven repo should be environmental-neutral, right?! So, will the agile-deploy facilitate my needs?


Well, my first thought would be to chnage the domain-object to represent the three fields. As you have a need to separate things, and well separating the area-code from the number would probably be smart anyway (and you would avoid primitive obsession).From what I understand you can't really chnage the domain object. If you have a PhoneNumber domain object, you can create a custom binder for all objects of type PhoneNumber and assemble three fields to one. I'm not quite sure how the binding/names of the separate fields would come into play here.Creating a separate object with all the fields and then copying it all to the domain object would be a last resort. It's the old DTO, duplicate definitions thingy all over again. When I said stay object oriented, I also said to reuse as much of the domain object as possible. So if you have to create a new object, reuse the domain object too. In a small case with just the phonenumber this is not obvious, but if you say that you are actually editing a Customer with and address a solution could be to build a CustomerForm object that references a Customer object. Then the CustomerForm could contain the specific phone1 etc. but for all other fields reference the Customer object (a JSTL reference would be something like ${form.customer.name}). This way you reuse as much of the original domain object, but add a little extra logic in the CustomerForm to accomodate the UI.

The comments to this entry are closed.


Contact ICF Interactive

  • ICF Interactive a full-service, interactive agency with the ability to guide brands digitally – through an informed strategy, inspired design, technical know-how and an obsession for humanity, we not only can launch your site but we can digitally catapult your brand. If you have a project in mind, would like information regarding our work, career opportunities, proposal requests or anything else, please feel free to get in touch. We’re ready for what’s next. hello@icfi.com