On Monday 19 September 2005 17:11, Daniel Fagerstrom wrote:
> This far when I have built bundles with Ant I have exploded bundles with
> embeded jars and put the embeded one on the classpath, but that is
> obviously not a satisfying solution. How can this be solved with M2? Is
> it possible to give a classloader to the compiler rather than an
> ordinary classpath, so that we can use an OSGi aware classloader while
> compiling? If we use "packaging" the plugin could also chose to embed
> dependencies that has package type "jar" and not embed dependencies of
> type "osgi-bundle".
Maybe I am a total idiot and doesn't understand how complicated life is, but I
don't see a problem.
1. Separate the codebase properly into an API jar and an IMPL bundle jar.
2. All other bundles depending on an API, puts it inside their bundle and
export it with correct versioning (which I agree can be tricky for
non-endorsed APIs).
Where is the problem, exactly?? If you are talking about "messy 3rd party", my
recommendation is library bundles exporting the whole sha-bang, and try to
influence the project to clean up their act (Cocoon included ;o) ). I do
realize the extent of Cocoon 3rd party dependencies, and getting them all to
change is not realistic, but...
Jeff wrote;
"A extends B and B extends C" --> Sorry, it is illegal in Java to say that A
has visibility of B but not C if you have inheritence hierarchies. A WILL be
a subtype of C, whether you like it or not. I must assume you mean something
else, but can't figure out what.
And as Richard noted on KF mailing list, Require-Bundle seems to be a bad new
feature which I have a hard time to see the benefit of, compared to a
Require-Service counter-part. Any suggestion that Maven dependencies are
somehow linked to Require-Bundle is suspect to say the least.
OSGi was not invented to be brutalized, but to be respected in a co-operative
manner. It is important to "play nice" and not "but I want to do it my
way..." as seems to be the rhythm of programmers nowadays.
Cheers
Niclas
