Small correction; Pax Exam was initially a "Bundle Test Framework" that leveraged Pax Runner as the "OSGi-Container-Starter". Pax Exam 2 took on the role of "doing everything" and even be used as the "OSGi-Container-Starter" instead of improving Pax Runner, which slowly decayed as a result.
Specialization vs Abstractions is a very delicate balance to make, and the latter definitely needs strong existing implementations to validate the abstractions. My suggestion, Christoph; Create a proof-of-concept, find out if it is really viable, and bring back some data. Maybe it will be amazing. Maybe you realize it is a bad idea. Who knows until it has been tried? Cheers On Sun, Dec 3, 2017 at 1:52 AM, 'Christoph Läubrich' via OPS4J < [email protected]> wrote: > 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. > -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java -- -- ------------------ 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.
