feat(java,info): add vertex info builder

[Jarvx200]

Reason for this PR

Refactor for VertexInfo telescoping constructor ( #740 )

What changes are included in this PR?

Added a simple builder for the class with basic testing

Are these changes tested?

yes

Are there any user-facing changes?

no

[codecov-commenter]

Codecov Report

❌ Patch coverage is 92.59259% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.83%. Comparing base (9b2219e) to head (0a67400).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
.../main/java/org/apache/graphar/info/VertexInfo.java	92.59%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #764      +/-   ##
============================================
+ Coverage     75.77%   75.83%   +0.05%     
- Complexity      470      472       +2     
============================================
  Files            82       82              
  Lines          8550     8577      +27     
  Branches        964      966       +2     
============================================
+ Hits           6479     6504      +25     
- Misses         1873     1875       +2     
  Partials        198      198              

Flag	Coverage Δ
java-info	78.20% <92.59%> (+0.42%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[yangxk1]

❌ Patch coverage is 68.96552% with 9 lines in your changes missing coverage. Please review.

Hi @Jarvx200 , pls add more test case

[Jarvx200]

Hey there, I've looked at the builders and there seem to be some recurring attributes that need to have specific methods and transient fields (eg. PropertyGroups), would it be ok if i create an abstract generic super-class for the builders so I keep the code concise and avoid redundancy?

[Thespica]

Hey there, I've looked at the builders and there seem to be some recurring attributes that need to have specific methods and transient fields (eg. PropertyGroups), would it be ok if i create an abstract generic super-class for the builders so I keep the code concise and avoid redundancy?

Hi @Jarvx200 , that's an excellent suggestion. Creating an abstract super-class for the builders is a great approach to handle recurring attributes (like PropertyGroups, baseUri and etc.) and keep the code concise by avoiding redundancy.

Please feel free to proceed with that implementation. It's a solid design choice.

[Jarvx200]

Sure thing, I will adhere to this design choice and continue working, thanks for the feedback!

[Jarvx200]

Hey there, I this is a rough sketch of the proposed abstract builder, I will have to solve the conflicts locally first and find a way to organize the files in such a way that the access modifiers remain to minimum.
Please let me know if this design is ok and if I should continue working on it!
@Thespica

Breaking: Moved PropertyGroups to another file, this might cause some problems, I will try to fix them as soon as possible

[Jarvx200]

Looking on the errors it seems like the tests fail because I extracted PropertyGroups from PropertyGroup. The problem with it being inside is the fact that the AbstractBuilder can't see it.

If it's ok, I think extracting the AbstractBuilder from it's package and placing it with the other classes which require it. It will help with this but also will help by limiting the access modifiers in it's internal api.

[yangxk1]

Hi @Jarvx200 , I think some simplicity can be wasted in order to keep it easy to read. We can add a builder method in propertyGroups , than we can call

public EdgeInfo/VerterxBuilder propertyGroups(PropertyGroups propertyGroups){
    propertyBuilder(properyGroups);
}

public EdgeInfo/VerterxBuilder propertyGroups(PropertyGroup propertyGroup){
    propertyBuilder(propertyGroup);
}

in both VertexBuilder and EdgeBuilder.
However, for ElementGenericAbstractBuilder.java‎, In order to simplify version and prefix in builder, we have introduced such complex methods. Is this worth it?

[Jarvx200]

Hey there, thanks a lot for the feedback. Looking back it seems a bit too complicated and it might be harder to mentain. I will try to find a middleground so I respect DRY principles but don't overcomplicate the codebase.

Maybe embedding a small builder as an instance variable for common fields could be a bit of a better idea?
@yangxk1

[yangxk1]

@Jarvx200 ,We can implement it in a simple way, and then improve it later. What do you think?
We can temporarily add common files in both classes builder

[Jarvx200]

For sure, I will do it like you proposed at first so it's working and then we can work on reducing redundancy!
@yangxk1