-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Runtime Agent API #61
Conversation
To allow usage with existing EMMA integrations the following API should also be supported:
|
@Godin I added a initial implementation which directly depends on agent classes. To make this work the dependencies in the API classes has to be transformed the same way than the agent packages. I wonder whether this is possible with the shade plug-in. Alternatively this could be easily done with ASM. |
@marchof I don't think that this is possible with maven-shade-plugin, because those classes not in the agent module. And I wonder how to integrate into build ASM transformations? Another option - usage of reflection. BTW, why separate module? Why not in the same as agent? |
Also actually we can use an MBean to access an agent without tricks with relocation of packages, since it will be registered by default ( #62 ), but unfortunately package "javax.management" not available on Android. |
@Godin regarding ASM transformations: We might need to create our own maven-plugin that does the job as part of the build. Or simply run the utility as a Java program. |
@Godin regarding separate module, this was my original motivation:
But for now I can live with both limitations. We can still think about different solutions if we encounter real-life scenarios where these points turn out as blockers. My only remaining concern is package naming. We have
|
@Godin I reworked my the implementation: Now org.jacoco.agent.rt exposes the APIs directly. Can you give this another try with your Android prototype? |
@marchof Out of curiosity - why you changed your mind? |
@Godin To keep things simple for now. We can still separate it if we run in problems in certain scenarios. |
@marchof Ok, I will check this today in the evening. |
@marchof Hi Marc, Sorry for the delay - it took me quite some time to understand why this doesn't work on Android with LocalController. And here is an explanation: LocalController closes the stream only on shutdown (what not happens on Android) and there is no call of method "flush" in writeExecutionData. One of the ways to fix this - is to invoke "flush". But in this case stream anyway remains unclosed. Can it lead to side effects? Another option is to update "com.vladium.emma.rt.RT" to not call "dump", but instead use "getExecutionData" to write dump into specified file. This will also allow to use this compatibility layer with output mode "none" ( #63 ). WDYT? |
@Godin We can actually re-think the current LocalController implementation which keeps the exec file open. In e9c536c we changed it this way to fail fast when the file can't be created. But I think we can change the implementation in a way that on startup a empty file is created and for every dump we open and close the file. Looks cleaner to me anyways. If you agree with this approach I work on this later today. |
@marchof Indeed - this solution sounds good and looks cleaner. But for me - this is not an opposite (but an addition) to the modification of "com.vladium.emma.rt.RT". So I would prefer to make both modifications. |
@Godin You're right about emma.rt.RT implementation. I'll implement it as you proposed (interpreting the 'merge' parameter as append). So we can change the LocalController in a different story. |
@Godin Done. Can you please re-test? I'll add some more unit tests and want to merge this to continue on mbean and output=none. |
@marchof Cool! Now it works as expected, so let's go for merge! |
@marchof Don't forget to update changelog ;) |
Didn't I? |
Yep, indeed. |
For special integration scenarios or experimental usages an optional API to the JaCoCo agent should be provided that can be accessed from the running JVM. This API comes as a separate bundle and can be bundled with an application if needed. The API should be designed in a way that it does not require additional dependencies e.g. on org.jacoco.core.
Support operations are: