Hi John,
sorry, my bad. I thought "core JAR" refers to Arquillian.
I took a look at the source code and noticed that you implemented a
"offline instrumentation" aproach. Since JaCoCo 0.6.2 this is available
out of the box. Some pointers:
- The implementation for instrumentation is called
org.jacoco.core.runtime.OfflineInstrumentationAccessGenerator
- jacocoagent.jar can directly be used as the JaCoCo offline runtime. It
already contains a shaded version of ASM5.
- To collect coverage information within the container the runtime
offers a public API in package org.jacoco.agent.rt
(http://www.eclemma.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/package-summary.html).
I'm a litle reluctant to distribute a shaded version of ASM with JaCoCo
core. As I said ASM is used in the JaCoCo core API (not just used
internally). I don't want anybody to depend "our" version of ASM APIs.
Cheers,
-marc
On 02.11.14 16:54, John D. Ament wrote:
Hi,
No, JaCoCo isn't inside the app server. The jacoco core library ends
up inside the app server to trigger test reads. I guess you guys
would be the best to explain what the core JAR does in respect to JaCoCo?
Perhaps looking at the source code would help
you? https://github.com/arquillian/arquillian-extension-jacoco - it's
pretty straight forward on how it integrates w/ JaCoCo.
John
On Sunday, November 2, 2014 10:22:36 AM UTC-5, Marc R. Hoffmann wrote:
Hi John,
sorry for asking, but I'm not familiar with the Arquillian
arhitecture:
- I understand that the JaCoCo agent whichs runs on the app server
is not the problem, right?
- The problem is with the "core JAR". What is the purpose of the
core JAR in respect to JaCoCo?
- Is there some repo or architecture outline I can study?
Cheers,
-marc
On 02.11.14 14:32, John D. Ament wrote:
Hi,
Actually what Arquillian is doing is creating its own shaded JAR
(at runtime) that contains the JaCoCo and ASM libraries in it,
along with the Arquillian extension. This is the core JAR. the
agent runs separately to receive data from the app server.
The key thing to my request is the relocation of the classes.
The ASM 3.1 JAR that ships gets activated by application that
use it - e.g. CXF in your runtime.
This is a classified shaded JAR, not a replacement shaded JAR. I
wouldn't want to break anyone who might be using the old one.
John
On Sunday, November 2, 2014 5:46:41 AM UTC-5, Mirko Friedenhagen
wrote:
Just guessing: Arquilian builds an agent of it's own based on
jacoco-core which is deployed to/running as part of Wildfire
formerly-known-as-jboss. WF uses asm4. To ease building the
arquilian-jacoco-agent a shaded jar could be helpful.
Drawback: it has a similar but distinct API.
Regards
Mirko
--
Sent from my mobile
On Nov 2, 2014 9:31 AM, "Marc R. Hoffmann"
<[email protected]> wrote:
Hi John,
ASM5 is required for Java 8 support.
We already deliver two artifacts with shaded ASM5 included:
1) The JaCoCo agent itself (here even jacoco itself is
relocated to a random package name to allow running
JaCoCo on JaCoCo)
2) The jacocoant.jar which is part of the all-in-download
distribution
I don't think we can shade ASM for org.jacoco.core as ASM
is part of the API here (more API to come once we have
filtering). My assumption is that we should only apply
shading for "stand alone tools" which do not provide a
Java API.
John, what is the specific situation where you run in
trouble? Runtime? Analysis/Report generation time? I'm
not familiar with the Arquillian architecture.
Cheers,
-marc
On 02.11.14 01:15, John D. Ament wrote:
So, I wanted to run this idea by the JaCoCo folks.
I'm somewhat affiliated with Arquillian. Today I ran
into an issue when someone upgraded the Arquillian
JaCoCo extension to 0.7.1 and Java 8 support. While a
great idea, looks like you did this by upgrading to ASM
5 as well.
The problem is that ASM 5 isn't compatible w/ WildFly
8.1 (at least not yet) due to some JAX-WS dependencies.
I'm able to work around this issue in Arquillian by
creating a shaded JAR based on JaCoCo and ASM 5, where
ASM 5 gets relocated to a different package. However
before that goes in, I have to ask - would you be
willing to distribute a shaded JAR w/ a relocation of
ASM 5 to avoid this upgrade compatibility issue?
I did a quick POC locally and it did work just as well.
You can see the changes here:
https://github.com/johnament/jacoco/commit/8bc85be663005ab490dadbdb76dfee0a13f4033d
<https://github.com/johnament/jacoco/commit/8bc85be663005ab490dadbdb76dfee0a13f4033d>
If you're interested in the additional distribution, I
can raise a PR to merge my code into JaCoCo to create
the shaded JAR.
Let me know.
John
--
You received this message because you are subscribed to
the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to [email protected].
For more options, visit
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to
the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to [email protected].
For more options, visit
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the
Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups "JaCoCo
and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
