Discussion:
Selective Compiling, is this possible?
(too old to reply)
Neil Corbet
2014-03-31 15:43:54 UTC
Permalink
Hello All,

I have a scenario where I need to make sure one bundle compiles against
another.

Here is my scenario:

BundleA exposes package *my.company.org.dao*. This bundle uses spring to
create mock objects against interfaces in said package. These mock objects
are exposed as services that a UnitTest bundle ( eclipse-test-plugin) uses
strictly for unit testing a service implementation bundle.

BundleB exposes the same package *my.company.org.dao*. But these interfaces
extend spring data PagingAndSortingRepository, which the mocking framework
does not like.

BundleC imports *package my.company.org.dao*. I need this one to compile
against BundleB and not BundleA.

When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.

Is there a way to use the maven tycho compiler plugin to compile against
BundleB and not BundleA?

Thanks,

Neil
Mikhail Kalkov
2014-03-31 16:18:38 UTC
Permalink
Hi,

Do I understand correctly that you have two bundles expose the same
package, which contains both java interface and implementation classes?
This would explain why you want to control bundle selection at compile
time. However, wouldn't it be better to move interface classes to a
separate BundleD, and make both BundleA and BundleB provide implementation
of interfaces from BundleD? Then there is no interface duplication and an
appropriate implementation can be automatically selected at runtime.

Kind regards,
Mikhail Kalkov

Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring to
create mock objects against interfaces in said package. These mock objects
are exposed as services that a UnitTest bundle ( eclipse-test-plugin) uses
strictly for unit testing a service implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the mocking
framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to compile
against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.
Is there a way to use the maven tycho compiler plugin to compile against
BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Mikhail Kalkov
2014-03-31 16:23:37 UTC
Permalink
Also, this FAQ item suggests a way to debug classloading issues to confirm
your analysis:
https://wiki.eclipse.org/Tycho/FAQ#How_to_switch_on_eclipse_tracing_during_test_execution.3F

/Mikhail


On Mon, Mar 31, 2014 at 6:18 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Hi,
Do I understand correctly that you have two bundles expose the same
package, which contains both java interface and implementation classes?
This would explain why you want to control bundle selection at compile
time. However, wouldn't it be better to move interface classes to a
separate BundleD, and make both BundleA and BundleB provide implementation
of interfaces from BundleD? Then there is no interface duplication and an
appropriate implementation can be automatically selected at runtime.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring
to create mock objects against interfaces in said package. These mock
objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the mocking
framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to compile
against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.
Is there a way to use the maven tycho compiler plugin to compile against
BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Neil Corbet
2014-03-31 16:30:53 UTC
Permalink
Mikhail,

Actually, BundleA and BundleB contain only interfaces. No implementation
classes. BundleB's interfaces extends the SpringData
PagingAndSortingRepository interfaces and abstracts classes. Spring Data
generates Implementation classes behind the scenes so I do not have to
write them.

BundleA's interfaces only contain the methods that the tests need. This way
they can be Mocked up a little easier. I was having trouble with Mockito
and the SpringData stuff playing nicely together.

I think the scenario you mentioned above would be nice ( and I may be able
to "re-architect" it in some manner ), but I am a little perplexed as to
how it decides which bundle to compile with and If I have any control over
that.

Thanks,
Neil




On Mon, Mar 31, 2014 at 12:18 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Hi,
Do I understand correctly that you have two bundles expose the same
package, which contains both java interface and implementation classes?
This would explain why you want to control bundle selection at compile
time. However, wouldn't it be better to move interface classes to a
separate BundleD, and make both BundleA and BundleB provide implementation
of interfaces from BundleD? Then there is no interface duplication and an
appropriate implementation can be automatically selected at runtime.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring
to create mock objects against interfaces in said package. These mock
objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the mocking
framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to compile
against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.
Is there a way to use the maven tycho compiler plugin to compile against
BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Mikhail Kalkov
2014-03-31 17:54:22 UTC
Permalink
Well, that's what I mean. If you have both BundleA and BundleB export java
interface com.acme.foobar.IData, I *think *these interfaces will be
considered different by osgi/java runtime. That's probably why you got
"method not found" exception. Another alternative is that the wrong bundle
is selected at runtime. If you insist on keeping this design, I don't see
other alternatives than replacing ImportPackage stanza with RequireBundle
one in MANIFEST.MF.

As for resolution, consider that Tycho is a Maven extension. What it does
is translating OSGi dependencies declared in MANIFEST.MF into Maven ones
and using Maven to resolve them. In the default and recommended
configuration (pomfirst=false) Tycho resolves dependencies declared in
pom.xml against maven repositories, and dependencies originating from
MANIFEST.MF against reactor and p2 repositories (called target platform).
The target platform is computed *independently *for each maven module by
taking all p2 repositories and reactor artifacts, filtering them according
to requirements defined in p2.inf or pom.xml and merging the results. I
*think*, Tycho would not like it if two different bundles provided the same
package, and would print an error, but maybe it just prints a warning and
picks one of them. In other words, if you think that a wrong bundleX is
picked up, it's because that bundleX is in the target platform for bundleY
and because it satisfies some requirement of bundleY. In both cases, you
most likely need to fix a problem in MANIFEST.MF. Btw, one common way to
package tests with tycho is to make test bundle a fragment of host bundle,
but I don't have much experience with Spring and don't know if it blends
well.

Disclaimer: I'm not a Maven/Tycho/Equinox/p2 developer but have been using
it for a while and that's how I think it works.

Kind regards,
Mikhail Kalkov

Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Mikhail,
Actually, BundleA and BundleB contain only interfaces. No implementation
classes. BundleB's interfaces extends the SpringData
PagingAndSortingRepository interfaces and abstracts classes. Spring Data
generates Implementation classes behind the scenes so I do not have to
write them.
BundleA's interfaces only contain the methods that the tests need. This
way they can be Mocked up a little easier. I was having trouble with
Mockito and the SpringData stuff playing nicely together.
I think the scenario you mentioned above would be nice ( and I may be
able to "re-architect" it in some manner ), but I am a little perplexed as
to how it decides which bundle to compile with and If I have any control
over that.
Thanks,
Neil
On Mon, Mar 31, 2014 at 12:18 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Hi,
Do I understand correctly that you have two bundles expose the same
package, which contains both java interface and implementation classes?
This would explain why you want to control bundle selection at compile
time. However, wouldn't it be better to move interface classes to a
separate BundleD, and make both BundleA and BundleB provide implementation
of interfaces from BundleD? Then there is no interface duplication and an
appropriate implementation can be automatically selected at runtime.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring
to create mock objects against interfaces in said package. These mock
objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the mocking
framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to
compile against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.
Is there a way to use the maven tycho compiler plugin to compile
against BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Neil Corbet
2014-03-31 18:58:35 UTC
Permalink
Mikhail,

Thanks for the response.

*If you insist on keeping this design, I don't see other alternatives than
replacing ImportPackage stanza with RequireBundle one in MANIFEST.MF.*

I thought of doing this, but it makes my WebService bundle more tightly
coupled to my DAO bundle. I was using Spring to inject the DAO as an OSGI
Service into my WebServices bundle.

*I think, Tycho would not like it if two different bundles provided the
same package, and would print an error, but maybe it just prints a warning
and picks one of them. In other words, if you think that a wrong bundleX is
picked up, it's because that bundleX is in the target platform for bundleY
and because it satisfies some requirement of bundleY.*

This is where I have tried to maintain a balance between the pde workspace
and Tycho. I can run my unit tests from the pde using the JunitPluginTest
and selecting all of the needed plugins for the run configuration. I needed
to do something similar for the Tycho Surefire plugin. I could ensure that
it included and started my DAO bundle with the mock implementations.

When running my product from eclipse, I can do the same in my run
configuration and ensure that my DAO bundle with the SpringData
implementations is included.

*Btw, one common way to package tests with tycho is to make test bundle a
fragment of host bundle, but I don't have much experience with Spring and
don't know if it blends well.*

I tried to make it a fragment at first, but I had to move it to a
standalone bundle due to loading and timing issues in the spring framework.
I do have some integration tests that work when used as a fragment.


