This project should supply a single features artifact for Karaf

[chirino]

Merge the following two modules:
./drools-osgi/drools-karaf-features
./switchyard/release/karaf/features

[cmoulliard]

Why the drools-jbpm features xml file has been removed from the master branch (https://github.com/jboss-integration/fuse-bxms-integ/blob/6.2.x/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml) ?

[dvirgiln]

Initially, as far as I see, the kie/drools features were defined as well in the drools package:

https://repository.jboss.org/nexus/content/repositories/m2-proxy/org/drools/drools-karaf-features/6.2.0.Final/drools-karaf-features-6.2.0.Final-features.xml

In fuse-bxms it is added this repository. We are using 6.2.0.Final kie dependencies.
Normally what can be done in the future is, add in fuse-bxms features the ones related the drools project added here, like camel-kie, drools-decision-table-kie-spring-camel-example", drools-decision-kie-blueprint-camel-example,
and also remove them from the drools kie features.
But for that we need a new release of kie.

[cmoulliard]

Be careful ! The drools/jbpm project don't manage anymore the drools/jbpm karaf features that I have created initially. This is why the code has been imported into fuse-bxms-integration. That means that this project should continue to generate the features xml file of what is specific for switchyard BUT also drools + jbpm + kie features too.

Remark : I will check with drools/jbpm team why 6.2.Final features file has been released as it seems that this is a mistake.

[chirino]

I don't think we want to take on maintaining drools/jbpm in this project. We have a problem if the drools team is does not want to maintain their Karaf integration.

[cmoulliard]

But drools/jbpm team is not longer interested to maintain karaf integration ...

[chirino]

Then the BxMS team at RedHat needs to do it. And if they can't, then RedHat can't say we support BxMS on Karaf. The best the Fuse team can do is assist them and support the glue code between their software and Camel/SY.

[mdproctor]

After our discussions on irc, it has been decided that -integ should retain a strict separation of code and only include bits that are specifically for integration of the two platforms, and not include anything that is a common or core library to that platform.

1. split bundles so only kie-camel bundle is in -integ pack (mario)
2. ask QE to work with us on improving test coverage (petr)
3. will be two community distributions for OSGi. the kie one and the -integ one. (mfusco)
4. need to keep an eye on disconnected updates - i.e. when -integ is updated, and kie isn't and vice versa. there may be longer delays before issues are found.

[fusesource-ci]

+1

On Apr 29, 2015, at 11:10 AM, mdproctor [email protected] wrote:

After our discussions on irc, it has been decided that -integ should retain a strict separation of code and only include bits that are specifically for integration of the two platforms, and not include anything that is a common or core library to that platform.

1. split bundles so only kie-camel bundle is in -integ pack (mario)
2. ask QE to work with us on improving test coverage (petr)
3. will be two community distributions for OSGi. the kie one and the -integ one. (mfusco)
4. need to keep an eye on disconnected updates - i.e. when -integ is updated, and kie isn't and vice versa. there may be longer delays before issues are found.

We should consider how many branches to maintain and where. i.e. It’s probably ok for -integ master to track BxMS master SNAPSHOTs. But we might want to also have a -integ branch that tracks the latest community releases.

and https://github.com/jboss-fuse/fuse-integration https://github.com/jboss-fuse/fuse-integration will hold the private repos which track the latest productized versions.

—
Reply to this email directly or view it on GitHub #9 (comment).