[equinox-dev] [prov] changes in the UI
I just released a bunch of changes in the UI to support smarter and faster grouping/filtering in the available IU view. In the admin UI you can now set prefs that control: - whether latest version only of an IU is shown (if so, older versions are grouped underneath the latest...kinda weird, but lets you decide on the fly how much to see) - whether categories should be used These work in combination with the previous preference for showing only groups. In the end-user UI, categories are always used, groups are always used as the filter, and the latest version is shown by default, with a preference allowing you to see all. The element structure of the various views is radically different, and it's possible I've missed a detail regarding the adapters such that an action/prop page/etc. won't find the right model element. I tested install/update/uninstall scenarios from both UI's, but it's possible I've missed something. I don't like to release and run, but... ...I'm out until next week. I'll check email a bit tomorrow to make sure there's not something awfully wrong susan___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] M3 docs and screen snaps
I'm updating the doc and screen snaps of the agent UI in the getting started and admin UI guides on the wiki. My working assumption is that the shipped agent won't have any repos set up initially. And I'm using the testUpdates server in the example... So someone let me know (or change the doc) if this ends up being different... susan___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] M3 Testing status
Andrew, 1) after some hand-holding by Pascal, I got metadata generated for both 3.4M2 and I200710300010 in the same location. If I do this, I only get one sdk entry. Is this desirable? I can't install the 3.4M2 sdk. Did you change the -rootVersion property in the metadata generator for each generation? I can generate multiple SDK's and I see them all, provided the versions are unique. Otherwise I'm not sure what could be wrong. For example, if you try the remote update site (http://download.eclipse.org/eclipse/testUpdates/), you can see multiple sdk entries, one for each i-build. However, I get no Software Updates (incubation) in the SDK. Should I? After/while you provision the SDK, you need to install the userui. Otherwise you won't have Software Updates (Incubation). I did this during my initial setup by using the RCP agent to install both the sdk and userui into a new profile. I was able to select both and install at the same time, and when I launched the provisioned SDK, the end user UI was there. can one run just the agent UI from a provisioned install? ie. not as part of the sdk? Yes, you can run just a provisioned agent without an SDK. That's what the downloadable agent is doing. In theory you could use it to install an SDK on top of itself and when you relaunched it you would get an SDK that also had the admin UI perspective (this worked in M2 but I haven't tried it lately). susan Andrew Overholt [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/30/2007 12:48 PM Please respond to Andrew Overholt,Equinox development mailing list To: equinox-dev@eclipse.org cc: Subject:[equinox-dev] [prov] M3 Testing status Hi, I've been trying to go through: http://wiki.eclipse.org/Equinox_p2_tests and I'm running into a few issues: 1) after some hand-holding by Pascal, I got metadata generated for both 3.4M2 and I200710300010 in the same location. If I do this, I only get one sdk entry. Is this desirable? I can't install the 3.4M2 sdk. 2) getting past 1) by generating metadata just for M2, I can provision M2 and run it. Nice! However, I get no Software Updates (incubation) in the SDK. Should I? 3) can one run just the agent UI from a provisioned install? ie. not as part of the sdk? I will report more when I get past the whole can't update in the UI issue. Thanks, Andrew ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev C.DTF has been removed from this note on October 30, 2007 by Susan M Franklin ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [p2] javascript
I've just updated the project sets to remove rhino. Pascal Rapicault [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/15/2007 10:27 AM Please respond to Equinox development mailing list To: Equinox development mailing list equinox-dev@eclipse.org cc: Subject:Re: [equinox-dev] [p2] javascript Done | | From: | | --| |Pascal Rapicault/Ottawa/[EMAIL PROTECTED] | --| | | To:| | --| |Equinox development mailing list equinox-dev@eclipse.org| --| | | Date: | | --| |10/15/2007 01:17 PM| --| | | Subject: | | --| |Re: [equinox-dev] [p2] javascript | --| This is because the map files and the features have not been updated yet. I will take care of this. | | From: | | --| |James D Miles [EMAIL PROTECTED] | --| | | To:| | --| |equinox-dev@eclipse.org | --| | | Date: | | --| |10/15/2007 12:34 PM | --| | | Subject: | | --| |[equinox-dev] [p2] javascript | --| I repopulated my workspace with head this morning. The org.mozilla.rhino plugin was still in the workspace. I was expecting it to be removed since Simon's changes.___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Director API experiments
I understand and can agree with this approach. If I am writing the
helpers, then it makes me think that my existing helper code
(ProvisioningUtil) and perhaps my operations should move to their own
bundle. Because I think this kind of functionality may be useful for any
client, not just an RCP client. I will make a decision after I've written
the code and looked at the dependencies.
Pascal and I talked some more about the Oracle. What we think should
happen is that IDirector2 and Oracle collapse into something called a
Planner. The Planner can return a Plan. (I'm sure the real names
will be more specific). So a client asks the planner for an install plan,
something like
Plan myPlan = myPlanner.install(ius, profile, monitor);
if myPlan.getStatus().isOK()) {
ProvisioningUtil.getSizingInfo(myPlan);
// etc
ProvisioningUtil.performPlan(myPlan);
} else {
// report the problems to the user
}
The IDirector API will remain the same, so that clients that just want to
try an install and don't care to know beforehand if it will fail will call
IStatus installStatus = myDirector.install(ius, profile, monitor);
Pascal, I'm assuming that myPlan.getStatus() and the status returned by
myDirector.install(...) are the same? Meaning, the way we would report an
install failure could basically be the same code path for reporting a
potential install failure (checking for the same kinds of problems)...
As a side note, this pseudo-code does not include an entry point name
anymore. In talking about all this with Pascal, we think the entry point
is disappearing. I'll report that discussion in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204823
susan
Pascal Rapicault [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/04/2007 08:01 AM
Please respond to Equinox development mailing list
To: Equinox development mailing list equinox-dev@eclipse.org
cc: Equinox development mailing list
equinox-dev@eclipse.org, [EMAIL PROTECTED]
Subject:Re: [equinox-dev] [prov] Director API experiments
Thx for the feedback Susan, I sympathize with the problems you raised.
Let me expose the dilema I'm faced with:
- We need to make sure that the simple things are simple, for example an
optimistic user who just want to install an IU should just have to call
one
method (IDirector.install())
- We want to make sure more advanced scenarios are possible, for example a
user willing to cause the prefetch of the IUs before prompting for install
(IDirector2 +Engine)
But what I seem to hear here is that we would need another level of API
that would make the not so advanced and relatively common things easy to
do (e.g. size computation, prefetch, ???).
My problem with this approach is :
- more API to maintain
- what are the criteria to use to add something to this API?
- what is the way to factor this API to avoid unecessary coupling?
- if we put it all in one place, that would bring along too much stuffs
but as we are all lazy we would all be using this helper rather than the
part of the API we need thus bringing too much for our use case.
(note that currently some of the phases are not optimally placed wrt to
bundle)
So in clear, adding stuffs to DirectorResult is not something that I'm
thrilled with and having loads of helpers somewhere in the core code is
not
great either.
For the time being I can help you author helpers that would reside in the
UI and once we understand the shape of these we can decide where they
belong. Note that I would think that they leave in the UI, because they
are
specific to your usecases and we can probably make some assumptions about
the structure of the system and thus justify the coupling.
PaScaL
[EMAIL PROTECTED] wrote on 10/03/2007 12:58:24 PM:
Here is my first impression. I might change my mind later after
working with it awhile.
I like the idea of IDirector2 replacing IDirector and putting some
helper methods somewhere that perform phases for me if I give them a
DirectorResult. But it would be cool if it doesn't even feel like
engine phases to a client. It's just an intermediary step to doing
somethingOnce I have the result, I can do all kinds of cool
things with it (actually perform it, or get the size, etc.).
It also seems like the Oracle goes away and those methods become
helpers, because the DirectorResult can be used to figure out
whether I can install, whether there are updates, etc.
For example, today's code:
if (myOracle.canInstall(ius, profile, monitor)) {
director.install(ius, profile, name, monitor);
} else {
// tell user I can't install, not sure why
}
new code:
DirectorResult result = myDirector.install(ius, profile, name, monitor);
if (result.getStatus().isOK()) {
// call some helper
myHelper.performInstall(profile, result, monitor)
} else {
Re: [equinox-dev] [prov] Director API experiments
Here is my first impression. I might change my mind later after working
with it awhile.
I like the idea of IDirector2 replacing IDirector and putting some helper
methods somewhere that perform phases for me if I give them a
DirectorResult. But it would be cool if it doesn't even feel like engine
phases to a client. It's just an intermediary step to doing
somethingOnce I have the result, I can do all kinds of cool things
with it (actually perform it, or get the size, etc.).
It also seems like the Oracle goes away and those methods become helpers,
because the DirectorResult can be used to figure out whether I can
install, whether there are updates, etc.
For example, today's code:
if (myOracle.canInstall(ius, profile, monitor)) {
director.install(ius, profile, name, monitor);
} else {
// tell user I can't install, not sure why
}
new code:
DirectorResult result = myDirector.install(ius, profile, name, monitor);
if (result.getStatus().isOK()) {
// call some helper
myHelper.performInstall(profile, result, monitor)
} else {
// Now I can hopefully tell the user something interesting based
on the status
}
For some reason, I was hoping/expecting DirectorResult to have more
behavior. I looked at DirectorResult and had no idea what to do with the
operands. Then I found the sizing example in the director app. Creating
a sizing phase and performing it in the engine with the operands
definitely feels a lot different than anything else I've had to call. I'm
an API client who prefers not to know the inner workings of the engine.
So I'm wondering if DirectorResult could be the place where these helpers
live...
DirectorResult result = myDirector.install(ius, profile, name, monitor);
if (result.getStatus().isOK()) {
SizingInfo info = result.getSizeInfo(); // I use SizingInfo
instead of SizingPhase because it doesn't feel like a phase from the
outside
// Use this info to tell the user more about the install
// Once they decide to install
result.performInstall();
} else {
// Use result.getStatus() to explain why the install can't be
performed
}
Of course, helper methods located elsewhere could do the same thing...pass
the helper a DirectorResult and it does the work.
It's just a matter of whether you view DirectorResult as a data structure
or as the actual helper.
Either way, I prefer to treat it as something opaque that I give to
someone smarter than me to do the work, rather than build the phase set
and run the engine, etc.
susan
Pascal Rapicault [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/03/2007 07:06 AM
Please respond to Equinox development mailing list
To: Equinox development mailing list equinox-dev@eclipse.org
cc:
Subject:[equinox-dev] [prov] Director API experiments
Hi,
Back in August, we had a discussion [1] around changing the director API
(or having a Oracle) to enable scenarios like:
- show the user with what will happen as a result of adding / removing an
IU (e.g. compute the install size, etc.)
- allow for download of the artifacts before doing configuration
- decouple the engine from the director
- ...
Yesterday I finally got to prototype this new API. To avoid disruption, I
created a new class called IDirector2. This new API no longer calls the
Engine but instead returns an array of Operands (see these Operands as a
delta that takes the profile from its current state to what you want it to
be). These Operands can then be used as input to the engine to actually
change the profile, or do some reasoning about them.
In order to excercise this API, I changed the director application and I
also implemented an install / download size. So far so good. Still one
things annoys me: If this API replaces the IDirector API then simple
install scenarios become hard to do programmatically since the engine
needs
to be called separately. So there are several possibilities:
- have IDirector and IDirector2 be one
- have the Oracle have the ability of IDirector2 and keep IDirector as is
- replace IDirector with IDirector2 and have an higher API to address the
simple usecases, much like we have the ProvisioningHelpers
What do you think?
PaScaL
[1] http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02717.html
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [p2] UI priorities for M3
Hi, everyone. One of the goals for M3 is to try to define the conent/scope of our 3.4 deliverable. So I'm trying to balance our desire to resolve unknowns with getting current workflows more polished. I'm interested in the community's feedback on the current M3 UI plan, which currently includes - improving the install/uninstall/update workflow by providing more info (size, time, invalid states, etc.) - polling for software updates and notifying the user - improved support for browsing repos (IU categories and filtering) - more info in admin artifact repo views (You can see the expanded detail at http://wiki.eclipse.org/Equinox_p2_User_Interface#Milestone_plan). This is a rather aggressive plan but still does not address some other big UI items, most notably - UI for rollback - presentation of licenses So if you have opinions on the pressing issues and priorities in the UI, please let me know via this list, or annotating bugs you care about, etc thanks, susan___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] - internal error updating metadata
Is anyone else seeing these errors in their working IDE? For example, I just got this error while syncing with the repository. An internal error occurred during: Updating metadata. java.lang.NegativeArraySizeException I believe this is a self hosting issue (keeping metadata up to date with the workspace), but thought I better post just to make sure. When we get these errors, should we be cleaning out the metadata generated for a self hosting launch, and if so, exactly what needs to be deleted? thanks, susan___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] fix for bugzilla
It's bogus of me that the UI chokes on the null value. A less draconian solution is to patch it up as Andrew did in bug #197970. I'll clean these up in the next set of changes. susan David R Stevenson/Redmond/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/26/2007 01:41 PM Please respond to Equinox development mailing list To: [EMAIL PROTECTED], equinox-dev@eclipse.org cc: Subject:[equinox-dev] [prov] fix for bugzilla I committed a fix for bugzilla 197404 - Profile class has wrong property name string assigned to PROP_NAME. I also fixed a couple of other naming inconsistencies, in particular property name constant for flavor from flavor to eclipse.prov.flavor. This has a side-effect in existing persisted profiles of causing an error dialog when browsing the profile properties in the UI, because there is no value under the new flavor key. The (draconian) solution is to delete the agent data and existing installs and the agent data and reinstall (if desired). Let me know if you have any questions/problems. - Dave___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] provisioning self hosting
My biggest problem at the time was that I was running eclipse in ways I had not had to before: - I usually run Eclipse application (workbench) launches, and using those OSGI and test launch configs was kind of bizarre. - If the data is not set up propertly you get those RepositoryCreation/FileNotFound exceptions and then it's like...hmmm..what do I do now? - I got confused by the startup sequence. I had to manually start the bundles in my code the first time in order to get a provisioning console, but after that they were resumed, so the sequence and timing of getting those exceptions changed. I'm not an OSGi hacker so I really didn't know how to diagnose or figure out how to debug things going on in startup. If the code could more gracefully handle missing xml files that would be a start (if there's no content.xml can we just assume an empty repository?) Also the existing doc kind of scared me off, with all the discussion of workspace left/middle/right. I'm still not sure I'm clear on the extra indirection of the middle workspace. I think it would have been better to explain things a bit better, and in particular how often/necessary it is to update the provisioning code in workspace left if you are updating it in workspace middle. As far as I understand, workspace middle is only necessary so that workspace right can be launched in the right way? Or perhaps I still don't quite get it. And...finally.. I think the terminology is a bit misleading because self hosting might imply self provisioning which we can do in a self hosting workspace, but not necessarily. I would be happy to discuss one on one if you think it's helpful, as I was ignorant of all things provisioning and OSGI coming into this... susan Jeff McAffer [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/23/2007 08:56 AM Please respond to Equinox development mailing list To: Equinox development mailing list equinox-dev@eclipse.org cc: Subject:Re: [equinox-dev] provisioning self hosting Not sure I understand. If one is writing some system that calls the provisioning API, they need to selfhost. Such a person may have no interest in how provisioning works, writing tools for it, ... They simply want to call the code to have things installed at runtime. An example would be someone porting TOAST to use the new provisioning stuff. They had their own provisioning, then put it one Update Manager and now want to put it on the new provisioning system. They develop bundles that have nothing to do with provisioning but when they run they need to be able to dynamically install them without having to deploy or generate metadata manually or... Code and run. The proviisoning Geting Started page is targetted at people looking to get started with the provisioning code. By definition it seems then that they fall into the groups you have identified plus the folks I pointed out. Who else would be reading the getting started page? BTW, I have no problem splitting up the page but am not clear on how to do that. Jeff Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/23/2007 09:02 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc equinox-dev@eclipse.org, [EMAIL PROTECTED] Subject Re: [equinox-dev] provisioning self hosting I helped Andrew O. with the self hosting setup and what became apparent at that time was this is *not* a getting started scenario for someone just willing to step through an installation. This setup is interesting for two groups of people, the tool smiths willing to understand how provisioning and PDE will be reconciliated in 3.4, and people willing to setup complex provisioning scenario without writing metadata manually. However those expectations were not clear, and scared people away from provisioning. Rather than building up this page I would appreciate if you could split the self hosting doc into its separate page. PaScaL Jeff McAffer/Ottawa/IB [EMAIL PROTECTED] To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] provisioning self 07/22/2007 09:23 hosting PM Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org In looking through provisioning bug reports recently there have been a few cases where people have expressed frustration or problems with their selfhosting setup.The configuration is currently quite
