Easysoa-registry-api-frascati project must be free of Nuxeo dependencies

[JGuillemotte]

Problem : The project easysoa-registry-api-frascati contains nuxeo dependencies, especially in test classes. This happened because of FraSCAti in Nuxeo wrapper (see #21). This project must be free of Nuxeo dependencies.

All the Nuxeo dependencies must be used only in the project easysoa-registry-frascati.

One solution could be to reimplement NuxeoFraSCAti's interface (FraSCAtiServiceItf) on top of the real FraSCAti.

Related : #79 EasySOA startable "App"

[JGuillemotte]

New problem spotted in org.nuxeo.frascati.api.AbstractProcessingContext. This class use a delegate class (implementing org.ow2.frascati.assembly.factory.api.ProcessingContext interface) but some called methods do not exists in the delegate. Result is a NullPointerException.

TODO INRIA : Refactor this API to use common interfaces between standalone FraSCAti and NuxeoFraSCAti versions, especially for FraSCAtiServiceItf, ex. by implementing this last one directly on top of FraSCAti. Or Other ideas ?

[JGuillemotte]

There are 2 different use contexts :

• A remote context where FraSCAti is executed outside Nuxeo (easysoa-regsitry-api-frascati)
• A local context where FraSCAti is embeded in Nuxeo (easysoa-registry-frascati)

We have a main test for each context.

• for remote (IMPORTANT it wrongly refers to Nuxeo dependencies & wrapper) : RestApiFrascatiImportServiceTest.java (see https://github.com/easysoa/EasySOA/blob/master/easysoa-registry/easysoa-registry-api/easysoa-registry-api-frascati/src/test/java/org/easysoa/sca/frascati/RestApiFrascatiImportServiceTest.java)
• for local : LocalApiFrascatiImportServiceTest.java (see https://github.com/easysoa/EasySOA/blob/master/easysoa-registry/easysoa-registry-frascati/src/test/java/org/easysoa/sca/frascati/LocalApiFrascatiImportServiceTest.java)

And for each test, we have several different use cases :

• Import / parsing use case : to parse directly / explicitly a composite or a zip or jar file to detect SOA services.
• Discovery context : to start a composite in Frascati and get informed about its services / called back by FraSCAti.

Between all of them, the code that visits Composites and tells (a local or remote) EasySOA about their services is shared in https://github.com/easysoa/EasySOA/tree/master/easysoa-registry/easysoa-registry-api/easysoa-registry-api-frascati/src/main/java/org/easysoa/sca . It is then extended to be completed & used

• on remote / standalone FraSCAti's side (in the same project, but it's already tied to FraSCAti since shared code visits STP Model's Composites) https://github.com/easysoa/EasySOA/tree/master/easysoa-registry/easysoa-registry-api/easysoa-registry-api-frascati/src/main/java/org/easysoa/sca/frascati
• on Nuxeo's side https://github.com/easysoa/EasySOA/tree/master/easysoa-registry/easysoa-registry-core/src/main/java/org/easysoa/sca

TODO How can we have (at least) import within Nuxeo and runtime discovery within FraSCAti (standalone, and if possible embedded in Nuxeo), while sharing most of the code and not refactoring too much ?

A few ideas :

• change "import" use case so it does not explicitly visit Composites, but do it the discovery way i.e. callback
• share the STP Model on both FraSCAti & Nuxeo sides of FraSCAti API & wrapper, but beware to known conflict on org.eclipse.jdt.core (see wiki)
• "reimplement FraSCAtiServiceItf on top of standalone FraSCAti" including model wrapper on top of STP Model (?)

[mdutoo]

Also TODO improve architecture of build of Inria contributed projects, towards tree-like submodules having parent poms (we can discuss the right structure together).

Because for now, some submodules have no parent pom AND don't define themselves FraSCAti repositories, therefore can make the build fail. For instance it was the case in easysoa-frascati-processor.