The changes in gatein-pc are purely around lifecycle modifications and enhancements, and don't entail anything CDI specific within them.

However, gatein-portal/component/pc is modified to add the listener to perform CDI injection within ExoPortletApplicationDeployer, and the code for the listener brings with it the need for CDI on the classpath of the module.

My current thinking is to create a gatein-portal/component/cdi module that contains the listener code, with dependencies on CDI, etc.  Then in ExoPortletApplicationDeployer I try to instantiate the listener based on the class name, and do nothing if that fails.

I see the benefit of this being that we don't then have to ensure that each package option we provide also bundles a CDI implementation, as neither Tomcat or Jetty support CDI OOTB. So ExoPortletApplicationDeployer can simply not add the listener for CDI when the class is not present, and whether its present is determined by packaging.

Does that sound ok?

Also, the CDI scope implementations I think are best suited to be in a new repo under gatein on github, which contains the scopes and the CDI extension to activate them.  And once again the packaging will be updated to include it for only environments that contain a CDI implementation, such as AS.

Thanks

Ken