I want to give all the "BOM heads" an FYI that the Fedora Java SIG is currently selecting artifacts to use to create the RPMs that correspond to the "official implementation" of each Java EE API [1]. Much like the JBoss specs, these RPM packages will become the official "headers" for any Java packages that rely on Java EE APIs. Here's an example: https://apps.fedoraproject.org/packages/cdi-api The JBoss community, several members in particular (Shelly, Pete, Karel, etc), have put in a lot of effort to groom and curate a set of Java EE API JARs. I'd hate to see that effort passed up in Fedora. Take note of the criteria that Stanislav mentions below to determine which artifact to use to create the API package for each spec (# of dependencies is a primary concern). If you'd like to participate in this decision, feel free to submit feedback in the #fedora-java IRC channel or the fedora-devel(a)lists.fedoraproject.org list (or contact your local representative, i.e., Marek or Carlo, hehehe). If you need some motivation as to why you want to get involved, here's a preview of some of the artifacts that have been selected. Note that few are from the JBoss specs: • ... • javax.el - tomcat-el-2.2-api • javax.enterprise.inject - cdi-api • javax.inject - atinject • .. • javax.persistence - geronimo-jpa • javax.security.auth.message - geronimo-jaspic-spec • javax.servlet - tomcat-servlet-3.0-api • javax.servlet.jsp - glassfish-jsp/glassfish-jsp-api • javax.servlet.jsp.jstl - jakarta-taglibs-standard Now is the time to have this conversation. It's a "speak now or hold your peace" sort of thing. -Dan [1] https://admin.fedoraproject.org/mailman/private/java-devel/2012-June/0044... -------- Original Message -------- Subject: [fedora-java] Chosing implementations for EE APIs and finalizing guidelines Date: Thu, 28 Jun 2012 15:16:57 +0200 From: Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; To: Fedora Java Development <java-devel(a)lists.fedoraproject.org&gt; 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 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. 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. 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... -- Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

I'm not sure I really want to rehash this discussion. The funny bit is JBoss EE artifacts are *not* used, because they are the cleanest and best. :-) The other vendor API artifacts contain hacks tailored to specified servers, so it is going to be an interesting sight. Okay, I'll give it one more shot. Carlo On 07/04/2012 12:29 PM, Pete Muir wrote: > The issue is that the APIs don't have an official implementation (only a reference implementation), nor are they designed to be "mixed and matched" like this. Sounds like a recipe for issues to me. > > The right way to do this is to pick a particular vendors set, and cross your fingers that it will work, unless you can do it properly, and pull it the right API set for the right dependency. > > BTW I don't really understand when this is used, and why it's an issue. Surely packages shouldn't be changing their declared dependencies, and each api impl doesn't share a namespace. > > On 4 Jul 2012, at 01:50, Dan Allen wrote: > >> I want to give all the "BOM heads" an FYI that the Fedora Java SIG is currently selecting artifacts to use to create the RPMs that correspond to the "official implementation" of each Java EE API [1]. Much like the JBoss specs, these RPM packages will become the official "headers" for any Java packages that rely on Java EE APIs. Here's an example: https://apps.fedoraproject.org/packages/cdi-api >> >> The JBoss community, several members in particular (Shelly, Pete, Karel, etc), have put in a lot of effort to groom and curate a set of Java EE API JARs. I'd hate to see that effort passed up in Fedora. Take note of the criteria that Stanislav mentions below to determine which artifact to use to create the API package for each spec (# of dependencies is a primary concern). If you'd like to participate in this decision, feel free to submit feedback in the #fedora-java IRC channel or the fedora-devel(a)lists.fedoraproject.org list (or contact your local representative, i.e., Marek or Carlo, hehehe). >> >> If you need some motivation as to why you want to get involved, here's a preview of some of the artifacts that have been selected. Note that few are from the JBoss specs: >> • ... >> • javax.el - tomcat-el-2.2-api >> • javax.enterprise.inject - cdi-api >> • javax.inject - atinject >> • .. >> • javax.persistence - geronimo-jpa >> • javax.security.auth.message - geronimo-jaspic-spec >> • javax.servlet - tomcat-servlet-3.0-api >> • javax.servlet.jsp - glassfish-jsp/glassfish-jsp-api >> • javax.servlet.jsp.jstl - jakarta-taglibs-standard >> Now is the time to have this conversation. It's a "speak now or hold your peace" sort of thing. >> >> -Dan >> >> [1] https://admin.fedoraproject.org/mailman/private/java-devel/2012-June/0044... >> >> >> -------- Original Message -------- >> Subject: [fedora-java] Chosing implementations for EE APIs and finalizing guidelines >> Date: Thu, 28 Jun 2012 15:16:57 +0200 >> From: Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; >> To: Fedora Java Development <java-devel(a)lists.fedoraproject.org&gt; >> >> 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 >> >> 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. >> >> 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. >> >> 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... >> >> >> -- >> Stanislav Ochotnicky >> <sochotnicky(a)redhat.com&gt; >> >> Software Engineer - Base Operating Systems Brno >> >> PGP: 7B087241 >> Red Hat Inc. >> http://cz.redhat.com >> >> >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev

Basically Fedora maintainers want to have a single version of everything.

So this would mean that (Fedora) AS 7 would build & run with those API artifacts.

Unless a pom explicitly specifies a jboss-spec artifact and Marek decides to package those in the regular fashion.

So having a dependency on javax.enterprise:cdi-api would place you in the shit house. ;-)

