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 <[email protected]> wrote:
Guillaume Nodet wrote:
On Tue, Mar 23, 2010 at 04:04, Joe Bohn <[email protected]> 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
[email protected] 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
