[Design of JBoss Build System] - Re: Release of jboss-retro
by pgier
Kabir brought up the issue of backwards compatibility with the previous versions of retro, so I'm putting off the release until we figure out a good plan.
The problem is that in the new version of jboss retro, some of the classes have been moved to new packages. So code that was retroed with the previous version of jboss-retro will not work with the new runtime. This means that if aop is retroed with the new version it depends on the new runtime, and if the app server is retroed with the old version, it will depend on the old runtime.
So some options are:
1. Never make changes to runtime class names or method signatures.
Pro: This will allow backwards compatibility in most cases.
Con: Not much flexibility for refactoring, we will probably have to include some automated way to run tests that are retroed with the old version running on the runtime of the new version.
2. Change class/package/method names for major versions, and keep a branch for updates to older versions. In this case we will keep a branch to add new features to an old version but keep a compatible runtime.
Major versions would be allowed to break compatibility.
Pro: Allows refactoring
Con: Would have to maintain multiple branches.
3. After moving a class, use inheritance to keep a place holder for the old runtime class.
This would mean that after a class is moved, a new subclass of the new class is created in the old location.
Pro: Allows refactoring and backwards compatibility
Con: Causes a lot of extra placeholder classes hanging around.
Maybe the best option is to stick with option 1, until we are able to have multiple retro-runtimes loaded at once (osgi classloader). But I would appreciate any feedback on this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054126#4054126
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054126
18 years, 9 months
[Design of JBoss jBPM] - Re: process patch files
by brittm
anonymous wrote : And you want to update complex processes with patches? Think that is going to work?
We already do it (successfully) by directly manipulating the database--sometimes through screens developed for that pupose. (Unfortunately, the 10 or so departments that we serve can't seem to come up with all their real requirements until they start using the system in production. And I suppose we have had one or two *ahem* mistakes on our part.)
anonymous wrote : What's easier with patching?
1) With patching, I don't need to deploy configuration and code that I'm not changing. The larger and more complicated an environment becomes, the higher the risk of introducing unintented changes, and hence the more benefits patching provides.
2) If a business looses track of a PAR project for whatever reason (company is acquired, IT is restructured, developers leave, data loss, etc.), and jBPM can't hand back the par file for rebuilding, then patching is the only option other than rewriting the process.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054063#4054063
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054063
18 years, 9 months
[Design of JBoss jBPM] - Re: console security
by david.lloyd@jboss.com
"kukeltje" wrote : me curious to... was just trying the latest console out and have some findings... not sure whether I should report them or not since I do not know if work is still on the todo list and do not want to polute the jira.
|
| So (O/T) things I notice are:
| - tasks can be 'ended' via a normal transition without ever being started, hence no start date in the task (related to the examine thing below)
| - the moment the comment appears is confusing.... should maybe be preceded by a popup like 'you just finished this task, do you want to add a comment to it (yes/no)
| - the 'examine' is kind of strange.. examine to me is not being able to work on it... (read only)
| - Can I start a dutch translation?
|
Yes, this is an admin console so you can do pretty much anything allowed by the API, including things that are probably not a good idea. Use the security configuration in access.properties to limit access to different functions.
The comments screen has a kind of ugly layout, but functionally I think it makes sense. Patches welcome to make it look nicer. :-) The task screens are not intended so much for people to be able to run their day-to-day tasks, but rather so that administrators can see what the status of things are, and "take things over" if needed.
As for a dutch translation - please do! You can point out all the faults in my L10n efforts. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054052#4054052
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054052
18 years, 9 months