Carlo On 07/05/2012 01:38 PM, Pete Muir wrote: > I'm not really understanding who the target of these apis are? Will they be used by end users? Or only by people making rpms for fedora? > > On 5 Jul 2012, at 08:14, Carlo de Wolf wrote: > >> I'm not sure I really want to rehash this discussion. >> >> The funny bit is JBoss EE artifacts are *not* used, because they are the cleanest and best. :-) >> >> The other vendor API artifacts contain hacks tailored to specified servers, so it is going to be an interesting sight. >> >> Okay, I'll give it one more shot. >> >> Carlo >> >> On 07/04/2012 12:29 PM, Pete Muir wrote: >>> The issue is that the APIs don't have an official implementation (only a reference implementation), nor are they designed to be "mixed and matched" like this. Sounds like a recipe for issues to me. >>> >>> The right way to do this is to pick a particular vendors set, and cross your fingers that it will work, unless you can do it properly, and pull it the right API set for the right dependency. >>> >>> BTW I don't really understand when this is used, and why it's an issue. Surely packages shouldn't be changing their declared dependencies, and each api impl doesn't share a namespace. >>> >>> On 4 Jul 2012, at 01:50, Dan Allen wrote: >>> >>>> I want to give all the "BOM heads" an FYI that the Fedora Java SIG is currently selecting artifacts to use to create the RPMs that correspond to the "official implementation" of each Java EE API [1]. Much like the JBoss specs, these RPM packages will become the official "headers" for any Java packages that rely on Java EE APIs. Here's an example: https://apps.fedoraproject.org/packages/cdi-api >>>> >>>> The JBoss community, several members in particular (Shelly, Pete, Karel, etc), have put in a lot of effort to groom and curate a set of Java EE API JARs. I'd hate to see that effort passed up in Fedora. Take note of the criteria that Stanislav mentions below to determine which artifact to use to create the API package for each spec (# of dependencies is a primary concern). If you'd like to participate in this decision, feel free to submit feedback in the #fedora-java IRC channel or the fedora-devel(a)lists.fedoraproject.org list (or contact your local representative, i.e., Marek or Carlo, hehehe). >>>> >>>> If you need some motivation as to why you want to get involved, here's a preview of some of the artifacts that have been selected. Note that few are from the JBoss specs: >>>> • ... >>>> • javax.el - tomcat-el-2.2-api >>>> • javax.enterprise.inject - cdi-api >>>> • javax.inject - atinject >>>> • .. >>>> • javax.persistence - geronimo-jpa >>>> • javax.security.auth.message - geronimo-jaspic-spec >>>> • javax.servlet - tomcat-servlet-3.0-api >>>> • javax.servlet.jsp - glassfish-jsp/glassfish-jsp-api >>>> • javax.servlet.jsp.jstl - jakarta-taglibs-standard >>>> Now is the time to have this conversation. It's a "speak now or hold your peace" sort of thing. >>>> >>>> -Dan >>>> >>>> [1] https://admin.fedoraproject.org/mailman/private/java-devel/2012-June/0044... >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: [fedora-java] Chosing implementations for EE APIs and finalizing guidelines >>>> Date: Thu, 28 Jun 2012 15:16:57 +0200 >>>> From: Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; >>>> To: Fedora Java Development <java-devel(a)lists.fedoraproject.org&gt; >>>> >>>> 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 >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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... >>>> >>>> >>>> -- >>>> Stanislav Ochotnicky >>>> <sochotnicky(a)redhat.com&gt; >>>> >>>> Software Engineer - Base Operating Systems Brno >>>> >>>> PGP: 7B087241 >>>> Red Hat Inc. >>>> http://cz.redhat.com >>>> >>>> >>>> _______________________________________________ >>>> jdf-dev mailing list >>>> jdf-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>

On 05.07.2012 15:07, Pete Muir wrote: > > On 5 Jul 2012, at 13:58, Carlo de Wolf wrote: > >> Basically Fedora maintainers want to have a single version of >> everything. > > So do I, doesn't meant it's reality ;-) > > Anyway, I guess as long as they do understand that it's not true that > just because the class name and the package name, it doesn't mean the > code name is the same, and there are real differences in impl between > the various API jars, and are willing to take the risk that by > imposing this rule on the code, they may well break stuff, then I > don't really have an objection, personally. Obviously, it seems a > somewhat crazy thing to do, as all the good testing work done on the > upstream version of the app server is undone. I know that, for > example, it could introduce a major performance impact, as one > version of el-api that is floating around has some bad locking in it, > that we fix in the jboss-spec artifacts. In fact, if there is an implementation of an API, the resulting code should do the same. That's theory, of course :)

