I have a local test working. It's not going to work too cleanly, but its doable.
If you look at this test for instance: https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/se/discovery/trimmed/TrimmedBeanArchiveSETest.java , its dependent on having a bean archive with this beans.xml file https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/resources/org/jboss/cdi/tck/tests/se/discovery/trimmed/beans.xml Maybe we'll get lucky and this is the only case of a special beans.xml, but we may need multiple test projects to accomplish it (maybe some examples?) John On Sun, Jul 30, 2017 at 6:19 PM Mark Struberg <[email protected]> wrote: > Well, we would need to keep the JBoss copyright. > Which is something I'd rather like to avoid because it's essentially just > a test. > > I'm currently moving from the tomcat7-m-p to cargo-maven2-plugin. > I can help and take a look into those SE parts affter all that is running > again. > > LieGrue, > strub > > > > Am 31.07.2017 um 00:11 schrieb John D. Ament <[email protected]>: > > > > Agreed, when I first looked at it. Not so much afterwards. Andrew (ALR) > > was working on an idea a long time ago of having an "SE Container" where > it > > was a fully isolated JVM that you could just push classes to. I think > > that's what they were trying to do here. > > > > I raised my first TCK issue today :-) I'll raise another for this (was > > thinking about it anyways), since I'm really not sure what they were > going > > for with this test. > > > > Would it be an issue to just duplicate the tests here? > > > > John > > > > On Sun, Jul 30, 2017 at 6:01 PM Mark Struberg <[email protected] > > > > wrote: > > > >> With other words: this part of the TCK should not have been using > >> Arquillian in the first place. > >> > >> LieGrue, > >> strub > >> > >>> Am 30.07.2017 um 23:59 schrieb Romain Manni-Bucau < > [email protected] > >>> : > >>> > >>> Just exclude these tests and remplace them by webbeans-se normal tests. > >>> This is good enough and doesnt require arquillian hacks. > >>> > >>> Le 30 juil. 2017 23:56, "John D. Ament" <[email protected]> a > écrit > >> : > >>> > >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau < > >> [email protected]> > >>> wrote: > >>> > >>>> Se code can work with arquillian tuning the scanner in owb.props but > not > >>>> sure it does wirrh it if we cover the tests in standalone already. > Wdyt? > >>>> > >>> > >>> Romain, I have no idea what you're asking here. > >>> > >>> > >>>> > >>>> Le 30 juil. 2017 22:29, "John D. Ament" <[email protected]> a > >> écrit : > >>>> > >>>>> Mark, > >>>>> > >>>>> Sure, its this TCK test in particular: > >>>>> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/ > >>>>> src/main/java/org/jboss/cdi/tck/tests/se/container/ > >>>>> BootstrapSEContainerTest.java#L57 > >>>>> > >>>>> From looking at what they're doing, it seems like they're trying to > >>>> create > >>>>> an isolated classpath using the Arquillian SE container, and > expecting > >>>> the > >>>>> beans to be discovered from there. However, the SE container OWB is > >>>>> initializing ends up mixing ShrinkWrap and XBean behavior, which > causes > >>>> JAR > >>>>> discovery to behave a bit different. > >>>>> > >>>>> BTW, I did try changing the protocol, no luck as the JAR generated > >> isn't > >>>> a > >>>>> real JAR. > >>>>> > >>>>> John > >>>>> > >>>>> On Sun, Jul 30, 2017 at 3:52 PM Mark Struberg > >> <[email protected] > >>>>> > >>>>> wrote: > >>>>> > >>>>>> Hi John! > >>>>>> > >>>>>> We actually don't use xbean at all in the arquillian adapter. > >>>>>> The scanning is done manually. You can dig that in the > >>>>>> OwbArquillianScannerService. > >>>>>> Can you share your setup? Probably might help a bit later. > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>>> Am 30.07.2017 um 20:23 schrieb John D. Ament < > [email protected] > >>>>> : > >>>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> So I've been trying to dig into why OWB's CDI TCK tests are > >>>> failing. I > >>>>>>> have it down to 22 failures that should mostly be passing (or are > >>>>> failing > >>>>>>> in the wrong spot). The most common failure is because of this: > >>>>>>> > >>>>>>> Caused by: java.lang.UnsupportedOperationException: unsupported > >>>>> archive > >>>>>>> type: archive:8a164bf7-f1d7-407e-b612-633720f769f1.jar/ > >>>>>>> at > >>>>>>> > >>>>>> org.apache.xbean.finder.archive.ClasspathArchive. > >>>>> archive(ClasspathArchive.java:87) > >>>>>>> at > >>>>>>> > >>>>>> org.apache.webbeans.corespi.scanner.xbean.CdiArchive.< > >>>>> init>(CdiArchive.java:67) > >>>>>>> > >>>>>>> I'm not sure if this is an XBean issue or an OWB issue. Basically, > >>>>> when > >>>>>>> bootstrapping CDI SE, we're getting some shrinkwrap JARs on the > >>>>> classpath > >>>>>>> (which is on purpose, I think they're trying to make a CDI bean > >>>> archive > >>>>>> in > >>>>>>> addition to what's in the SE container). XBean doesn't know what > >>> the > >>>>>>> "archive" protocol means. I suspect if the first if statement in > >>>>>>> ClasspathArchive were changed to (line > >>>>>>> 53): if(location.getProtocol().equals("jar") || > >>>>>>> location.getProtocol().equals("archive")) { then it would fix it, > >>> but > >>>>> not > >>>>>>> 100% sure. > >>>>>>> > >>>>>>> John > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
