[
https://issues.apache.org/jira/browse/HDDS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16578450#comment-16578450
]
Allen Wittenauer commented on HDDS-341:
---------------------------------------
bq. Is it a problem with binary or source distribution
Both.
bq. Not sure if it's a problem to include some ozone specific source in a
hadoop source releases.
[TBF: Officially, the only ASF release is the source release. The rest are
considered 'convenience artifacts'. While I disagree with the letter of the
law, that's what it is.]
In order to fix the Hadoop source distribution, I'm fairly certain that the
ozone dirs and related source will almost certainly need to be re-arranged. It
doesn't make a lot of sense to me to release an ozone source distribution that
won't even be close to matching what trunk looks like organizationally.
The binary release also has a pretty big issue: the maven dependencies are such
that ozone's jars will depend upon 3.2.0-SNAPSHOT. From a maven repository
view of the world, this is extremely problematic. Doing a maven deploy in just
the ozone dirs means that the poms will point to non-existent dependencies.
Doing a maven deploy at the root of hadoop means pushing a 3.2.0-SNAPSHOT
release onto somewhere official and I have no idea what the impact of that
would be. Specifically:
* is that different than what
https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-trunk-Commit/ does?
* will those jars get overridden by that job?
* what if they don't get overridden and all maven builds for 3.2.0 are horribly
broken until the official release?
* what if they do get overridden in a subtle, incompatible way and now ozone
jars are broken?
The only way out that I can see is:
a) move everything to parent ozone dir (just to make things easier)
b) change the pom for that to be non-relative and tie it directly to 3.1.1 or
some other released hadoop-project pom prior to release
I have a hunch though that the first release of ozone in a maven dependency
context might be effectively blocked for 3.2.0 hadoop release though. It just
depends upon what changes from trunk that are coming from outside of its source
tree it requires.
> HDDS/Ozone bits are leaking into Hadoop release
> -----------------------------------------------
>
> Key: HDDS-341
> URL: https://issues.apache.org/jira/browse/HDDS-341
> Project: Hadoop Distributed Data Store
> Issue Type: Bug
> Components: Ozone Manager
> Reporter: Anu Engineer
> Priority: Blocker
> Fix For: 0.2.1
>
>
> [~aw] in the Ozone release discussion reported that Ozone is leaking bits
> into Hadoop. This has to be fixed before Hadoop 3.2 or Ozone 0.2.1 release.
> I will make this a release blocker for Ozone.
>
> {noformat}
> >Has anyone verified that a Hadoop release doesn't have _any_ of the extra
> >ozone bits that are sprinkled outside the maven modules?
> [aengineer] : As far as I know that is the state, we have had multiple Hadoop
> releases after ozone has been merged. So far no one has reported Ozone bits
> leaking into Hadoop. If we find something like that, it would be a bug.
> [aw]: There hasn't been a release from a branch where Ozone has been merged
> yet. The first one will be 3.2.0. Running create-release off of trunk
> presently shows bits of Ozone in dev-support, hadoop-dist, and elsewhere in
> the Hadoop source tar ball.
> So, consider this as a report. IMHO, cutting an Ozone release prior to
> a Hadoop release ill-advised given the distribution impact and the
> requirements of the merge vote.
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
