Business analysts are thinking about other stuff when they are editing pd-s.
It's the frameworks responsibility to detect changes.
We want to make it as automated as possible, so we'll try a comparator
implementation, and suggest it to the community if it proves successful.
Thanks :)
View the o
Bad release, imo.
Upgrading causes too much trouble.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3923843#3923843
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3923843
Hi Rainer,
Good idea. But how and when do you calculate that "version" variable in your
code? As far as I understand you calculate it from a timestamp, is it the
timestamp when the build procedure is run?
In our team the build timestamp would be inappropriate. We are using a central
db, local
I'm afraid versionnumber wouldn't help.
Of course, the par which we haven't yet deployed does not have a version number
(afaik, version numbers are not described in the process archive). And after
deploying it, its versionnumber will become MAX(VERSIONNUMBER_) + 1.
The question is should we deplo
Dropping JbdlXmlWriter would also affect my project.
We are using it at application startup to decide whether the process definition
structure has changed and we need to redeploy. We are fetching the pd as an
object graph from the db, then converting it to xml, and comparing the xml to
the origi
In relation to your posts, guys,
does anybody have an idea how to get a hash from what is deployed in the
database on one hand, and what we have locally as a par file on the other hand?
I want my app to to check at startup whether the par on the filesystem needs to
be deployed to the database. Id
