Emily,

Michael Musgrove and I discussed this about 18 months ago, if I recall correctly, back when SmallRye was first formed.

Once Michael explained that the LRA implementation for MicroProfile was tightly coupled to Narayana versions we decided it was best to remain where it was as opposed to creating a project dependency nightmare.

In addition, not all MicroProfile implementations reside within SmallRye. The MP REST Client implementation was moved to RESTEasy about 6 months ago as it was a "better fit" than being isolated from the JAX-RS implementation. Where it makes sense, implementations of MicroProfile specifications will reside with a particular project instead of SmallRye

Ken

Yes I agree. My concern about moving the code out of the narayana code base was twofold: the effort involved and that it would slow us down too much for little benefit.

Note that the implementation is a thin'ish layer on top of Narayana ArjunaCore. It's also worthwhile pointing out that the client API is private to the implementation - ie it is not part of the spec. We use it for the participant JAX-RS filters to interact directly with our coordinator implementation via REST calls (again this is not part of the "official" spec).

I am still not convinced that the benefits of such a move before a first release are worthwhile and could impact achieving the initial specification. Our plan was to get version 1 out the door and minimise anything that would slow us down.

If I recall it wasn't so much the dependencies in the LRA client itself, but that Narayana wants to be able to release a distribution that includes the LRA Client. So if the implementation lived in SmallRye then the release process would be unnecessarily complicated because Narayana core would need to be released, then the SmallRye LRA Client could be released, and then a Narayana distribution release is done. It's just easier if it's all in Narayana.

As for re-licensing, that's something the Narayana team, and possibly Legal, would need to discuss and agree

Ken

You are right that the internal client API is mostly independent of the rest of the LRA implementation since it is implemented using REST calls.

We only have 1 outstanding issue Issues · eclipse/microprofile-lra · GitHub  to resolve before we can produce a spec/API GA MP-LRA release and then we will finalise the implementation. Once that is ready we can invest some effort in cleaning up the client and making it generally available. I would prefer to go down this route since once GA is released we will know that the client is communicating with a stable API.

I mean making sure it is not tied to Arjuna and making sure the license is correct (Apache v2 seems reasonable). If we do that then I don't think moving it to a different repo is essential.

From what I understand, the relicencing you are requesting seems to be effectively for narayana/rts/lra/lra-client at master · jbosstm/narayana · GitHub  and narayana/rts/lra/lra-service-base at master · jbosstm/narayana · GitHub  rather than the whole of narayana/rts/lra at master · jbosstm/narayana · GitHub - is that correct? And the purpose is to allow connection to an out of process Narayana LRA implementation (but the licence of that is not something you are concerned about)?

If that is the case and regarding progress to the GA, from my quick review of those specific modules I would mention there appears to have been very few material changes recently, but maybe mmusgrov is aware of major changes expected in those modules required for the GA?

Just to be clear, if my assumption was correct them most of the implementation would remain LGPL v2.1 but it would just be lra-client and lra-service-base that changed.

Just to mention with our discussions moving to google groups, please can further discussion take place over here: https://groups.google.com/forum/#!forum/narayana-users