If the bnd google group doesn't respond with a 'you idiot, here's the reason' sort of email, I shall set to work on such a model.
On Wed, Nov 26, 2014 at 4:33 PM, David Bosschaert <david.bosscha...@gmail.com> wrote: > Hi Benson, > > Would it be possible to create a little project that reproduces the > behaviour, so that someone on this list can try it? That might help in > pinpointing the issue... > > Cheers, > > David > > On 26 November 2014 at 21:29, Benson Margulies <ben...@basistech.com> wrote: >> On Wed, Nov 26, 2014 at 12:29 PM, Felix Meschberger <fmesc...@adobe.com> >> wrote: >>> Hmm, that sounds strange. Unless you also export c.b.rosette from the >>> dam-model bundle without a version and thus the import is actually a >>> re-import, I am out of tips… >> >> There are no files in c.b.rosette in the jar file, just in >> c.b.rosette.dm. Time to bug the bnd people, I guess. >> >>> >>> Regards >>> Felix >>> >>>> Am 26.11.2014 um 17:52 schrieb Benson Margulies <ben...@basistech.com>: >>>> >>>> This is pretty odd. As you can see below, there's just one dependency >>>> being included. That 'common-api' dependency exports >>>> com.basistech.rosette. The project-of-the-moment imports it, but does >>>> not end up with a version on the import. >>>> >>>> The only export _here_ is com.basistech.rosette.dm.*. Since that's >>>> 'inside' of com.basistech.rosette, could this be an issue? >>>> >>>> >>>> ➜ model git:(try-improved-parent) ✗ mvn dependency:tree >>>> [INFO] Scanning for projects... >>>> [INFO] >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> [INFO] Building adm-model 1.10.2-SNAPSHOT >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> [INFO] >>>> [INFO] --- maven-dependency-plugin:2.5.1:tree (default-cli) @ adm-model --- >>>> [INFO] com.basistech:adm-model:bundle:1.10.2-SNAPSHOT >>>> [INFO] +- com.basistech:common-api:jar:34.0.0:compile >>>> [INFO] +- com.google.guava:guava:jar:16.0.1:compile >>>> [INFO] +- junit:junit:jar:4.11:test >>>> [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test >>>> [INFO] \- com.googlecode.jmockit:jmockit:jar:1.7:test >>>> >>>> >>>> On Wed, Nov 26, 2014 at 10:13 AM, Benson Margulies <ben...@basistech.com> >>>> wrote: >>>>> On Wed, Nov 26, 2014 at 9:49 AM, Felix Meschberger <fmesc...@adobe.com> >>>>> wrote: >>>>>> Hi >>>>>> >>>>>> IIRC you only get the split-package warning if you embed a package which >>>>>> is provided by more than one dependency. >>>>> >>>>> Is there an option to get some sort of log or trace that would help me >>>>> track down two exporters of the same package? >>>>> >>>>> >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>>> Am 26.11.2014 um 15:33 schrieb Benson Margulies <ben...@basistech.com>: >>>>>>> >>>>>>> On Wed, Nov 26, 2014 at 9:25 AM, Felix Meschberger <fmesc...@adobe.com> >>>>>>> wrote: >>>>>>>> Hi Benson >>>>>>>> >>>>>>>> Do you have two dependencies in the class path which contain the same >>>>>>>> com.basistech.rosette package ? >>>>>>> >>>>>>> I hope not. I don't get any split-package warnings after I went to a >>>>>>> good deal of trouble fix that up. I'll go hunting. >>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Felix >>>>>>>> >>>>>>>> Am 26.11.2014 um 14:56 schrieb Benson Margulies <ben...@basistech.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't know if this is, in fact, a bnd question. Here's an import >>>>>>>>> generated by the plugin. Note that there's a version on the first, and >>>>>>>>> not on the second. >>>>>>>>> >>>>>>>>> Import-Package: >>>>>>>>> com.basistech.rosette,com.basistech.rosette.dm;version=" >>>>>>>>> [1.10,2)" >>>>>>>>> >>>>>>>>> Here is the Export-Package in the manifest of the bundle that exports >>>>>>>>> com.basistech.rosette: >>>>>>>>> >>>>>>>>> Export-Package: >>>>>>>>> com.basistech.rosette;version="34.0.0",com.basistech.ros >>>>>>>>> ette.util;version="34.0.0",com.basistech.util;version="34.0.0" >>>>>>>>> >>>>>>>>> Note the version. >>>>>>>>> >>>>>>>>> So, howcome I don't get a version on the import? >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
