Hello A single thought. Some time ago I was considering ... the opposite. I mean I worked with Arquillan that tried to be used as Karaf testing framework - with mixed results. I tried implementing Arquillian resources/runners/... to be able to configure Karaf instance as naturally as in pax-exam (features, config files, ...). I even tried adding support for configuring features, PIDs, config files of Karaf in Arquillain, but I didn't have time to proceed.
But Arquillian is quite good with JEE, CDI stuff (and kubernetes for example) because there's clearer distinction between the "server" and "application". With OSGi, server and applications are effectively the same - a bunch of OSGi bundles. In my humble opinion, pax-exam is THE testing framework for OSGi and it could be too high energy/result ratio to make pax-exam be more philosophy (OSGi vs the rest) agnostic. But that's maybe because I don't have experience with non OSGi parts of pax-exam. Or in other words - if someone uses Arquillian (s)he rather avoids pax-exam, because "it's OSGi". I see there are integrations for Tomcat, Wildfly, weld, ... But from reorganization point of view - that's great idea - to have e.g., github/ops4j/org.ops4j.pax.exam.core (instead of exam2, which is at version 5.0.0-SNAPSHOT already) and github/ops4j/org.ops4j.pax.exam.osgi and others... So just my 2¢. best regards Grzegorz Grzybek 2017-12-02 18:52 GMT+01:00 'Christoph Läubrich' via OPS4J < [email protected]>: > While working on the codebase of Pax Exam the last month an idea cam into > my mind I'd like to discuss. > > Over the years Pax Exam evolved from an "OSGi-Container-Starter" to a > general-purpose container-testing-framework with lots of features and > container-types (J2EE, CDi, OSGi, ...) but also has grown more and more but > became harder and harder to keep track of all possible side-effects and > keep track dependencies when doing changes. > > So I would suggest to restructure the whole "thing" into a core project > and a number of extension projects that can be managed, released and > evolved independently: > > - having one org.ops4j.exam project, dropping the pax part (since in fact > its not only about OSGi anymore) maybe even start with a fresh 1.0.0 > Version, that includes the core API (Container-API, Basic Options, Drivers) > - having one org.ops4j.exam.extension.osgi project, that is all about OSGi > containers and related options > - having one org.ops4j.exam.extension.cdi for cdi related stuff > - having one org.ops4j.exam.extension.j2ee and so on... > - maybe havining more e.g. for Tony's acceptance testing that is a > seperate topic as well, maybe the same will apply to Karaf+EclipseContainer > > That would have several advantages over the current model: > - separation of concerns, resulting in a cleaner view what belongs together > - easier refactoring/evolving/release since the must be no "big-bang" > change but e.g. the core can add new features/releases and the extensions > can then adopt now or later > - easier handling of dependencies because each extension can have its own > dependency chain without hte need to include all in one > - easier testing, since it is now clear what is tested where > - faster buildtimes because each project can be build and tested on its > own no need to download the whole CDI/J2EE stuff when working on the OSGi > part > - easier integration of new features and handling of merges because now a > new feature of an extension won't hold back e.g. the release of the core > > The (minor) drawback would be that for new core features there must be > first a release of the core before extensions can adopt, but the advantages > outweigh this IMO. > > > Any thoughts? I know this would be a great change and lots of work but I'm > convinced that this will rewarded soon by a faster, cleaner and even more > powerful framework than ever before :-) > > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- You received this message because you are subscribed to the Google > Groups "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
