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 18:40:33 GMT
Joe Bohn wrote:
> There are definitely still issues.   I fixed AriesTrader but there are 
> still issues with Blog and I'm not sure about the other samples/tutorials.
> I'd still like to understand if you are planning to continue your 
> changes by removing the individual maven-bundle-plugin configuration 
> from the poms in samples and a few other areas.  From what I can see 
> these projects still include the maven-bundle-plugin configuration:
> - eba-maven-plugin
> - jpa
> - samples
> - tutorials
> I'm not sure exactly what the problems are with the Blog sample. It may 
> be related some poor package names and I suspect it will require 
> restructuring some of them.  For example, several of the bundles include 
> export package of "!org.apache.aries.samples.*".  However, to get the 
> maven-bundle-plugin to generate the correct output we now need to add 
> Private-Package entries for these packages.  This broad package name 
> covers much more than it should given that all of the packages start 
> with "org.apache.aries.samples".  I suspect the real fix is to rework 
> the package names so that the packages can be more specific in these 
> configuration parameters to the maven-bundle-plugin.   Zoe, can you take 
> a look at blog?


I have a version of Blog that works again.   I can check it in if you'd 
like me to.  I made the following changes:
- Added some missing Private-Packages to get bundles to deploy correctly
- Added "biz" to the package name for items in blog-biz
- Renamed these api packages (and all references):
   - "" => 
   - "" => 

I don't think that we want the ".api" at the end of the packages - it's 
redundant - but the way that I did the move in svn prevents me from 
doing the second move necessary to remove the final api - so I would 
need to check in this way and then we can move them again and drop the 
trailing ".api".


> Joe
> Guillaume Nodet wrote:
>> I've fixed the jndi problem. Let me know if there are still some 
>> problems,
>> but I guess we should have integration tests for samples to make sure 
>> they
>> start.
>> On Tue, Mar 23, 2010 at 15:39, 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?
>>> 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?
>>> 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/>
>>> -- 
>>> Joe


View raw message