Does this make sense.
Makes sense. I see a need to have feature sets like the Arduino C++ Developer Toolkit being available but not necessarily part of the C++ package. I’m a follower of the "start from a minimal platform package and install what you need” religion.
To me it sounds that the main differentiators to existing approaches and the Eclipse Projects Marketplace are:
1. Easily install different (language) tool sets in one IDE. That was possible before as well - but maybe not that obvious as in a Marketplace entry before. 2. New prepackaged feature combinations (spanning more than one Eclipse project). Before projects could offer a feature on their update site or on the simrel repo. With the marketplace logical feature that have (sub) features from the c++ tools project and some IoT projects may be combined. With that it may be easier for a user to decide what he needs and may make it easier to consume these projects
I wouldn’t be surprised if many projects would request their own specific logical feature that comes with plugin A,B,C. Having you as the authority to decide which feature combination makes sense will be an interesting experiment. Maybe there should be more guidelines in the beginning. But this is a minor issue IMHO.
I’m more concerned about installation problems that will occur because of missing dependencies, illegal version constraints etc. At the moment every project individually (has to) check its marketplace error log to find out when and why an installation fails. If those logical features are set up, every participating project should monitor whether these bundle combinations can actually be installed. Right now, the EPP packages are such a checkpoint. I’m afraid that we will loose one such checkpoint with the Marketplace feature. One idea to mitigate this: Maybe we can sent weekly installation error reports by email to feature maintainers? Then they would at least notice what’s going wrong and may take the necessary actions.
2cts. Marcel
This is meant to augment the packages (either downloaded or
installed via Oomph).
I don't think that the EPP packages disappear anytime soon. I think
that it would be very cool if we ever get to a point where the
installer lets you mix and match (e.g. build a custom package that
includes Java, C/C++, and PHP tools), and Marketplace might
reasonably play a role in that.
For now, though, this is intended to make it easier for a user to
take--for example--the Eclipse IDE for C/C++ Developers and add
Tools for Java Developers. I personally get a lot of questions about
combining packages/functionality and in my experience, explaining to
users how to use the p2 installer to add features is a painful
multiples step process. Instead, I can just say "drag and drop
this".
Plus, these solutions can include things that we really think that
the user should have even if they don't know that they need it. e.g.
Code Recommenders.
FWIW, I don't expect that the Java solution will get used very much
as most of the packages already include Java.
Does this make sense.
Wayne
On 01/05/15 04:42 PM, Marcel Bruch
wrote:
I’ve no opinion or proposals yet but I’ve some trouble to contrast this approach with the existing EPP packages and (elsewhere discussed) Oomph-based standard profiles.
More concrete:
Can you elaborate how, for instance, the Java Developer Tools Feature on the Marketplace will be different to EPP Java package?
Bug 459905 sounds like this. Thus, I’m missing the key motivation for this step. I assume that you are looking for a greater flexibility than we have today with EPP. Is this the main motivation?
Will EPP packages disappear some time soon?
Thanks,
Marcel
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
-- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
|
