| Re: [p2-dev] p2, authoring, and EMF? |
|
Thanks for taking the initiative here. Great to see. Like others on this thread, I am all for making things easier so this is interesting. Some clarifying questions / observations if you will... - Context setting... We made a very explicit decision that the data formats, schemas, ... underlying IUs, repositories, artifact descriptors, ... are not to be API. The fact that metadata repos currently are written as xml files is a mere happenstance of the current implementation. The content, structure and form of that can change from repo to repo (one might be XML, another a database, another a RESTful service, another, ..). The important bits are the IUs (in the case of metadata). So things like "content.xml export actions" don't seem to fit well. (see my next point on the publisher) - The tooling effort around p2 should be coordinated with the publisher. The idea behind the publisher is to support the easy publication of IUs and artifacts into repos. There are a wide variety of publishing actions and advice types that consume files, markup, state, ... and write to repos. Ideally authors of metadata actually have to do very little work as the actions would do the heavy lifting. In cases where there are no actions or the information required is simply missing, authors can advise actions or craft IUs from whole cloth. The authored form of advice is similarly unspecified. Ultimately all the publisher (well the actions) care about is that they have instances of the I*Advice interfaces they care about and use to do their job. Note as well that the publisher is used at development time to create/add-to repos and at runtime when watching dropins folders and the like. It is even concieved that you can deploy advice that would advise the publisher should it ever see a related publishing action (e.g., advising the dropins folder to add some property to all all bundles it discovers and publishes). - The work that the EMF team has done to keep the core small and running on small footprint JREs is great. It would be interesting to know what the size tradeoffs are here. Will we save some space by using EMF code rather than our own? In your experience, what would the net code space cost/savings be? While it is easy to say its just another NNNk, we do have to be aware that size does count. There are teams looking to use p2 in embedded environments etc. - What if any is the impact of the use of EMF for authoring on the runtime use of p2? For example, what p2 bundles would you expect to depend on EMF? Is there any opportunity to make the dependencies optional? - As Pascal pointed out, most of the APIs in this space are read-only. Can we use this characteristic to some advantage here? - You talked about exposing the p2 engine as an EMF API. Can you clarify what that would mean? What would it enable? Also to clarify, do you mean IEngine? Thanks again Jeff Benjamin CABÉ wrote: Hi all, |
