Add OSGi bundle manifests for all SwitchYard modules

[codeprince]

The feature comes from https://issues.jboss.org/browse/SWITCHYARD-340 .

My suggestion:

1 creating a new directory or module called switchyard-osgi

2 liking weld-osgi, we can only write a pom file for switchyard-osgi, the critical parts are as following:

1) exporting contents

2) Import-Package

3) Private-Package

4) dependencies (apart from switchyard all modules, maybe having some dependencies of switchyard modules)

I wish this can be done as quickly as possible.

Because I want to see whether having some possibility of integrating switchyard into glassfish v4.

Thanks

--Tang

[rcernich]

Hey Tang,

I wish this can be done as quickly as possible.

Patches are always welcome.

Best,

Rob

[codeprince]

Rob Cernich による書き込み:

Hey Tang,

I wish this can be done as quickly as possible.

Patches are always welcome.

Best,

Rob

Hi Rob,

I can understand the point because I am eager to finish the patch. However, there are some objective factors hindering more quick implementing it.

1. having not enough understanding for all modules

2. maybe having more suitable people,

In reality, meeting 1 and 2 only needs,

1) truely understanding all modules

2) having good experience of maven and plugins

Thanks

--Tang

[kcbabo]

It's a bit more complicated than including the OSGi bundle plugin and generating manifests for modules.  First, dependencies for AS 7 modules are at the module level, not the package level.  So there could be some teasing apart of package dependencies or a whole lot of require-bundle definitions.  Second, integration with the OSGi service registry and implementing a deployment life cycle via something like the OSGi Extender pattern.  These issues can and will be addressed as we want to be OSGi friendly, but they are not going to be fixed immediately unless someone in the community steps up to get it done.

[codeprince]

Babo,

Thanks your reply.

>First, dependencies for AS 7 modules are at the module level, not the package level.

If being such a case, I think that in the future, switchyard should consider doing some decoupling from AS 7 moudles, otherwise,

while integrating with other application server, this maybe will cause some unexpected results. A fact is that the reason that

weld is integrated into glassfish well is that it does not depend on some concreate application server's module. So, I think that in the future,

if can decoupling from AS 7 moudles by designing some switchyard spi liking weld-spi, these  spi can be leaved into
integration module of appserver vendors.

>Second, integration with the OSGi service registry and implementing a deployment life cycle via something like the OSGi Extender pattern.

The former needs to be considered especially in creating activator. However, latter(deployment integration) maybe should be leaved into integration module of appserver vendors.

The above are some unmatured ideas.

>but they are not going to be fixed immediately unless someone in the community steps up to get it done.

I agree with you.

Thanks

--Tang

[kcbabo]

The two considerations with SY and a given runtime are:

1) Dependency resolution

2) Deployment processing

The core and component layers in SwitchYard do not depend on any specific runtime (JBoss Modules, OSGi, AS 7, etc., etc.).  The only place we have a dependency on AS 7 is in our release repository where we assemble the core/components/quickstarts bits of SwitchYard and integrate into a target runtime.  OSGi integration would occur by creating OSGi module definitions for each SY module in core and components and then implementing the other pieces I mentioned above inside a distinct module in our release repository (alongside other runtimes like AS 7).

It's worth noting that SY runs in plain old Java SE right now inside unit tests or with our standalone bootstrap class.  With both options, there are assumptions about the deployment architecture (one application) and how dependencies are resolved (e.g. maven class path resolution via dependencies).

[codeprince]

Babo

I will spend three-five days to do some research based on your above reply, then see that if other runtimes(eg.glassfish) plan to integrate it, what will happen.

Thanks

--Tang

[kcbabo]

Sweet.  Give us a shout if you run into trouble.

[splatch]

With very few changes in package names everything works well. There is no problems with making SwitchYard modules OSGi friendly. The biggest problem is AS7 service layer which uses resources located in META-INF/services. I've spent some time on this topic. You may find changes in core here:

https://github.com/splatch/switchyard-core/tree/osgi

https://github.com/splatch/switchyard-components/tree/osgi

https://github.com/splatch/switchyard-release/tree/osgi/karaf

I used Apache Karaf as runtime - since, as Keith pointed, there is no direct dependencies from SwitchYard core and components to AS7 runtime it worked well. I just haven't got time to complete service discovery with Aries SPY-FLY.

[codeprince]

Thanks Lukasz, from your github, I found that you have made many work related packaging OSGi modules.