I may need to rethink my architecture some what, but the approach worked ok
until it didn't ( if you know what I mean ). Basically to get around it, I
had to make sure that the Mock one and the Spring Data one had
*EXACTLY*the same methods and method signatures that are referenced in
the
WebServices bundle. I was off a little on only one DAO interface. I am just
a little worried that my Spring Data Repositories might now be completely
implemented if it is compiling against the more stripped down bundle.

Thanks again,
Neil


On Mon, Mar 31, 2014 at 1:54 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Well, that's what I mean. If you have both BundleA and BundleB export java
interface com.acme.foobar.IData, I *think *these interfaces will be
considered different by osgi/java runtime. That's probably why you got
"method not found" exception. Another alternative is that the wrong bundle
is selected at runtime. If you insist on keeping this design, I don't see
other alternatives than replacing ImportPackage stanza with RequireBundle
one in MANIFEST.MF.
As for resolution, consider that Tycho is a Maven extension. What it does
is translating OSGi dependencies declared in MANIFEST.MF into Maven ones
and using Maven to resolve them. In the default and recommended
configuration (pomfirst=false) Tycho resolves dependencies declared in
pom.xml against maven repositories, and dependencies originating from
MANIFEST.MF against reactor and p2 repositories (called target platform).
The target platform is computed *independently *for each maven module by
taking all p2 repositories and reactor artifacts, filtering them according
to requirements defined in p2.inf or pom.xml and merging the results. I
*think*, Tycho would not like it if two different bundles provided the
same package, and would print an error, but maybe it just prints a warning
and picks one of them. In other words, if you think that a wrong bundleX is
picked up, it's because that bundleX is in the target platform for bundleY
and because it satisfies some requirement of bundleY. In both cases, you
most likely need to fix a problem in MANIFEST.MF. Btw, one common way to
package tests with tycho is to make test bundle a fragment of host bundle,
but I don't have much experience with Spring and don't know if it blends
well.
Disclaimer: I'm not a Maven/Tycho/Equinox/p2 developer but have been using
it for a while and that's how I think it works.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Mikhail,
Actually, BundleA and BundleB contain only interfaces. No implementation
classes. BundleB's interfaces extends the SpringData
PagingAndSortingRepository interfaces and abstracts classes. Spring Data
generates Implementation classes behind the scenes so I do not have to
write them.
BundleA's interfaces only contain the methods that the tests need. This
way they can be Mocked up a little easier. I was having trouble with
Mockito and the SpringData stuff playing nicely together.
I think the scenario you mentioned above would be nice ( and I may be
able to "re-architect" it in some manner ), but I am a little perplexed as
to how it decides which bundle to compile with and If I have any control
over that.
Thanks,
Neil
On Mon, Mar 31, 2014 at 12:18 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Hi,
Do I understand correctly that you have two bundles expose the same
package, which contains both java interface and implementation classes?
This would explain why you want to control bundle selection at compile
time. However, wouldn't it be better to move interface classes to a
separate BundleD, and make both BundleA and BundleB provide implementation
of interfaces from BundleD? Then there is no interface duplication and an
appropriate implementation can be automatically selected at runtime.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring
to create mock objects against interfaces in said package. These mock
objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the mocking
framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to
compile against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.
Is there a way to use the maven tycho compiler plugin to compile
against BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Mikhail Kalkov
2014-04-01 13:02:49 UTC
Permalink
How does PDE know which of two bundles providing the same package should be
selected? I think the Tycho counterpart to "selecting all of the needed
plugins for the run configuration" would be to select all of the needed
modules for the maven reactor, i.e. have to different top pom.xml files,
one of which includes BundleA and another one includes BundleB.

