First, thanks for all the feedback. I finished the current milestone just as Ganymede came out, and then everyone (including me) went on vacation, so I have not received that much feedback yet. I wanted to cover the basics of P2 - and I learned about how P2 works at the same time as I wrote the authoring tool. I know I rounded a lot of corners in getting something out for review/use and I am looking forward to collaborating on making this a good tool.
Further comments inline....
On Aug 18, 2008, at 5:47 PM, Anaik Trihoreau wrote:
We want to use p2 with a more user-friendly interface, for our development teams. The aim is to build some eclipse specific configurations, one per project. Thus, each developer working on a project has exactly the same configuration as his team members, and can only update the IUs allowed by the configuration manager.
Of course, the cherry on the cake would be to also be able to easily deal with the target platform under p2 control. Indeed, for "web projects", only the development environment is really useful, and target platform doesn't make sense. But, for complex Eclipse developments, we want to constrain both the development environment ("use Ecore Tools v.X", "use checkstyle Y", ...) _and_ the target platform.
As we want to create a user friendly IU editor, we're currently having a look at the work done by Henrik to see how to use it, how to add the features we need, and how to improve and simplify the user interface.
Here are some points we have thought about :
- the Overview tab miss some properties, like a checkbox "Group", that could be checked by default. Furthermore, the "name" field doesn't seem to allow spaces? (see later for our Databinding comments).
It's also probably necessary to add a tab allowing to edit every "non-standard" property of the IUs (every property whose name is not something like "org.eclipse.equinox.p2.*" ...?)
Sounds like things that should be fixed.
- in Required Capabilities, we think it might be useful to have a wizard behind the "Add" action, to allow browsing for existing capabilities.
- Step 1) User can chose the source : IUs installed in the running profile, or IUs available into the referenced repositories
- Step 2) User can then select some capabilities provided by these IUs (if he doesn't want the whole pack)
- Step 3) User can enter differents options : a range (a "standard range" can be generated by default, in order not to have a strong dependency like "3.0.0.v200806092130-7C78ELSE8VrRVor6q2hez07sOLY" or something :-)), os/ws/arch/nl filter, greedy flag (default to checked), multiple, optional.
- On "finish", the list of choosen items are added to required capabilities.
Agree - getting help specifying required capabilities is important. That is the next set of features that I thought should be added.
- A similar wizard could also help to add Artifacts.
Agree. It is also needed to have the ability to make artifacts and the IU available in appropriate p2 (meta data and artifact repository format) - so they can be used. I thought about the use case to create new IU's that correspond to features/configurations (that do not have any artifacts of their own).
- In the same way, a wizard may help to fill Provided Capabilities, making a list of capabilities that the IU is able to provide.
Yes, also a logic step when adding artifacts. Again a bit tricky - how to extract the capabilities if what is being included is not OSGi bundles, or indeed not written in some other language than Java?
- We think it would also be great to allow to easily export the edited IU into a new or existing repo., and, maybe, to directly propose a repository editor.
Yes, that would be neat.
I had a look at the code base of the IU editor and I noticed that you're currently using your own implementation of Databinding (with Mutators, etc.). Was something missing in the Eclipse Databinding framework (http://wiki.eclipse.org/JFace_Data_Binding/Original_Design) ? I especially think this is great to deal with Forms because the MessageManager can directly be bound to the "validation context" of the binding, and things like conversions, validations, etc. are much more natural using the "declarative" approach of this framework.
The reason for using "my own databinding" is that I already had most of that written and I have not used Eclipse Data Binding. I have was sort of hoping someone would step up and say "and this is how you do the same with Data Binding" :)
Besides, some refactoring is certainly needed to be able to implement the features described above, and we would be very pleased to work hand in hand with you to make the editor better.
Agree - both refactoring/changing and adding appropriate extension points (extracting capabilities, supporting custom touch points, etc.)
Henrik, what is your current status on this project?
Project was proposed and was supposed to be started as a subproject somewhere near p2. Ganymede release, vacation, and then some repository reorganizations put a pause on dev work. My plan is to continue when I am done with some deliveries I have committed to over the next week or so.
Have you done some improvements that are not committed in the buckminster SVN?
No, it is all there.
Don't know the best way to collaborate on specifying features and doing the development work, but a starting point is probably to elaborate on a proposal on the wiki. Then get the actual project under way, and get some resources to help with development.