[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2e-dev] maven-bundle-plugin based OSGi bundle fails to export package contents correctly if the same package is located in multiple dependencies
|
bundleA does not list src/ as source folder in build.properties. Once I
fixed that and updated project classpath, I get what I believe expected
Access restriction compilation errors.
Description Resource Path Location Type
Access restriction: The type Class3 is not accessible due to restriction
on required project projectB Activator.java /bundleA/src/a/b/e line 12
Java Problem
Access restriction: The type Class3 is not accessible due to restriction
on required project projectB Activator.java /bundleA/src/a/b/e line 5
Java Problem
Access restriction: The type Class3 is not accessible due to restriction
on required project projectB Activator.java /bundleA/src/a/b/e line 12
Java Problem
Access restriction: The constructor Class3() is not accessible due to
restriction on required project projectB Activator.java
/bundleA/src/a/b/e line 12 Java Problem
--
Regards,
Igor
On 12-08-22 6:03 AM, Alexander Potapov wrote:
Hello Igor,
Today I did small demo for you. You can find it here:
https://github.com/outro666/test.git
bundleA should have compilation problems.
On my real workspace, when I change manifest file dependencies, i.e.
required bundles (wrapperes) or package imports, then bundle (bundleA in
our case) resolves different package contents from wrappers.
Br,
Alexander
On 22 August 2012 04:17, Igor Fedorenko <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>>> 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: 3.8.0.v20120525-1249-____7c7vFitFFt6Zr5a12MM4IKMFZ
Build id: I20120608-1400
m2e plugin:
Version: 1.1.0.20120530-0009
maven-bundle-plugin:
Version: 2.3.7
I use OSGi wrapping bundles (maven-bundle-plugin generates
manifest and
uses Maven container for dependencies resolution). They
wrap
projects
which are also under development on the same workspace.
I have 2 projects with the same package.
For instance:
Project A has package:
a.b.c
Project B has packages:
a.b.c
a.b.d
Project B produces 2 artifacts. One of them contains
everything
(Artifact B1) and another one contains only a.b.c
package contents
(Artifact B2).
Moving a.b.c package from Project B "is not possible".
Because
it will
introduce cycle in dependencies. Package rename is also
prohibited,
because of compatibility issues.
One solution could be - move Project A contents inside
Project
B, but it
is also not an option because Project B will be too heavy.
I have 2 wrappers for both projects:
Wrapper A' which has dependencies to project A and B
(Artifact
B2). It
exports a.b.c package.
Wrapper B' has dependency to project B and it exports
a.b.d package.
Now, if I do not have Project B on my workspace then
wrappers
resolve
artifacts(Artifact B2 + Project A artifact for A'
wrapper bundle,
Artifact B1 for B' wrapper bundle) from maven local
repository and
everything works fine.
But if I have this Project B on my workspace and Maven
container of
wrapper bundle resolves it like a reference to the
project then
I get
compilation errors (Access restriction) in bundles
which are
using this
wrapper(by importing package or specifying wrapper
bundle as
required).
It seems like wrapper bundles export package partially,
what
seems to be
unexpected.
Also tried to specify access rules on Maven container -
doesn't
work at all.
Am I doing something wrong here? Or can you suggest
something?
Br,
Alexander
___________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
___________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev