Hi Andi,
Short answer:
pax-exam-util is nothing but the "don't know where to put this, ask
Toni"-bundle. That's one of the things we need to sort out before the
2.3.0 release.
Long answer:
Pax Exam has stuff required by the drivers (outside OSGi), stuff
required by the containers (inside OSGi) and stuff required by both.
Moreover, there's stuff that might be useful to other projects and
should not stay in Exam (e.g. the ServiceLookup class which is a
candidate for Pax Swissbox).
I'm sure there is an implicit architecture defining which Exam artifact
belongs to which of these categories, but this needs to be made
explicit, and in some cases I could only guess.
At first I tried putting my additions into pax-exam and adapting the
maven-bundle-plugin configuration, and things just wouldn't work until I
started using this separate pax-exam-util bundle.
By now, I believe the point I missed at that time is all the embedded
dependencies in pax-exam-extender-service, so I may have been banging my
head against the wrong manifest all the time.
You may remember some other discussions we had about embedded
dependencies in the context of Pax Logging and Pax Wicket. In general,
my motto is "Embedded Dependencies Considered Harmful". Embedding is the
opposite of modularity - it's simply not the OSGi way. Embedding and
exporting dependencies at the same time is even worse, because it forces
your own choices on your users.
pax-exam-extender-service embeds some Swissbox and OPS4J Base
dependencies and keeps them private, so no harm is done. But why not
simply import the dependencies? Pax Exam automatically provisions itself
and its dependencies to the test container, so users don't really notice
if there's 4 or 10 extra bundles in their system under test.
Another unpleasant side effect of embedding is that it complicates the
build process and breaks some IDE features. Normally, with Eclipse and
m2e, you can run any runnable class in a Maven project at any time just
by right-clicking it. This does not work for embedded dependencies
because the sources are not in the right place, so you have to turn off
workspace resolution and run Maven builds of dependencies manually,
which is rather annoying.
Coming back to the classes currently in pax-exam-util: PathUtils and
ServiceLookup are meant to be public APIs to be used by Exam test
authors. If we move them to Pax Swissbox, pax-exam-extender-service
should import Swissbox instead of embedding and exporting it.
Filter and Injector could go into pax-exam, but maybe they are generic
enough to be extracted to some other utility project.
Best regards,
Harald
Am 03.09.2011 07:33, schrieb Andreas Pieber:
Hey Toni, Hey Harald,
Taking a look at the various artifacts in paxexam I'm curious if it is
really required to have an exam-util. From a user point of view it's an
additional artifact he have to add and from a dev point of view an
additional point to search things :-). Looking at the code in the
artifact I'm not sure if it really have to be in an own artifact and if
we couldn't simply merge it into the main exam artifact.
WDYT?
Kind regards,
Andreas
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
