Re: Understanding the snapshot and release process

[Christofer Dutz]

Regarding java8 and java7 artifacts …

This could be problematic, if we wanted to publish both.

Having a binary tar.gz with a java8 and one with java7 doesn’t seem to be a 
problem, but having two artifacts deployed to Maven-Central is no trivial task.
Exactly this type of jars for different java versions is one of the things the 
Maven guys are currently working on as part of the Java 9 – Jigsaw support. But 
it’s a nightmare. We could start creating java8 jars as default and add a 
second “java7” jar using the “java7” classifier, but then a lot of the 
mechanisms in Maven no longer work. 

I could offer to generally build java7 versions and to test them with java7 and 
java8 … I think this topic should be discussed a little more before I start 
implementing this.

Right now, I would opt for distributing java8 binaries to Maven Central and to 
offer downloadable java7 binary distributions.

Chris



Am 07.06.17, 21:06 schrieb "Christofer Dutz" :

Hi,

Right now I didn't configure anything regarding the assembly of the source 
artifact. It's apaches default config. I'll look into a more fine-tuned version.

And regarding the artifact name ... Justin suggested that change, but 90% 
of the other projects don't do it that way. I was waiting for your opinions 
before doing that. It does make the dependencies a lot more verbose. After all 
you can't use the artifacts without the groupId "org.apache.effect" which 
includes "apache" and "edgent".

But sure, I'll change that if you all want me to.

Chris

Von meinem Samsung Galaxy Smartphone gesendet.


 Ursprüngliche Nachricht 
Von: Dale LaBossiere 
Datum: 07.06.17 18:45 (GMT+01:00)
An: dev@edgent.apache.org
Betreff: Re: Understanding the snapshot and release process

OK, so mvn install -Papache-release generates the source release bundle zip.

I poked around for a while but couldn’t come up with the incantation
needed to start excluding things from the zip.  e.g., the zip includes
all of the residual gradle generated **/build/

Chris, can you enhance the configs so as to exclude the various
things that the gradle build was configured to exclude?
See top level build.gradle/srcReleaseTarGz task.
Also exclude src/site (that present in the zip too), right?

The generated zip’s name is:
  target/edgent-parent-1.2.0-SNAPSHOT-source-release.zip

“edgent-parent” ?  today we, I thought correctly, have “apache-edgent” 
there.
Also, the required “incubating” is missing in the release bundle name.

Thanks,
— Dale

> On Jun 7, 2017, at 10:35 AM, Christofer Dutz  
wrote:
>
> Checking our repo:
> https://repository.apache.org/#view-repositories;releases~browsestorage
>
> I can see that fewer than about 10% of all apache projects do that … But 
I wouldn’t mind adding that, if the others agree.
>
> Chris
>
>
>
> Am 07.06.17, 14:54 schrieb "Justin Mclean" :
>
>Hi,
>
>While not a requirement prefixing with apache may add some legal 
protection and is good from a branding point of of view.
>
>Thanks,
>Justin
>

Re: Understanding the snapshot and release process

[Dale LaBossiere]

> On Jun 8, 2017, at 4:19 AM, Christofer Dutz  wrote:
> 
> Regarding java8 and java7 artifacts …

Coincidentally, I started investigating this space yesterday and 
retrolambda-maven-plugin
and was just composing mail on the question of publishing java8 and java7 to 
mvn repos :-)

[ fwiw, so far I had defined a Profile (e.g., mvn install -Ptgt=java7) and
changed the “target” build directory to “target/${edgent.target.kind}”
(e.g., target/{java8,java7}).  Things were working fine up to that point:
generated class files and module jars. ]

> This could be problematic, if we wanted to publish both.
> ...
> I could offer to generally build java7 versions and to test them with java7 
> and java8 … I think this topic should be discussed a little more before I 
> start implementing this.
> 
> Right now, I would opt for distributing java8 binaries to Maven Central and 
> to offer downloadable java7 binary distributions.

Ugh.  Publishing java8 in a mvn repo but java7/android as a binary tgz seems 
really bad.
It creates two different ways (and needed doc) for users building an Edgent app
and installing Edgent jars onto a “device”.

Could you elaborate on the problems using the maven coordinate “classifier”?
The maven doc [1] has this exactly as use case for it (they use “jdk15” vs 
“jdk14”).
At a high (ignorant) level I don’t have a problem with the classifier being nil 
for java8 :-)

If using a coordinate classifier is a no-go, what about (grimace) incorporating 
it into the
groupId:  org.apache.edgent, org.apache.edgent.java7  ?

A bit related, what coordinate component is “incubating” supposed to be 
incorporated into?

— Dale

[1] https://maven.apache.org/pom.html 

Re: Understanding the snapshot and release process

[Christofer Dutz]

Hi Dale,

Today I had some progress on the java7 side.
I successfully added the retrolambda-maven-plugin in a dedicated java7 profile 
to the main pom. Now the plugin automatically kicks in and converts the classes 
after compiling them. I also added the animal-sniffer-maven-plugin to 
explicitly check against the signatures of 1.7 or 1.8 JDKs. This all seems to 
be working. Unfortunately, the backporting of default methods in interfaces 
seems to be a problem. The default methods in DirectTestSetup can’t seem to be 
backported if the interface and the implementing class are not in the same 
retrolambda execution. Eventually refactoring the tests to work without default 
methods would be a good idea.

The problem with classifiers is that maven automatically resolves artifacts. 
Depending on the scope different artifacts are pulled in. In general, we would 
be using the “compile” scope. So, if I add a dependency with classifier “java7” 
then it would pull in that jar in the java7 version, but the transitive 
dependencies would probably be the java8 ones, so you would have to explicitly 
define all the transitive dependencies with the classifier. We don’t want that 
;-)

I also contacted the maven guys on their mailing list. They did have the one or 
the other solution. In general, they would all come down to adding the type to 
the version. So, we would start producing “1.2.0.java7” and “1.2.0.java8” or 
“1.2.0.7” and “1.2.0.8” versions (I would prefer the first as it doesn’t 
suggest the java 8 version being slightly newer than the 7 version). Another 
alternative would be to prefix the version with the target version. “7.1.2.0” 
and “8.1.2.0” … but I don’t really like that option. In this case, I would have 
to refactor the build to use variables in all modules except the parent poms 
(you can’t use variables for parent poms). Then travis/Jenkins would run two 
build:

mvn clean deploy
mvn clean deploy –Pjava7

In the end, it would result in both versions being built, tested and deployed, 
but in the end the java7 version would remain in the workspace as the second 
executions “clean” removed any reference to the java8 version.

Hope that explains the dilemma a little more. At least with these 
version-suffixes we would have a fully working solution. I’ll get into changing 
this tomorrow.

By the way … anyone got an idea how I can make Travis not die on out of memory? 
Tried several things, but it didn’t seem to do the job.

Chris




Am 08.06.17, 16:13 schrieb "Dale LaBossiere" :


> On Jun 8, 2017, at 4:19 AM, Christofer Dutz  
wrote:
> 
> Regarding java8 and java7 artifacts …

Coincidentally, I started investigating this space yesterday and 
retrolambda-maven-plugin
and was just composing mail on the question of publishing java8 and java7 
to mvn repos :-)

[ fwiw, so far I had defined a Profile (e.g., mvn install -Ptgt=java7) and
changed the “target” build directory to “target/${edgent.target.kind}”
(e.g., target/{java8,java7}).  Things were working fine up to that point:
generated class files and module jars. ]

> This could be problematic, if we wanted to publish both.
> ...
> I could offer to generally build java7 versions and to test them with 
java7 and java8 … I think this topic should be discussed a little more before I 
start implementing this.
> 
> Right now, I would opt for distributing java8 binaries to Maven Central 
and to offer downloadable java7 binary distributions.

Ugh.  Publishing java8 in a mvn repo but java7/android as a binary tgz 
seems really bad.
It creates two different ways (and needed doc) for users building an Edgent 
app
and installing Edgent jars onto a “device”.

Could you elaborate on the problems using the maven coordinate “classifier”?
The maven doc [1] has this exactly as use case for it (they use “jdk15” vs 
“jdk14”).
At a high (ignorant) level I don’t have a problem with the classifier being 
nil for java8 :-)

If using a coordinate classifier is a no-go, what about (grimace) 
incorporating it into the
groupId:  org.apache.edgent, org.apache.edgent.java7  ?

A bit related, what coordinate component is “incubating” supposed to be 
incorporated into?

— Dale

[1] https://maven.apache.org/pom.html 

Re: Understanding the snapshot and release process

[Dale LaBossiere]

> On Jun 8, 2017, at 10:43 AM, Christofer Dutz  
> wrote:
> 
> Eventually your approach with a sub-directory inside the target would be a 
> valid option … would probably have to adjust the maven-clean-plugin too, but 
> that should work in getting all results inside the target directory in 
> parallel.

maven-clean-plugin seemed to work OK.  Hmm… would there be a way to get a 
“clean all”?  Maybe that’s what you meant.

mvn clean -P tgt-java7  # cleans all target/java7
mvn clean # cleans all target/java8

That was with pom.xml changes:

  
java8
...
  

  

  tgt-java7
  

  tgt
  java7

  
  
java7
  
...


  
target/${edgent.target.kind}
...
  

Re: Understanding the snapshot and release process

[Dale LaBossiere]

sorry no idea about travis and memory

On Jun 8, 2017, at 10:40 AM, Christofer Dutz  wrote:
> ...
> Today I had some progress on the java7 side.
...
> problem. The default methods in DirectTestSetup can’t seem to be backported 
> if the interface and the implementing class are not in the same retrolambda 
> execution. Eventually refactoring the tests to work without default methods 
> would be a good idea.
I’ll look into that.

> The problem with classifiers is that maven automatically resolves artifacts. 
> Depending on the scope different artifacts are pulled in. In general, we 
> would be using the “compile” scope. So, if I add a dependency with classifier 
> “java7” then it would pull in that jar in the java7 version, but the 
> transitive dependencies would probably be the java8 ones, so you would have 
> to explicitly define all the transitive dependencies with the classifier. We 
> don’t want that ;-)

Thought I was following it but then not :-)  
I may have to try a test using classifier so as to really understand how/why it 
won’t work. 

But if encoding tgt-kind in the versionId is the way to go… (I think it would 
be nice if it could be avoided for tgt-java8, e.g., just 1.2.0, not 1.2.0.java8)

In travis I don’t think you’ll be able to just/only say
mvn clean deploy# compile/test/deploy java8
mvn clean deploy -Pjava7# compile/test/deploy java7

That’s because the compile for java7, including the tests, must be done with a 
java8 JDK (with retrolambda then applied).  There’s no java7 JDK in the mix for 
java7 compile.

But to really test the compiled java7-compatible tests one has to first switch 
the environment to a java7 JRE and then run them in that environment (they 
can’t be compiled in a java7 env because they use lambdas).

That’s why the travis / gradle/ant stuff was structured out the way it was:
switch to java8
gradlew release   # compiles Edgent into jars for 
java8,7,android.
# NOTE, tests are not bundled into 
jars. So there are just the j8 class files
gradlew test # runs the already compiled Edgent tests 
(with java8)
gradlew test7Compile  # recompile the tests-only to be java7 compatible
switch to java7
gradlew test7Run# runs the already java7-compatible compiled 
Edgent tests (with java7)

Also at a high level I think we don’t want to deploy one config unless all 
configs are OK.

— Dale