External modules

[objectiser]

Curently switchyard builds the AS7 modules that it requires for external libs. For the Overlord BAM project, I would ideally like to install drools, mvel, etc in situations where switchyard is not present.

The problem - when both switchyard and bam need to be installed, how do we handle potential conflicts, either in version or content of these modules? Ideally we need to make sure that both switchyard and bam work regardless of installation order.

Where the modules relate to other jboss.org projects (e.g. drools and jbpm), it would be useful if those projects provided an artifact containing the module for their jars - possibly this is something we could raise with the relevant teams.

However that would not deal with the case of non jboss.org projects.

Therefore wanted to suggest possibly decoupling the external modules from the switchyard build, and having them as reusable artifacts. This would remove the duplication of creating the module content, and thus avoiding conflicting module requirements, leaving only the version issue - which could potentially be dealt with using a bom. So when the bom is updated, a new set of module artifacts are built for both internal (jboss.org) and external projects - and then any dependent projects can update their bom version to pull in both the dependency versions and access the relevant subset of modules.

This is not really a switchyard issue, but an integration platform wide issue. But thought if we can identify a solution, then it can be proposed for the wider platform if appropriate.

Thoughts?

Regards

Gary

[rcernich]

Hey Gary,

Whatever we do should probably use the new "layers" as described here:  https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization

I suspect this could make things easier moving forward.  It would be nice if drools, etc. provided their own layer, which we could add as a dependency, thus providing a layer on top of a layer (I'm really resisting an onion analogy;)).

Best,

Rob

[objectiser]

Hi Rob

Thanks for the link. This may provide an answer - but still looks like work in progress.

Can we provide an interim solution that creates groups of modules which would be equivalent to these layers, and then have install checks to see whether a 'layer' is already installed, to ensure only additional modules are installed?

If the preference is to wait for this work to be completed, then I can just take a copy of the relevant modules from switchyard, and we just need to make sure they stay in step?

Regards

Gary

[kcbabo]

I don't believe there are modularized (in the AS7/JBoss Modules sense) versions of the projects we depend on.  If and when these become available, I'd certainly be happy to pull that in vs. introducing our own module definitions and packaging for dependencies.  As of now, all external dependencies are defined separately within our release build (jboss-as7/modules/src/main/resources/external) and the versions of those are included within our BOM (parent/pom.xml).  If you want to include the same versions in a standalone build, then you could import our parent pom in a <dependencyManagement> definition of your pom.xml.

If the goal is to have a completely separate repository or maven module that could build external dependencies, that's not something we've considered so far.  I suppose it's possible by splitting internal/external modules at the maven level within our release build.  Not sure how much more useful that would be for other projects though.

[objectiser]

Keith Babo wrote:

If the goal is to have a completely separate repository or maven module that could build external dependencies, that's not something we've considered so far.  I suppose it's possible by splitting internal/external modules at the maven level within our release build.  Not sure how much more useful that would be for other projects though.

Not sure - for BAM it would be possible to use the switchyard parent pom and external module artifact, but not sure whether other projects in the integration platform would want to. It also makes it difficult for other projects to include their additional dependencies/modules that are not relevant to switchyard.

[kcbabo]

Let's take a step back and look at the requirements just for Overlord BAM.  We've discussed a few things in this thread - could you confirm which of these are important from a BAM standpoint:

1) Using the same versions of external modules that SY uses.

2) Pulling in pre-built external modules from the SY project so that the exact same modules can be used.

3) Reusing the assembly configuration for external modules with the ability to change versions of the dependencies used in the modules.

[objectiser]

Even just for Overlord BAM, there are two possible views:

a) BAM closely aligned to Switchyard - which is fine for the SOA platform. The main focus here is to remain aligned with the versions and module contents used by switchyard. However it means that if BAM needs additional external modules, it would need to manage them separately.

So (1) and (2) are important here.

The disadvantage of this approach is that if Overlord BAM is installed without switchyard, it still needs to install of the external modules associated with switchyard.

b) BAM independent of Switchyard, but where it may be installed in the same environment

In this case, the modules would need to be independently managed, rather than as a group, so that each project could just pull in the ones they need.

So option (a) could be a reasonable short term solution, but (b) is obviously the ideal.

[kcbabo]

Well, #2 could address (a) and (b) if the modules were published as maven artifacts.

[objectiser]

If they were published as separate module artifacts - I assumed by #2 you were referring to the current single artifact containing all external modules?

[kcbabo]

Yes, separate artifacts.

[objectiser]

That would work then.

Whether or not this would need to be expanded and made as a more independent effort at some point, would depend on how many other integration platform projects have overlapping external module requirements.

Should I raise a jira for this? Is it something that could be done soon?

[kcbabo]

Hey!  I didn't say I was gonna do it.  Just saying it would work. :-)

We might have to do something similar to this for Camel extension components, so can probably solve several problems here.  I have it on my list as a discussion topic for the F2F.  This is not going to be completed in the next week, but it's possible it could make it in for 0.8.

[objectiser]

Thanks, that should be fine.