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.
> > 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
--
Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
