You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "mhahn.dev" <mh...@gmail.com> on 2018/02/01 17:07:29 UTC
Re: Extension activities
Hi Sathwik,
do you already have an idea when the changes might become part of an official release?
Best regards,Michael
-------- Ursprüngliche Nachricht --------Von: Sathwik B P <sa...@gmail.com> Datum: 30.01.18 11:28 (GMT+01:00) An: dev@ode.apache.org Betreff: Re: Extension activities
Hi Michael,
Thanks for your contribution. Your PR has been merged.
regards,
sathwik
On Mon, Jan 29, 2018 at 9:04 PM, Michael Hahn <mh...@gmail.com> wrote:
> Hi Sathwik,
>
> sure!
>
> I merged your commits into my fork and replaced the tabs with spaces
> (hopefully) in all affected source files.
> The PR should reflect the updates now.
>
> By the way, is there any source code formatting guideline/template for ODE
> to avoid conflicts in future? :-)
>
> Best regards,
> Michael
>
> -----Ursprüngliche Nachricht-----
> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> Gesendet: Montag, 29. Januar 2018 11:53
> An: dev@ode.apache.org
> Betreff: Re: Extension activities
>
> Hi Michael,
>
> Sorry for the delay.
>
> I had a brief look and it seems good to me.
> The PR has a lot of tabs in the source, would it be possible to remove
> them and resubmit the PR? I also have updgraded trunk to JAVA 8, there are
> couple of commit for it from the point when your repo forked, can you take
> it up in your repo and the new PR should be a smooth checkin.
>
> Would that be possible?
>
> regards,
> sathwik
>
> On Wed, Jan 17, 2018 at 3:16 PM, Michael Hahn <mh...@gmail.com> wrote:
>
> > Hi Sathwik,
> >
> > sure, the forked repo is available at: https://github.com/hahnml/ode
> >
> > Best regards,
> > Michael
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > Gesendet: Mittwoch, 17. Januar 2018 10:34
> > An: dev@ode.apache.org
> > Betreff: Re: Extension activities
> >
> > Hi Micheal,
> >
> > Thanks for the contribution.
> >
> > Will have a look at it when I get sometime. Can you share your forked
> > repo link?
> >
> > regards,
> > sathwik
> >
> > On Mon, Jan 15, 2018 at 6:20 PM, Michael Hahn <mh...@gmail.com>
> wrote:
> >
> > > Hi Sathwik,
> > >
> > > as discussed I created a corresponding PR for porting the extension
> > > activity support (https://github.com/apache/ode/pull/4).
> > > In addition, I added an initial BPEL REST extension activity bundle
> > > as an example together with related test cases in 'bpel-test' project.
> > >
> > > Looking forward to your feedback, let me know if something is
> > > missing or has to be adapted :-)
> > >
> > > Best regards,
> > > Michael
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > Gesendet: Mittwoch, 29. November 2017 06:11
> > > An: dev@ode.apache.org
> > > Betreff: Re: Extension activities
> > >
> > > Micheal,
> > > Am done with porting to trunk. You can start on your PR.
> > >
> > > On Nov 25, 2017 13:17, "Sathwik B P" <sa...@gmail.com> wrote:
> > >
> > > > MIchael,
> > > >
> > > > Just hold on to making changes for the trunk, am bringing the
> > > > 1.3.8 commits from the release branch to the trunk. I should
> > > > probably done in about 2-3 days. Major library upgrades are coming
> in.
> > > >
> > > > Just to summarize the changes in the trunk JACOB has been moved
> > > > into a different sub project
> > > > [https://github.com/apache/ode-jacob], the new OModel is here
> > > > https://github.com/apache/ode/tree/master/bpel-nobj
> > .
> > > >
> > > > The compiler has undergone changes. I believe porting of extension
> > > > activities onto this new model will not be straight forward as the
> > > > extension feature was built on the older OModel.
> > > >
> > > > regards,
> > > > sathwik
> > > >
> > > > On Fri, Nov 24, 2017 at 5:43 PM, Sathwik B P
> > > > <sa...@gmail.com>
> > > wrote:
> > > >
> > > >> Micheal,
> > > >>
> > > >> I am working towards 1.3.8 release. We cannot bring the extension
> > > >> activity feature on 1.3.x branch
> > > >>
> > > >> On Nov 24, 2017 15:46, "Michael Hahn" <mh...@gmail.com> wrote:
> > > >>
> > > >>> Hi Sathwik,
> > > >>>
> > > >>> thanks for the pointers.
> > > >>>
> > > >>> I've seen on GitHub that you are currently working on the
> "ode-1.3.x"
> > > >>> branch.
> > > >>> Should I also do the porting based on that branch or better on
> > > >>> the master?
> > > >>>
> > > >>> Regards,
> > > >>> Michael
> > > >>>
> > > >>> -----Ursprüngliche Nachricht-----
> > > >>> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > >>> Gesendet: Donnerstag, 23. November 2017 14:52
> > > >>> An: dev@ode.apache.org
> > > >>> Betreff: Re: Extension activities
> > > >>>
> > > >>> Hi Hahn,
> > > >>>
> > > >>> Good to hear about your interest on porting Extension activities
> > > >>> onto the trunk. It only exists in APACHE_ODE_2.X-experimental"
> > branch.
> > > >>>
> > > >>> I suppose these should be the initial commits from Tammo,
> > > >>> [ODE-159, ODE-160]
> > > >>> https://github.com/apache/ode/commit/5ef69232cc6f19cf2818dd1
> > > >>> b110416b959297126
> > > >>> https://github.com/apache/ode/commit/1d5fa185a77c944e8d4a708
> > > >>> b451611fa74d5c2dc
> > > >>>
> > > >>> You can just go up the commits if there are more.
> > > >>>
> > > >>>
> > > >>> regards,
> > > >>> sathwik
> > > >>>
> > > >>> On Thu, Nov 23, 2017 at 4:39 PM, Michael Hahn
> > > >>> <mh...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>> > Hi,
> > > >>> >
> > > >>> > I'm actually very interested in the support of BPEL extension
> > > >>> > activities in ODE and also willing to help to integrate/build
> > > >>> > the feature :-) Some years ago I was able to successfully port
> > > >>> > the extension activity support from the
> > "APACHE_ODE_2.X-experimental"
> > > >>> > branch into an ODE 1.3.4 release.
> > > >>> >
> > > >>> > So, if someone can give me a pointer where to find the most
> > > >>> > recent version of the extension activity related classes, I
> > > >>> > can integrate the feature into the current trunk and provide
> > > >>> > the result as a pull request. Else I can also simply go with
> > > >>> > the version in the "APACHE_ODE_2.X-experimental" branch as a
> > > >>> > starting
> > point.
> > > >>> >
> > > >>> > Regards,
> > > >>> > Michael
> > > >>> >
> > > >>> > -----Ursprüngliche Nachricht-----
> > > >>> > Von: Sathwik B P [mailto:sathwik@apache.org]
> > > >>> > Gesendet: Mittwoch, 18. Oktober 2017 15:53
> > > >>> > An: dev@ode.apache.org
> > > >>> > Betreff: Re: Extension activities
> > > >>> >
> > > >>> > Hi Oliver,
> > > >>> >
> > > >>> > ODE 2.0 branch was an experimental branch and is not
> > > >>> > maintained since a very long time. I will have to revisit it
> > > >>> > myself, in case it involves changes to the ODE object model,
> > > >>> > then we cannot bring it on any of 1.3.x releases because of
> > > >>> > chances of breaking binary
> > > >>> compatibilities.
> > > >>> >
> > > >>> > In order to make new features available, we moved towards JSON
> > > >>> > based state serialization away from JAVA serialization in the
> > > >>> > trunk which is in 1.4 release.
> > > >>> >
> > > >>> > Currently, we are seeking new committers, you might want to
> > > >>> > discuss the feature that you are willing to contribute and
> > > >>> > probably help us
> > > >>> build it.
> > > >>> >
> > > >>> > regards,
> > > >>> > sathwik
> > > >>> >
> > > >>> >
> > > >>> > On Wed, Oct 18, 2017 at 4:22 PM, Oliver Kopp
> > > >>> > <ko...@gmail.com>
> > > >>> wrote:
> > > >>> >
> > > >>> > > Hi,
> > > >>> > >
> > > >>> > > In the context of our usage, we rely on BPEL extension
> > > >>> > > activity support within ODE for enabling the invocation of
> > > >>> > > REST APIs through a corresponding extension bundle. We
> > > >>> > > therefore ported the extension activity support from the
> > > >>> > > 2.0-alpha branch (already some years ago and therefore not
> > > >>> > > up to date with "latest" version on GitHub) into the current
> > > >>> > > 1.3.7 release build which works. The problem is that by
> > > >>> > > changing the source code of the official ODE 1.3.7 release,
> > > >>> > > we have to ship our extended version of ODE and take over
> > > >>> > > responsibilities regarding licenses, etc. Therefore, it
> > > >>> > > would be really nice if there will be an ODE 1.3.x release
> > > >>> > > with integrated extension activity support, so that we can
> > > >>> > > use/refer to ODE as it is and as a result treat it as a
> > > >>> > > ready to use open source middleware such as
> > > Tomcat, we just use within our ecosystem.
> > > >>> > >
> > > >>> > > Do you see any chance to release a corresponding
> > > >>> > > distribution that contains extension activity support in the
> near future?
> > > >>> > >
> > > >>> > > In return we are really interested in open sourcing our
> > > >>> > > BPEL4REST extension bundle so that it can be shipped as a
> > > >>> > > feature
> > > with ODE!
> > > >>> > > 👨🔧
> > > >>> > >
> > > >>> > > Cheers,
> > > >>> > >
> > > >>> > > Oliver
> > > >>> > >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>>
> > > >
> > >
> > >
> >
> >
>
>
Re: Extension activities
Posted by Oliver Kopp <ko...@gmail.com>.
Hi Sahtwik,
Thank you for clarification!
I also understand your high quality goals. My hope is that with Michael
Hahn as (Apache ODE?) committer can help to achieve these goals.
Cheers,
Oliver
2018-02-23 12:41 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> Oliver,
>
> Apache Ci is Jenkins, code pushes will trigger the build almost immediately
> and snapshots are availavle in the Apache snapshot repo.As I have already
> responded that we cannot market/expose snapshot artifacts to the users as
> per the organization policy no matter which CI tools one proposes to use.
>
> What is your idea behind CI-Pipeline?
>
> regards,
> sathwik
>
> On Fri, Feb 23, 2018 at 5:02 PM, Sathwik B P <sa...@gmail.com> wrote:
>
> > Hi Michael,
> >
> > Just a quick jot down of tasks for JACOB. Migration is another, need to
> > see what is missing in JACOB.
> >
> > JACOB [Release branch (2.0a) - compatible with the ODE trunk branch]
> > ------------------------------------------------------------
> > -------------------------------------------
> > 1) Update pom
> > -- Upgrade Jackson to latest stable release
> > -- JDK 8
> > 2) Lookout for patterns in source as indicated in the CVE [
> > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson].
> > 3) Make a new CI build for the 2.0a-JDK 8.
> > 4) Run the ODE trunk build to take up latest jacob snapshot.
> > 5) Look out for any JACOB open JIRA issues. [issues.apache.org/jira/
> > browse/JACOB]
> >
> > Migrations testing from 1.3.7
> > ------------------------------
> > 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction
> > manager on TOMCAT or use the Embedded ODE Tomee distro.
> > 2) Deploy a prrocess and run an instance of the process.
> > 3) Configure the ODE trunk to the same external database. Run database
> > migration scripts [need to check if there is any required].
> > 4) Do we need to recompile the process binary[.cbp file] to new OModel?
> > This is the real thing.
> > 5) Complete the running process instance. Runtime processing state
> > migration would be tested.
> > 6) Create a fresh process instance on the trunk and complete the running
> > instance.
> > 7) Verify all the exmaple processes in similar fashion.
> >
> > Lets see how it goes from here.
> >
> > regards,
> > sathwik
> >
> > On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mh...@gmail.com>
> wrote:
> >
> >> Hi Sathwik,
> >>
> >> I could commit to support you with the releasing (new JACOB
> >> implementation, ODE) and to help you by taking up features/issues on the
> >> trunk and fix/test them, e.g., implementation of migration from java
> >> serialized jacob states to json based jacob states as mentioned by
> Tammo.
> >>
> >> Would it be possible to create a consolidated roadmap/task list to
> >> exactly define the tasks/steps necessary for the different releases?
> >> So that everybody that wants to contribute is able to do so because at
> >> the moment it is hard to get an idea what the open points are (at least
> >> from my perspective).
> >> If I can help with that, just let me know :-)
> >>
> >> Best regards,
> >> Michael
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> >> Gesendet: Donnerstag, 22. Februar 2018 08:07
> >> An: dev@ode.apache.org
> >> Betreff: Re: Extension activities
> >>
> >> Oliver,
> >>
> >> What is your commitment towards continued interest in developing ODE
> >> further beyond the extension activities? [We are on the verge of zero
> >> project activity].
> >> We can offer committership.
> >>
> >> Trunk is RAW code, never tested. We also probably need to see if there
> >> are any security concerns with respect to JSON serialization used in the
> >> new Serialization mechanism, I vaguely remember as there was a flag
> raised
> >> on it sometime ago on a different project.
> >> We can probably look for an Alpha release unless the PMC disagrees. This
> >> process will require quite an effort on the administrative front.
> >> With my limited bandwidth since I only contribute during my free time,
> >> it's going to be quite a task. I have the 1.3.8 release process on my
> plate.
> >>
> >> What do you mean by "correlation between source + binary"?
> >>
> >> regards,
> >> sathwik
> >>
> >> On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <ko...@gmail.com>
> wrote:
> >>
> >> > Hi,
> >> >
> >> > Sorry for being pushy. The thing, I want to know is: What steps need
> >> > to be taken to create a release which contains our ported extension
> >> activities?
> >> > Should we port them to another branch? Are there features which we
> >> > should help implementing (Jacob?)?
> >> >
> >> > We need an "official" source + binary of the Apache Foundation of
> >> > Apache ODE including support of the extension activities.
> >> >
> >> > It might be possible that an alpha or beta version also works fine. I
> >> > think, the correlation between source + binary is also there and it
> >> > has a touch of a release. So maybe a beta release of the current state
> >> > is possible without much effort from your side? O:-)
> >> >
> >> > Cheers,
> >> >
> >> > Oliver
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > 2018-02-21 13:40 GMT+01:00 Oliver Kopp <ko...@gmail.com>:
> >> >
> >> > > Hi,
> >> > >
> >> > > I think, it's a chiggen-egg problem.
> >> > >
> >> > > Why not establish a more modern release-early-release-often cycle to
> >> > > show activity to the community? What is hindering a CI pipeline?
> >> > > This could
> >> > also
> >> > > ease jumping in this project.I have experience with CircleCI and
> >> > > Travis
> >> > if
> >> > > that helps.
> >> > >
> >> > > This could also kick-off a Google Summer-of-Code project somehow?
> >> > >
> >> > > Cheers,
> >> > >
> >> > > Oliver
> >> > >
> >> > > 2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> >> > >
> >> > >> Hi Oliver,
> >> > >>
> >> > >> May be, we wait to see for the kind of involvment in the DEV
> >> > >> community which justifies the release proposal. Head back to the
> >> > >> run up of 1.3.7 release on the ODE-1.3.x branch and look for the
> >> > >> kind of involvement of devs and also consider the time that these
> >> > >> developers spend on contributing to ODE and then probably revisit
> >> > >> the release cycles.
> >> > >>
> >> > >> ODE 1.4 was envisaged to be a major GA release with new features,
> >> > >> but
> >> > due
> >> > >> to lack of involvement in the community it has not seen the light
> >> > >> of the day. I would encourage developers to take up features/issues
> >> > >> on the
> >> > trunk
> >> > >> and fix/test them and share information to the community, so that
> >> > >> the
> >> > PMC
> >> > >> can make a sound judgement about releases.
> >> > >>
> >> > >> We would definitely like to see fresh blood coming into the
> >> community.
> >> > >>
> >> > >> regards,
> >> > >> sathwik
> >> > >>
> >> > >> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >>
> >> > >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> >> > >>
> >> > >> > I dont have a timeline as of yet. The trunk has lot of changes.
> >> > >> > We
> >> > need
> >> > >> to
> >> > >> > release the new JACOB implementation. Revisit the clustering
> >> > >> implementation
> >> > >> > based on hazelcast. We need to test migrations from 1.3.x
> >> > >> > versions
> >> > from
> >> > >> > java serialization to json based serialization. We need to
> >> > >> > document
> >> > >> these.
> >> > >> > All this is sitting on the trunk.
> >> > >> >
> >> > >>
> >> > >> Oh, wow, this sounds like much work.
> >> > >>
> >> > >> Can't we rethink the release model? I am pretty impressed, what
> >> > >> Angular
> >> > is
> >> > >> doing. They seem to follow "Release early, release often" (
> >> > >> https://en.wikipedia.org/wiki/Release_early,_release_often ) very
> >> > >> close and they are not afraid of getting issue reports.
> >> > >>
> >> > >> You are doing an amazing job at Apache ODE. It should be possible
> >> > >> that your work reaches the public very soon: New features and fixes
> >> > >> should be released soon and not be kept hidden for a long time.
> >> > >>
> >> > >> I would propose the following:
> >> > >>
> >> > >> 1. Start using semantic versioning - https://semver.org/ 2. Make
> >> > >> sure that the each of the points you listed are marked as
> >> > >> openedissue 3. Release ODE 3.0.0 from the trunk straight away. -
> >> > >> Reason: A) There
> >> > was
> >> > >> once ODE 2.x, so that should be skipped. B) It is NOT backward
> >> > compatible
> >> > >> with ODE 1.x (Jacob-JSON things)
> >> > >> 4. Work on the JSON migration from java serialized jacob states to
> >> > >> json based 5. Release ODE 4.0.0, which is then (hopefully)
> >> > >> backard-compatible with 1.3.x
> >> > >>
> >> > >> Reasoning:
> >> > >>
> >> > >> 1. The 1.x line can still be maintained as rock-solid engine
> >> > >> implementation for business users 2. Starting from 3.x, ODE is a
> >> > >> fast-moving project, which can include contributions from external
> >> > >> fast and also have the possibility to
> >> > "release
> >> > >> early, release often"
> >> > >>
> >> > >> I would also propose to have the "master" branch always release
> >> ready:
> >> > All
> >> > >> tests are green.
> >> > >>
> >> > >> WDYT?
> >> > >>
> >> > >> Cheers,
> >> > >>
> >> > >> Oliver
> >> > >> --
> >> > >> http://github.com/koppor/
> >> > >>
> >> > >
> >> > >
> >> >
> >>
> >>
> >
>
Re: Extension activities
Posted by Sathwik B P <sa...@gmail.com>.
Oliver,
Apache Ci is Jenkins, code pushes will trigger the build almost immediately
and snapshots are availavle in the Apache snapshot repo.As I have already
responded that we cannot market/expose snapshot artifacts to the users as
per the organization policy no matter which CI tools one proposes to use.
What is your idea behind CI-Pipeline?
regards,
sathwik
On Fri, Feb 23, 2018 at 5:02 PM, Sathwik B P <sa...@gmail.com> wrote:
> Hi Michael,
>
> Just a quick jot down of tasks for JACOB. Migration is another, need to
> see what is missing in JACOB.
>
> JACOB [Release branch (2.0a) - compatible with the ODE trunk branch]
> ------------------------------------------------------------
> -------------------------------------------
> 1) Update pom
> -- Upgrade Jackson to latest stable release
> -- JDK 8
> 2) Lookout for patterns in source as indicated in the CVE [
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson].
> 3) Make a new CI build for the 2.0a-JDK 8.
> 4) Run the ODE trunk build to take up latest jacob snapshot.
> 5) Look out for any JACOB open JIRA issues. [issues.apache.org/jira/
> browse/JACOB]
>
> Migrations testing from 1.3.7
> ------------------------------
> 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction
> manager on TOMCAT or use the Embedded ODE Tomee distro.
> 2) Deploy a prrocess and run an instance of the process.
> 3) Configure the ODE trunk to the same external database. Run database
> migration scripts [need to check if there is any required].
> 4) Do we need to recompile the process binary[.cbp file] to new OModel?
> This is the real thing.
> 5) Complete the running process instance. Runtime processing state
> migration would be tested.
> 6) Create a fresh process instance on the trunk and complete the running
> instance.
> 7) Verify all the exmaple processes in similar fashion.
>
> Lets see how it goes from here.
>
> regards,
> sathwik
>
> On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mh...@gmail.com> wrote:
>
>> Hi Sathwik,
>>
>> I could commit to support you with the releasing (new JACOB
>> implementation, ODE) and to help you by taking up features/issues on the
>> trunk and fix/test them, e.g., implementation of migration from java
>> serialized jacob states to json based jacob states as mentioned by Tammo.
>>
>> Would it be possible to create a consolidated roadmap/task list to
>> exactly define the tasks/steps necessary for the different releases?
>> So that everybody that wants to contribute is able to do so because at
>> the moment it is hard to get an idea what the open points are (at least
>> from my perspective).
>> If I can help with that, just let me know :-)
>>
>> Best regards,
>> Michael
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
>> Gesendet: Donnerstag, 22. Februar 2018 08:07
>> An: dev@ode.apache.org
>> Betreff: Re: Extension activities
>>
>> Oliver,
>>
>> What is your commitment towards continued interest in developing ODE
>> further beyond the extension activities? [We are on the verge of zero
>> project activity].
>> We can offer committership.
>>
>> Trunk is RAW code, never tested. We also probably need to see if there
>> are any security concerns with respect to JSON serialization used in the
>> new Serialization mechanism, I vaguely remember as there was a flag raised
>> on it sometime ago on a different project.
>> We can probably look for an Alpha release unless the PMC disagrees. This
>> process will require quite an effort on the administrative front.
>> With my limited bandwidth since I only contribute during my free time,
>> it's going to be quite a task. I have the 1.3.8 release process on my plate.
>>
>> What do you mean by "correlation between source + binary"?
>>
>> regards,
>> sathwik
>>
>> On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <ko...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > Sorry for being pushy. The thing, I want to know is: What steps need
>> > to be taken to create a release which contains our ported extension
>> activities?
>> > Should we port them to another branch? Are there features which we
>> > should help implementing (Jacob?)?
>> >
>> > We need an "official" source + binary of the Apache Foundation of
>> > Apache ODE including support of the extension activities.
>> >
>> > It might be possible that an alpha or beta version also works fine. I
>> > think, the correlation between source + binary is also there and it
>> > has a touch of a release. So maybe a beta release of the current state
>> > is possible without much effort from your side? O:-)
>> >
>> > Cheers,
>> >
>> > Oliver
>> >
>> >
>> >
>> >
>> >
>> > 2018-02-21 13:40 GMT+01:00 Oliver Kopp <ko...@gmail.com>:
>> >
>> > > Hi,
>> > >
>> > > I think, it's a chiggen-egg problem.
>> > >
>> > > Why not establish a more modern release-early-release-often cycle to
>> > > show activity to the community? What is hindering a CI pipeline?
>> > > This could
>> > also
>> > > ease jumping in this project.I have experience with CircleCI and
>> > > Travis
>> > if
>> > > that helps.
>> > >
>> > > This could also kick-off a Google Summer-of-Code project somehow?
>> > >
>> > > Cheers,
>> > >
>> > > Oliver
>> > >
>> > > 2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
>> > >
>> > >> Hi Oliver,
>> > >>
>> > >> May be, we wait to see for the kind of involvment in the DEV
>> > >> community which justifies the release proposal. Head back to the
>> > >> run up of 1.3.7 release on the ODE-1.3.x branch and look for the
>> > >> kind of involvement of devs and also consider the time that these
>> > >> developers spend on contributing to ODE and then probably revisit
>> > >> the release cycles.
>> > >>
>> > >> ODE 1.4 was envisaged to be a major GA release with new features,
>> > >> but
>> > due
>> > >> to lack of involvement in the community it has not seen the light
>> > >> of the day. I would encourage developers to take up features/issues
>> > >> on the
>> > trunk
>> > >> and fix/test them and share information to the community, so that
>> > >> the
>> > PMC
>> > >> can make a sound judgement about releases.
>> > >>
>> > >> We would definitely like to see fresh blood coming into the
>> community.
>> > >>
>> > >> regards,
>> > >> sathwik
>> > >>
>> > >> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >>
>> > >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
>> > >>
>> > >> > I dont have a timeline as of yet. The trunk has lot of changes.
>> > >> > We
>> > need
>> > >> to
>> > >> > release the new JACOB implementation. Revisit the clustering
>> > >> implementation
>> > >> > based on hazelcast. We need to test migrations from 1.3.x
>> > >> > versions
>> > from
>> > >> > java serialization to json based serialization. We need to
>> > >> > document
>> > >> these.
>> > >> > All this is sitting on the trunk.
>> > >> >
>> > >>
>> > >> Oh, wow, this sounds like much work.
>> > >>
>> > >> Can't we rethink the release model? I am pretty impressed, what
>> > >> Angular
>> > is
>> > >> doing. They seem to follow "Release early, release often" (
>> > >> https://en.wikipedia.org/wiki/Release_early,_release_often ) very
>> > >> close and they are not afraid of getting issue reports.
>> > >>
>> > >> You are doing an amazing job at Apache ODE. It should be possible
>> > >> that your work reaches the public very soon: New features and fixes
>> > >> should be released soon and not be kept hidden for a long time.
>> > >>
>> > >> I would propose the following:
>> > >>
>> > >> 1. Start using semantic versioning - https://semver.org/ 2. Make
>> > >> sure that the each of the points you listed are marked as
>> > >> openedissue 3. Release ODE 3.0.0 from the trunk straight away. -
>> > >> Reason: A) There
>> > was
>> > >> once ODE 2.x, so that should be skipped. B) It is NOT backward
>> > compatible
>> > >> with ODE 1.x (Jacob-JSON things)
>> > >> 4. Work on the JSON migration from java serialized jacob states to
>> > >> json based 5. Release ODE 4.0.0, which is then (hopefully)
>> > >> backard-compatible with 1.3.x
>> > >>
>> > >> Reasoning:
>> > >>
>> > >> 1. The 1.x line can still be maintained as rock-solid engine
>> > >> implementation for business users 2. Starting from 3.x, ODE is a
>> > >> fast-moving project, which can include contributions from external
>> > >> fast and also have the possibility to
>> > "release
>> > >> early, release often"
>> > >>
>> > >> I would also propose to have the "master" branch always release
>> ready:
>> > All
>> > >> tests are green.
>> > >>
>> > >> WDYT?
>> > >>
>> > >> Cheers,
>> > >>
>> > >> Oliver
>> > >> --
>> > >> http://github.com/koppor/
>> > >>
>> > >
>> > >
>> >
>>
>>
>
Re: Extension activities
Posted by Oliver Kopp <ko...@gmail.com>.
Hi,
would an etherpad instance (maybe created using https://pad.riseup.net/)
help to coordinate? Do you have other means "inbetween" issue tracker and
mailinglists in place in the context of Apache ODE?
Cheers,
Oliver
2018-02-23 12:32 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> Hi Michael,
>
> Just a quick jot down of tasks for JACOB. Migration is another, need to see
> what is missing in JACOB.
>
> JACOB [Release branch (2.0a) - compatible with the ODE trunk branch]
> ------------------------------------------------------------
> -------------------------------------------
> 1) Update pom
> -- Upgrade Jackson to latest stable release
> -- JDK 8
> 2) Lookout for patterns in source as indicated in the CVE [
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson].
> 3) Make a new CI build for the 2.0a-JDK 8.
> 4) Run the ODE trunk build to take up latest jacob snapshot.
> 5) Look out for any JACOB open JIRA issues. [
> issues.apache.org/jira/browse/JACOB]
>
> Migrations testing from 1.3.7
> ------------------------------
> 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction
> manager on TOMCAT or use the Embedded ODE Tomee distro.
> 2) Deploy a prrocess and run an instance of the process.
> 3) Configure the ODE trunk to the same external database. Run database
> migration scripts [need to check if there is any required].
> 4) Do we need to recompile the process binary[.cbp file] to new OModel?
> This is the real thing.
> 5) Complete the running process instance. Runtime processing state
> migration would be tested.
> 6) Create a fresh process instance on the trunk and complete the running
> instance.
> 7) Verify all the exmaple processes in similar fashion.
>
> Lets see how it goes from here.
>
> regards,
> sathwik
>
> On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mh...@gmail.com> wrote:
>
> > Hi Sathwik,
> >
> > I could commit to support you with the releasing (new JACOB
> > implementation, ODE) and to help you by taking up features/issues on the
> > trunk and fix/test them, e.g., implementation of migration from java
> > serialized jacob states to json based jacob states as mentioned by Tammo.
> >
> > Would it be possible to create a consolidated roadmap/task list to
> exactly
> > define the tasks/steps necessary for the different releases?
> > So that everybody that wants to contribute is able to do so because at
> the
> > moment it is hard to get an idea what the open points are (at least from
> my
> > perspective).
> > If I can help with that, just let me know :-)
> >
> > Best regards,
> > Michael
>
Re: Extension activities
Posted by Sathwik B P <sa...@gmail.com>.
Hi Michael,
Just a quick jot down of tasks for JACOB. Migration is another, need to see
what is missing in JACOB.
JACOB [Release branch (2.0a) - compatible with the ODE trunk branch]
-------------------------------------------------------------------------------------------------------
1) Update pom
-- Upgrade Jackson to latest stable release
-- JDK 8
2) Lookout for patterns in source as indicated in the CVE [
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson].
3) Make a new CI build for the 2.0a-JDK 8.
4) Run the ODE trunk build to take up latest jacob snapshot.
5) Look out for any JACOB open JIRA issues. [
issues.apache.org/jira/browse/JACOB]
Migrations testing from 1.3.7
------------------------------
1) Deploy ODE 1.3.7 with external database [mysql] and any transaction
manager on TOMCAT or use the Embedded ODE Tomee distro.
2) Deploy a prrocess and run an instance of the process.
3) Configure the ODE trunk to the same external database. Run database
migration scripts [need to check if there is any required].
4) Do we need to recompile the process binary[.cbp file] to new OModel?
This is the real thing.
5) Complete the running process instance. Runtime processing state
migration would be tested.
6) Create a fresh process instance on the trunk and complete the running
instance.
7) Verify all the exmaple processes in similar fashion.
Lets see how it goes from here.
regards,
sathwik
On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mh...@gmail.com> wrote:
> Hi Sathwik,
>
> I could commit to support you with the releasing (new JACOB
> implementation, ODE) and to help you by taking up features/issues on the
> trunk and fix/test them, e.g., implementation of migration from java
> serialized jacob states to json based jacob states as mentioned by Tammo.
>
> Would it be possible to create a consolidated roadmap/task list to exactly
> define the tasks/steps necessary for the different releases?
> So that everybody that wants to contribute is able to do so because at the
> moment it is hard to get an idea what the open points are (at least from my
> perspective).
> If I can help with that, just let me know :-)
>
> Best regards,
> Michael
>
> -----Ursprüngliche Nachricht-----
> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> Gesendet: Donnerstag, 22. Februar 2018 08:07
> An: dev@ode.apache.org
> Betreff: Re: Extension activities
>
> Oliver,
>
> What is your commitment towards continued interest in developing ODE
> further beyond the extension activities? [We are on the verge of zero
> project activity].
> We can offer committership.
>
> Trunk is RAW code, never tested. We also probably need to see if there are
> any security concerns with respect to JSON serialization used in the new
> Serialization mechanism, I vaguely remember as there was a flag raised on
> it sometime ago on a different project.
> We can probably look for an Alpha release unless the PMC disagrees. This
> process will require quite an effort on the administrative front.
> With my limited bandwidth since I only contribute during my free time,
> it's going to be quite a task. I have the 1.3.8 release process on my plate.
>
> What do you mean by "correlation between source + binary"?
>
> regards,
> sathwik
>
> On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <ko...@gmail.com> wrote:
>
> > Hi,
> >
> > Sorry for being pushy. The thing, I want to know is: What steps need
> > to be taken to create a release which contains our ported extension
> activities?
> > Should we port them to another branch? Are there features which we
> > should help implementing (Jacob?)?
> >
> > We need an "official" source + binary of the Apache Foundation of
> > Apache ODE including support of the extension activities.
> >
> > It might be possible that an alpha or beta version also works fine. I
> > think, the correlation between source + binary is also there and it
> > has a touch of a release. So maybe a beta release of the current state
> > is possible without much effort from your side? O:-)
> >
> > Cheers,
> >
> > Oliver
> >
> >
> >
> >
> >
> > 2018-02-21 13:40 GMT+01:00 Oliver Kopp <ko...@gmail.com>:
> >
> > > Hi,
> > >
> > > I think, it's a chiggen-egg problem.
> > >
> > > Why not establish a more modern release-early-release-often cycle to
> > > show activity to the community? What is hindering a CI pipeline?
> > > This could
> > also
> > > ease jumping in this project.I have experience with CircleCI and
> > > Travis
> > if
> > > that helps.
> > >
> > > This could also kick-off a Google Summer-of-Code project somehow?
> > >
> > > Cheers,
> > >
> > > Oliver
> > >
> > > 2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> > >
> > >> Hi Oliver,
> > >>
> > >> May be, we wait to see for the kind of involvment in the DEV
> > >> community which justifies the release proposal. Head back to the
> > >> run up of 1.3.7 release on the ODE-1.3.x branch and look for the
> > >> kind of involvement of devs and also consider the time that these
> > >> developers spend on contributing to ODE and then probably revisit
> > >> the release cycles.
> > >>
> > >> ODE 1.4 was envisaged to be a major GA release with new features,
> > >> but
> > due
> > >> to lack of involvement in the community it has not seen the light
> > >> of the day. I would encourage developers to take up features/issues
> > >> on the
> > trunk
> > >> and fix/test them and share information to the community, so that
> > >> the
> > PMC
> > >> can make a sound judgement about releases.
> > >>
> > >> We would definitely like to see fresh blood coming into the community.
> > >>
> > >> regards,
> > >> sathwik
> > >>
> > >> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >>
> > >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> > >>
> > >> > I dont have a timeline as of yet. The trunk has lot of changes.
> > >> > We
> > need
> > >> to
> > >> > release the new JACOB implementation. Revisit the clustering
> > >> implementation
> > >> > based on hazelcast. We need to test migrations from 1.3.x
> > >> > versions
> > from
> > >> > java serialization to json based serialization. We need to
> > >> > document
> > >> these.
> > >> > All this is sitting on the trunk.
> > >> >
> > >>
> > >> Oh, wow, this sounds like much work.
> > >>
> > >> Can't we rethink the release model? I am pretty impressed, what
> > >> Angular
> > is
> > >> doing. They seem to follow "Release early, release often" (
> > >> https://en.wikipedia.org/wiki/Release_early,_release_often ) very
> > >> close and they are not afraid of getting issue reports.
> > >>
> > >> You are doing an amazing job at Apache ODE. It should be possible
> > >> that your work reaches the public very soon: New features and fixes
> > >> should be released soon and not be kept hidden for a long time.
> > >>
> > >> I would propose the following:
> > >>
> > >> 1. Start using semantic versioning - https://semver.org/ 2. Make
> > >> sure that the each of the points you listed are marked as
> > >> openedissue 3. Release ODE 3.0.0 from the trunk straight away. -
> > >> Reason: A) There
> > was
> > >> once ODE 2.x, so that should be skipped. B) It is NOT backward
> > compatible
> > >> with ODE 1.x (Jacob-JSON things)
> > >> 4. Work on the JSON migration from java serialized jacob states to
> > >> json based 5. Release ODE 4.0.0, which is then (hopefully)
> > >> backard-compatible with 1.3.x
> > >>
> > >> Reasoning:
> > >>
> > >> 1. The 1.x line can still be maintained as rock-solid engine
> > >> implementation for business users 2. Starting from 3.x, ODE is a
> > >> fast-moving project, which can include contributions from external
> > >> fast and also have the possibility to
> > "release
> > >> early, release often"
> > >>
> > >> I would also propose to have the "master" branch always release ready:
> > All
> > >> tests are green.
> > >>
> > >> WDYT?
> > >>
> > >> Cheers,
> > >>
> > >> Oliver
> > >> --
> > >> http://github.com/koppor/
> > >>
> > >
> > >
> >
>
>
AW: Extension activities
Posted by Michael Hahn <mh...@gmail.com>.
Hi Sathwik,
I could commit to support you with the releasing (new JACOB implementation, ODE) and to help you by taking up features/issues on the trunk and fix/test them, e.g., implementation of migration from java serialized jacob states to json based jacob states as mentioned by Tammo.
Would it be possible to create a consolidated roadmap/task list to exactly define the tasks/steps necessary for the different releases?
So that everybody that wants to contribute is able to do so because at the moment it is hard to get an idea what the open points are (at least from my perspective).
If I can help with that, just let me know :-)
Best regards,
Michael
-----Ursprüngliche Nachricht-----
Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
Gesendet: Donnerstag, 22. Februar 2018 08:07
An: dev@ode.apache.org
Betreff: Re: Extension activities
Oliver,
What is your commitment towards continued interest in developing ODE further beyond the extension activities? [We are on the verge of zero project activity].
We can offer committership.
Trunk is RAW code, never tested. We also probably need to see if there are any security concerns with respect to JSON serialization used in the new Serialization mechanism, I vaguely remember as there was a flag raised on it sometime ago on a different project.
We can probably look for an Alpha release unless the PMC disagrees. This process will require quite an effort on the administrative front.
With my limited bandwidth since I only contribute during my free time, it's going to be quite a task. I have the 1.3.8 release process on my plate.
What do you mean by "correlation between source + binary"?
regards,
sathwik
On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <ko...@gmail.com> wrote:
> Hi,
>
> Sorry for being pushy. The thing, I want to know is: What steps need
> to be taken to create a release which contains our ported extension activities?
> Should we port them to another branch? Are there features which we
> should help implementing (Jacob?)?
>
> We need an "official" source + binary of the Apache Foundation of
> Apache ODE including support of the extension activities.
>
> It might be possible that an alpha or beta version also works fine. I
> think, the correlation between source + binary is also there and it
> has a touch of a release. So maybe a beta release of the current state
> is possible without much effort from your side? O:-)
>
> Cheers,
>
> Oliver
>
>
>
>
>
> 2018-02-21 13:40 GMT+01:00 Oliver Kopp <ko...@gmail.com>:
>
> > Hi,
> >
> > I think, it's a chiggen-egg problem.
> >
> > Why not establish a more modern release-early-release-often cycle to
> > show activity to the community? What is hindering a CI pipeline?
> > This could
> also
> > ease jumping in this project.I have experience with CircleCI and
> > Travis
> if
> > that helps.
> >
> > This could also kick-off a Google Summer-of-Code project somehow?
> >
> > Cheers,
> >
> > Oliver
> >
> > 2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> >
> >> Hi Oliver,
> >>
> >> May be, we wait to see for the kind of involvment in the DEV
> >> community which justifies the release proposal. Head back to the
> >> run up of 1.3.7 release on the ODE-1.3.x branch and look for the
> >> kind of involvement of devs and also consider the time that these
> >> developers spend on contributing to ODE and then probably revisit
> >> the release cycles.
> >>
> >> ODE 1.4 was envisaged to be a major GA release with new features,
> >> but
> due
> >> to lack of involvement in the community it has not seen the light
> >> of the day. I would encourage developers to take up features/issues
> >> on the
> trunk
> >> and fix/test them and share information to the community, so that
> >> the
> PMC
> >> can make a sound judgement about releases.
> >>
> >> We would definitely like to see fresh blood coming into the community.
> >>
> >> regards,
> >> sathwik
> >>
> >> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >>
> >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> >>
> >> > I dont have a timeline as of yet. The trunk has lot of changes.
> >> > We
> need
> >> to
> >> > release the new JACOB implementation. Revisit the clustering
> >> implementation
> >> > based on hazelcast. We need to test migrations from 1.3.x
> >> > versions
> from
> >> > java serialization to json based serialization. We need to
> >> > document
> >> these.
> >> > All this is sitting on the trunk.
> >> >
> >>
> >> Oh, wow, this sounds like much work.
> >>
> >> Can't we rethink the release model? I am pretty impressed, what
> >> Angular
> is
> >> doing. They seem to follow "Release early, release often" (
> >> https://en.wikipedia.org/wiki/Release_early,_release_often ) very
> >> close and they are not afraid of getting issue reports.
> >>
> >> You are doing an amazing job at Apache ODE. It should be possible
> >> that your work reaches the public very soon: New features and fixes
> >> should be released soon and not be kept hidden for a long time.
> >>
> >> I would propose the following:
> >>
> >> 1. Start using semantic versioning - https://semver.org/ 2. Make
> >> sure that the each of the points you listed are marked as
> >> openedissue 3. Release ODE 3.0.0 from the trunk straight away. -
> >> Reason: A) There
> was
> >> once ODE 2.x, so that should be skipped. B) It is NOT backward
> compatible
> >> with ODE 1.x (Jacob-JSON things)
> >> 4. Work on the JSON migration from java serialized jacob states to
> >> json based 5. Release ODE 4.0.0, which is then (hopefully)
> >> backard-compatible with 1.3.x
> >>
> >> Reasoning:
> >>
> >> 1. The 1.x line can still be maintained as rock-solid engine
> >> implementation for business users 2. Starting from 3.x, ODE is a
> >> fast-moving project, which can include contributions from external
> >> fast and also have the possibility to
> "release
> >> early, release often"
> >>
> >> I would also propose to have the "master" branch always release ready:
> All
> >> tests are green.
> >>
> >> WDYT?
> >>
> >> Cheers,
> >>
> >> Oliver
> >> --
> >> http://github.com/koppor/
> >>
> >
> >
>
Re: Extension activities
Posted by Sathwik B P <sa...@gmail.com>.
Oliver,
What is your commitment towards continued interest in developing ODE
further beyond the extension activities? [We are on the verge of zero
project activity].
We can offer committership.
Trunk is RAW code, never tested. We also probably need to see if there are
any security concerns with respect to JSON serialization used in the new
Serialization mechanism, I vaguely remember as there was a flag raised on
it sometime ago on a different project.
We can probably look for an Alpha release unless the PMC disagrees. This
process will require quite an effort on the administrative front.
With my limited bandwidth since I only contribute during my free time, it's
going to be quite a task. I have the 1.3.8 release process on my plate.
What do you mean by "correlation between source + binary"?
regards,
sathwik
On Wed, Feb 21, 2018 at 9:40 PM, Oliver Kopp <ko...@gmail.com> wrote:
> Hi,
>
> Sorry for being pushy. The thing, I want to know is: What steps need to be
> taken to create a release which contains our ported extension activities?
> Should we port them to another branch? Are there features which we should
> help implementing (Jacob?)?
>
> We need an "official" source + binary of the Apache Foundation of Apache
> ODE including support of the extension activities.
>
> It might be possible that an alpha or beta version also works fine. I
> think, the correlation between source + binary is also there and it has a
> touch of a release. So maybe a beta release of the current state is
> possible without much effort from your side? O:-)
>
> Cheers,
>
> Oliver
>
>
>
>
>
> 2018-02-21 13:40 GMT+01:00 Oliver Kopp <ko...@gmail.com>:
>
> > Hi,
> >
> > I think, it's a chiggen-egg problem.
> >
> > Why not establish a more modern release-early-release-often cycle to show
> > activity to the community? What is hindering a CI pipeline? This could
> also
> > ease jumping in this project.I have experience with CircleCI and Travis
> if
> > that helps.
> >
> > This could also kick-off a Google Summer-of-Code project somehow?
> >
> > Cheers,
> >
> > Oliver
> >
> > 2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> >
> >> Hi Oliver,
> >>
> >> May be, we wait to see for the kind of involvment in the DEV community
> >> which justifies the release proposal. Head back to the run up of 1.3.7
> >> release on the ODE-1.3.x branch and look for the kind of involvement of
> >> devs and also consider the time that these developers spend on
> >> contributing
> >> to ODE and then probably revisit the release cycles.
> >>
> >> ODE 1.4 was envisaged to be a major GA release with new features, but
> due
> >> to lack of involvement in the community it has not seen the light of the
> >> day. I would encourage developers to take up features/issues on the
> trunk
> >> and fix/test them and share information to the community, so that the
> PMC
> >> can make a sound judgement about releases.
> >>
> >> We would definitely like to see fresh blood coming into the community.
> >>
> >> regards,
> >> sathwik
> >>
> >> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >>
> >> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> >>
> >> > I dont have a timeline as of yet. The trunk has lot of changes. We
> need
> >> to
> >> > release the new JACOB implementation. Revisit the clustering
> >> implementation
> >> > based on hazelcast. We need to test migrations from 1.3.x versions
> from
> >> > java serialization to json based serialization. We need to document
> >> these.
> >> > All this is sitting on the trunk.
> >> >
> >>
> >> Oh, wow, this sounds like much work.
> >>
> >> Can't we rethink the release model? I am pretty impressed, what Angular
> is
> >> doing. They seem to follow "Release early, release often" (
> >> https://en.wikipedia.org/wiki/Release_early,_release_often ) very close
> >> and
> >> they are not afraid of getting issue reports.
> >>
> >> You are doing an amazing job at Apache ODE. It should be possible that
> >> your
> >> work reaches the public very soon: New features and fixes should be
> >> released soon and not be kept hidden for a long time.
> >>
> >> I would propose the following:
> >>
> >> 1. Start using semantic versioning - https://semver.org/
> >> 2. Make sure that the each of the points you listed are marked as
> >> openedissue
> >> 3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There
> was
> >> once ODE 2.x, so that should be skipped. B) It is NOT backward
> compatible
> >> with ODE 1.x (Jacob-JSON things)
> >> 4. Work on the JSON migration from java serialized jacob states to json
> >> based
> >> 5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
> >> 1.3.x
> >>
> >> Reasoning:
> >>
> >> 1. The 1.x line can still be maintained as rock-solid engine
> >> implementation
> >> for business users
> >> 2. Starting from 3.x, ODE is a fast-moving project, which can include
> >> contributions from external fast and also have the possibility to
> "release
> >> early, release often"
> >>
> >> I would also propose to have the "master" branch always release ready:
> All
> >> tests are green.
> >>
> >> WDYT?
> >>
> >> Cheers,
> >>
> >> Oliver
> >> --
> >> http://github.com/koppor/
> >>
> >
> >
>
Re: Extension activities
Posted by Oliver Kopp <ko...@gmail.com>.
Hi,
Sorry for being pushy. The thing, I want to know is: What steps need to be
taken to create a release which contains our ported extension activities?
Should we port them to another branch? Are there features which we should
help implementing (Jacob?)?
We need an "official" source + binary of the Apache Foundation of Apache
ODE including support of the extension activities.
It might be possible that an alpha or beta version also works fine. I
think, the correlation between source + binary is also there and it has a
touch of a release. So maybe a beta release of the current state is
possible without much effort from your side? O:-)
Cheers,
Oliver
2018-02-21 13:40 GMT+01:00 Oliver Kopp <ko...@gmail.com>:
> Hi,
>
> I think, it's a chiggen-egg problem.
>
> Why not establish a more modern release-early-release-often cycle to show
> activity to the community? What is hindering a CI pipeline? This could also
> ease jumping in this project.I have experience with CircleCI and Travis if
> that helps.
>
> This could also kick-off a Google Summer-of-Code project somehow?
>
> Cheers,
>
> Oliver
>
> 2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
>
>> Hi Oliver,
>>
>> May be, we wait to see for the kind of involvment in the DEV community
>> which justifies the release proposal. Head back to the run up of 1.3.7
>> release on the ODE-1.3.x branch and look for the kind of involvement of
>> devs and also consider the time that these developers spend on
>> contributing
>> to ODE and then probably revisit the release cycles.
>>
>> ODE 1.4 was envisaged to be a major GA release with new features, but due
>> to lack of involvement in the community it has not seen the light of the
>> day. I would encourage developers to take up features/issues on the trunk
>> and fix/test them and share information to the community, so that the PMC
>> can make a sound judgement about releases.
>>
>> We would definitely like to see fresh blood coming into the community.
>>
>> regards,
>> sathwik
>>
>> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
>>
>> Hi,
>>
>>
>> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
>>
>> > I dont have a timeline as of yet. The trunk has lot of changes. We need
>> to
>> > release the new JACOB implementation. Revisit the clustering
>> implementation
>> > based on hazelcast. We need to test migrations from 1.3.x versions from
>> > java serialization to json based serialization. We need to document
>> these.
>> > All this is sitting on the trunk.
>> >
>>
>> Oh, wow, this sounds like much work.
>>
>> Can't we rethink the release model? I am pretty impressed, what Angular is
>> doing. They seem to follow "Release early, release often" (
>> https://en.wikipedia.org/wiki/Release_early,_release_often ) very close
>> and
>> they are not afraid of getting issue reports.
>>
>> You are doing an amazing job at Apache ODE. It should be possible that
>> your
>> work reaches the public very soon: New features and fixes should be
>> released soon and not be kept hidden for a long time.
>>
>> I would propose the following:
>>
>> 1. Start using semantic versioning - https://semver.org/
>> 2. Make sure that the each of the points you listed are marked as
>> openedissue
>> 3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
>> once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
>> with ODE 1.x (Jacob-JSON things)
>> 4. Work on the JSON migration from java serialized jacob states to json
>> based
>> 5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
>> 1.3.x
>>
>> Reasoning:
>>
>> 1. The 1.x line can still be maintained as rock-solid engine
>> implementation
>> for business users
>> 2. Starting from 3.x, ODE is a fast-moving project, which can include
>> contributions from external fast and also have the possibility to "release
>> early, release often"
>>
>> I would also propose to have the "master" branch always release ready: All
>> tests are green.
>>
>> WDYT?
>>
>> Cheers,
>>
>> Oliver
>> --
>> http://github.com/koppor/
>>
>
>
Re: Extension activities
Posted by Oliver Kopp <ko...@gmail.com>.
Hi,
I think, it's a chiggen-egg problem.
Why not establish a more modern release-early-release-often cycle to show
activity to the community? What is hindering a CI pipeline? This could also
ease jumping in this project.I have experience with CircleCI and Travis if
that helps.
This could also kick-off a Google Summer-of-Code project somehow?
Cheers,
Oliver
2018-02-03 5:26 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> Hi Oliver,
>
> May be, we wait to see for the kind of involvment in the DEV community
> which justifies the release proposal. Head back to the run up of 1.3.7
> release on the ODE-1.3.x branch and look for the kind of involvement of
> devs and also consider the time that these developers spend on contributing
> to ODE and then probably revisit the release cycles.
>
> ODE 1.4 was envisaged to be a major GA release with new features, but due
> to lack of involvement in the community it has not seen the light of the
> day. I would encourage developers to take up features/issues on the trunk
> and fix/test them and share information to the community, so that the PMC
> can make a sound judgement about releases.
>
> We would definitely like to see fresh blood coming into the community.
>
> regards,
> sathwik
>
> On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
>
> Hi,
>
>
> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
>
> > I dont have a timeline as of yet. The trunk has lot of changes. We need
> to
> > release the new JACOB implementation. Revisit the clustering
> implementation
> > based on hazelcast. We need to test migrations from 1.3.x versions from
> > java serialization to json based serialization. We need to document
> these.
> > All this is sitting on the trunk.
> >
>
> Oh, wow, this sounds like much work.
>
> Can't we rethink the release model? I am pretty impressed, what Angular is
> doing. They seem to follow "Release early, release often" (
> https://en.wikipedia.org/wiki/Release_early,_release_often ) very close
> and
> they are not afraid of getting issue reports.
>
> You are doing an amazing job at Apache ODE. It should be possible that your
> work reaches the public very soon: New features and fixes should be
> released soon and not be kept hidden for a long time.
>
> I would propose the following:
>
> 1. Start using semantic versioning - https://semver.org/
> 2. Make sure that the each of the points you listed are marked as
> openedissue
> 3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
> once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
> with ODE 1.x (Jacob-JSON things)
> 4. Work on the JSON migration from java serialized jacob states to json
> based
> 5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
> 1.3.x
>
> Reasoning:
>
> 1. The 1.x line can still be maintained as rock-solid engine implementation
> for business users
> 2. Starting from 3.x, ODE is a fast-moving project, which can include
> contributions from external fast and also have the possibility to "release
> early, release often"
>
> I would also propose to have the "master" branch always release ready: All
> tests are green.
>
> WDYT?
>
> Cheers,
>
> Oliver
> --
> http://github.com/koppor/
>
Re: Extension activities
Posted by Sathwik B P <sa...@gmail.com>.
Hi Oliver,
May be, we wait to see for the kind of involvment in the DEV community
which justifies the release proposal. Head back to the run up of 1.3.7
release on the ODE-1.3.x branch and look for the kind of involvement of
devs and also consider the time that these developers spend on contributing
to ODE and then probably revisit the release cycles.
ODE 1.4 was envisaged to be a major GA release with new features, but due
to lack of involvement in the community it has not seen the light of the
day. I would encourage developers to take up features/issues on the trunk
and fix/test them and share information to the community, so that the PMC
can make a sound judgement about releases.
We would definitely like to see fresh blood coming into the community.
regards,
sathwik
On Feb 2, 2018 20:27, "Oliver Kopp" <ko...@gmail.com> wrote:
Hi,
2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> I dont have a timeline as of yet. The trunk has lot of changes. We need to
> release the new JACOB implementation. Revisit the clustering
implementation
> based on hazelcast. We need to test migrations from 1.3.x versions from
> java serialization to json based serialization. We need to document these.
> All this is sitting on the trunk.
>
Oh, wow, this sounds like much work.
Can't we rethink the release model? I am pretty impressed, what Angular is
doing. They seem to follow "Release early, release often" (
https://en.wikipedia.org/wiki/Release_early,_release_often ) very close and
they are not afraid of getting issue reports.
You are doing an amazing job at Apache ODE. It should be possible that your
work reaches the public very soon: New features and fixes should be
released soon and not be kept hidden for a long time.
I would propose the following:
1. Start using semantic versioning - https://semver.org/
2. Make sure that the each of the points you listed are marked as
openedissue
3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
with ODE 1.x (Jacob-JSON things)
4. Work on the JSON migration from java serialized jacob states to json
based
5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
1.3.x
Reasoning:
1. The 1.x line can still be maintained as rock-solid engine implementation
for business users
2. Starting from 3.x, ODE is a fast-moving project, which can include
contributions from external fast and also have the possibility to "release
early, release often"
I would also propose to have the "master" branch always release ready: All
tests are green.
WDYT?
Cheers,
Oliver
--
http://github.com/koppor/
Re: Extension activities
Posted by Oliver Kopp <ko...@gmail.com>.
Hi,
2018-02-01 18:45 GMT+01:00 Sathwik B P <sa...@gmail.com>:
> I dont have a timeline as of yet. The trunk has lot of changes. We need to
> release the new JACOB implementation. Revisit the clustering implementation
> based on hazelcast. We need to test migrations from 1.3.x versions from
> java serialization to json based serialization. We need to document these.
> All this is sitting on the trunk.
>
Oh, wow, this sounds like much work.
Can't we rethink the release model? I am pretty impressed, what Angular is
doing. They seem to follow "Release early, release often" (
https://en.wikipedia.org/wiki/Release_early,_release_often ) very close and
they are not afraid of getting issue reports.
You are doing an amazing job at Apache ODE. It should be possible that your
work reaches the public very soon: New features and fixes should be
released soon and not be kept hidden for a long time.
I would propose the following:
1. Start using semantic versioning - https://semver.org/
2. Make sure that the each of the points you listed are marked as
openedissue
3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
with ODE 1.x (Jacob-JSON things)
4. Work on the JSON migration from java serialized jacob states to json
based
5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
1.3.x
Reasoning:
1. The 1.x line can still be maintained as rock-solid engine implementation
for business users
2. Starting from 3.x, ODE is a fast-moving project, which can include
contributions from external fast and also have the possibility to "release
early, release often"
I would also propose to have the "master" branch always release ready: All
tests are green.
WDYT?
Cheers,
Oliver
--
http://github.com/koppor/
Re: Extension activities
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi,
AFAIR there is no migration from java serialized jacob states to json based
jacob states implemented yet. It might be worth revisiting the state of the
jacob refactorings in terms of stability and portability.
Best,
Tammo
On Thu, Feb 1, 2018 at 6:45 PM, Sathwik B P <sa...@gmail.com> wrote:
> I dont have a timeline as of yet. The trunk has lot of changes. We need to
> release the new JACOB implementation. Revisit the clustering implementation
> based on hazelcast. We need to test migrations from 1.3.x versions from
> java serialization to json based serialization. We need to document these.
> All this is sitting on the trunk.
>
> I am looking into releasing 1.3.8 now, which has major library upgrades
> coming in.
>
> Its needs time and assistance.
>
> I have limited bandwidth.
>
> On Feb 1, 2018 22:37, "mhahn.dev" <mh...@gmail.com> wrote:
>
> Hi Sathwik,
> do you already have an idea when the changes might become part of an
> official release?
> Best regards,Michael
> -------- Ursprüngliche Nachricht --------Von: Sathwik B P <
> sathwik.bp@gmail.com> Datum: 30.01.18 11:28 (GMT+01:00) An:
> dev@ode.apache.org Betreff: Re: Extension activities
> Hi Michael,
>
> Thanks for your contribution. Your PR has been merged.
>
> regards,
> sathwik
>
>
> On Mon, Jan 29, 2018 at 9:04 PM, Michael Hahn <mh...@gmail.com> wrote:
>
> > Hi Sathwik,
> >
> > sure!
> >
> > I merged your commits into my fork and replaced the tabs with spaces
> > (hopefully) in all affected source files.
> > The PR should reflect the updates now.
> >
> > By the way, is there any source code formatting guideline/template for
> ODE
> > to avoid conflicts in future? :-)
> >
> > Best regards,
> > Michael
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > Gesendet: Montag, 29. Januar 2018 11:53
> > An: dev@ode.apache.org
> > Betreff: Re: Extension activities
> >
> > Hi Michael,
> >
> > Sorry for the delay.
> >
> > I had a brief look and it seems good to me.
> > The PR has a lot of tabs in the source, would it be possible to remove
> > them and resubmit the PR? I also have updgraded trunk to JAVA 8, there
> are
> > couple of commit for it from the point when your repo forked, can you
> take
> > it up in your repo and the new PR should be a smooth checkin.
> >
> > Would that be possible?
> >
> > regards,
> > sathwik
> >
> > On Wed, Jan 17, 2018 at 3:16 PM, Michael Hahn <mh...@gmail.com>
> wrote:
> >
> > > Hi Sathwik,
> > >
> > > sure, the forked repo is available at: https://github.com/hahnml/ode
> > >
> > > Best regards,
> > > Michael
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > Gesendet: Mittwoch, 17. Januar 2018 10:34
> > > An: dev@ode.apache.org
> > > Betreff: Re: Extension activities
> > >
> > > Hi Micheal,
> > >
> > > Thanks for the contribution.
> > >
> > > Will have a look at it when I get sometime. Can you share your forked
> > > repo link?
> > >
> > > regards,
> > > sathwik
> > >
> > > On Mon, Jan 15, 2018 at 6:20 PM, Michael Hahn <mh...@gmail.com>
> > wrote:
> > >
> > > > Hi Sathwik,
> > > >
> > > > as discussed I created a corresponding PR for porting the extension
> > > > activity support (https://github.com/apache/ode/pull/4).
> > > > In addition, I added an initial BPEL REST extension activity bundle
> > > > as an example together with related test cases in 'bpel-test'
> project.
> > > >
> > > > Looking forward to your feedback, let me know if something is
> > > > missing or has to be adapted :-)
> > > >
> > > > Best regards,
> > > > Michael
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > > Gesendet: Mittwoch, 29. November 2017 06:11
> > > > An: dev@ode.apache.org
> > > > Betreff: Re: Extension activities
> > > >
> > > > Micheal,
> > > > Am done with porting to trunk. You can start on your PR.
> > > >
> > > > On Nov 25, 2017 13:17, "Sathwik B P" <sa...@gmail.com> wrote:
> > > >
> > > > > MIchael,
> > > > >
> > > > > Just hold on to making changes for the trunk, am bringing the
> > > > > 1.3.8 commits from the release branch to the trunk. I should
> > > > > probably done in about 2-3 days. Major library upgrades are coming
> > in.
> > > > >
> > > > > Just to summarize the changes in the trunk JACOB has been moved
> > > > > into a different sub project
> > > > > [https://github.com/apache/ode-jacob], the new OModel is here
> > > > > https://github.com/apache/ode/tree/master/bpel-nobj
> > > .
> > > > >
> > > > > The compiler has undergone changes. I believe porting of extension
> > > > > activities onto this new model will not be straight forward as the
> > > > > extension feature was built on the older OModel.
> > > > >
> > > > > regards,
> > > > > sathwik
> > > > >
> > > > > On Fri, Nov 24, 2017 at 5:43 PM, Sathwik B P
> > > > > <sa...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> Micheal,
> > > > >>
> > > > >> I am working towards 1.3.8 release. We cannot bring the extension
> > > > >> activity feature on 1.3.x branch
> > > > >>
> > > > >> On Nov 24, 2017 15:46, "Michael Hahn" <mh...@gmail.com>
> wrote:
> > > > >>
> > > > >>> Hi Sathwik,
> > > > >>>
> > > > >>> thanks for the pointers.
> > > > >>>
> > > > >>> I've seen on GitHub that you are currently working on the
> > "ode-1.3.x"
> > > > >>> branch.
> > > > >>> Should I also do the porting based on that branch or better on
> > > > >>> the master?
> > > > >>>
> > > > >>> Regards,
> > > > >>> Michael
> > > > >>>
> > > > >>> -----Ursprüngliche Nachricht-----
> > > > >>> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > > >>> Gesendet: Donnerstag, 23. November 2017 14:52
> > > > >>> An: dev@ode.apache.org
> > > > >>> Betreff: Re: Extension activities
> > > > >>>
> > > > >>> Hi Hahn,
> > > > >>>
> > > > >>> Good to hear about your interest on porting Extension activities
> > > > >>> onto the trunk. It only exists in APACHE_ODE_2.X-experimental"
> > > branch.
> > > > >>>
> > > > >>> I suppose these should be the initial commits from Tammo,
> > > > >>> [ODE-159, ODE-160]
> > > > >>> https://github.com/apache/ode/commit/5ef69232cc6f19cf2818dd1
> > > > >>> b110416b959297126
> > > > >>> https://github.com/apache/ode/commit/1d5fa185a77c944e8d4a708
> > > > >>> b451611fa74d5c2dc
> > > > >>>
> > > > >>> You can just go up the commits if there are more.
> > > > >>>
> > > > >>>
> > > > >>> regards,
> > > > >>> sathwik
> > > > >>>
> > > > >>> On Thu, Nov 23, 2017 at 4:39 PM, Michael Hahn
> > > > >>> <mh...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>> > Hi,
> > > > >>> >
> > > > >>> > I'm actually very interested in the support of BPEL extension
> > > > >>> > activities in ODE and also willing to help to integrate/build
> > > > >>> > the feature :-) Some years ago I was able to successfully port
> > > > >>> > the extension activity support from the
> > > "APACHE_ODE_2.X-experimental"
> > > > >>> > branch into an ODE 1.3.4 release.
> > > > >>> >
> > > > >>> > So, if someone can give me a pointer where to find the most
> > > > >>> > recent version of the extension activity related classes, I
> > > > >>> > can integrate the feature into the current trunk and provide
> > > > >>> > the result as a pull request. Else I can also simply go with
> > > > >>> > the version in the "APACHE_ODE_2.X-experimental" branch as a
> > > > >>> > starting
> > > point.
> > > > >>> >
> > > > >>> > Regards,
> > > > >>> > Michael
> > > > >>> >
> > > > >>> > -----Ursprüngliche Nachricht-----
> > > > >>> > Von: Sathwik B P [mailto:sathwik@apache.org]
> > > > >>> > Gesendet: Mittwoch, 18. Oktober 2017 15:53
> > > > >>> > An: dev@ode.apache.org
> > > > >>> > Betreff: Re: Extension activities
> > > > >>> >
> > > > >>> > Hi Oliver,
> > > > >>> >
> > > > >>> > ODE 2.0 branch was an experimental branch and is not
> > > > >>> > maintained since a very long time. I will have to revisit it
> > > > >>> > myself, in case it involves changes to the ODE object model,
> > > > >>> > then we cannot bring it on any of 1.3.x releases because of
> > > > >>> > chances of breaking binary
> > > > >>> compatibilities.
> > > > >>> >
> > > > >>> > In order to make new features available, we moved towards JSON
> > > > >>> > based state serialization away from JAVA serialization in the
> > > > >>> > trunk which is in 1.4 release.
> > > > >>> >
> > > > >>> > Currently, we are seeking new committers, you might want to
> > > > >>> > discuss the feature that you are willing to contribute and
> > > > >>> > probably help us
> > > > >>> build it.
> > > > >>> >
> > > > >>> > regards,
> > > > >>> > sathwik
> > > > >>> >
> > > > >>> >
> > > > >>> > On Wed, Oct 18, 2017 at 4:22 PM, Oliver Kopp
> > > > >>> > <ko...@gmail.com>
> > > > >>> wrote:
> > > > >>> >
> > > > >>> > > Hi,
> > > > >>> > >
> > > > >>> > > In the context of our usage, we rely on BPEL extension
> > > > >>> > > activity support within ODE for enabling the invocation of
> > > > >>> > > REST APIs through a corresponding extension bundle. We
> > > > >>> > > therefore ported the extension activity support from the
> > > > >>> > > 2.0-alpha branch (already some years ago and therefore not
> > > > >>> > > up to date with "latest" version on GitHub) into the current
> > > > >>> > > 1.3.7 release build which works. The problem is that by
> > > > >>> > > changing the source code of the official ODE 1.3.7 release,
> > > > >>> > > we have to ship our extended version of ODE and take over
> > > > >>> > > responsibilities regarding licenses, etc. Therefore, it
> > > > >>> > > would be really nice if there will be an ODE 1.3.x release
> > > > >>> > > with integrated extension activity support, so that we can
> > > > >>> > > use/refer to ODE as it is and as a result treat it as a
> > > > >>> > > ready to use open source middleware such as
> > > > Tomcat, we just use within our ecosystem.
> > > > >>> > >
> > > > >>> > > Do you see any chance to release a corresponding
> > > > >>> > > distribution that contains extension activity support in the
> > near future?
> > > > >>> > >
> > > > >>> > > In return we are really interested in open sourcing our
> > > > >>> > > BPEL4REST extension bundle so that it can be shipped as a
> > > > >>> > > feature
> > > > with ODE!
> > > > >>> > > 👨🔧
> > > > >>> > >
> > > > >>> > > Cheers,
> > > > >>> > >
> > > > >>> > > Oliver
> > > > >>> > >
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
--
Tammo van Lessen - http://www.taval.de
Re: Extension activities
Posted by Sathwik B P <sa...@gmail.com>.
I dont have a timeline as of yet. The trunk has lot of changes. We need to
release the new JACOB implementation. Revisit the clustering implementation
based on hazelcast. We need to test migrations from 1.3.x versions from
java serialization to json based serialization. We need to document these.
All this is sitting on the trunk.
I am looking into releasing 1.3.8 now, which has major library upgrades
coming in.
Its needs time and assistance.
I have limited bandwidth.
On Feb 1, 2018 22:37, "mhahn.dev" <mh...@gmail.com> wrote:
Hi Sathwik,
do you already have an idea when the changes might become part of an
official release?
Best regards,Michael
-------- Ursprüngliche Nachricht --------Von: Sathwik B P <
sathwik.bp@gmail.com> Datum: 30.01.18 11:28 (GMT+01:00) An:
dev@ode.apache.org Betreff: Re: Extension activities
Hi Michael,
Thanks for your contribution. Your PR has been merged.
regards,
sathwik
On Mon, Jan 29, 2018 at 9:04 PM, Michael Hahn <mh...@gmail.com> wrote:
> Hi Sathwik,
>
> sure!
>
> I merged your commits into my fork and replaced the tabs with spaces
> (hopefully) in all affected source files.
> The PR should reflect the updates now.
>
> By the way, is there any source code formatting guideline/template for ODE
> to avoid conflicts in future? :-)
>
> Best regards,
> Michael
>
> -----Ursprüngliche Nachricht-----
> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> Gesendet: Montag, 29. Januar 2018 11:53
> An: dev@ode.apache.org
> Betreff: Re: Extension activities
>
> Hi Michael,
>
> Sorry for the delay.
>
> I had a brief look and it seems good to me.
> The PR has a lot of tabs in the source, would it be possible to remove
> them and resubmit the PR? I also have updgraded trunk to JAVA 8, there are
> couple of commit for it from the point when your repo forked, can you take
> it up in your repo and the new PR should be a smooth checkin.
>
> Would that be possible?
>
> regards,
> sathwik
>
> On Wed, Jan 17, 2018 at 3:16 PM, Michael Hahn <mh...@gmail.com> wrote:
>
> > Hi Sathwik,
> >
> > sure, the forked repo is available at: https://github.com/hahnml/ode
> >
> > Best regards,
> > Michael
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > Gesendet: Mittwoch, 17. Januar 2018 10:34
> > An: dev@ode.apache.org
> > Betreff: Re: Extension activities
> >
> > Hi Micheal,
> >
> > Thanks for the contribution.
> >
> > Will have a look at it when I get sometime. Can you share your forked
> > repo link?
> >
> > regards,
> > sathwik
> >
> > On Mon, Jan 15, 2018 at 6:20 PM, Michael Hahn <mh...@gmail.com>
> wrote:
> >
> > > Hi Sathwik,
> > >
> > > as discussed I created a corresponding PR for porting the extension
> > > activity support (https://github.com/apache/ode/pull/4).
> > > In addition, I added an initial BPEL REST extension activity bundle
> > > as an example together with related test cases in 'bpel-test' project.
> > >
> > > Looking forward to your feedback, let me know if something is
> > > missing or has to be adapted :-)
> > >
> > > Best regards,
> > > Michael
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > Gesendet: Mittwoch, 29. November 2017 06:11
> > > An: dev@ode.apache.org
> > > Betreff: Re: Extension activities
> > >
> > > Micheal,
> > > Am done with porting to trunk. You can start on your PR.
> > >
> > > On Nov 25, 2017 13:17, "Sathwik B P" <sa...@gmail.com> wrote:
> > >
> > > > MIchael,
> > > >
> > > > Just hold on to making changes for the trunk, am bringing the
> > > > 1.3.8 commits from the release branch to the trunk. I should
> > > > probably done in about 2-3 days. Major library upgrades are coming
> in.
> > > >
> > > > Just to summarize the changes in the trunk JACOB has been moved
> > > > into a different sub project
> > > > [https://github.com/apache/ode-jacob], the new OModel is here
> > > > https://github.com/apache/ode/tree/master/bpel-nobj
> > .
> > > >
> > > > The compiler has undergone changes. I believe porting of extension
> > > > activities onto this new model will not be straight forward as the
> > > > extension feature was built on the older OModel.
> > > >
> > > > regards,
> > > > sathwik
> > > >
> > > > On Fri, Nov 24, 2017 at 5:43 PM, Sathwik B P
> > > > <sa...@gmail.com>
> > > wrote:
> > > >
> > > >> Micheal,
> > > >>
> > > >> I am working towards 1.3.8 release. We cannot bring the extension
> > > >> activity feature on 1.3.x branch
> > > >>
> > > >> On Nov 24, 2017 15:46, "Michael Hahn" <mh...@gmail.com> wrote:
> > > >>
> > > >>> Hi Sathwik,
> > > >>>
> > > >>> thanks for the pointers.
> > > >>>
> > > >>> I've seen on GitHub that you are currently working on the
> "ode-1.3.x"
> > > >>> branch.
> > > >>> Should I also do the porting based on that branch or better on
> > > >>> the master?
> > > >>>
> > > >>> Regards,
> > > >>> Michael
> > > >>>
> > > >>> -----Ursprüngliche Nachricht-----
> > > >>> Von: Sathwik B P [mailto:sathwik.bp@gmail.com]
> > > >>> Gesendet: Donnerstag, 23. November 2017 14:52
> > > >>> An: dev@ode.apache.org
> > > >>> Betreff: Re: Extension activities
> > > >>>
> > > >>> Hi Hahn,
> > > >>>
> > > >>> Good to hear about your interest on porting Extension activities
> > > >>> onto the trunk. It only exists in APACHE_ODE_2.X-experimental"
> > branch.
> > > >>>
> > > >>> I suppose these should be the initial commits from Tammo,
> > > >>> [ODE-159, ODE-160]
> > > >>> https://github.com/apache/ode/commit/5ef69232cc6f19cf2818dd1
> > > >>> b110416b959297126
> > > >>> https://github.com/apache/ode/commit/1d5fa185a77c944e8d4a708
> > > >>> b451611fa74d5c2dc
> > > >>>
> > > >>> You can just go up the commits if there are more.
> > > >>>
> > > >>>
> > > >>> regards,
> > > >>> sathwik
> > > >>>
> > > >>> On Thu, Nov 23, 2017 at 4:39 PM, Michael Hahn
> > > >>> <mh...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>> > Hi,
> > > >>> >
> > > >>> > I'm actually very interested in the support of BPEL extension
> > > >>> > activities in ODE and also willing to help to integrate/build
> > > >>> > the feature :-) Some years ago I was able to successfully port
> > > >>> > the extension activity support from the
> > "APACHE_ODE_2.X-experimental"
> > > >>> > branch into an ODE 1.3.4 release.
> > > >>> >
> > > >>> > So, if someone can give me a pointer where to find the most
> > > >>> > recent version of the extension activity related classes, I
> > > >>> > can integrate the feature into the current trunk and provide
> > > >>> > the result as a pull request. Else I can also simply go with
> > > >>> > the version in the "APACHE_ODE_2.X-experimental" branch as a
> > > >>> > starting
> > point.
> > > >>> >
> > > >>> > Regards,
> > > >>> > Michael
> > > >>> >
> > > >>> > -----Ursprüngliche Nachricht-----
> > > >>> > Von: Sathwik B P [mailto:sathwik@apache.org]
> > > >>> > Gesendet: Mittwoch, 18. Oktober 2017 15:53
> > > >>> > An: dev@ode.apache.org
> > > >>> > Betreff: Re: Extension activities
> > > >>> >
> > > >>> > Hi Oliver,
> > > >>> >
> > > >>> > ODE 2.0 branch was an experimental branch and is not
> > > >>> > maintained since a very long time. I will have to revisit it
> > > >>> > myself, in case it involves changes to the ODE object model,
> > > >>> > then we cannot bring it on any of 1.3.x releases because of
> > > >>> > chances of breaking binary
> > > >>> compatibilities.
> > > >>> >
> > > >>> > In order to make new features available, we moved towards JSON
> > > >>> > based state serialization away from JAVA serialization in the
> > > >>> > trunk which is in 1.4 release.
> > > >>> >
> > > >>> > Currently, we are seeking new committers, you might want to
> > > >>> > discuss the feature that you are willing to contribute and
> > > >>> > probably help us
> > > >>> build it.
> > > >>> >
> > > >>> > regards,
> > > >>> > sathwik
> > > >>> >
> > > >>> >
> > > >>> > On Wed, Oct 18, 2017 at 4:22 PM, Oliver Kopp
> > > >>> > <ko...@gmail.com>
> > > >>> wrote:
> > > >>> >
> > > >>> > > Hi,
> > > >>> > >
> > > >>> > > In the context of our usage, we rely on BPEL extension
> > > >>> > > activity support within ODE for enabling the invocation of
> > > >>> > > REST APIs through a corresponding extension bundle. We
> > > >>> > > therefore ported the extension activity support from the
> > > >>> > > 2.0-alpha branch (already some years ago and therefore not
> > > >>> > > up to date with "latest" version on GitHub) into the current
> > > >>> > > 1.3.7 release build which works. The problem is that by
> > > >>> > > changing the source code of the official ODE 1.3.7 release,
> > > >>> > > we have to ship our extended version of ODE and take over
> > > >>> > > responsibilities regarding licenses, etc. Therefore, it
> > > >>> > > would be really nice if there will be an ODE 1.3.x release
> > > >>> > > with integrated extension activity support, so that we can
> > > >>> > > use/refer to ODE as it is and as a result treat it as a
> > > >>> > > ready to use open source middleware such as
> > > Tomcat, we just use within our ecosystem.
> > > >>> > >
> > > >>> > > Do you see any chance to release a corresponding
> > > >>> > > distribution that contains extension activity support in the
> near future?
> > > >>> > >
> > > >>> > > In return we are really interested in open sourcing our
> > > >>> > > BPEL4REST extension bundle so that it can be shipped as a
> > > >>> > > feature
> > > with ODE!
> > > >>> > > 👨🔧
> > > >>> > >
> > > >>> > > Cheers,
> > > >>> > >
> > > >>> > > Oliver
> > > >>> > >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>>
> > > >
> > >
> > >
> >
> >
>
>