handling the Rufuses under vendor/ (was : Are ruote-web and kisha compatibles?)
John Mettraux
>
> My question is: how do I get updates for the many other RUFUSES projects?
> Do I need to create seven remote entries? (ruote dollar eval lru mnemo
> scheduler verbs) and do seven manual updates?
Hello Pat,
the Rufuses aren't supposed to change too often.
> Re-running the install_workflow_engine everytime does not feel right
> (wouldn't git lose track of the changes mine and yours?)
It would upgrade the Rufuses and the workflow engine with my changes.
If you need to change the workflow engine (or something in a Rufus)
consider providing a patch
(http://rubyforge.org/tracker/?atid=10025&group_id=2609&func=browse /
http://rubyforge.org/tracker/?atid=18586&group_id=4812&func=browse) or
fork the rufus / ruote so that I can see what you needed to change.
On the other hand for some category of changes, monkey-patching is ideal.
It is somehow equivalent to the "rake freeze rails" thing (with all
the due respect for Rails).
Best regards,
--
John Mettraux - http://jmettraux.wordpress.com
Pat Cappelaere
Ruote-web and Ruote are the two pieces that might change quite a bit.
So I guess this answers one question: I need to add one more remote entry
in my git config file for ruote itelf to keep it in sync with your changes.
I may have to make some changes in Ruote to support the upcoming audit trail
analysis API from the Stevens Institute. This could stay in the separate
wfxml branch...
But I cannot assume that the other Rufuses are not changing either...
This gets a little complicated... I need to try a few things to see how this
would work...
I am wondering if anyone else is doing something similar?
Thanks,
V/R,
Pat.
John Mettraux
>
> Ruote-web and Ruote are the two pieces that might change quite a bit.
> So I guess this answers one question: I need to add one more remote entry
> in my git config file for ruote itelf to keep it in sync with your changes.
>
> I may have to make some changes in Ruote to support the upcoming audit trail
> analysis API from the Stevens Institute. This could stay in the separate
> wfxml branch...
that would call for a fork of Ruote or for a nice bit of
monkey-patching from Ruote-web. You're the end user, at the end of the
specialization chain, monkey-patching is not bad.
> But I cannot assume that the other Rufuses are not changing either...
> This gets a little complicated... I need to try a few things to see how this
> would work...
you can install them as gems (see
lib/tasks/install_workflow_engine.rake, second task), even Ruote.
Are you building the new GeoBPMS ? Are you building a WfXML-R package
based on OpenWFEru ? What's your audience ?
Cheers,
Pat Cappelaere
> On Wed, May 14, 2008 at 1:25 AM, Pat Cappelaere <cappe...@gmail.com> wrote:
>>
>> Ruote-web and Ruote are the two pieces that might change quite a bit.
>> So I guess this answers one question: I need to add one more remote entry
>> in my git config file for ruote itelf to keep it in sync with your changes.
>>
>> I may have to make some changes in Ruote to support the upcoming audit trail
>> analysis API from the Stevens Institute. This could stay in the separate
>> wfxml branch...
>
> that would call for a fork of Ruote or for a nice bit of
> monkey-patching from Ruote-web. You're the end user, at the end of the
> specialization chain, monkey-patching is not bad.
Monkey-patching is not that good when you have to keep patching rev after
rev.
>
>> But I cannot assume that the other Rufuses are not changing either...
>> This gets a little complicated... I need to try a few things to see how this
>> would work...
>
> you can install them as gems (see
> lib/tasks/install_workflow_engine.rake, second task), even Ruote.
True for the little ones. Harder to do for Ruote itself.
> Are you building the new GeoBPMS ?
Yes.
> Are you building a WfXML-R package based on OpenWFEru ?
Yes
> What's your audience ?
People that need to use workflows at the Enterprise level and are not
interested in or cannot afford using a SOAP-based approach. They still need
to leverage existing standards that can be used across many services rather
than develop their own for that specific need.
V/R,
Pat.