Community
Participate
Working Groups
With the advent of Eclipse as a runtime technology and more and more projects (e.g., BIRT, EMF, Equinox, RAP, ...) producing runtime related output it has been suggested that we add a "Runtime" or "Target Platform" or... category to the Galileo repository. This would serve several purposes 1) Give projects that define runtime related output a means of delivering that output to potential consumers. 2) Enable developers to discover and consume runtime related bits easily 3) Leverage the newly renovated Target Platform Provisioning support added by the p2 and PDE teams. This allows developers to directly add content to their target platform using p2 workflows and infrastructure. Consider the following scenario (yes, there will be variations and exceptions but this is offered as but one motivating example that is witnessed quite frequently): - Some team is developing an RCP application (or server side or e4 or...). They use EMF and BIRT amongst various other technologies from Eclipse - a small portion of the team is dedicated to developing models and another to developing reports. The rest are develop the remaining business logic etc. - The report and model developers need the full tooling and support for the related projects installed in their IDE to facilitate the creation of the artifacts. - The rest of the team needs only the required runtime bits for the various technologies and this need only be in their target platform. No tooling need be installed in their IDE. - Similarly the report guys don't need the modeling tools and vice versa. In today's approach each project makes available some features or zips that contain a mixture of tooling and runtime bits. These are installed in the IDE and, in the general case, another copy in the target platform (unless you happen to be developing your app based on the same version of Eclipse that is running your IDE). This is cumbersome and leads to IDE bloat and duplication. To address this the PDE and p2 teams have implemented "target provisioners" that allow developers to incrementally add target content from repos and other sources. By adding your "runtime content" to the Galileo repository and categorizing it appropriately, it is easy for the rest of the development team to find and get the just the bits they need for the target platform without having to install all the tooling and whatever else that might drag along. Remember much of our tooling is very comprehensive (good) but as a result, brings with it many requirements (not so good). As you will note from the examples, this is not a "runtime project" thing. The beauty of Eclipse is that there is relevant stuff all over the place. Much of it remains relatively inaccessible today because a) there has not been a good access mechanism (target provisioning) and b) the repos were not setup to accommodate the content. So, to the category: (warning, another naming discussion) Name: "Runtime" , "Target Platform Components", ... Description: This category identifies various Eclipse technology that is commonly used in runtime scenarios from RCP to embedded to server side. The components in this category are intended to be added to your Target Platform, not installed into your IDE. <could do better here> Criteria: Theoretically many different things could fit in here. Again, the wonder of Eclipse is that lots of function is useful in lots of cases. For round one we should be pragmatic and include a reasonable set of obviously runtime related function. This is not to be exclusive but rather to project a clear vision for the category to developers. For simplicity, if some function has wide appeal in non-tooling/ide scenarios then it is a candidate for inclusion in this category (see below). Content form: Each project that participates will create or identify one or more (small number) "target features" that include both the binary and the source for their runtime function. This can be composed of pre-existing features or created from scratch. It is key to note that these "target features" are not intended to be installed into IDEs but rather provisioned into target platforms. Projects may also choose to create and include deployable runtime features. Candidate content: - Equinox (all elements including p2, server side, ...) - eRCP - BIRT report engine and perhaps viewer - EMF core runtime elements - RAP target - EclipseLink runtime - ECF - Eclipse RCP and delta pack - Teneo - GEF runtime - Riena - Swordfish This idea has been socialized to most of these projects (all with positive responses). There may be more and not all that remain will fit or want to participate (!). Overall there will be perhaps 20 features in the category for Galileo.
In the RT PMC call this morning we discussed the naming of such a category and came up with the following suggestion: Target Platform Runtime Components The thinking was that people interested in this category are likely getting there via the target provisioning workflow in the IDE so having "Target Platform" in the name is attractive. Similarly, having Target Platform in there is suitably unattractive to people looking to install stuff into their IDE. Finally, having Runtime in the name fits with the Foundation's strategic goal of highlighting Eclipse as a runtime technology.
+1 to "Target Platform Runtime Components" category. I need this category to place the runtime content from the equinox project.
+1 for a Target Platform Runtime Components category. I have permanently the problem that users of Riena want Riena and "something else", like they want Riena plus Equinox plus RCP plus something else. A catalog from which to install a list of components into a target platform is what a lot of Riena users would use.
+1, I think this is a good idea.
In general, I like this idea, but have some comments and suggestions I hope generate some constructive discussion and improvements in my own thinking (if nothing else). For one, The category seems at a "different level" than the other categories. As I thought about this, I think that might be because our current, other categories are subcategories of some higher level category that might be called "IDEs and Development Tools". So, that makes me wonder if we might want to conceptualize this as two high level categories Target Platform Runtime Components, and IDEs and Development Tools And each of those could have their own subcategories -- the one already spelled out, and the runtime sub-categories you could decide (now, or later). Does this conceptualization match your mental models of this space? Or am I off base? Another thought ... what should we do, conceptually, about things that could be cross-classified. Jetty, while not in Galileo, could conceivably go under "webtools" as well. That is, that's where users might think to find it. Would it, conceptually, make sense to provide it in both places, or are there reasons to nudge users to never install things like that in their IDE's dev. env. Is there performance differences or other reasons?
I agree with the dual nature of this. If we want to go to deeper category nesting then what you suggest is fine. In reality at least for Galileo 90% of the people will be interested in the tools content so adding another level of nesting might lead to worse usability but at least conceptually we agree. Another possibility is a separate repo for the runtime stuff. Most people I've talked to seemed to feel that this was less than optimal because folks needed to "know more" and it raises coherence issues/questions. As for things that can go either way, IMO both is a good answer. The reason the repo and categories exist is to help people consume our output. It if is reasonable for people to need/want function X in both their tooling and their runtime, so be it. Having said that, it is unclear for example in cases like Jetty that people actually want to add Jetty to their IDE. Jetty, EclipseLink, ... might come along as part of the implementation of some tooling support (e.g., Help, WTP, Dali,...) but it is unclear if Jetty itself should show up in the tools category. Related, the features being talked about here are SDK features. a) they should have source, ... b) they may well have more stuff than any one product/project would reasonably need So while it may make sense for Jetty et al to show up as a term in the Tools category, it seems less likely that the features envisioned would show up there. Some other "deployment features" might show up tools and those features might be included in the SDK features that show up in Runtime... This is not hard and fast, just one view on how the world could look.
(In reply to comment #6) > Another possibility is a separate repo for the runtime stuff. > Most people I've > talked to seemed to feel that this was less than optimal because folks needed > to "know more" and it raises coherence issues/questions. > What if the additional runtime repo was also included along with the tool repo in the Platform's provided URL's? They'd both "show up" to users, right? I suppose in theory that would allow one to be disabled by default, if that would ever be desirable by some "product" ... not that I know of any ... just seems more flexible. I like the two repository approach since with current P2/site.xml categories, we are limited to the "2 deep" we currently have. Also, with the current limitations of our build system (and P2/site.xml categorization) features can not show up in two categories at the same site (see bug 269943). Not sure how Thomas Hallgren's build system will effect these constraints. See bug 270058. I've added Thomas to CC so he can comment. Not sure if its an advantage or disadvantage, but guess a separate repo would require some new "space" on download server (such as /releases/runtimes/galileo ). This might be better, to have separate "build", separate space, just for the practical reason that several runtime sub-projects are coming in late. Riena is only one in the build, so far. That way, the "tools" repo could mirror, be widely available, with the runtime repo undergoing more "last minute" change. Sounds like with the current build, there's some runtime things that can not fit in (e.g. equinox sdk) since it won't "install" into a galileo product, so that would argue for separate sites. Again, Thomas Hallgren's process might "fix" this limitation ... I'm just trying to point out some practical aspects that have to be solved.
My concern about having two repos is that it is more moving parts. People are seemingly easily confused by this sort of thing as it raises questions like "what's different", "why is X in y and not in Z", and the posibility that accidental repo incoherence go unnoticed. Priming the IDE with the repo URLs help but there are still cases where people have to know the URL (happened to me today for some reason) and it still happens that people are shown a selection of repos to use and they have to choose. More cognitive load. Part of the overall story we are telling is that the same bundles (stuff) can be used in lots of different ways/scenarios. To turn around and make people go to different places makes that story harder to sell. Note that the two level category thing is not a limitation in p2. it can do any number of levels. If that addresses the issue then we can look to facilitate such a structure.
Let's count this as settled for now. New category has been added to the build model with the recommended name and description. So far I just put Riena in there and will leave it up to projects to decide if they belong there ... under Jeff's guidance :)
Thanks David. What is the best means for adding to and tracking this category? For example, the Equinox team respectfully requests that the Equinox SDK feature be added to this category. Finally, in light of your comments elsewhere on the use of EclipseRT, should the category be called something like the following? EclipseRT Target Platform Components
(In reply to comment #10) > Thanks David. What is the best means for adding to and tracking this category? > > For example, the Equinox team respectfully requests that the Equinox SDK > feature be added to this category. > Equinox should already be there, except for the bugs/issues being discussed in bug 272829. Others can be added by projects (and you :) as you see fit. If you need help with mechanics of that, just let me know ... and I'll document it better :) > Finally, in light of your comments elsewhere on the use of EclipseRT, should > the category be called something like the following? > EclipseRT Target Platform Components > I don't _think_ so. I was thinking of EclipseRT just in provider names, of those from EclipseRT Project. This category, I was thinking, was a little broader than that, just the general concept of "runtime" ... not those specific to that EclipseRT "brand". Let me know if I'm misunderstanding.
(In reply to comment #11) > > I don't _think_ so. I was thinking of EclipseRT just in provider names, of > those from EclipseRT Project. This category, I was thinking, was a little > broader than that, just the general concept of "runtime" ... not those specific > to that EclipseRT "brand". Let me know if I'm misunderstanding. > I do not think the category should contain EclipseRT in the name for now. It will make it seem like only thinks from the RT project are allowed, which we wanted to avoid I think.
I do understand and agree that this is a little confusing. Perhaps Ian can shed some light. FWIW here is my 2c... - The Eclipse Runtime Project (aka RT) is a project, not a brand - EclipseRT is a brand not a project
(In reply to comment #13) > I do understand and agree that this is a little confusing. ... If I may add a humorous observation ... This is similar to the confusion about the Eclipse Platform Project being an Eclipse Project, and ... well, the Eclipse Platform. Seems we don't learn from our mistakes ... or, we are just not very imaginative when it comes to names. [hehe, at least humorous to me.]
(In reply to comment #13) > I do understand and agree that this is a little confusing. Perhaps Ian can > shed some light. FWIW here is my 2c... > > - The Eclipse Runtime Project (aka RT) is a project, not a brand > - EclipseRT is a brand not a project > We, and I use the royal we, are trying to create a brand called EclipseRT to include all Eclipse technology that people include in their applications. FWIW, the term 'Target Platform' has no meaning to me. What is it trying to convey?
(In reply to comment #15) > FWIW, the term 'Target Platform' has no meaning to me. What is it trying to > convey? > The old Galileo builder used an Eclipse IDE installation with the delta-pack on top and referred to this as the "target platform". The new builder simply uses the repository appointed by the EP contribution as its "target platform" so now, it's just another contribution that everyone else happens to have downstream dependencies to so I agree, the term "target platform" doesn't really make sense anymore.
wait a second. "Target Platform" has huge meaning and has for some time. It is the PDE concept of "the stuff against which you are compiling" There has been quite some effort into target platform management in 3.4 and 3.5. In fact it is that that is driving this effort to have this new category in the repo in the first place. See comment 0. To further strengthen the case for including "Target Platform" in the name the users interested in that category will have just run though steps like "Preferences > PDE > Target Platform > Edit > Add > Software Site > Runtime Target Platform Components" Notice the correspondence ebtween what the user is doing (editing their Target Platofrm) and the name of the category.
(In reply to comment #17) > wait a second. "Target Platform" has huge meaning and has for some time. I did say 'meaning to me'. :-) I am not a PDE user so my statement still stands. Granted I am not a target user but this does mean you need to be a PDE user to appreciate the term 'Target Platform'. This might be okay; I am just making the observation.
Actually, that is a bonus. People who are not PDE users will not know what Target Platform means and will not be interested in the category. Exactly what we wanted.
(In reply to comment #19) > Actually, that is a bonus. People who are not PDE users will not know what > Target Platform means and will not be interested in the category. Exactly what > we wanted. > Not sure if you are being sarcastic or not? :-) Are you implying the EclipseRT technology can/should only be used by PDE users?
Just FYI, the term "Target Platform" is not used by PDE alone. WTP uses it a lot to describe its target operating environment (such as application servers, databases etc) and of course it's also used to describe the target architecture in embedded. Related to Faceted Project Framework (FProj), Kosta and I would actually like to see the concept of a target platform pushed down from FProj right into Platform, since it is a general IDE concept -- describing the environment in which any artifacts you develop are scheduled to run (or just "live").
(In reply to comment #20) > > Not sure if you are being sarcastic or not? :-) Are you implying the > EclipseRT technology can/should only be used by PDE users? > What Jeff states is true (hope you did not take it personally :-)). This category is really intended to be used to manage target platforms in PDE (see comment 0 for full details).
> Just FYI, the term "Target Platform" is not used by PDE alone. WTP uses it a > lot to describe its target operating environment (such as application servers, > databases etc) and of course it's also used to describe the target architecture > in embedded. I do hope that the idea of using "Target Platform" as a prominent category on the update site was not executed. I see a lot of potential for user confusion once you consider the functional scope of all Eclipse projects contributing to Galileo. Even without that consideration, the use of this term is also quite inappropriate for an update site category. The "target platform" is what you configure to develop against. An update site category is a description of functionality that it contains. The term "target platform" as applied to a category provides no description of what it contains.
(In reply to comment #22) > (In reply to comment #20) > > > > Not sure if you are being sarcastic or not? :-) Are you implying the > > EclipseRT technology can/should only be used by PDE users? > > > > What Jeff states is true (hope you did not take it personally :-)). Trust me I don't take anything around naming personally.
The proposed category name is EclipseRT Target Platform Components When I said that people not using PDE will not know what "Target Platform" means I really meant the term "EclipseRT Target Platform Components". Clearly the term "Target Platform" is in use in a number of places. That is why it is qualified with EclipseRT. Sorry if that caused some confusion. So just to reiterate: EclipseRT is stuff running on Equinox (loosely speaking). PDE is Equinox tooling. The contents of the category are things that should be added to people's PDE Target Platform in the process of developing things that run on Equinox (EclipseRT stuff). This together should: - fully describe the intent and content of the of the category - make the category content attractive to PDE users - make the category content unattractive to others What more could you ask for in a name? :-)
