Details
-
Improvement
-
Status: Closed
-
Trivial
-
Resolution: Fixed
-
0.6
-
None
-
None
Description
It would be nice to be able to obtain the used Mahout version through the Java API. This enables users to output the version information for debugging purposes or simple to document which Mahout version is used.
Attachments
Attachments
- MAHOUT-875.patch
- 4 kB
- Oliver B. Fischer
Issue Links
- relates to
-
MAHOUT-670 Provide a performance measurement framework for Mahout
- Closed
-
MAHOUT-892 Allow to obtain used Mahout version via ./bin/mahout
- Closed
Activity
Patch applies cleanly, however I do not quite get how this is supposed to work. It seems like the patch adds support for generating version information as part of the maven build cycle? Which maven command do I need to issue to do this generation? Do you plan to also add integration of this into the ./bin/mahout script?
That is right. I use the usual ways Maven processes resources and substitutes parameters. Currently MahoutVersion.java contains only a placeholder like public final static String VERSION = "${project.version}";. Maven will replace it by the version value in the POM.
Of cource, I can apply this solution also to the ./bin/mahout script. Would it be engough to add support for an option --version which forces the script to output a string like Apache Mahout xyz?
Of course, I can apply this solution also to the ./bin/mahout script. Would it be enough to add support for an option --version which forces the script to output a string like Apache Mahout xyz?
That seems like plenty for now. We can add a resource and version API later if people want it in addition.
Also, I believe that Package in the context of maven already provides something like that in the jar meta-data.
I will provide a new patch within the next days with support for ./bin/mahout.
What about adding ${project.version} to driver.classes.props? This way you can get the version via MahoutDriver, which loads this file.
I had a rough look at driver.classes.props and it seems that this properties has an different use. It seems so, that is is only used to translate message keys into a more meaningfull string.
Sure. But it is reasonable to have a message key that translates into the version string.
I can add it to driver.classes.props without any problem.
Applying the same mechanism to the ./bin/mahout script and to driver.classes.props means to move the to the directories for resources. This is easily done for the driver.classes.props but not for the script. This would require a much more radical change to the build infrastructure.
The driver.classes.default.props file (renamed from driver.classes.props by the ant-run plugin) may not be a good location after all since it won't be used if there is a user provided driver.classes.props on the classpath.
Maybe a 'version' program with a version.props file? This way you can run 'bin/mahout version' and the script does not need to be filtered or modified.
I would like to create a second separate issue for adding the version information to the ./bin/mahout script since it requires more effort than adding the same information to the Java API. Any objections?
No problem - go ahead and move the discussion on adding the version number information to the shell script to a new issue.
I just created MAHOUT-892. This issue addresses the requested changes to the mahout script below bin.
This version of the patch adds also a version string to driver.classes.props.
To test the patch simply enter the directory core and enter mvn compile. The patch enhences the POM to copy the MahoutVersion.java file to target\generated-sources\version. While copying the file, Maven replaces all known properties in the file.
driver.classes.props contains now the key org.apache.mahout.version. It is set to the value of project.version. To replace the property by its value, I use the filterchain feature of Ant.
driver.classes.props contains now the key org.apache.mahout.version. It is set to the value of project.version. To replace the property by its value, I use the filterchain feature of Ant.
It would be better to not depend on ant and use the property replacement capabilities of Maven. In particular, resources already get this treatment by default so you can put references to the properties you care about in a resource and simply read that resource when you want the version info.
In addition, the version of Mahout is to be found in the META-INF directory in the jar. This allows this code to get the desired version. Resources can also be used.
Here is sample code:
public class Version { public static String version() { return Version.class.getPackage().getImplementationVersion(); } public static String versionFromResource() throws IOException { return Resources.toString(Resources.getResource("version"), Charsets.UTF_8); } }
Unfortunately, the standard method based on Package.getImplementationVersion will not work with our current job jar because of some non-standardness in the build process. It does work on the mahout-core jar itself. Also, it doesn't work in debugging since it depends on META-INF appearing in the right jar.
The resources approach will work regardless of how the code is packaged. To interpolate variables into a resource, the following needs to be added to the pom:
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
This should be added to the <build> element.
The following needs to be put into a file in core/src/main/resources/version
${project.version}
See also
http://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html
http://docs.oracle.com/javase/7/docs/technotes/guides/versioning/spec/versioning2.html#wp89936
http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
@Ted: I will overhaul the patch and resubmit it in some days.
I provided a new version of the patch which takes Teds suggestions into consideration.
This looks simple and sweet to me.
It works my having maven insert the version into a resource and then a method method reads the resource.
It doesn't give information about included libraries, but knowing the Mahout version should give you that.
Integrated in Mahout-Quality #1283 (See https://builds.apache.org/job/Mahout-Quality/1283/)
MAHOUT-875 - Added version object with associated resource.
tdunning : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1225885
Files :
- /mahout/trunk/core/src/main/java/org/apache/mahout/Version.java
- /mahout/trunk/core/src/main/resources/version
- /mahout/trunk/pom.xml
This patch illustrates how the Maven version information could be used to provide it via the Java API of Mahout.