[
https://issues.apache.org/jira/browse/HBASE-24319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099580#comment-17099580
]
Istvan Toth commented on HBASE-24319:
-------------------------------------
To elaborate on the problem (as explained to my by [~busbey] and [~elserj]):
Say you have three profiles:
* _haddop-A_ activeByDefault
* _hadoop-B_
* _release_
As soon as you activate the _release_ profile via any means (be it -P, or some
other activation criterium)
_haddop-A_ will be deactivated, and the build breaks.
So activeByDefault only works if you have exactly one set of mutually exclusive
profiles.
See https://issues.apache.org/jira/browse/MNG-4917 for a worked example.
The activation-by-property method works around this limitation, but it also has
a problem.
If you want to a default profile, you have to duplicate its contents. Say, you
want hadoop-A as default.
In this case you need:
* _default_ activated when hadoop.profile is undefined
* _hadoop-A_ which is IDENTICAL to _default_, activated on hadoop.profile=A
* _hadoop-B_ , activated on hadoop.profile=B
If you use the -P option in conjunction with this setup, you'll have multiple
profiles activated, so
using the above setup with -Phadoop-B will result in both the _default_ and the
_hadoop-B_ profiles
being activated.
See https://issues.apache.org/jira/browse/MNG-4917 on how this is the intended
behaviour, and how
activeByDefault is useless in all but the most trivial cases.
Based on the above my opinion is:
* Using activeByDefault is a non-starter in any real-world project
* If activeByDefault is not used, then -P is usable, but you cannot have a
default profile.
* If want multiple mutually exclusive profiles, with default, then the only
workable solution is
activation by system property, and duplicating the default one.
For our use case this means that something has to give:
* We must drop the hadoop.profile maven profiles in master, and move all config
from 3.0 to the top level. This is my preferred approach, but it will hurt a
bit while backporting changes.
* Or if we want to keep the profiles, but still have a default, we have to use
ugly hacks, like changing the activation parameters to something like
hadoop.profile=breakthebuild for the2.0 profile, and
hadoop.profile!=breakthebuild for the 3.0 profile, which will default to 3.0,
as long as someone doesn't *run maven -Dhadoop.profile=breakthebuild*
> Clearly document how profiles for the sake of Hadoop compatibility work
> across all branches
> -------------------------------------------------------------------------------------------
>
> Key: HBASE-24319
> URL: https://issues.apache.org/jira/browse/HBASE-24319
> Project: HBase
> Issue Type: Task
> Components: build, hadoop2, hadoop3
> Reporter: Josh Elser
> Priority: Major
>
> In HBASE-24280, we investigated a test failure which was ultimately caused by
> the simultaneous activation of the (intended mutually exclusive) hadoop-2 and
> hadoop-3 profiles.
> After master has moved to only supporting profile activation via the profile
> itself (rather than a system property) with the removal of the hadoop-2
> profile, the build was inadvertently broken as all branches (or is it just
> 2.x branches and master?) use the one build/yetus scripts in dev-support.
> To make sure that these scripts continue to work against all branches, we
> need to have a clear decision on how profile activation is expected to work
> in our HBase build. Otherwise, we'll come back to this problem where each
> branch does things ever-so-slightly different, requiring a bunch of {{if
> branch-2; else if branch-2.2; else if branch-2.3}} type changes to our yetus
> scripts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
