Deprecate old domain classes

[berezovskyi]

Lyo Domains project shall become the only source of our domain spec shape classes:

[berezovskyi]

@jadelkhoury @jamsden I think we need to remove or at least deprecate all the oslc4j.client.resources classes that have a corresponding counterpart in Lyo Domains.

[jadelkhoury]

I agree to deprecate as soon as Lyo.domains is updated. Part of your effort in the ref Implementation? We can also move whatever is not supported to Lyo.domains to have everything in one place.

We should then think of the name. Is Lyo.domains most appropriate? We’d need an “OSLC” in the name.

[berezovskyi]

What kind of update are waiting for? I don’t have anything planned right now.

-- /Andrew (from phone)

On 10 Apr 2020, at 09:52, Jad El-khoury notifications@github.com<mailto:notifications@github.com> wrote:

I agree to deprecate as soon as Lyo.domains is updated. Part of your effort in the ref Implementation? We can also move whatever is not supported to Lyo.domains to have everything in one place.

We should then think of the name. Is Lyo.domains most appropriate? We’d need an “OSLC” in the name.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/eclipse/lyo.client/issues/86#issuecomment-611923507, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAPZXRZTPHDWUDQAHGRKFDRL3F4HANCNFSM4MFCBJEQ.

[jadelkhoury]

What kind of update are waiting for? I don’t have anything planned right now.

I am mainly thinking of the work on the reference implementation. No more changes to lyo.domains planned?

[berezovskyi]

No, I also think that it could be good to remove all those classes now for 4.0.0.M2 to actually see if anything breaks for people other than namespaces. I expect field types not to match in all cases.

[berezovskyi]

To be clear: no further updates are expected to Domains from RefImpl.

[jadelkhoury]

OK! Let's deprecate! Should we also just move these classes to the Lyo Domains repo? It would make it easier in the future to merge the content.

[berezovskyi]

Sure, moving the classes seems to be a good first step! The users would just have to add a new package and will be able to use deprecated classes. I can do the change.

-- Cheers, Andrew

On 2020-04-20 , at 11:09, Jad El-khoury notifications@github.com<mailto:notifications@github.com> wrote:

OK! Let's deprecate! Should we also just move these classes to the Lyo Domains repo? It would make it easier in the future to merge the content.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/eclipse/lyo.client/issues/86#issuecomment-616416015, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAPZXUYTNAKFPZ45SQ2KRDRNQGLLANCNFSM4MFCBJEQ.

[jamsden]

The old Java client samples rely on some old domain classes, and I suspect anyone using the old client depends on them too. So we'd need to consider these users.

[berezovskyi]

@jamsden ok, let's deprecate them without moving them

[jadelkhoury]

Good to deprecate now. Just to clarify, we only deprecate the domain-related classes. Classes relating to - for example - queries Shall remain.

Maybe time to consider releasing 4.0.0? Because then, we can delete these deprecated classes in the snapshot versions that follow.

[berezovskyi]

My plan now is this:

1. Finish RefImpl. Make any changes needed to the SNAPSHOT.
2. Release 4.0.0.M2 to "cement" refimpl code from breaking.
3. Release 4.0.0 if nobody complains about 4.0.0.M2.

[berezovskyi]

@jamsden @jadelkhoury shall we also deprecate domain classes in the old version of the client too?

[jadelkhoury]

you mean for the Wink-based one? I don't see the point. I'd keep that as it is. I don't believe we plan to maintain it, so might as well keep it untouched

[berezovskyi]

then I close this as fixed in master