[
https://issues.apache.org/jira/browse/HADOOP-7368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047301#comment-13047301
]
Alejandro Abdelnur commented on HADOOP-7368:
--------------------------------------------
IMO, the current mechanism brings obscurity/complexity to the build process.
And if you open a JAR, replace a file, and reJAR, then you know you are doing
something funny. (And you could do that with the annotation class as well)
> Mechanism for providing version info of hadoop jars
> ---------------------------------------------------
>
> Key: HADOOP-7368
> URL: https://issues.apache.org/jira/browse/HADOOP-7368
> Project: Hadoop Common
> Issue Type: Improvement
> Components: build
> Affects Versions: 0.23.0
> Reporter: Luke Lu
> Assignee: Luke Lu
> Fix For: 0.23.0
>
>
> In 0.20.x, only one jar (hadoop-core-*.jar) really matters. The
> o.a.h.util.VersionInfo combined with saveVersion.sh script (generating a
> package level annotation) served us well. For 0.23+, due to the project split
> and modularization of mapreduce (currently in MR-279), a lot more essential
> hadoop jars are created. The potential of mixing up the jars is significantly
> increased as well. We need a simple way to list the version info (version,
> branch, source checksum etc.) for all the jars involved. This is essential
> for QE and tracking down various issues.
> I propose that we use a VersionProvider interface (similar to the current
> VersionInfo util class) and ServiceLoader to enumerate the version providers
> in the jars.
> {code}
> public interface VersionProvider {
> String getJar();
> String getPackage();
> String getVersion();
> String getRevision();
> String getBranch();
> String getDate();
> String getUrl();
> String getSourceChecksum();
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
