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 <[email protected]> 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 <[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 > -- Alasdair Nottingham [email protected]
