Please dont branch - except in sandbox mode - before the sed option is right, in terms of maintenance this is not what we want and we always failed synching branches properly in most ee project but tomcat which does it very right.
Le mer. 8 mai 2019 à 18:13, Arne Limburg <arne.limb...@openknowledge.de> a écrit : > Oh yes, in JSF it would be hard to support both, because there is so much > impl in the spec. > But JSF is a good example where it isn't needed. > > In the the JSF applications I know there are not much javax.faces imports, > probably only Converters and Validators. > It's getting hard when it comes to custom components. > > Probably for JSF-implementations it would not be a good idea to support > both packages. > So there may be different strategies for impls of different specs. > > -- > Arne Limburg – Enterprise Architect > > > > OPEN KNOWLEDGE GmbH > Poststraße 1, 26122 Oldenburg > Mobil: +49 151 - 108 22 942 > Tel: +49 441 - 4082-154 > Fax: +49 441 - 4082-111 > arne.limb...@openknowledge.de > www.openknowledge.de > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > Geschäftsführer: Lars Röwekamp, Jens Schumann > > Nächste Konferenz: > > Java Forum Nord | Hannover | 24. September 2019 > > Nächste Akademie: > > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019 > > Treffen Sie uns auf weiteren Konferenzen, > Summits und Events: > > Zu unseren weiteren Events > > > > Am 08.05.19, 18:04 schrieb "Thomas Andraschko" < > andraschko.tho...@gmail.com>: > > Not sure about OWB but MyFaces would be alot of work or even not > possible. > So hopefully no impl >must< support both > > Arne Limburg <arne.limb...@openknowledge.de> schrieb am Mi., 8. Mai > 2019, > 17:48: > > > Mark, > > > > I'll take your branch and check, how much effort it would be to > support > > both packages at the same time. > > > > -- > > Arne Limburg – Enterprise Architect > > > > > > > > OPEN KNOWLEDGE GmbH > > Poststraße 1, 26122 Oldenburg > > Mobil: +49 151 - 108 22 942 > > Tel: +49 441 - 4082-154 > > Fax: +49 441 - 4082-111 > > arne.limb...@openknowledge.de > > www.openknowledge.de > > > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > > Geschäftsführer: Lars Röwekamp, Jens Schumann > > > > Nächste Konferenz: > > > > Java Forum Nord | Hannover | 24. September 2019 > > > > Nächste Akademie: > > > > API, Microservices & DDD Summit | München | 17. - 19. Juni 2019 > > > > Treffen Sie uns auf weiteren Konferenzen, > > Summits und Events: > > > > Zu unseren weiteren Events > > > > > > > > Am 08.05.19, 17:38 schrieb "Mark Struberg" <strub...@yahoo.de.INVALID > >: > > > > I'd say we do branches and continue with jakarta.*. > > The current OWB release is very stable and fast. So I don't > expect > > many changes. > > > > > > > > > https://github.com/struberg/openwebbeans/blob/jakarta/webbeans-impl/src/main/java/org/apache/webbeans/container/BeanManagerImpl.java#L37 > > > > Done that on last friday already :) > > > > LieGrue, > > strub > > > > > > > > > Am 08.05.2019 um 14:21 schrieb Arne Limburg < > > arne.limb...@openknowledge.de>: > > > > > > Hi all, > > > > > > Being at the JAX conference now, I am quite oftenly confronted > with > > the javax vs. Jakarta discussion. > > > Besides that it is not clear how to handle that at the API > level > > (btw. Good blog entries, David and Mark), I am thinking of how it > could be > > handled at implementation level. > > > My preferred solution would be the complete separation of Java > EE > > APIs (with javax packages) and Jakarta EE APIs (with jakarta > packages) > > > and having the implementation support both. The question is, > are we > > able to handle this without much code change? > > > > > > My first idea was to define an own set of interfaces like > > > public interface Bean<T> extends > > javax.enterprise.inject.spi.Bean<T>, > jakarta.enterprise.inject.spi.Bean<T> { > > > … > > > } > > > We could then use this interface as return value for or > interfaces > > whereever Bean is the return value in specification interfaces. > > > > > > The only problem I see with this approach seems to be with > > Collection return values and generics, i.e. > > javax.enterprise.inject.spi.Bean#getInjectionPoints() returns a > > Set<javax.enterprise.inject.spi.InjectionPoint> and > > jakarta.enterprise.inject.spi.Bean#getInjectionPoints() would return > a > > Set<jakarta.enterprise.inject.spi.InjectionPoint>. In an ideal world > our > > common interface would return a > Set<org.apache.openwebbeans.InjectionPoint> > > where org.apache.openwebbeans.InjectionPoint extends the other > > InjectionPoints. But that does not work for generics. > > > Regarding parameters the solution would be to have both > methods and > > call one from the other, wrapping the parameter, which most probably > should > > work out. > > > > > > Any ideas/opinions on that? > > > > > > Cheers, > > > Arne > > > > > > -- > > > Arne Limburg – Enterprise Architect > > > > > > > > > OPEN KNOWLEDGE GmbH > > > Poststraße 1, 26122 Oldenburg > > > Mobil: +49 151 - 108 22 942 > > > Tel: +49 441 - 4082-154 > > > Fax: +49 441 - 4082-111 > > > arne.limb...@openknowledge.de > > > www.openknowledge.de <https://www.openknowledge.de/> > > > > > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > > > Geschäftsführer: Lars Röwekamp, Jens Schumann > > > > > > Nächste Konferenz: > > > > > > Java Forum Nord | Hannover | 24. September 2019 < > > https://www.openknowledge.de/event/java-forum-nord/> > > > > > > Nächste Akademie: > > > > > > API, Microservices & DDD Summit | München | 17. - 19. Juni > 2019< > > https://www.openknowledge.de/event/at-api-und-microservises-summit/> > > > > > > Treffen Sie uns auf weiteren Konferenzen, > > > Summits und Events: > > > > > > Zu unseren weiteren Events<https://www.openknowledge.de/event/ > > > > > > > > > > > > > > > > > > > > > > > > >
