On Fri, Feb 1, 2019 at 9:59 AM sebb <seb...@gmail.com> wrote: > > On Fri, 1 Feb 2019 at 14:12, Woonsan Ko <woon...@apache.org> wrote: > > > > On Fri, Feb 1, 2019 at 5:02 AM Christofer Dutz > > <christofer.d...@c-ware.de> wrote: > > > > > > Hi, > > > > > > I would opt for setting up Jenkins to auto deploy snapshots to the Apache > > > repo. Done that for quite a lot of projects, so happy to help out. > > > > Please help and direct us! :-) > > I once tried it but got in stuck before: > > - https://issues.apache.org/jira/browse/SCXML-236 > > Just completed.
Thank you so much! Now javadocs were fixed and it was deployed onto snapshot repo: - https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-scxml2/2.0-SNAPSHOT/ Cheers, Woonsan > > > - https://issues.apache.org/jira/browse/INFRA-10366 > > > > > > > > Cutting a release would be required for us to use it in our drivers (or > > > we can't Release them). I will definitely not use an "unofficial release" > > > in an Apache project. So a formal one would be required. But I'm happy to > > > help get it there. However I would need to know what's still missing. > > > > Me, too! > > > > @Ate, could you chime in here to give insights on the current status > > and what we can do together to be able to cut a release (soon)? > > > > Cheers, > > > > Woonsan > > > > > > > > Chris > > > > > > > > > > > > Outlook für Android<https://aka.ms/ghei36> herunterladen > > > > > > ________________________________ > > > From: Woonsan Ko <woon...@apache.org> > > > Sent: Friday, February 1, 2019 9:09:53 AM > > > To: Commons Developers List > > > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify > > > (industrial) protocols? > > > > > > On Thu, Jan 31, 2019 at 11:21 AM Christofer Dutz > > > <christofer.d...@c-ware.de> wrote: > > > > > > > > Hi all, > > > > > > > > So I just finished a first operational scxml based state machine, that > > > > connects to a remote host and exchanges messages described by dfdl by > > > > serializing xml templates which I define inside my CustomAction > > > > elements of my scxml document. > > > > > > > > And the coolest thing is, that the remote Siemens PLC answered > > > > correctly :-) > > > > > > > > Still needs a lot of work. Especially we would need at least working > > > > snapshots of commons-scxml (the ones on repo.apachr.org are hugely out > > > > of sync) ... You need help with that? Had to tweak some minor things to > > > > build locally, but should be easy to fix. > > > > > > If it helps, we (Ate and I) have deployed M1 tag to our maven repo and > > > used it for years already in our products: > > > - > > > http://maven.onehippo.com/maven2/org/apache/commons/commons-scxml2/2.0-M1/ > > > > > > If we can deploy it or a snapshot to an ASF repo, it will help the > > > community. Should we decide to cut a release or just deploy to a > > > snapshot repo? > > > > > > > > > > > Would be cool, if someone could review what I'm doing (haven't > > > > committed it yet as it would break the build due to outdated snapshots) > > > > ... Don't wanna walk into the wrong direction and if we work together, > > > > I bet this could be for the benefit of Plc4x and commons-scxml :-) > > > > > > Cool. Give us a link. > > > From my experiences, it seems better not to depend on too many > > > expressions or scripts. Keeping it to the most normal standard > > > elements, with some custom actions to be used still in a declarative > > > way, seems simpler and more maintainable to me. > > > > > > Regards, > > > > > > Woonsan > > > > > > > > > > > Chris > > > > > > > > > > > > Outlook für Android<https://aka.ms/ghei36> herunterladen > > > > > > > > ________________________________ > > > > From: Woonsan Ko <woon...@apache.org> > > > > Sent: Tuesday, January 29, 2019 4:49:16 PM > > > > To: Commons Developers List > > > > Subject: Re: [SCXML] Using SCXML + Daffodil in order to fully specify > > > > (industrial) protocols? > > > > > > > > Hi Chris, > > > > > > > > On Tue, Jan 29, 2019 at 8:26 AM Christofer Dutz > > > > <christofer.d...@c-ware.de> wrote: > > > > > > > > > > Hi all, > > > > > > > > > > I am a member of the Apache PLC4X podling. There we are implementing > > > > > drivers for communicating with industrial hardware. > > > > > Now we had started with manually implemented Java drivers, but it has > > > > > always been our goal to ship drivers in multiple languages. > > > > > > > > > > As we are currently starting work on the C++ versions, it was time to > > > > > work on some way to universally define these protocols > > > > > and have the drivers in each supported language generated. > > > > > > > > > > As a first step I wrote DFDL schemas and tests using Apache Daffodil > > > > > and this worked perfectly for defining the format of the > > > > > messages being exchanged. Now I still had to model the protocol > > > > > itself: Which message with what content is sent at which time? > > > > > How does the information provided by users get in requests and out > > > > > of responses? > > > > > So I was looking for some way to specify a State machine in XML … I > > > > > stumbled over SCXML > > > > > And can you imagine my surprise when I noticed Apache has something > > > > > for this in its toolbox? > > > > > > > > > > Right now I’m working on writing such a SCXML schema mixing together > > > > > SCXML + DFDL + Custom extensions to achieve the > > > > > goal of fully specifying these protocols. So far it’s looking good, > > > > > but I would like to ask, if someone here (ideally with SCXML > > > > > experience) > > > > > would be interested in joining us and working on this. > > > > > > > > Sounds cool! I'm not familiar with DFDL, but I'd like to help with > > > > some of my experiences with SCXML and our current Commons SCXML > > > > implementations. > > > > > > > > > > > > > > I know that the activity on the SCXML project seems to have been … > > > > > well minimal. But still I think it’s a good option. > > > > > > > > > > Any opinions, suggestions, things I should consider? > > > > > > > > One issue with the SCXML subproject is that it has been refactored a > > > > lot since v2, but it has never been released for years. So, people > > > > seem to feel hard to try it. > > > > Another is that Ate and I have used it mostly for a specific use > > > > case--document publication workflow in CMS--with M1 [1]; it kind of > > > > lacks of diversity. In that sense, new faces from diverse backgrounds > > > > will be more than welcome and more beneficial to the community. > > > > > > > > Perhaps you can test some PoC or its scenarios in conceptual level > > > > with M1 tag to see if everything is okay. > > > > > > > > Another thing is that we should consider releasing it often (again > > > > like 0.x's). Perhaps just because we bumped the version to 2.0.0 > > > > thanks to the expected whole refactoring, we might just have been > > > > hesitant to cut a release of v2.x.x while we're not ready yet to > > > > fulfill all the requirements of SCXML specification. > > > > > > > > Regards, > > > > > > > > Woonsan > > > > > > > > [1] http://commons.apache.org/proper/commons-scxml/roadmap.html > > > > > > > > > > > > > > Chris > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
