On 13 Feb 2014, at 17:08, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote: > Wouldn't it make more sense to roll our own version of "typed" then?
Why roll our own when there’s a standard annotation available? I can always add our own version of @Typed under a different package, but that doesn’t seem to encourage re-use. > Leaking "ee" stuff from core does not seem like nice thing. > > Kristian (Who will only touch "ee" stuff with a pitchfork) > > 2014-02-13 18:01 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>: > >> Please keep @Typed annotation available outside of core. >> >> I use @Typed annotation in one of my (private) core extensions where I >> need a class to implement an interface but not make that interface >> visible for injection in other components. >> >> -- >> Regards, >> Igor >> >> >> On 2/13/2014, 9:43, Jason van Zyl 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? 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? >>> >>> 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.) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