You raised a good point about testing/performance, but as long, as we use our implementations (which are packaged already for Fedora), we're good. > Anyway, as you say, the least evil way to do this would be to pick > *one* set of the artifacts, so at least things are consistent. E.g. > geronimo, or jboss should be quite ok, and certainly better than the > Oracle ones. +10 Building Sun/Oracle implementations is a nightmare... But there are still a few which we rely on, for example jaxb. This was truly a nightmare, to package... >> So this would mean that (Fedora) AS 7 would build & run with those >> API artifacts. > > Got it, thanks for clarifying. > > I know with JSF for example you *must* run with the right version of > the API jar for your JSF impl. OTOH CDI should be ok with any > version. IOW it's all a little random. > >> Unless a pom explicitly specifies a jboss-spec artifact and Marek >> decides to package those in the regular fashion. > > Presumably all of JBoss AS does specifically specify jboss-spec > artitfacts? JBoss AS 7 - (mostly?) yes, JBoss AS 7 deps - no. There is no standardization on our own Java EE implementations (requiring servlet vs. our specific implementation). Some of projects are still using old org.jboss.javae:jboss-javaee stuff and so on. We need to be aware that we're not talking here about AS7 runtime only, we're talking about the whole build time AND runtime dependency set. This makes things more exciting :)

