Chosing implementations for EE APIs and finalizing guidelines
 

On 06/28/2012 09:16 AM, 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


+1

This should be based on the default JDK version provided by Fedora,
which is currently JDK 7 for Fedora 17 / 18.




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.


+1

# of dependencies is one of the first concerns I heard when I began
telling developers about the JBoss AS package. If they are necessary,
it's reasonable to explain. When a dependency doesn't seem at all
related, people start to develop a bad opinion of the package. It's not
just about disk space, it's also about perception.


-Dan

--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction

--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

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.


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.

Ultimately any API artifact must not have a dependency which is not an
API artifact in itself.


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?
(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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel