ITW to build with jdk9 post b41

Jiri Vanek jvanek at redhat.com
Fri Feb 6 14:05:35 UTC 2015


On 02/06/2015 02:47 PM, Fridrich Strba wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello, Jiří,
>
> On 06/02/15 12:41, Jiri Vanek wrote:
>> instead of +export JACOCO_OPERATOR_EXEC=$(SYSTEM_JRE_DIR)/bin/java
>> $(COVERAGE_JAVA_ARGS) -cp
>> $(JACOCO_OPERATOR_DIR):$(JACOCO_CLASSPATH):.
>> org.jacoco.operator.Main
>>
>> you have
>>
>> +export JACOCO_OPERATOR_EXEC=$(SYSTEM_JRE_DIR)/bin/java
>> $(EMMA_JAVA_ARGS) -cp $(JACOCO_OPERATOR_DIR):$(JACOCO_CLASSPATH):.
>> org.jacoco.operator.Main
>>
>> Please fix.
>
> Done in the attached patch, along with one hanging dependency for one
> of the clean targets.
>
>> Also one thing to think about -
>>
>> you changed my: +JUNIT_RUNTIME:=$(JUNIT_JAR) $(HAMCREST_JAR) ...
>> (eg) +       $(call composeclasspath, $(JUNIT_RUNTIME)
>> $(TEST_EXTENSIONS_DIR)) \
>>
>> to
>>
>> +      $(call composeclasspath, $(JUNIT_JAR) $(HAMCREST_JAR)
>> $(TEST_EXTENSIONS_DIR)) \
>>
>> I'm wondering what is better.
>>
>> I would vote for my approach - as you specify junit_runtime once.
>> If junit runtime will be redefined again,  the the change will be
>> needed only on one space.
>
> I have no strong opinion about this one. I put back the JUNIT_RUNTIME.
> We only have to be sure that we keep in mind that they are space
> separate segments and not to use it ever without the joinsegment call.
>
>> btw - your joinsegments is really cool :) I never realized this
>> approach! ty!
>
> Yeah, when I was working on this, I realized that without something
> like this we were likely to meet some illegally looking classpath or a
> - -classpath followed by another option in certain cases. So, these
> macros were looking like the only way to be more or less protected
> against this kind of problems.
>
>> As for emma - I wonted to remove those two vars too, but then I
>> noted that those are also hardcoded in several (remaining) targets,
>> and was lazy to doublecheck  it all again.
>
> Some of the tests take a file, rename it to _noEmma then run test,
> then again rename the result to _withEmma and the original _noEmma to
> something without suffix. This operations might be possible to kill,
> but then, I think one can do it in a follow-up patch, since this
> change starts to be somehow long :)
>
>> Please fix the issue with  $(COVERAGE_JAVA_ARGS) x
>> $(EMMA_JAVA_ARGS) Although I preffere "my junit_runtim" approach,
>> I'mnot going to force you. Feel free to use which you think is
>> better.
>
> OK, fixed in the attached patch.
>
>> After rhose solved, ok for head (actually - considering release
>> date of jdk9 - only head, oook?)
>
> If one can backport to 1.5, I would not be against, but then I can do
> it myself and keep the patch around.
>
>> Do you wont to get push access or are you ok with me pushing for
>> you?
>
> Whichever is better for you. I don't mind push access, but then I
> would need some briefing about changelogs and other similar things, so
> that I don't screw up the established order. So, you can push as you
> desire.
Hello!

I will write Changelog, add you to authors and add comment line to
# note this is *space* separated list, as composeclasspath is called on them in classpath usage
JUNIT_RUNTIME:=$(JUNIT_JAR) $(HAMCREST_JAR)

And push for you. Later I will try to negotiate push access for you.


Thank you!


J.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlTUxfEACgkQu9a1imXPdA/mGwCbBDz7Ag+MVzHc89xmxj278dB2
> skAAn2OY9MSptxHf3111r1M4XAminQYN
> =H82e
> -----END PGP SIGNATURE-----
>



More information about the distro-pkg-dev mailing list