You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kalumet-dev@incubator.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2012/06/12 17:43:35 UTC

[HEADS UP] "Update plan" and generic resources

Hi all,

As discussed in another thread, I'm going to cut off 0.6-incubating 
release. To be able to do that, I'm going to work on the documentation.

The purpose of this release is:
- to provide a first incubator release to the community in order to have 
some user feedback and start to blog, etc about Kalumet
- to have a tag on a "stable" version before starting some refactorings

In terms of refactoring, my first proposal is the following.

Currently, Kalumet uses a "static" update plan:
0/ send a notification e-mail and wait the notification count down
1/ first Kalumet update "softwares" with the "Before J2EE flag" set to true
2/ after it updates the J2EE application servers:
2.1/ JDBC connection pools
2.2/ JDBC data sources
2.3/ JMS servers, queues and topics
2.4/ JNDI bindings/aliases
2.5/ J2EE applications
2.5.1/ configuration files (with mapping substitution)
2.5.2/ databases
2.5.3/ archives (ear, war)
3/ "softwares" with the "Before J2EE flag" set to false
4/ publication of results by e-mail

My proposal is:
1/ introduce a "free" update plan. We have something already there in 
software, the idea is the use the same for a whole environment. The user 
will have a "palette" of resources (J2EE application server, OSGi 
container, ESB, generic JMX client, location, system command, etc) that 
it can choose to define each steps of an update plan.
For instance, an update plan will look like:
        1.1/ copy the file A from there to there and replace text in the 
file
        1.2/ execute foobar system command
        1.3/ copy the file B from there to there
        1.4/ install/update JDBC data sources in JBoss application server J
        1.5/ install/update feature D in Karaf K
        1.6/ install/update war W in JBoss application server J
        etc
The user will be able to do exactly what I want, without limit (the 
limitation is the resources that we provide in the palette)
2/ The Kalumet API will be more generic in order to easily extend the 
palette

Regards
JB
-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com