Hi John! Was partly an error on my side as I mixed up files from cdictrl-servlet with the modules/servlet during the review.
I've now updated the cdictrl-servlet pom to also support other profiles than only 'Weld' and 'OWB'. We might still need to updated this for Weld2. I've also updated the buildall.sh script which helps testing quiet a few combinations locally. Feel free to update this file. But please only with profiles which do not need any local installations (means only the 'embedded' modes plz). Will commit shortly. LieGrue, strub On Saturday, 23 August 2014, 23:45, John D. Ament <john.d.am...@gmail.com> wrote: > > >Hi Mark! > > > > >On Sat, Aug 23, 2014 at 2:51 PM, Mark Struberg <strub...@yahoo.de> wrote: > >> Hi! >> >> cdictrl-servlet directly defines cdi-1.0 artifacts. This breaks Weld-1.2 >> and OWB-2.x. >> > >Yes, I was thinking that as well. Probably don't need a dependency on >CDI-1.0 APIs anyways. I can remove that. However, as far as I know this >doesn't break CDI 1.1/1.2 compatibility. I've built it locally on OWB >1.2.x, Weld 1.1.10, 2.2.1 all seemed fine. I'm actually running a perf >test against Weld 2.2.3 on one of my apps via the module this weekend. > > >> >> The whole module is actually pretty weird. >> >> It is a submodule of cdictrl but I seems to have not much to do with >> cdictrl. Instead it even has dependencies to deltaspike-core... >> >> >I'm not sure what you mean here. It declares a dependency on cdictrl-api, >not deltaspike-core. See [1]. > > >> How do we proceed? >> Sorry that this slipped through our quality control. >> >> >Well, I first proposed this back in March/April. Little feedback was >given. If you have other issues with it, please don't hesitate to drop a >mail or raise a JIRA ticket. > > >> >> LieGrue, >> strub >> > >- John > > >[1]: >https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/servlet/pom.xml > > > >
