<mailto:
igor@xxxxxxxxxxxxxx <mailto:
igor@xxxxxxxxxxxxxx>>> wrote:
I think there is a good explanation to the behaviour you
see, but I'd
need an example project to tell for sure.
--
Regards,
Igor
On 12-08-21 7:00 PM, Alexander Potapov wrote:
Thank you for fast reply.
OK, I understand that all-or-nothing thing. But why
a.b.c Java
package
contents (from A and B projects) are not visible as one
package with
classes from both projects?
If I change the order of dependencies specified as
required bundles
(i.e. wrappers A' and B') in manifest file then
different package
contents are resolved. It should resolve wrapper project
exports. Looks
like classpath entry idea is ignored here and each
Maven container
reference project threated like a bundle.
Is it correct behavior of interaction between Maven
container
and OSGi
import/export (or required-bundle) mechanisms? Sounds
like not.
Br,
Alexander
On Aug 22, 2012 12:02 AM, "Igor Fedorenko"
<
igor@xxxxxxxxxxxxxx <mailto:
igor@xxxxxxxxxxxxxx>
<mailto:
igor@xxxxxxxxxxxxxx <mailto:
igor@xxxxxxxxxxxxxx>>
<mailto:
igor@xxxxxxxxxxxxxx
<mailto:
igor@xxxxxxxxxxxxxx> <mailto:
igor@xxxxxxxxxxxxxx
<mailto:
igor@xxxxxxxxxxxxxx>>>
> wrote:
Workspace dependencies are all-or-nothing thing,
so clients
of B will
always see all packages, regardless if they ask
for B1 or
B2. This
limitation is rather fundamental to how maven works --
project model
does not have enough information to know contents
of B1 and
B2, and how
jdt works -- it is not possible to depend on some
project
output, so
this limitation won't be relaxed any time soon.
You may be able to workaround the problem by
splitting B in
two separate
projects, but I don't know if this is an option or
not.
--
Regards,
Igor
On 12-08-21 4:12 PM, Alexander Potapov wrote:
Hello,
I have setup:
Eclipse Juno with PDE:
Version: