Kin-man Chung wrote:
> There are a
>> couple of things to fix in jsp project:
>> Api and imlementation go together. You seem to be promoting them
>> differently. You should really be producing one bundle which has both
>> api and implementation just like JavaMail bundle is done. I repeat,
>> nobody should be able to use an api jar without the api
>> implementation unless they are just compiling some code. So, why
>> promote them separately as runtime artifacts. In fact, I see in jsp
>> project, they are evolving in their own pace and hence you have some
>> version range settings in place. Why do we need such complexity?
>
> I totally disagree. JSP api is a javaee api, and as such, any other
> vendor can supply its own implementation. By separating the api from
> the implementation, we are encouraging other vendors to use our api.
> Otherwise what's the point of the separation? This has been the case
> with the past versions of servlet and JSP.
There is no need to separate other than breaking build dependencies.
Other Java EE vendors should maintain their own APIs or use our API and
implementation together. As I said, look at the way JavaMail is done.
There is a misunderstanding by many of our GlassFish developers that
Java EE APIs can be used standalone. No, they can't be. They are always
accompanied by an implementation. Many of the APIs also know about
implementation details. e.g., many Java EE APIs have a static factory
method to create a root object and those APIs fallback to an
implementation class if user has not configured to use a different
implementation. e.g., look at SAXParserFactory.newInstance method:
http://java.sun.com/javase/6/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance()
>
>>
>> Secondly, the groupId of the api artifact does not convey the fact
>> that jsp project has generated the artifact.
>>
> The group for the jsp-api is javax.servlet.jsp, as it should be. This
> makes it easier for people outside of Sun to find it in the repo, and
> encourage reuse. Shouldn't the API be vendor neutral?
>
It's not as if JCP is publishing is these API jars. JCP is publishing
only the spec and the .class is generated by some java.net project.
> There is a discussion going on now (with Bill, Roberto, and Jerome etc)
> to use javax.* as a group-id for other javaee api's. It is generally
> believed to be a good idea, though we won't necessarily do it right-
> away.
>
I am surprised we are having this discussion yet again. Exactly an year
back, I had had this discussion with the exactly the same set of folks
and we came to the conclusion of using org.glassfish as groupId and
primary package name (e.g., javax.ejb) as the artifactId for any API jar
produced by GlassFish project. If someone is changing the decision and
not keeping me in loop, I can't help. One thing I want to tell is that
maven coordinates for an artifact does not include repository it comes
from. So, if every appserver project like JBoss, Geronimo, GlassFish
start using javax.servlet as groupdId and servlet-api as artifactId,
then developers will find multiple varying copies of these API jars in
various maven repositories and they will be confused.
Thanks,
Sahoo