Kie Scanner - Dynamic update FileSystem Monitor

[Ashish Soni]

Hi Drools Experts , 

Is there any example or way we can monitor FileSystem for new DRL file instead of Maven Repo for dynamic update on the Rules / DRL Files.

Thanks,

Ashish

[Ashish Soni]

Any suggestion as it is not always good practice to install maven in production environment for kiescanner , Is there any other way to monitor the JAR / DRL file .

Ashish

[Mark Proctor]

On 20 Jul 2015, at 15:46, Ashish Soni <ashish...@gmail.com> wrote:

Any suggestion as it is not always good practice to install maven in production environment for kiescanner ,

Why?

Is there any other way to monitor the JAR / DRL file .

No, we don’t see a need to develop something, that is duplicating something that Maven provides.

If we started doing this, we’d need to emulate maven version resolving, snapshot, latest, release. We’d need to emulate maven dependency resolving, then there is all the maven configuration, such as proxies and security and so on.

What we may do in the future is have a push based system, where instead of everything being  resolved on the client, we do all of this on the server and then push the changes to the client. So we’ll use Maven to prepare the push payload to the kieserver, probably with some UI to manage the push windows. Sounds like a great task for someone in the community to do :)

Mark

Ashish

On Friday, 17 July 2015 08:22:45 UTC-4, Ashish Soni wrote:

Hi Drools Experts , 

Is there any example or way we can monitor FileSystem for new DRL file instead of Maven Repo for dynamic update on the Rules / DRL Files.

Thanks,

Ashish

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/07809b19-18ca-45c8-8c23-12901cd0ebc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ashish Soni]

why  need to go through maven the simple requirement is can we just monitor a file system where it load the whole package or set of DRL file copied.
Maven comes with its own complexity and why we need to install maven on production system where the application is running.
Dynamic update can happen without the maven also.

[Mark Proctor]

On 20 Jul 2015, at 19:19, Ashish Soni <ashish...@gmail.com> wrote:

why  need to go through maven the simple requirement is can we just monitor a file system where it load the whole package or set of DRL file copied.

What are your versioning semantics for repeatable builders? What’s your governance for stable, snapshot and release? How do you have version range semantic governance for automatic updates? How do you handle  splitting knowledge across different builds and using dependencies (and transitive dependencies) to combine this, and have versioning semantics and governance work across those transitive dependencies. This is complex stuff to do right.

We’ve gone for a solution that addresses the widest set of requirements we have had over the years, and provides it in a commonly understood way.

We did what you proposed in 5x, and it just ended in endless questions and complaints from people who wanted something with enterprise semantics. Our main aim for now was to have a single solution, that addressed the widest set of requirements, which embedded Maven provides. We do plan to progress beyond this, which I’ll come back to in a moment.

For now if you look through the api examples it shows how to do a lot of stuff manually, like loading jars from disk and updating versions - all without maven. It wouldn’t take much for you to disk scan for new jars, load it into the repository and call updateToVersion - as long as you don’t use SNAPSHOT, RELEASE or LATEST in your versioning semantics. And of course don’t want dependency resolving. 

We’ve avoided providing this, because stunted solutions without enough thought and planning end up growing beyond original expectation and require support and maintenance, and before you know it you are back with the 5x knowledge-agent. So I want to make sure anything we do grows out and compliments what we have already.

At the moment kie-ci uses maven to both resolve dependencies and updates and then apply them. In the future we might look at ways of splitting this, especially as I want to move to a more “pushed” based deployment, which would not require maven or anything else installed on the client side. Any resolving or governance is determined else where and the results pushed to the kie-ci server to apply. In our case this would be some maven based service that would result in the push, but you could do your own simple disk scanner and your own push.

Maven comes with its own complexity and why we need to install maven on production system where the application is running.

This is a myth i’ve heard repeated “you shouldn’t put maven on a production box”. There is no reason for this, it’s a massively tested piece of software with high levels of reliability. Nothing is installed, as it uses embedded maven and aether, which is just another project library jar on your class path. The only issues are that it doesn’t play nicely in an OSGi environment, due to plexus, although we’ve managed to work around this. The complexity is hidden from the user, so this again is a non issue.

Dynamic update can happen without the maven also.

They can, and you can see this from the api examples, that demonstrate how to do this manually. But as per above, when you automate this, at an enterprise level it may require everything I listed in my first paragraph. For now we prefer people to roll their own - rather than lock us into a stunted solution.

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/b50beae3-d8a2-42d7-b311-d83e3f141eff%40googlegroups.com.