Open maxonfjvipon opened 7 months ago
Hi! I think I've already done most part of the feature. But I've just noticed that I don't understand why annotation @Versionized
should be removed in B.class
?
A.class (decompiled to java)
package qwerty.org.eolang; @Versionized class A { org.eolang.C c; B b; // ... }
B.class (decompiled to java)
package qwerty.org.eolang; class B { org.eolang.C // ... }
@SevyConst it's an our mistake, thank you. It the result B
class annotation should not be removed. But actually after modification this annotation does not really matter.
@SevyConst if you took this task, it would be better to assign you to the ticket so nobody else touches it. So should I assign you?
@maxonfjvipon yes, it would be great☺️ I think, I will try to do a pull request in two days. I didn't break the issue down into the steps - my fault
@SevyConst the larger pull request - the harder it would be for review. I strongly recommend you to break it down into at least two steps. It would be easer for you to get your changes merged and for us to review it.
Ok, I will do it
Hi, @maxonfjvipon I wrote the integration test. It contains more than 1k lines, because the testing is very important for such core thing as versioning. I got stuck with qulice - there are 926 violations only in the test, though I had tried to write code in your style. Could you please recommend some tools for reformatting?
@SevyConst that's the reason I recommended to split the task into the small peaces) Unfortunately there's no a specific tool for such reformatting. We do it by our hands. Could you please at least make a pull request so we could at least look at the code
@SevyConst sometimes IntelliJ IDEA auto-formatting helps
@yegor256 @maxonfjvipon thank you for answering. I have just made a pull-request so you can see what have been done at the current moment. That’s why I added not only the integration test but also a Mojo class. Please see the description of the pull request for more details. I also just have made some auto-formatting by IDEA but I don’t got into the details due to lack of time. Unfortunately, I will not have much time in the next 10 days
One of the parts of the #1602 implementation is bytecode modifications.
We need separated standalone mojo in
eo-maven-plugin
.The parameters of the mojo:
Algorithm of the mojo:
.class
files.class
files@Versionized
annotation is used. Let's call this listL
.L
: 3.1. modify corresponding.class
file by appending hash (see parameters of the mojo) in front of every object usage from the listL
(ifA.class
contains the usage of objectorg.eolang.B
and objectB
inorg.eolang.B.class
has@Versionized
annotation, inA.class
this usage should be replaced with$hash.org.eolang.B
, see example) 3.2. save modified.class
file to output directory appending hash in front of relative path (if we modifiedorg/eolang/A.class
, it should be saved to output directory as$hash/org/eolang/A.class
) 3.3 if object usage is not in the listL
- it should not be modified in the.class
fileExample
input directory:
target/classes
output directory:target/modified-classes
hash:qwerty
Before
A.class (decompiled to java)
B.class (decompiled to java)
C.class (decompiled to java)
After:
A.class (decompiled to java)
B.class (decompiled to java)
C.class (decompiled to java)
Implemented mojo + integration test that confirms that mojo works = resolved issue.
The issue may be done in several steps (you may use less or more):
@Disabled
annotation