On Fri, Jan 8, 2016 at 9:49 AM, Allen Wittenauer <[email protected]> wrote: > >> On Jan 8, 2016, at 5:58 AM, Sean Busbey <[email protected]> wrote: >> >> before I file a ticket, figured I'd do a sanity check. >> >> when maven is using custom repos and in multijdk mode, should we make >> a custom repo per-jdk to ensure that we don't get cross-talk between >> reactor classes made with different jdks or dependencies that might be >> in a jdk-version-activated profile? > > > Have we seen this happening in the wild? Presently, JAVA_HOME is > used for non-multi-jdk tests and when a multi-jdk test is executed, JAVA_HOME > is always the last version executed (it is *ALWAYS* added to the list). So > the state of the local repo cache should be consistent in theory. > > Of course, if multiple runs are happening at the same time, then > instances should be turned on/kicking in to prevent that as well.
hbase has jdk-specific profiles that e.g. change what system dependencies are used, but I don't think anything changes which code goes in to jar. I believe there's no error in our current handling, so long as jdk7 is JAVA_HOME and thus is used to handle the install call for project artifacts (or I guess the oldest jdk to be used, generally). Alternatively, if we could avoid a `mvn install` entirely then we wouldn't have to worry about what goes in to the local repo.
