----- Original Message -----
From: "Carlo de Wolf" <cdewolf(a)redhat.com>
Sent: Thursday, July 5, 2012 10:49:10 AM
Subject: Re: [fedora-java] 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
> 1 implementation for each API.
> I have made initial proposal for these APIs into the draft. My
> 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")
JDK 6 (not applicable here, but case in point))
So these dependencies should be really scrutinized properly and I
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
> being javax.servlet.jsp where I preferred glassfish-jsp over
> 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
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
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
In the end it boils down to: which problems you would like to fix
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.
(and whose help do you want to have/need?)
(Especially the 'have' versus 'need' set might differ largely. :-P )
> 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
> 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
> in them. If you don't like them...speak up. If you don't, you will
> have my sympathies later. So I'll wait a week for comments. I plan
> finalize new guidelines by the end of next week. Then call SIG
> (finally) and vote on it before presenting it to the FPC.
java-devel mailing list