Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] dependency on a fragment in a sibling project

Ooh, thanks Jan!!!  I did not know about that option, and I did not know
that the tycho plugin was of aware of it either.  So since
jars.extra.classpath is a PDE thing and I had to use
Eclipse-ExtensibleAPI: true in the host bundle for PDE's sake I thought
maybe the jars.extra.classpath fix would obviate the need for
Eclipse-ExtensibleAPI: true for PDE but that doesn't appear to be the
case.  I can live with having to crack the host jar to make my debugger
happy, but do you know why PDE still needs the host manifest altered?




On 6/21/13 1:42 AM, "Sievers, Jan" <jan.sievers@xxxxxxx> wrote:

>you can use jars.extra.classpath in build.properties to add
>bundles/fragments to the compile classpath.
>See patch attached.
>
>Jan
>
>-----Original Message-----
>From: tycho-user-bounces@xxxxxxxxxxx
>[mailto:tycho-user-bounces@xxxxxxxxxxx] On Behalf Of Tim Harsch
>Sent: Donnerstag, 20. Juni 2013 06:22
>To: Tycho user list
>Subject: Re: [tycho-user] dependency on a fragment in a sibling project
>
>So I created a SSCE at https://bitbucket.org/harschware/tychofragment
>
>With this project you can import each of the projects into eclipse,
>right-click Run As -> Eclipse Application on the
>com.example.some.bundle.wanting.access.to.badclass project (with -console
>argument), and then search for the bundle in the osgi console and start
>it.  You will see the bundle print something from the
>ClassWithPackagePrivateConstructor.
>
>OK, so PDE is happy, now how to get it to build?  You can see from this
>build log, the problem that occurs:
>https://bitbucket.org/harschware/tychofragment/src/cd6b3bc434b97808de4e380
>4
>113c1c2c6c4d196f/mvnInstall.log?at=master
>
>
>Any ideas appreciated.
>Tim
>
>On 6/19/13 3:23 PM, "Tim Harsch" <tharsch@xxxxxxxx> wrote:
>
>>Thanks so much Jan!
>>   I am not, intentionally anyway, attempting a split package.  I will
>>work up a small self contained example to make more clear...  In the
>>meantime it may be useful to know that the reason I am creating a
>>fragment
>>is that I am attempting to add some capability to an eclipse-plugin that
>>I
>>do not own, or have the source for.  I think I could get the third party
>>plugin to add the functionality that I need but, their release cycle
>>won't
>>get it out the door before my release cycle comes.  So I need to modify
>>their plugin in this way (I think).
>>
>>I ran into this fragment issue in the Eclipse PDE environment as well.  I
>>was able to solve my compile time problems in PDE through the use of
>>Eclipse-ExtensibleAPI manifest header.   As described here:
>>http://stackoverflow.com/questions/7141398/eclipse-osgi-bundle-reqiure-an
>>o
>>t
>>her-bundles-fragment
>>
>>Yes, that means I had to crack the 3rd party bundle, add that manifest
>>header to the manifest and repackage the bundle.  Yuck! I'm only willing
>>to do that because the header is addressing an Eclipse PDE issue and
>>shouldn't be needed in the OSGI container.  The bundle and the fragment
>>should get fused.  Or said another way:  From what I understand this
>>shouldn't be an issue at runtime when the bundle and its fragment are
>>deployed into Equinox because the container will treat them as one bundle
>>and I'm home free.
>>
>>I spent the vast portion of the day working out side issues, so that I
>>could verify that I really do need this bundle and fragment in this way.
>>Turns out I do, so I now really need to work out the tycho build part of
>>the problem.  I will cook up a small self contained example and send it
>>out ASAP.
>>
>>Thanks,
>>Tim
>>
>>
>>
>>On 6/19/13 12:17 AM, "Sievers, Jan" <jan.sievers@xxxxxxx> wrote:
>>
>>>From what I can tell, what you have is a split package [1] with the
>>>additional complication that some of the classes come fom a fragment.
>>>At this point, all I can recommend is to avoid split packages
>>>altogether,
>>>even more in combination with fragments.
>>>E.g. there are known bugs in p2 [2] which prevent split package
>>>disambiguation.
>>>
>>>If we would know the problem you are trying to solve here, we might be
>>>able to give better advice.
>>>
>>>Regards,
>>>Jan
>>>
>>>[1] http://wiki.osgi.org/wiki/Split_Packages
>>>[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=360659
>>>
>>>From: tycho-user-bounces@xxxxxxxxxxx
>>>[mailto:tycho-user-bounces@xxxxxxxxxxx] On Behalf Of Tim Harsch
>>>Sent: Mittwoch, 19. Juni 2013 01:23
>>>To: Tycho user list
>>>Subject: [tycho-user] dependency on a fragment in a sibling project
>>>
>>>Hi all,
>>>I have a project where the parent has two children A & B.  A is a
>>>fragment that is providing an additional class via package foo.bar to
>>>the
>>>host bundle (H) .  H exports package foo.bar.  B is an eclipse-plugin
>>>that imports the packages foo.bar.
>>>
>>>When my I run maven compile at the parent.  A builds fine.  And B chokes
>>>when looking for the new class in foo.bar.
>>>
>>>Note:  B is referencing the project A via a <dependency> declaration in
>>>its pom.
>>>
>>>I hope that was clear, any additional info I can provide let me know.
>>>
>>>Thanks,
>>>Tim
>>>_______________________________________________
>>>tycho-user mailing list
>>>tycho-user@xxxxxxxxxxx
>>>https://dev.eclipse.org/mailman/listinfo/tycho-user
>>
>>_______________________________________________
>>tycho-user mailing list
>>tycho-user@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/tycho-user
>
>_______________________________________________
>tycho-user mailing list
>tycho-user@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/tycho-user



Back to the top