--Marek >> So having a dependency on javax.enterprise:cdi-api would place you >> in the shit house. ;-) > > It looks like that is included, from Dan's list? > >> >> Carlo >> >> On 07/05/2012 01:38 PM, Pete Muir wrote: >>> I'm not really understanding who the target of these apis are? >>> Will they be used by end users? Or only by people making rpms for >>> fedora? >>> >>> On 5 Jul 2012, at 08:14, Carlo de Wolf wrote: >>> >>>> I'm not sure I really want to rehash this discussion. >>>> >>>> The funny bit is JBoss EE artifacts are *not* used, because >>>> they are the cleanest and best. :-) >>>> >>>> The other vendor API artifacts contain hacks tailored to >>>> specified servers, so it is going to be an interesting sight. >>>> >>>> Okay, I'll give it one more shot. >>>> >>>> Carlo >>>> >>>> On 07/04/2012 12:29 PM, Pete Muir wrote: >>>>> The issue is that the APIs don't have an official >>>>> implementation (only a reference implementation), nor are >>>>> they designed to be "mixed and matched" like this. Sounds >>>>> like a recipe for issues to me. >>>>> >>>>> The right way to do this is to pick a particular vendors set, >>>>> and cross your fingers that it will work, unless you can do >>>>> it properly, and pull it the right API set for the right >>>>> dependency. >>>>> >>>>> BTW I don't really understand when this is used, and why it's >>>>> an issue. Surely packages shouldn't be changing their >>>>> declared dependencies, and each api impl doesn't share a >>>>> namespace. >>>>> >>>>> On 4 Jul 2012, at 01:50, Dan Allen wrote: >>>>> >>>>>> I want to give all the "BOM heads" an FYI that the Fedora >>>>>> Java SIG is currently selecting artifacts to use to create >>>>>> the RPMs that correspond to the "official implementation" >>>>>> of each Java EE API [1]. Much like the JBoss specs, these >>>>>> RPM packages will become the official "headers" for any >>>>>> Java packages that rely on Java EE APIs. Here's an example: >>>>>> https://apps.fedoraproject.org/packages/cdi-api >>>>>> >>>>>> The JBoss community, several members in particular (Shelly, >>>>>> Pete, Karel, etc), have put in a lot of effort to groom and >>>>>> curate a set of Java EE API JARs. I'd hate to see that >>>>>> effort passed up in Fedora. Take note of the criteria that >>>>>> Stanislav mentions below to determine which artifact to use >>>>>> to create the API package for each spec (# of dependencies >>>>>> is a primary concern). If you'd like to participate in this >>>>>> decision, feel free to submit feedback in the #fedora-java >>>>>> IRC channel or the fedora-devel(a)lists.fedoraproject.org >>>>>> list (or contact your local representative, i.e., Marek or >>>>>> Carlo, hehehe). >>>>>> >>>>>> If you need some motivation as to why you want to get >>>>>> involved, here's a preview of some of the artifacts that >>>>>> have been selected. Note that few are from the JBoss >>>>>> specs: • ... • javax.el - tomcat-el-2.2-api • >>>>>> javax.enterprise.inject - cdi-api • javax.inject - >>>>>> atinject • .. • javax.persistence - geronimo-jpa • >>>>>> javax.security.auth.message - geronimo-jaspic-spec • >>>>>> javax.servlet - tomcat-servlet-3.0-api • javax.servlet.jsp >>>>>> - glassfish-jsp/glassfish-jsp-api • javax.servlet.jsp.jstl >>>>>> - jakarta-taglibs-standard Now is the time to have this >>>>>> conversation. It's a "speak now or hold your peace" sort of >>>>>> thing. >>>>>> >>>>>> -Dan >>>>>> >>>>>> [1] >>>>>> https://admin.fedoraproject.org/mailman/private/java-devel/2012-June/0044... >>>>>> >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: [fedora-java] Chosing implementations for EE APIs >>>>>> and finalizing guidelines Date: Thu, 28 Jun 2012 15:16:57 >>>>>> +0200 From: Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; >>>>>> To: Fedora Java Development >>>>>> <java-devel(a)lists.fedoraproject.org&gt; >>>>>> >>>>>> 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 >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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... >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; >>>>>> >>>>>> Software Engineer - Base Operating Systems Brno >>>>>> >>>>>> PGP: 7B087241 Red Hat Inc. http://cz.redhat.com >>>>>> >>>>>> >>>>>> _______________________________________________ jdf-dev >>>>>> mailing list jdf-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>> >> >> >