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 <[email protected]> wrote: > Guillaume Nodet wrote: > >> On Tue, Mar 23, 2010 at 18:15, Joe Bohn <[email protected]> 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 <[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 >>> >>> >> >> >> > > -- > Joe > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
