The polling is now separate, all it does is call "mvn install" at regular intervals. It is possible to implement an alternative one that calls "mvn install" on remote request, although we haven't implemented that yet, but someone could do it by following the Scanner class and just hooking it up with JMS push.
We will probably add that for 6.1, but while the pushing feature and api is trivial, it would take time to building the tooling. Mark On 2 Aug 2013, at 22:30, Justin Holmes <justinmichaelhol...@gmail.com> wrote: > Hello Devs, > > I'm currently working on a project that employs Drools/jBPM 5.x. We author > knowledge assets in Guvnor and then use a KnowledgeAgent to pull down > compiled kpackages. This is an enterprise project, so we have about 6 > different environments that the kpackages need to be promoted to over time. > However, we've had issues with promoting assets via the polling/pull model > that is implemented in the KnowledgeAgent, as sometimes packages will be > pulled accidentally due to user error. I know the 6.x project moves to > KieContainer/KieServices using Maven, but my reading of the code suggests > that this is still a polling model against the Guvnor Repository. To me, it > seems that polling does not provide sufficient governance of the execution > environment, and that one would need to "push" a specific version of an KBase > into a specific environment, without a redeployment, to achieve the proper > level of control. > > So here is my line of questioning... > > 1) Am I correct that there is no feature in the project today that allows an > end user to "push" a KPackage into an environment? > 2) If the feature doesn't exist, would the team be interested in adding it > the project? I'm imagining that the feature would need to include both a > Guvnor server side component as well as client side component which exposes > some sort of service endpoint. > 3) If its a feature you guys are interested in, how can we begin the > conversation to build it? > > > - Justin > > > > > > > > > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
