----- Original Message ----- > From: "Carlo de Wolf" <cdewolf@xxxxxxxxxx> > To: java-devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Thursday, July 5, 2012 10:49:10 AM > Subject: Re: Chosing implementations for EE APIs and finalizing guidelines > > On 06/28/2012 03:16 PM, Stanislav Ochotnicky wrote: > > With new additions to packaging guidelines for EE APIs, we have to > > pick > > 1 implementation for each API. > > > > I have made initial proposal for these APIs into the draft[1]. My > > criterias: > > 1. if JDK provides it, we are done. Packages should remove this > > dependency from pom.xml files > > The JDK provides certain versions of an API. It may very well be that > the version actually required is incompatible. > (The only example that springs to mind is @Resource(lookup="foo") > with > JDK 6 (not applicable here, but case in point)) > > So these dependencies should be really scrutinized properly and I > would > say even keep them explicitly. Question: Who will/should keep them? My answer: If someone is interested in using such version it's up to him/her. But the people that look at the distro as a whole thing should work on simplifying the dependency graph to make the whole distro easier to maintain even if this proves to be inconvenient for few projects. Aka I would prefer to have a case where we make things better by 1-2% for a hundred(s) packages and 50% worse for 2-3 packages instead of the opposite. > > > > 2. Prefer packages with smaller and simpler BR/R chains. Good > > example > > being javax.servlet.jsp where I preferred glassfish-jsp over > > tomcat > > or other implementations. > > I prefer jboss-jsp-2.2-api. :-) > > Not only BR/R chain should be taken into account, but also state of > javadoc and upstream accessibility. > If we need a change in the JBoss artifacts we can enact them more > readily. BR/R is the only measure we have and it affects the time spend directly. Dead upstreams shouldn't be looked at all of course. But still I will be the first one to propose changing the preferred version to something that has fewer BR/R no matter where it comes from (as long as it's properly licensed!). Btw, if JBoss api packages start building with pure ant they will easily win over all the rest in terms of BR/R in my eyes, (pure make would be even better to reduce cyclic dependencies ;). > > Ultimately any API artifact must not have a dependency which is not > an > API artifact in itself. +1 000 000 One should always remember that BRs are as important for us. > > > > 3. Exception for 2nd point: if the project is proven to be > > difficult in > > the past, override. Example being geronimo projects which were > > overriden few times. > > Recipe for disaster. If a component can't handle a clean API artifact > and we install a 'dirty' one, then we can not expect other components > to > function properly. > > In the end it boils down to: which problems you would like to fix > where? TBH, I still look for the day when one would be able to just build his project without problems. So in terms of EE apis I'm still concerned by buildtime issues especially considering that they are just APIs to compile against and projects that use them at run time usually have explicit dependency on implementation. Alex > (and whose help do you want to have/need?) > (Especially the 'have' versus 'need' set might differ largely. :-P ) > > Carlo > > > > Even when we finalize this list, I don't expect it to be set in > > stone. I > > want it in the guidelines, but if situation arises where quick > > change is > > needed we can still do it. Longer-term, I'd like to package more > > simple > > independent implementations such as glassfish-jsp so we don't have > > dependency for example on tomcat in very basic dependency chain. > > > > > > Now, I'd like to give everyone time to look at my picks and poke > > holes > > in them. If you don't like them...speak up. If you don't, you will > > not > > have my sympathies later. So I'll wait a week for comments. I plan > > to > > finalize new guidelines by the end of next week. Then call SIG > > meeting > > (finally) and vote on it before presenting it to the FPC. > > > > > > > > [1] > > https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#EE_API_List > > > > > -- > java-devel mailing list > java-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/java-devel -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
