[fedora-java] Handling of EE apis and other multiple implementations

[Aleksandar Kurtakov]

----- Original Message -----
> From: "Carlo de Wolf" <cdewolf at redhat.com>
> To: java-devel at lists.fedoraproject.org
> Sent: Friday, May 11, 2012 12:57:57 PM
> Subject: Re: [fedora-java] Handling of EE apis and other multiple	implementations
> 
> On 05/11/2012 11:53 AM, Stanislav Ochotnicky wrote:
> > Quoting Aleksandar Kurtakov (2012-05-10 16:55:14)
> >>> Ergo: I would like to propose a standardization on naming and use
> >>> of
> >>> java EE APIs.
> >>>
> >>> There are several aspects of this:
> >>>   1. We need to chose 1 implementation to serve as "THE"
> >>>   implementation
> >>>      for each API.
> >> I propose this being to be the implementation of the latest
> >> version with smallest number of dependencies - both runtime and
> >> build time. This should work pretty well as the packages that can
> >> work with whatever implementation are easy to port to new version
> >> too.
> >>
> > Agreed there. Minimal dependencies are a major selling point for me
> > as
> > well. Unless of course there is some deficiency in the
> > implementation.
> 
> Not all implementations follow the same functionality. In some cases
> defaults are provided within the implementation.

This is supposed to be used only by package that need only the API as defined by some  JSR. All other use cases are hopeless and packages would have to choose what they work with for a number of reasons.

Alex

> 
> Carlo
> >
> >>> So it looks like we are not consistent and I would like to fix
> >>> that.
> >>> My
> >>> first idea was to have:
> >>>
> >>>      Provides: javax.xml
> >>>      ...
> >>>      %files
> >>>      %{_javadir}/javax.xml.jar # this is symlink
> >>>
> >>> Then I realized JSP is "javax.servlet.jsp", and Servlet API is a
> >>> superset so first 2 parts of package name would not be enough
> >>> there.
> >>> We
> >>> could still have:
> >>>
> >>>      Provides: javax.servlet # in servlet impl
> >>> and:
> >>>      Provides: javax.servlet.jsp # in jsp impl
> >>>
> >>> To be clear: I want the names to be simple to deduce without
> >>> going
> >>> through spec files, searching with yum (much) etc. The simpler
> >>> the
> >>> better. I would hope Java devs chime in here. What would be the
> >>> first
> >>> thing that came to your mind here?
> >> This proposal pretty much matches the osgi bundle names see
> >> http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/
> >> javax.activation
> >> javax.annotation
> >> javax.el
> >> javax.inject
> >> javax.jws
> >> javax.mail
> >> javax.management
> >> javax.management.remote
> >> javax.persistence
> >> javax.security.auth.message
> >> javax.servlet
> >> javax.servlet.jsp
> >> javax.servlet.jsp.jstl
> >> javax.transaction
> >> javax.ws.rs
> >> javax.wsdl
> >> javax.xml
> >> javax.xml.bind
> >> javax.xml.rpc
> >> javax.xml.soap
> >> javax.xml.stream
> >> javax.xml.ws
> >>
> >> So sticking close to each other would be even better.
> > Note to all, that we have a working draft[1] for new guidelines.
> > There are
> > a few improvements (better explanation of %add_maven_depmap macro,
> > few
> > more hints here and there), removal of old guideline cruft (mostly
> > maven2 related) and now I've added an initial EE api packaging
> > guideline.
> >
> > See [2] for a diff against current guidelines. Feel free to tweak,
> > add,
> > improve. We can review/fix/revert whatever changes come in later
> > before
> > putting it to a vote during our overdue SIG meeting.
> >
> > One thing I wonder about adding is that each javax.XX providing
> > package
> > should also install additional file which would basically
> > constitute
> > needed classpath to run the implementation (i.e. arguments for
> > build-classpath). For example "glassfish-jsp-api" would need
> > "glassfish-jsp" on the classpath so it would install let's say:
> > %{_javadir}/javax.servlet.jsp.classpath (just an idea)
> > and this would contain:
> > glassfish-jsp
> >
> >>> As for versioning APIs, I am not sure that would be needed. We
> >>> usually
> >>> try to keep packages up to date with latest APIs and packages not
> >>> supporting current API can be moved to an older implementation.
> >> No versions needed for the default. Every package that doesn't
> >> stick to the default should pick implementation on its own or ask
> >> for help to get ported.
> >>
> >> I really like the proposal.
> >
> > [1]
> > https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
> > [2] http://goo.gl/GYrOf
> >
> 
> --
> java-devel mailing list
> java-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel