Shouldn't the version information be in the manifest for the jar file containing the classes, accessed via java.lang.Package?
Roman Grigoriadi wrote on 05/ 3/17 09:49 AM: > Hi, > > you can find new web rev here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > <http://cr.openjdk.java.net/%7Eaefimov/jaxws-integrations/8176508/01/> > > Previous review comments are addressed. > >> The change to version.properties reminds me to ask if there is anything in >> the jaxws repo to indicate the version of the JAX-* components? It's often >> difficult to determine what bits are in the JDK vs. the upstream project. > > Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we > are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example > in > jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties > There is: > # for JDK integration - include version in source zip > jaxb.jdk.version=2.3.0-b170412.1723 > > We can add another version.properties file with versions of all JAX-* > components. We may also change version from 2.3.0-SNAPSHOT to something unique > like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. > > Roman > > >> On 12 Mar 2017, at 16:14, Alan Bateman <alan.bate...@oracle.com >> <mailto:alan.bate...@oracle.com>> wrote: >> >> >> >> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>> Hi, >>> >>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >>> <http://cr.openjdk.java.net/%7Eaefimov/jaxws-integrations/8176508/00/> >>> >> I skimmed the changes and have a few comments (I'm sure Lance or someone else >> will do a more detailed review). >> >> In JAXBContext then "must be open to the java.xml.bind module" should be >> "must be open to at least the java.xml.bind module" so as to cover the case >> that the package is opened unconditionally or to java.xml.bind and other >> modules. In addition, include "at least" makes it consistent with other >> wording that we have agreed for other areas. >> >> In MailcapCommandMap then the following doesn't seem right for the class >> description: >> >> 59 * (Where <i>java.home</i> is the value of the "java.home" System >> property >> 60 * and <i>conf</i> is the directory named "conf" if it exists, >> 61 * otherwise the directory named "lib"; the "conf" directory was >> 62 * introduced in JDK 1.9.) >> >> It might be simpler to just have javadoc specify that it attepts to locate >> the `mailcap` file in the Java run-time image and then add an @implNote with >> the details as to where it looks for specific runtime releases. >> >> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's >> use in new code has been discouraged for many years and maybe this could >> start out using String.split rather than the legacy class. >> >> The change to version.properties reminds me to ask if there is anything in >> the jaxws repo to indicate the version of the JAX-* components? It's often >> difficult to determine what bits are in the JDK vs. the upstream project. >> >> -Alan >
