Whats Next?

[h1dden-da3m0n]

Context

I haven had the most time to spend on this Plugin lately (evident in #85), however the time I had and spent made me realize one thing. Despite my best efforts at keeping the comparability to XML REST services once #85 is merged there will be a whole functionality branch not working due to limitations of the default xPath (as far as I was able to debug).

With that said I want to announce officially that I will be deprecating the comparability of this Plugin to XML responses with the next major version (i.e. 2.0.0).

Immediate Future

So what does that mean if you are using this Plugin to interface with XML REST endpoints?

Not much, I am planing to push at least 2 more 'minor' versions before calling it 2.0.0 and remove the XML aspect of this plugin.

Can I protest?

Well this is a Open Source Plugin, of course you can and you should let me know what you think of this planed change!
Additionally, you can bring up good reasons as to why I should keep XML in!
However, if there isn't a solid enough reason or a XML wizard steps in and wants to maintain the XML branch of this plugin then it will end as planed with 2.0.0.

Planed Releases

• 1.5.x - will include the changes found in feat: display value selector #85 (thank you again for your contribution @rolaca11)
• 1.6.x - will (finally) bring pagination support (both Link Pagination according to RFC5988 as well as offset pagination via Continuation Token are planed for now)
• 1.7.x - optional maintenance release (if it happens the final release with XML support, otherwise 1.6.x will be the final XML support release)
• 2.0.0 - XML support removed (likely around the start of 2022)
• next?

Final Words

I am sorry for everyone who is affected by this change, but I simply can't find the motivation and time to support XML based REST in 2021.
This is a bit of a selfish move, but unless someone steps up and wants to fix/maintain the XML side this is how things are planed for now.

[tdaniely-dn]

Hello, half off topic,
Would the kind maintainers welcome a PR for AWS rest scheme by selecting AWS type credentials?

[h1dden-da3m0n]

Hello, half off topic, Would the kind maintainers welcome a PR for AWS rest scheme by selecting AWS type credentials?

you mean support for the AWS Credential Plugin and its credential type as an optional dependency?
I am not opposed to it, just a tat tight on time lately, hence why there are things that have not yet been realised that where laid out as planed in this issue 😅

TLDR: yes please feel free to open a PR contributing that, just be sure that it stays an optional dependency

[tdaniely-dn]

Hello, half off topic, Would the kind maintainers welcome a PR for AWS rest scheme by selecting AWS type credentials?

you mean support for the AWS Credential Plugin and its credential type as an optional dependency? I am not opposed to it, just a tat tight on time lately, hence why there are things that have not yet been realised that where laid out as planed in this issue 😅

TLDR: yes please feel free to open a PR contributing that, just be sure that it stays an optional dependency

I eventually opted to using the aws sdk from groovy script in Active Choices plugin. Since it's a more straight forward solution, Although it's implicit dependency on the AWS plugins.

[h1dden-da3m0n]

if it works for you all good in my book 👍
Thank you for reporting back though 🙂