/Mikhail
Post by Neil Corbet
Mikhail,
Thanks for the response.
*If you insist on keeping this design, I don't see other alternatives than
replacing ImportPackage stanza with RequireBundle one in MANIFEST.MF.*
I thought of doing this, but it makes my WebService bundle more tightly
coupled to my DAO bundle. I was using Spring to inject the DAO as an OSGI
Service into my WebServices bundle.
*I think, Tycho would not like it if two different bundles provided the
same package, and would print an error, but maybe it just prints a warning
and picks one of them. In other words, if you think that a wrong bundleX is
picked up, it's because that bundleX is in the target platform for bundleY
and because it satisfies some requirement of bundleY.*
This is where I have tried to maintain a balance between the pde workspace
and Tycho. I can run my unit tests from the pde using the JunitPluginTest
and selecting all of the needed plugins for the run configuration. I needed
to do something similar for the Tycho Surefire plugin. I could ensure that
it included and started my DAO bundle with the mock implementations.
When running my product from eclipse, I can do the same in my run
configuration and ensure that my DAO bundle with the SpringData
implementations is included.
*Btw, one common way to package tests with tycho is to make test bundle a
fragment of host bundle, but I don't have much experience with Spring and
don't know if it blends well.*
I tried to make it a fragment at first, but I had to move it to a
standalone bundle due to loading and timing issues in the spring framework.
I do have some integration tests that work when used as a fragment.
I may need to rethink my architecture some what, but the approach worked
ok until it didn't ( if you know what I mean ). Basically to get around it,
I had to make sure that the Mock one and the Spring Data one had *EXACTLY*the same methods and method signatures that are referenced in the
WebServices bundle. I was off a little on only one DAO interface. I am just
a little worried that my Spring Data Repositories might now be completely
implemented if it is compiling against the more stripped down bundle.
Thanks again,
Neil
On Mon, Mar 31, 2014 at 1:54 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Well, that's what I mean. If you have both BundleA and BundleB export
java interface com.acme.foobar.IData, I *think *these interfaces will be
considered different by osgi/java runtime. That's probably why you got
"method not found" exception. Another alternative is that the wrong bundle
is selected at runtime. If you insist on keeping this design, I don't see
other alternatives than replacing ImportPackage stanza with RequireBundle
one in MANIFEST.MF.
As for resolution, consider that Tycho is a Maven extension. What it does
is translating OSGi dependencies declared in MANIFEST.MF into Maven ones
and using Maven to resolve them. In the default and recommended
configuration (pomfirst=false) Tycho resolves dependencies declared in
pom.xml against maven repositories, and dependencies originating from
MANIFEST.MF against reactor and p2 repositories (called target platform).
The target platform is computed *independently *for each maven module by
taking all p2 repositories and reactor artifacts, filtering them according
to requirements defined in p2.inf or pom.xml and merging the results. I
*think*, Tycho would not like it if two different bundles provided the
same package, and would print an error, but maybe it just prints a warning
and picks one of them. In other words, if you think that a wrong bundleX is
picked up, it's because that bundleX is in the target platform for bundleY
and because it satisfies some requirement of bundleY. In both cases, you
most likely need to fix a problem in MANIFEST.MF. Btw, one common way to
package tests with tycho is to make test bundle a fragment of host bundle,
but I don't have much experience with Spring and don't know if it blends
well.
Disclaimer: I'm not a Maven/Tycho/Equinox/p2 developer but have been
using it for a while and that's how I think it works.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Mikhail,
Actually, BundleA and BundleB contain only interfaces. No implementation
classes. BundleB's interfaces extends the SpringData
PagingAndSortingRepository interfaces and abstracts classes. Spring Data
generates Implementation classes behind the scenes so I do not have to
write them.
BundleA's interfaces only contain the methods that the tests need. This
way they can be Mocked up a little easier. I was having trouble with
Mockito and the SpringData stuff playing nicely together.
I think the scenario you mentioned above would be nice ( and I may be
able to "re-architect" it in some manner ), but I am a little perplexed as
to how it decides which bundle to compile with and If I have any control
over that.
Thanks,
Neil
On Mon, Mar 31, 2014 at 12:18 PM, Mikhail Kalkov <
Post by Mikhail Kalkov
Hi,
Do I understand correctly that you have two bundles expose the same
package, which contains both java interface and implementation classes?
This would explain why you want to control bundle selection at compile
time. However, wouldn't it be better to move interface classes to a
separate BundleD, and make both BundleA and BundleB provide implementation
of interfaces from BundleD? Then there is no interface duplication and an
appropriate implementation can be automatically selected at runtime.
Kind regards,
Mikhail Kalkov
Eclipse Developer | Purple Scout AB | www.purplescout.com
Kyrkogatan 20-22, SE-41110 Gothenburg, Sweden
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles
against another.
BundleA exposes package *my.company.org.dao*. This bundle uses
spring to create mock objects against interfaces in said package. These
mock objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the mocking
framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to
compile against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in BundleB
extending the spring data interfaces. BundleA is not in the feature that
defines my product.
Is there a way to use the maven tycho compiler plugin to compile
against BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Martin Weber
2014-04-01 15:57:30 UTC
Permalink
Post by Mikhail Kalkov
How does PDE know which of two bundles providing the same package should be
selected? I think the Tycho counterpart to "selecting all of the needed
What about a 'split package'? AFAIK, this allows for different bundles
contributing classes to the same package.
Even the Eclipse workbench uses that.

