castor-data-binding / castor

http://castor-data-binding.github.io/castor/
35 stars 29 forks source link

Generated code shows wrong castor version in comments #49

Closed aner-perez closed 8 years ago

aner-perez commented 8 years ago
/*
 * This class was automatically generated with
 * <a href="http://www.castor.org">Castor 1.3.3</a>, using an XML
 * Schema.
 * $Id$
 */

This was generated from Castor 1.4.1-SNAPSHOT from GitHub even though it says 1.3.3 in the generated comment. Looks like xml/src/main/java/org/exolab/castor/util/Version.java has not been manually updated to reflect the current Castor version.

These changes modify the maven build so filtering is performed on xml/src/main/resources/META-INF/MANIFEST.MF (to set the correct version number) and Version.java is updated to set the static VERSION field to the value read from the MANIFEST.MF file (should happen once at class load time)

wguttmn commented 8 years ago

There's actually two relevant files, Version.java and VERSION. During very old Ant builds (years ago), those files needed to be updated manually before a release.

You change definitely is a step forward, but personally I think that the version number from the Maven POM should be used.

wguttmn commented 8 years ago

Btw, I temp. switched back the version of the Castor Maven plugin to 2.1, so build shouldnot fail anymore (Travis).

aner-perez commented 8 years ago

These changes actually end up doing just that (using the maven version).

parent/pom.xml already sets the VERSION property to ${project.version} and the existing xml/src/main/resources/META-INF/MANIFEST.MF already had placeholders using the VERSION

The only changes that needed to happen was for maven to do the actual string replacements on the MANIFEST.MF file and to actually use the value in Version.java

This code does not use the etc/VERSION file, only the version defined in the parent/pom.xml

wguttmn commented 8 years ago

Just pushed a commit that takes your coder changes above and build on top of them