edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: Understanding the snapshot and release process
Date Fri, 16 Jun 2017 16:43:34 GMT

> On Jun 16, 2017, at 4:46 AM, Christofer Dutz <christofer.dutz@c-ware.de> 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

View raw message