Import-Package: org.eclipse.ui;ui.workbench=split,

Martin
--
| Martin Weber
| RazorCat Development GmbH
| Witzlebenplatz 4 fon: +49-(30)-536 357 46
| 14057 Berlin fax: +49-(30)-536 357 60
|
|--------------------------------------------
| Geschäftsführer: Michael Wittner
| Sitz der Gesellschaft: Berlin
| Amtsgericht: Berlin, HRB 65326
Igor Fedorenko
2014-04-01 17:33:09 UTC
Permalink
Although not documented, it is possible to add extra constraints to help
Tycho dependency resolver choose from alternative providers of the same
capability. Try adding configuration like below to BundleC pom.xml file


<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>eclipse-plugin</type>
<id>BundleB</id>
<versionRange>0.0.0</versionRange>
</requirement>
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>

This will tell Tycho to resolve BundleC dependencies as if it had
"Require-Bundle: BundleB" in addition to existing Import-Package, which
will give BundleB strong preference over BundleA.

Alternatively, you can filter BundleA from BundleC target platform as
explain in [1]

[1] https://wiki.eclipse.org/Tycho/Target_Platform#Filtering

--
Regards,
Igor
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring
to create mock objects against interfaces in said package. These mock
objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the
mocking framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to compile
against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in
BundleB extending the spring data interfaces. BundleA is not in the
feature that defines my product.
Is there a way to use the maven tycho compiler plugin to compile
against BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Neil Corbet
2014-04-01 18:31:29 UTC
Permalink
Mikhail, Martin, and Igor,

Thanks for all the input towards my problem. The solution that Igor posted
looks like what I was looking for. One interesting thing I have learned
from the exercise is that each bundle is treated as if it has its own
target platform. It would have never occurred to me to add the platform
configuration plugin at the individual bundle level.

I am going to give this a try and I will try to post back what I find.

Thanks again,

Neil
Post by Igor Fedorenko
Although not documented, it is possible to add extra constraints to help
Tycho dependency resolver choose from alternative providers of the same
capability. Try adding configuration like below to BundleC pom.xml file
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>eclipse-plugin</type>
<id>BundleB</id>
<versionRange>0.0.0</versionRange>
</requirement>
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>
This will tell Tycho to resolve BundleC dependencies as if it had
"Require-Bundle: BundleB" in addition to existing Import-Package, which
will give BundleB strong preference over BundleA.
Alternatively, you can filter BundleA from BundleC target platform as
explain in [1]
[1] https://wiki.eclipse.org/Tycho/Target_Platform#Filtering
--
Regards,
Igor
Post by Neil Corbet
Hello All,
I have a scenario where I need to make sure one bundle compiles against
another.
BundleA exposes package *my.company.org.dao*. This bundle uses spring
to create mock objects against interfaces in said package. These mock
objects are exposed as services that a UnitTest bundle (
eclipse-test-plugin) uses strictly for unit testing a service
implementation bundle.
BundleB exposes the same package *my.company.org.dao*. But these
interfaces extend spring data PagingAndSortingRepository, which the
mocking framework does not like.
BundleC imports *package my.company.org.dao*. I need this one to compile
against BundleB and not BundleA.
When I built my product and installed it, I kept getting an error when
using one of my services that a method was not found. It seems it was
compiling BundleC against BundleA's dao package and not the ones in
BundleB extending the spring data interfaces. BundleA is not in the
feature that defines my product.
Is there a way to use the maven tycho compiler plugin to compile
against BundleB and not BundleA?
Thanks,
Neil
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
https://dev.eclipse.org/mailman/listinfo/tycho-user
Continue reading on narkive:
Loading...