Kie-Workbench build triggers

[Esteban Aliverti]

Hi guys,

I don't know if this is the best place for these questions or not. If not, please let me know where should I post this.

I'm working on some customizations of kie-workbench (mainly focused on jbpm-designer module) and I have some questions about the kie-workbench behavior. It would be nice if somebody from the kie-workbench team could shade some light here.

I'm currently using version 6.2.1-SNAPSHOT of kie-workbench.

My first problem is related to what happens when you save a process in the jbpm-designer (and possibly other type of assets, but I'm not sure). The behavior I see is that every time you save a process (a new one or modifications over an existing one), a build of the package is triggered. The logs show that this should be an incremental build, but the reality is that it takes a lot of time. My questions here are: 

- Is this build required? What's its purpose?

- Can I turn this "feature" off? I would like to only build my package when I go to the Project Editor screen and click 'Build and Deploy'

My second issue, may be related to the first one. One of the modifications I did in the workbench is that every time a process is saved, I create a couple of DRL assets on the fly and store them into the same project where the process is. The code I use to create the DRL assets is something like this:

    

                 AssetBuilder builder = AssetBuilderFactory.getAssetBuilder(Asset.AssetType.Text);

        builder.content(myDRL)

                .uniqueId(PathFactory.newPath(name, processURI).toURI())

                .type("drl")

                .name(name)

                .location(location);

        this.profile.getRepository().createAsset(builder.getAsset()); //where profile.getRepository() returns an instance of org.jbpm.designer.repository.vfs.VFSRepository

The problem with this approach is that for every single asset I persist, a new build of the package is triggered. I would really like to have a way to avoid this. This is not only increasing the saving time of a process, but it is also causing some exceptions in the backend such as: ERROR [org.jboss.as.ejb3.invocation] (EJB default - 4) JBAS014134: EJB Invocation failed on component IncrementalBuilderExecutorManager for method public void org.guvnor.common.services.builder.IncrementalBuilderExecutorManager.execute(org.guvnor.common.services.builder.AsyncIncrementalBuilder): javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation@101ecf7d - could not obtain lock within 5000MILLISECONDS

The third problem is related to the dependencies of a project. Now that we are using maven (which, by the way, I think is a great improvement over the way Guvnor managed dependencies in the past), things can get messy very very fast, specially if you are planning to integrate the kie-workbench with an instance of kie-server. According to what I experienced, all the dependencies (and transitive dependencies) of the project are analyzed to extract the class information required by the kie-workbech. This information is then used in places such as the Guided Editor to provide assistance to the user while authoring a rule. There are 2 issues with this approach:

1.- You may be using some dependencies in your model that you don't want to be displayed into kie-workbench. 

2.- If you are planning to integrate your application with kie-server, then you also need to include the required dependencies to make your rules work. These depedencencies may include things like jbdc drivers, apache commons libraries, etc. For sure, you don't want these dependencies to be scanned by the kie-workbench to get any information that will then be used in the editors.

The mentioned issues, in my case, are causing the following inconveniences:

1.- Opening a rule in the kie-workbench take ages.

2.- Tons of exceptions such as the following flood the server's log:  [org.kie.workbench.common.services.backend.builder.Builder] (default task-65) Verification of class ca.uhn.fhir.narrative.ThymeleafResolver failed and will not be available for authoring.

Is there anything I can do to mitigate this? 

A good solution in the long run could be to add support to maven profiles in the kie-workbench. Maybe having different profiles, for example, design, runtime, etc. could be used by the workbench and kie-server to understand what dependencies are required for the different phases of rule authoring/execution.

Thoughts?   

Regards,

[Michael Anstis]

Hi,

I am on vacation at the moment but will give a quick summary to your questions:-

An incremental build is automatically triggered whenever a file in a project is saved. If a file affects the potential available types available for authoring a full build is triggered (e.g. pom.xml or DRL files - due to the potential for declarative types). This is essential (at the moment) as the underlying KIE Scanner incremental build does not support incremental changes to available class definitions.

Incremental builds can be disabled - there is a flag - see the application bootstrap classes in kie-(drools)-wb (I forget their name).

The build sub-system in the workbench is up for review; a number of critical issues have been identified - however I do not see a way to prevent full builds whenever the list of potential available classes changes unless KIE Scanner is also modified - this decision would be with Mark and/or Mario (however we've been looking into incremental Maven compilations too).

Hopefully my colleagues can fill some gaps until I return and get access to my laptop...

Cheers,

Mike

--
You received this message because you are subscribed to the Google Groups "Drools Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-developm...@googlegroups.com.
To post to this group, send email to drools-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-development/67fbc8fa-39a0-4916-9ad3-6808eaa21b91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Esteban Aliverti]

Thanks Mantis for your explanation.

I'll definitely look for the way to disable the incremental build. At least now I understand why it is required. I think that what I'm going to do is to disable it, create and persist all the necessary .drl assets and then enable it again. 

Regards,  

To unsubscribe from this group and stop receiving emails from it, send an email to drools-development+unsub...@googlegroups.com.