You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/03/23 08:11:40 UTC
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
On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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.
> 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
> 'org.osgi.service.jndi.services' 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
> 'org.osgi.service.jndi.services' 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: org.osgi.service.jndi.services;
> version="0.0.0"
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
> etc...
>
>
I'll try to fix that one asap.
>
>
> --
> Joe
>
>
> gnodet@apache.org wrote:
>
>> Author: gnodet
>> Date: Mon Mar 22 16:28:46 2010
>> New Revision: 926162
>>
>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>> Log:
>> ARIES-262: Use properties to configure the bundle plugin manifest
>> generation instead of configuring the plugin in each pom
>>
>> <snip/>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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
Posted by Joe Bohn <jo...@gmail.com>.
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 <jo...@gmail.com> 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
>>> 'org.osgi.service.jndi.services' 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
>>> 'org.osgi.service.jndi.services' 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:
>>> org.osgi.service.jndi.services;
>>> version="0.0.0"
>>> at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>
>>> etc...
>>>
>>>
>> I'll try to fix that one asap.
>>
>>
>>>
>>> --
>>> Joe
>>>
>>>
>>> gnodet@apache.org wrote:
>>>
>>>> Author: gnodet
>>>> Date: Mon Mar 22 16:28:46 2010
>>>> New Revision: 926162
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>> Log:
>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>> generation instead of configuring the plugin in each pom
>>>>
>>>> <snip/>
>>
>>
>>
>
>
--
Joe
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
Posted by Alasdair Nottingham <no...@apache.org>.
I would suggest packages with internal or impl in their names should
be hidden. These are the conventions I have seen the most for private
content. I don't think we follow it everywhere.
I'm not sure I like putting private in the package name since it is a
keyword in Java, but that is just a personal view.
Alasdair
On 23 March 2010 21:09, Guillaume Nodet <gn...@gmail.com> wrote:
> The "impl" is just what is configured for now in the default
> <aries.osgi.private.pkg> property, but I agree "private" would look better.
>
> On Tue, Mar 23, 2010 at 20:12, Joe Bohn <jo...@gmail.com> wrote:
>
>> Guillaume Nodet wrote:
>>
>>> On Tue, Mar 23, 2010 at 18:15, Joe Bohn <jo...@gmail.com> 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
>>>>
>>>>
>>> Yes, I suppose they should be upgrade too, but any help would be welcome.
>>>
>>
>> I'd be glad to take a help once I better understand the different
>> properties.
>>
>>
>>
>>>
>>> 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?
>>>>
>>>>
>>> Yeah, I think we definitely to rename the packages so that:
>>> * public packages match ${artifactId}.*
>>>
>>
>> This makes sense and I think is most often the case - but there are some
>> places where we stray from this.
>>
>>
>> * private packages match ${artifactId}.*.impl.*
>>>
>>
>> Requiring "impl" somewhere in the package name for a private package is a
>> little more restrictive. Is this a standard from somewhere else or do we
>> have some flexibility in the name? - perhaps something like ".private."
>> would be better?
>>
>>
>>
>> That will definitely help to reduce the amount of configuration needed.
>>>
>>>
>>> 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 <jo...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>>>>>> 'org.osgi.service.jndi.services' 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
>>>>>>>> 'org.osgi.service.jndi.services' 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:
>>>>>>>> org.osgi.service.jndi.services;
>>>>>>>> version="0.0.0"
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>>>>>> etc...
>>>>>>>>
>>>>>>>>
>>>>>>>> I'll try to fix that one asap.
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>> gnodet@apache.org wrote:
>>>>>>>>
>>>>>>>> Author: gnodet
>>>>>>>>
>>>>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>>>>>> New Revision: 926162
>>>>>>>>>
>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>>>>>> Log:
>>>>>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>>>>>> generation instead of configuring the plugin in each pom
>>>>>>>>>
>>>>>>>>> <snip/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>> Joe
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Joe
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
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
Posted by Guillaume Nodet <gn...@gmail.com>.
The "impl" is just what is configured for now in the default
<aries.osgi.private.pkg> property, but I agree "private" would look better.
On Tue, Mar 23, 2010 at 20:12, Joe Bohn <jo...@gmail.com> wrote:
> Guillaume Nodet wrote:
>
>> On Tue, Mar 23, 2010 at 18:15, Joe Bohn <jo...@gmail.com> 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
>>>
>>>
>> Yes, I suppose they should be upgrade too, but any help would be welcome.
>>
>
> I'd be glad to take a help once I better understand the different
> properties.
>
>
>
>>
>> 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?
>>>
>>>
>> Yeah, I think we definitely to rename the packages so that:
>> * public packages match ${artifactId}.*
>>
>
> This makes sense and I think is most often the case - but there are some
> places where we stray from this.
>
>
> * private packages match ${artifactId}.*.impl.*
>>
>
> Requiring "impl" somewhere in the package name for a private package is a
> little more restrictive. Is this a standard from somewhere else or do we
> have some flexibility in the name? - perhaps something like ".private."
> would be better?
>
>
>
> That will definitely help to reduce the amount of configuration needed.
>>
>>
>> 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 <jo...@gmail.com> wrote:
>>>>
>>>>
>>>> Guillaume Nodet wrote:
>>>>>
>>>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>>>>> 'org.osgi.service.jndi.services' 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
>>>>>>> 'org.osgi.service.jndi.services' 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:
>>>>>>> org.osgi.service.jndi.services;
>>>>>>> version="0.0.0"
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>>>>> etc...
>>>>>>>
>>>>>>>
>>>>>>> I'll try to fix that one asap.
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>> gnodet@apache.org wrote:
>>>>>>>
>>>>>>> Author: gnodet
>>>>>>>
>>>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>>>>> New Revision: 926162
>>>>>>>>
>>>>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>>>>> Log:
>>>>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>>>>> generation instead of configuring the plugin in each pom
>>>>>>>>
>>>>>>>> <snip/>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>> Joe
>>>
>>>
>>
>>
>>
>
> --
> Joe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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
Posted by Joe Bohn <jo...@gmail.com>.
Guillaume Nodet wrote:
> On Tue, Mar 23, 2010 at 18:15, Joe Bohn <jo...@gmail.com> 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
>>
>
> Yes, I suppose they should be upgrade too, but any help would be welcome.
I'd be glad to take a help once I better understand the different
properties.
>
>
>> 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?
>>
>
> Yeah, I think we definitely to rename the packages so that:
> * public packages match ${artifactId}.*
This makes sense and I think is most often the case - but there are some
places where we stray from this.
> * private packages match ${artifactId}.*.impl.*
Requiring "impl" somewhere in the package name for a private package is
a little more restrictive. Is this a standard from somewhere else or do
we have some flexibility in the name? - perhaps something like
".private." would be better?
> That will definitely help to reduce the amount of configuration needed.
>
>
>> 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 <jo...@gmail.com> wrote:
>>>
>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>>>> 'org.osgi.service.jndi.services' 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
>>>>>> 'org.osgi.service.jndi.services' 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:
>>>>>> org.osgi.service.jndi.services;
>>>>>> version="0.0.0"
>>>>>> at
>>>>>>
>>>>>>
>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>>>> at
>>>>>>
>>>>>>
>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>>>> at
>>>>>>
>>>>>>
>>>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>>>> etc...
>>>>>>
>>>>>>
>>>>>> I'll try to fix that one asap.
>>>>>>
>>>>>
>>>>> --
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>> gnodet@apache.org wrote:
>>>>>>
>>>>>> Author: gnodet
>>>>>>
>>>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>>>> New Revision: 926162
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>>>> Log:
>>>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>>>> generation instead of configuring the plugin in each pom
>>>>>>>
>>>>>>> <snip/>
>>>>>>>
>>>>>>>
>>>>> --
>>>> Joe
>>>>
>>>>
>>>
>>>
>> --
>> Joe
>>
>
>
>
--
Joe
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
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Mar 23, 2010 at 18:15, Joe Bohn <jo...@gmail.com> 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
>
Yes, I suppose they should be upgrade too, but any help would be welcome.
>
> 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?
>
Yeah, I think we definitely to rename the packages so that:
* public packages match ${artifactId}.*
* private packages match ${artifactId}.*.impl.*
That will definitely help to reduce the amount of configuration needed.
> 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 <jo...@gmail.com> wrote:
>>
>>
>>> Guillaume Nodet wrote:
>>>
>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>>> 'org.osgi.service.jndi.services' 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
>>>>> 'org.osgi.service.jndi.services' 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:
>>>>> org.osgi.service.jndi.services;
>>>>> version="0.0.0"
>>>>> at
>>>>>
>>>>>
>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>>> at
>>>>>
>>>>>
>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>>> at
>>>>>
>>>>>
>>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>>> etc...
>>>>>
>>>>>
>>>>> I'll try to fix that one asap.
>>>>>
>>>>
>>>>
>>>> --
>>>>> Joe
>>>>>
>>>>>
>>>>> gnodet@apache.org wrote:
>>>>>
>>>>> Author: gnodet
>>>>>
>>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>>> New Revision: 926162
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>>> Log:
>>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>>> generation instead of configuring the plugin in each pom
>>>>>>
>>>>>> <snip/>
>>>>>>
>>>>>>
>>>>
>>>> --
>>> Joe
>>>
>>>
>>
>>
>>
>
> --
> Joe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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
Posted by Joe Bohn <jo...@gmail.com>.
Joe Bohn wrote:
> 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?
>
> Zoe,
>
> 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):
> - "org.apache.aries.blog.persistence.api" =>
> "org.apache.aries.blog.api.persistence.api"
> - "org.apache.aries.blog.persistence.comment.api" =>
> "org.apache.aries.blog.api.persistence.comment.api"
>
> 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".
>
> WDYT?
> Joe
I decided to go ahead and check in this change in rev. 926778 under
ARIES-264. You can revert the change if you'd like. I decided that at
this point a working sample was better than a broken one.
Joe
>
>
>
>
>>
>> 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 <jo...@gmail.com> wrote:
>>>
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>>>> 'org.osgi.service.jndi.services' 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
>>>>>> 'org.osgi.service.jndi.services' 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:
>>>>>> org.osgi.service.jndi.services;
>>>>>> version="0.0.0"
>>>>>> at
>>>>>>
>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>>>>
>>>>>> at
>>>>>>
>>>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>>>>
>>>>>> etc...
>>>>>>
>>>>>>
>>>>>> I'll try to fix that one asap.
>>>>>
>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>> gnodet@apache.org wrote:
>>>>>>
>>>>>> Author: gnodet
>>>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>>>> New Revision: 926162
>>>>>>>
>>>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>>>> Log:
>>>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>>>> generation instead of configuring the plugin in each pom
>>>>>>>
>>>>>>> <snip/>
>>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
Joe
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
Posted by Joe Bohn <jo...@gmail.com>.
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?
Zoe,
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):
- "org.apache.aries.blog.persistence.api" =>
"org.apache.aries.blog.api.persistence.api"
- "org.apache.aries.blog.persistence.comment.api" =>
"org.apache.aries.blog.api.persistence.comment.api"
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".
WDYT?
Joe
>
> 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 <jo...@gmail.com> wrote:
>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>>> 'org.osgi.service.jndi.services' 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
>>>>> 'org.osgi.service.jndi.services' 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:
>>>>> org.osgi.service.jndi.services;
>>>>> version="0.0.0"
>>>>> at
>>>>>
>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>>>
>>>>> at
>>>>>
>>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>>>
>>>>> at
>>>>>
>>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>>>
>>>>> etc...
>>>>>
>>>>>
>>>>> I'll try to fix that one asap.
>>>>
>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>>
>>>>> gnodet@apache.org wrote:
>>>>>
>>>>> Author: gnodet
>>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>>> New Revision: 926162
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>>> Log:
>>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>>> generation instead of configuring the plugin in each pom
>>>>>>
>>>>>> <snip/>
>>>>>>
>>>>
>>>>
>>> --
>>> Joe
>>>
>>
>>
>>
>
>
--
Joe
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
Posted by Joe Bohn <jo...@gmail.com>.
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?
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 <jo...@gmail.com> wrote:
>
>>
>> Guillaume Nodet wrote:
>>
>>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>>> 'org.osgi.service.jndi.services' 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
>>>> 'org.osgi.service.jndi.services' 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:
>>>> org.osgi.service.jndi.services;
>>>> version="0.0.0"
>>>> at
>>>>
>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>>> at
>>>>
>>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>>> at
>>>>
>>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>>> etc...
>>>>
>>>>
>>>> I'll try to fix that one asap.
>>>
>>>
>>>> --
>>>> Joe
>>>>
>>>>
>>>> gnodet@apache.org wrote:
>>>>
>>>> Author: gnodet
>>>>> Date: Mon Mar 22 16:28:46 2010
>>>>> New Revision: 926162
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>>> Log:
>>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>>> generation instead of configuring the plugin in each pom
>>>>>
>>>>> <snip/>
>>>>>
>>>
>>>
>> --
>> Joe
>>
>
>
>
--
Joe
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
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jo...@gmail.com> wrote:
>
>
> Guillaume Nodet wrote:
>
>> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>>> 'org.osgi.service.jndi.services' 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
>>> 'org.osgi.service.jndi.services' 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:
>>> org.osgi.service.jndi.services;
>>> version="0.0.0"
>>> at
>>>
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>>> at
>>>
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>>> at
>>>
>>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>>> etc...
>>>
>>>
>>> I'll try to fix that one asap.
>>
>>
>>
>>> --
>>> Joe
>>>
>>>
>>> gnodet@apache.org wrote:
>>>
>>> Author: gnodet
>>>> Date: Mon Mar 22 16:28:46 2010
>>>> New Revision: 926162
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>>> Log:
>>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>>> generation instead of configuring the plugin in each pom
>>>>
>>>> <snip/>
>>>>
>>>
>>
>>
>>
>
> --
> Joe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
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
Posted by Joe Bohn <jo...@gmail.com>.
Guillaume Nodet wrote:
> On Tue, Mar 23, 2010 at 04:04, Joe Bohn <jo...@gmail.com> 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
>> 'org.osgi.service.jndi.services' 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
>> 'org.osgi.service.jndi.services' 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: org.osgi.service.jndi.services;
>> version="0.0.0"
>> at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
>> at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
>> etc...
>>
>>
> I'll try to fix that one asap.
>
>
>>
>> --
>> Joe
>>
>>
>> gnodet@apache.org wrote:
>>
>>> Author: gnodet
>>> Date: Mon Mar 22 16:28:46 2010
>>> New Revision: 926162
>>>
>>> URL: http://svn.apache.org/viewvc?rev=926162&view=rev
>>> Log:
>>> ARIES-262: Use properties to configure the bundle plugin manifest
>>> generation instead of configuring the plugin in each pom
>>>
>>> <snip/>
>
>
>
--
Joe