> On Jun 16, 2017, at 4:46 AM, Christofer Dutz <[email protected]>
> wrote:
>
> In case of a variable for the groupId the warning is the same except that it
> mentions groupId instead of version :-(
Hmm… any thoughts on plausible alternatives? ...and implications to
dev, release, and consumption of java7&android Edgent?
At a high level, something just seems wrong that it’s this hard to
create multiple variants of a product w/mvn, where the variants’
jars need different coordinates along some dimension.
The retrolambda plugin may be complicating things but it doesn't
feel like it’s the cause of the main issue: variable coordinate decls.
Related, without the use of variable-version decls, even ignoring
this j8/j7 thing, there would be <version>1.2.0-SNAPSHOT</version>
throughout every one of our (~65) poms. Even using
variable-version decls, that static decl is present in every pom’s
<parent> decl! Is it the really case that when we want to release
1.2.0 (not SNAPSHOT) or when it’s time for 1.3.0, every pom
has to be edited?
Just brainstorming… my head hurts :-\ I apologize in advance… :-)
E<n> means Edgent-java<n> ...
Is there any ~convenient way to synthesize/use alternate pom’s for E7?
Might there be a way to leverage “mvn —file <pom>” and also
pom.xml:<relativePath>?
e.g., have the pom.xml implicitly be j8/E8 oriented with non-variable
coordinate decl for the project.
Imagine building / staging a RC for E7 would be something like:
mk-j7-poms # create pom-j7.xml files adding “-java7” in versions and a
“relativePath” of ../pom-j7.xml
# **/pom-7.xml added to .gitignore; target dir is
still variable
mvn -f pom-j7.xml -Pjava7 clean install -DskipTests
# TBD do j7 testing
# …
mvn -f pom-j7.xml -Pjava7 deploy -Papache-release -DskipTests
Or if we’re going that far, then maybe needing/using a separate
clone/workspace to build & deploy E7 might be tolerable?
Though… while the gradle/ant tooling created j7 jars using *the* j8 jars,
this mvn tooling is already regenerating the j8 classes
and then running them through retrolambda, right? (if so, ugh)
Kinda feels like E7 artifacts should instead just declare a
dependency on their corresponding E8 jar artifact (not src)
and just do some (retrolambda) transform to generate the E7 jar artifacts.
Which seems to imply separate (~parallel) simpler poms for E7
which can then also have non-variable-version decl?
e.g., then something like
cd java7
mvn clean install -DskipTests
# TBD test
mvn deploy -Papache-release -DskipTests
Also, the current "mvn install -Papache-release -Pjava7"
generates -sources.jar, -javadoc.jar, -source-release.zip
Do we really want to distribute those (duplicate) set of those artifacts?
Don’t know if that might just mean more config tweaking or
if the retrolambda plugin / “deploy” flow for java isn’t really what
we want.
Your thoughts on all of this?
— Dale
