aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: svn commit: r926162 [1/2] - in /incubator/aries/trunk: application/application-api/ application/application-bundle/ application/application-converters/ application/application-converters/src/main/resources/OSGI-INF/blueprint/ application/applicat
Date Tue, 23 Mar 2010 15:10:38 GMT

I'm learning a little more as I try to get the samples working again. 
See comments in-line below.

Joe Bohn wrote:
> Guillaume Nodet wrote:
>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <> wrote:
>>> Guilluame,
>>> It seems that there is at least one issue with this change that I've
>>> noticed in our sample assemblies regarding the jndi bundle (see the 
>>> error
>>> below).  I'm not sure if there are any more but I suspect that there 
>>> are.
>>>  Perhaps we need to find some mechanism to verify that the generated 
>>> bundles
>>> are consistent after a global change such as this.
>> Ideally, integration tests should catch those errors I'd say.  I don't
>> really see a better mechanism.
> Perhaps just running the samples would help - that's how I discovered 
> this and some other issues.  I wonder if we can automate some of this to 
> make it easier to discover potential issues?
> Also, can you help me understand the current state of the change 
> (particularly regarding the samples)?  It seems that you were setting 
> the properties and removing the maven-bundle-plugin configuration in 
> many cases.  However, at least in the samples, I noticed that you did 
> not remove the bundle-plugin configuration or add the properties. 
> Unfortunately, the presence of the maven-bundle-plugin and particular 
> configuration changes in the parent pom produces changes in the 
> generated manifests of the samples - with the result being that they are 
> now very broken.  Are you planning to continue updating the samples to 
> get them working again?

I'm having success fixing some of the sample bundles - so I imagine I'll 
go ahead and check in those changes even if we plan to remove the 
maven-bundle-plugin configuration in the individual samples - at least 
it improves things for now.

> One other issue that I noticed after this change is the behavior when 
> installing EBA applications.  When installing an EBA into an Equinox 
> assembly the individual bundles are no longer started.  I see that there 
> were several application updates included in this change that may not be 
> related to the bundle plugin manifest generation.  Were these changes 
> intentionally included and is the behavior that I'm seeing the expected 
> result?

This seems to have been just a result of the errors in the bundles which 
prevented some from being resolved.  Apparently, if all of the bundles 
in an EBA are not resolved, none of them will start - and that seems to 
be what is happening in this case.   Once I fixed the bundles so that 
they could be resolved then all of the bundles are started when the EBA 
is installed.

> Thanks,
> Joe
>>> In the case of jndi, it seems that we are ending up with a manifest 
>>> for the
>>> jndi bundle that now includes an import-package for
>>> '' that did not exist prior to the change.
>>>  This is really strange because it seems that the intention of the 
>>> original
>>> configuration was preserved with the change (with the
>>> '' specified in the export-package - 
>>> perhaps
>>> the omission of the import-package * is somehow related? - but 
>>> changing that
>>> didn't seem to help).  However that import-package was not included 
>>> in the
>>> generated manifest prior to this change.  In my case, simply removing 
>>> this
>>> package from the export package in the pom resulted in it being 
>>> removed from
>>> the import in the generated bundle manifest and resolved the issue when
>>> starting the jndi bundle.  That got me to some more error on the sample
>>> bundles that I think are also related to this change.
>>> I also think it would be helpful to provide some more information on
>>> structure of the properties for this function that should be used in 
>>> various
>>> scenarios - either on the dev list, in the JIRA, or on the wiki.   It 
>>> seems
>>> that some of the properties are very similar in name and function but 
>>> are
>>> apparently fulfilling different purposes such as 'aries.osgi.import' vs.
>>> 'aries.osgi.import.pkg' and 'aries.osgi.export' vs. 
>>> 'aries.osgi.export.pkg'.
>>> Yeah, i'll take some time to do that.  I may start by putting some 
>>> doc on
>> the parent pom itself.
>>> For reference here is the current error when attempting to start the 
>>> jndi
>>> bundle.  You can see the same error starting either the Blog or 
>>> AriesTrader
>>> sample equinox assemblies.
>>> org.osgi.framework.BundleException: The bundle could not be resolved.
>>> Reason: Missing Constraint: Import-Package: 
>>> version="0.0.0"
>>>        at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(

>>>        at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(

>>>        at
>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(

>>> etc...
>> I'll try to fix that one asap.
>>> -- 
>>> Joe
>>> wrote:
>>>> Author: gnodet
>>>> Date: Mon Mar 22 16:28:46 2010
>>>> New Revision: 926162
>>>> URL:
>>>> Log:
>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>> generation instead of configuring the plugin in each pom
>>>>  <snip/>


View raw message