Hi Ron! The reason why cdictrl don't inherit from parent is that it is essentially a different beast. It is not an extension FOR containers, but is IS the part who boots the containers. Means it also has totally different dependencies, etc. That is also the reason why it is not part of the 'modules' but an own part. A big part of the parent pom is e.g. the switching of containers. But the cdictrl each run with exactly their own containers.
We could exclude the cdictrl module if you activate other containers. Or we might introduce a profile to be able to completely skip the cdictrl tree. I guess you are interested in making CI faster? LieGrue, strub On Thursday, 3 April 2014, 17:06, Ron Smeral <rsme...@redhat.com> wrote: Hi, > >I'm pretty sure something similar was discussed already, but anyway: >the cdictrl module is kind of strange with regard to the build >structure. It doesn't inherit from parent-code, but it is a module of >deltaspike-project (the root). > >This results in the fact, that cdictrl gets always tested, even in >real-container profiles (e.g. wildfly-managed) which doesn't make sense. >And the ContainerCtrlTckTest can't be categorised as SeCategory (which >it should be), because it doesn't depend on test-utils. > >This unfortunate project structure is especially problematic with regard >to issues like https://issues.apache.org/jira/browse/DELTASPIKE-558, >where the cdictrl tests hang and thus block the testsuite, without any >clean way of skipping it. > >Any chance of a little project restructuring? > >Ron > >-- >Ron Smeral >JBoss Quality Engineer >Brno > > > >
