Niclas Hedhman wrote:
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...
I would much prefer if all code was cleanly separated in API and
implementation. Unfortunatly most of the 50+ "soon to become bundles"
that Cocoon consist of nor the 100+ libraries it depend on is organized
that way. With jars containing both API and implementation, your point 2
above becomes less attractive. And to clean up all these jars from
numerous organizations seem not only extremely boring but also unrealistic.
To me it seem much easier to reuse the classloader mechanism that
allready must be part of any OSGi framework, for bundle building.
Especially as, at least the Eclipse version, seem to be designed to be
reusable.
/Daniel
