Hi Hong,
I have a couple comments, in context below...
You may wonder why I am being so nit-picky about this, especially so
early. Well the reason is to help early adopters.
Folks that use the dev build of NetBeans will soon start to create apps
that target GlassFish Server 3.1 builds.
NetBeans helps folks create the vendor specific dtds (like the ones we
are talking about now).
If NetBeans helps folks create the right DD file content right now, we
can change the DTDs that are for GlassFish Server 3.1 all we want... and
that aspect of their apps will be right and stay right as we develop the
features of GlassFish Server 3.1.
vbk
Hong Zhang wrote:
> Hi, Vince
>> I think we ought to go back to my original questions for guidance...
>>
>> Are these 'new dtds' going to become acceptable to GlassFish
>> Application Server 3.0? When and how?
> No, they won't.
>> If they are not going to be accepted by 3.0, should their doctype
>> imply that they are acceptable to GlassFish Server 3.0?
> Does the "Glasfish Server 3.0" have to mean acceptable by Glassfish
> Server 3.0, can it be interpreted as these dtds were converted from
> Glassfish 3.0 dtds? :-)
It could be interpreted that way. I think that interpretation is a new
one, compared to the way the doctype has been treated in past
releases... (though it is hard to tell, since the sun-*.dtd files did
not start to include the doctype info until recently [sjsas 9.0 timeframe])
There is additional evidence regarding the evolution of the public ID in
this file...
http://hg.netbeans.org/main-golden/annotate/c8a16871da49/j2ee.sun.appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/RunTimeDDCatalog.java
> [snip]
>> Regarding the 'versioning' of the glassfish dtd files:
>> I think we might want to also be guided by the following fact, as we
>> think about the 'version' of the glassfish-* descriptors:
>> There is no existing version of these descriptors...
>>
>> They will not exist until the folks start to create apps that target
>> 3.1 specifically.
>>
>> We could just as easily do this conversion
>>
>> sun-web-app_3_0-0.dtd --> glassfish-web-app_1_0-0.dtd
> But in the past, the version of the sun-* always match with the
> version of standard deployment descriptors, will it be too confusing
> if we just start from beginning now?
I agree with you on this one... I was just trying to make a point that
there is no existing version... we are at a clean slate moment with the
glassfish-* descriptors and their dtds.
>> (or even glassfish-web-app_3_1-0.dtd)
> I don't think it should be glassfish-web-app_3_1-0.dtd, I think the
> first two numbers mean spec version, unless there is a revision of
> Servlet Spec 3.0 for this release, we should keep the "3_0" part, and
> possibly change the last "0" to "1" if we want to increment version
> here: glassfish-web-app_3_0-1.dtd.
Why do we want to increment from non-existence to "1", when in the past
we have incremented from non-existence to "0"?
Having a glassfish-web-app_3_0-1 will lead to the question... where is
glassfish-web-app_3_0-0.dtd?
I think this also applies to glassfish-ejb-jar_3_1-1.dtd, too?
If it does not make sense to define the dtd contained in the file
glassfish-ejb-jar_3_1-0.dtd, why not put the content of the file
glassfish-ejb-jar_3_1-1.dtd into the file named
glassfish-ejb-jar_3_1-0.dtd...
>
> Thanks,
>
> - Hong