[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [pde-dev] Fwd: [m2e-dev] maven-bundle-plugin based OSGi bundle fails to export package contents correctly if the same package is located in multiple dependencies
|
Hello,
I have reported this bug. Bug ID is 388810.
Br,
Alexander.
On 4 September 2012 23:04, Curtis Windatt
<Curtis_Windatt@xxxxxxxxxx> wrote:
Hi Alexander,
Filing a bug would be a good step to
take as it can hopefully explain the problem more clearly than this email
exchange allows. While Igor's suggestion of using ?**/* is straightforward,
we would need to better understand possible side effects and performance
impacts it would have.
Curtis
Hello,
Please follow discussion below.
Should I report bug for this case?
Br,
Alexander
---------- Forwarded message ----------
From: Igor Fedorenko <igor@xxxxxxxxxxxxxx>
Date: 23 August 2012 14:31
Subject: Re: [m2e-dev] maven-bundle-plugin based OSGi bundle fails to export
package contents correctly if the same package is located in multiple dependencies
To: m2e-dev@xxxxxxxxxxx
Yes, I think you are right and I don't have a good explanation for why
this happens :-)
>From what I can tell, PDE generates incorrect classpath access rules in
PluginDependencies container. For bundleA->wrapperA dependency,
"forbidden" access rule reads "**/*", which tells jdt
compiler to stop
search and generate Access restriction error message if matching classes
are found. Better/proper forbidden access rule should read "?**/*",
which means "ignore matching classes and keep looking".
I don't believe this aspect of PDE behaviour is configurable, so you'd
need to talk to PDE developers to see if they can change how they
generate access rules or at least give m2e/tycho API to control this.
--
Regards,
Igor
On 12-08-23 4:26 AM, Alexander Potapov wrote:
Hello,
Yes, I'm speaking about this Access restriction error.
But why it is expected? bundleA should depend on manifest exports of
wrapper projects. But currently it is looking into Maven container.
I think it is wrong.
When I try to close projectsA and projectB then everything works fine.
It shows that bundleA depends on Maven containers somehow.
In this case, it should not matter what we have in Maven container. Is
it a workspace dependency or dependency from Maven local repository, we
have package which should be exported by wrappers.
I believe that Maven container is(and should be) only part of project
classpath. Then bundle export should decide what should it show to other
bundles.
Did you get my point now?
Br,
Alexander
On 23 August 2012 05:20, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>
wrote:
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
<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>
<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:
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>>
<mailto: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>>
<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>>
<mailto: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>>
<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>
<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
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-dev
