"camunda" wrote :
| Versioning is applied to applications and services, normally correspond to one EAR
(with Java classes, maybe web pages, wsdl, whatever. Depends on the kind of service).
There are two versioning schemes:
|
| 1.) Major Versions: Bigger changes. These may be not compatible. New major versions
may be run in parallel to older services.
|
| 2.) Minor versions = patches. These are patches, bug fixes or compatible changes. New
Minor versions replace the existing service.
|
Ok, clear. Would be my take to.
"camunda" wrote :
| The EAR includes the version in its name, so all beans and stuff include the version
in the JNDI-Name.
|
You do this manually (deploy time), manually (design time) or is this some automagic JBoss
AS feature?
"camunda" wrote :
| jBPM-processes are included in this EAR. New major versions will create new
processdefinition names (basically the version is added to the process name, e.g.
"websale_3").
|
Again, do you do this deploy time or designtime?
"camunda" wrote :
| "Normal" jbpm versioning is only applied on patch level.
|
Ok, makes me even more curious how you achieve this. The high-level take on it is clear,
now the devil^W details ;-)
"camunda" wrote :
| anonymous wrote : It is a more generic problem than just jBPM.
|
| Exactly, normally you have to take care of versioning for a lot of artefacts, so I
think this solution makes sense... And I like having bytecode and classpath stuff in EAR
files more than in the jBPM database...
|
It does make sense, I miss one thing though but I'll talk about that in the end.
"camunda" wrote :
|
| anonymous wrote : So maybe we could come up with something together with the seam
guys
|
| Yeah, maybe. But I think it is not only seam, but much more. Especially if you look
into the direction of the ESB with whatever services connected to it. This direction (to
the backend) is also very interessting.
You are right, but currently I am (was) focussing on the web side of things.
How do you run multiple major versions next to eachother? Suppose I have App A-v1 (version
1) on
http://myhost/AppA. That is easy to run. But now comes AppA-v2, an incompatible
major release. Running this on
http://myhost/AppA. is not possible since we already have
AppA-v1 there, so something more advanced needs to take place.
One thing I came upo with (and I do not know all the disadvantages yet, or alternatives,
so please shoot) is to have an AppA 'wrapper' which contains things like showing
tasklist (since our customers do not want to use to different 'apps' because
there are newer versions), basic navigation etc which is a war by itself running on url
http://myhost/AppA. The 'versioned' parts are in separate deployable artifacts
(war or ear) running on urls like
http://myhost/AppA-v1 or
http://myhost/AppA-v2 of which
the wrapper has knowledge via some defined schema so it can make a link directly to a
task. But there probably needs to be some kind of 'TaskHandlingPageUrlService' to
retrieve that.
I'll not go into it any further now and just let you guys shoot... But I do think
there needs to be some more generic mechanism for all this Gourvernance stuff...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179718#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...