XmlBeans changes / Make Batik optional

[kiwiwings]

Hello Devs,

I was working on XMLBEANS-555 and as usual there is more to be changed.
I've refactored the beans generation so there are no Factory inner classes in the beans interfaces.
This would be a breaking change and user code needs to be compiled again, but I think it's worth it as it's much less duplicated code now.

I've regenerated the poi beans and no changes on our code was necessary.

Apart of that I made the batik dependencies optional and handle errors while using the Serviceloader.
If user code is accessing the Service Provider code directly when running on the module-path, they'll get a NoClassDefFoundError.
I thought about wrapping that error, but I would simply add a FAQ entry and hope that Batik eventually fixes that error.

I would wait two days for a review offer and otherwise commit the xmlbeans change and upgrade the poi/xmlbeans dependency.

Best wishes,
Andi


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Hi Andi,
I can have a look. I guess the main comparison would be to compare the generated source from xmlbeans 3 or 4 to what we would generate after the patch. If the POI code does not need any changes after the proposed xmlbeans change then it seems likely that the new approach is a good way to go -- simpler generated code but easy for existing users to uptake.


Regards,
PJ



On Saturday 20 February 2021, 23:26:25 GMT, Andreas Beeker <[hidden email]> wrote:





Hello Devs,

I was working on XMLBEANS-555 and as usual there is more to be changed.
I've refactored the beans generation so there are no Factory inner classes in the beans interfaces.
This would be a breaking change and user code needs to be compiled again, but I think it's worth it as it's much less duplicated code now.

I've regenerated the poi beans and no changes on our code was necessary.

Apart of that I made the batik dependencies optional and handle errors while using the Serviceloader.
If user code is accessing the Service Provider code directly when running on the module-path, they'll get a NoClassDefFoundError.
I thought about wrapping that error, but I would simply add a FAQ entry and hope that Batik eventually fixes that error.

I would wait two days for a review offer and otherwise commit the xmlbeans change and upgrade the poi/xmlbeans dependency.

Best wishes,
Andi


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[kiwiwings]

HI PJ,

I've added the patch to XMLBEANS-555 - sorry for that vintage approach, I'm not working with GIT in the Apache context.

Thank you,
Andi

On 21.02.21 16:33, [hidden email] wrote:

> Hi Andi,
> I can have a look. I guess the main comparison would be to compare the generated source from xmlbeans 3 or 4 to what we would generate after the patch. If the POI code does not need any changes after the proposed xmlbeans change then it seems likely that the new approach is a good way to go -- simpler generated code but easy for existing users to uptake.
>
>
> Regards,
> PJ
>
>
>
> On Saturday 20 February 2021, 23:26:25 GMT, Andreas Beeker <[hidden email]> wrote:
>
>
>
>
>
> Hello Devs,
>
> I was working on XMLBEANS-555 and as usual there is more to be changed.
> I've refactored the beans generation so there are no Factory inner classes in the beans interfaces.
> This would be a breaking change and user code needs to be compiled again, but I think it's worth it as it's much less duplicated code now.
>
> I've regenerated the poi beans and no changes on our code was necessary.
>
> Apart of that I made the batik dependencies optional and handle errors while using the Serviceloader.
> If user code is accessing the Service Provider code directly when running on the module-path, they'll get a NoClassDefFoundError.
> I thought about wrapping that error, but I would simply add a FAQ entry and hope that Batik eventually fixes that error.
>
> I would wait two days for a review offer and otherwise commit the xmlbeans change and upgrade the poi/xmlbeans dependency.
>
> Best wishes,
> Andi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[kiwiwings]

... and the preliminary patch for using XmlBeans 4.0.1 + Batik sub-components (because the batik-all artifact has (duplicated) references to all sub-components)

When I commit the changes to the XmlBeans repo, I would download the .jar from Jenkins (into POI) while it's not yet released.


On 21.02.21 18:05, Andreas Beeker wrote:

> HI PJ,
>
> I've added the patch to XMLBEANS-555 - sorry for that vintage approach, I'm not working with GIT in the Apache context.
>
> Thank you,
> Andi
>
> On 21.02.21 16:33, [hidden email] wrote:
>> Hi Andi,
>> I can have a look. I guess the main comparison would be to compare the generated source from xmlbeans 3 or 4 to what we would generate after the patch. If the POI code does not need any changes after the proposed xmlbeans change then it seems likely that the new approach is a good way to go -- simpler generated code but easy for existing users to uptake.
>>
>>
>> Regards,
>> PJ
>>
>>
>>
>> On Saturday 20 February 2021, 23:26:25 GMT, Andreas Beeker <[hidden email]> wrote:
>>
>>
>>
>>
>>
>> Hello Devs,
>>
>> I was working on XMLBEANS-555 and as usual there is more to be changed.
>> I've refactored the beans generation so there are no Factory inner classes in the beans interfaces.
>> This would be a breaking change and user code needs to be compiled again, but I think it's worth it as it's much less duplicated code now.
>>
>> I've regenerated the poi beans and no changes on our code was necessary.
>>
>> Apart of that I made the batik dependencies optional and handle errors while using the Serviceloader.
>> If user code is accessing the Service Provider code directly when running on the module-path, they'll get a NoClassDefFoundError.
>> I thought about wrapping that error, but I would simply add a FAQ entry and hope that Batik eventually fixes that error.
>>
>> I would wait two days for a review offer and otherwise commit the xmlbeans change and upgrade the poi/xmlbeans dependency.
>>
>> Best wishes,
>> Andi
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]