On 13 Feb 2014, at 14:43, Jason van Zyl <ja...@takari.io> wrote: > On Feb 13, 2014, at 8:44 AM, Stuart McCulloch <mccu...@gmail.com> wrote: > >> On 13 Feb 2014, at 13:30, Jason van Zyl <ja...@takari.io> wrote: >> >>> I would consider something like SFL4J as something which is now part of our >>> API think it's fine to expose something like that. I'm not sure the same >>> holds true for CDI. Wouldn't it be better just to completely hide it? >> >> As mentioned in http://wiki.eclipse.org/Sisu/PlexusMigration#Type_Override, >> the @javax.enterprise.inject.Typed annotation can be used to restrict the >> type visibility of components. >> >> Hiding this package means you wouldn’t be able to use this feature outside >> of Maven core - so I guess it depends whether you consider CDI’s @Typed part >> of the component API like JSR330’s @Inject. > > I would say I don't consider it part of our API, so I'd be inclined to hide > it and strictly stick to JSR330. Will Sisu not load without it?
Hiding this package disables the optional runtime support for @Typed, but does not affect other container features - the container will still load without it. > I think we keep running into these issues with App Servers because people are > trying to run their App Server in Maven's runtime environment which doesn't > really make sense. For any of these strange conflicts that arise with SLF4J > or other APIs I think we should just encourage people to run any sort of test > for your App Server with an environment akin to production in that you should > fork once with your own classpath and whatever else you need. Maven's APIs > and runtime environment are for build related activities. Where we have this > cross over like like the jetty/tomcat/wildfly-maven-plugin I think we should > just tell people the best thing to do is fork once and do what you like. > >> The CDI API is at least standardised (one of the reasons why the container >> respects @Typed rather than creating it’s own ad-hoc annotation which >> wouldn’t be as portable). > > Why would we need it? You have any use cases at hand? I don’t know if anything in Maven uses it at the moment, it’s mainly to aid migration from Plexus (which always restricted a component's type visibility to its specific role class) to the new JSR330 model where a component’s type visibility is open - ie. it’s visible as any type in its hierarchy - unless you use @Typed to limit it to specific roles. I have some examples where it was useful in migrating legacy Plexus applications, but nothing specific to Maven. >>> On Feb 13, 2014, at 5:56 AM, Stuart McCulloch <mccu...@gmail.com> wrote: >>> >>>> On 13 Feb 2014, at 07:28, Kristian Rosenvold >>>> <kristian.rosenv...@gmail.com> wrote: >>>> >>>>> Stuart, >>>>> >>>>> We're seeing java.lang.LinkageError: loader constraint violation: loader >>>>> (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously >>>>> initiated loading for a different type with name >>>>> "javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I >>>>> can't really see this seeping through in DefaultClassRealmManager, but >>>>> google shows me https://java.net/jira/browse/GLASSFISH-20802 >>>>> >>>>> Is this something you understand ? >>>> >>>> DefaultClassRealmManager currently exposes the complete >>>> javax.enterprise.inject package from CDI-API: >>>> >>>> imports.put( "javax.enterprise.inject.*", coreRealm ); >>>> >>>> This package contains annotations, exceptions, and one interface - and it >>>> looks like the interface pulls in a type from javax.enterprise.util: >>>> >>>> >>>> http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/Instance.html#select(javax.enterprise.util.TypeLiteral,%20java.lang.annotation.Annotation...) >>>> >>>> Which means that while javax.enterprise.inject.Instance is loaded and >>>> exposed from the core realm, javax.enterprise.util.TypeLiteral will be >>>> loaded from core but not exposed - this is likely the cause of the >>>> constraint violation. >>>> >>>> There are two solutions - first we could narrow the exposure in >>>> DefaultClassRealmManager to: >>>> >>>> imports.put( "javax.enterprise.inject.Typed", coreRealm ); >>>> >>>> since that is the only CDI annotation we’re really interested in, and it >>>> has no dependencies to other types. >>>> >>>> Alternatively we could widen the exposure to include the >>>> javax.enterprise.util package: >>>> >>>> imports.put( "javax.enterprise.inject.*", coreRealm ); >>>> imports.put( "javax.enterprise.util.*", coreRealm ); >>>> >>>> which should also fix the loader constraint while not introducing other >>>> issues. >>>> >>>> WDYT? >>>> >>>>> Kristian >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/takari_io >>> --------------------------------------------------------- >>> >>> Selfish deeds are the shortest path to self destruction. >>> >>> -- The Seven Samuari, Akira Kurosawa >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > Simplex sigillum veri. (Simplicity is the seal of truth.)
