[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 168281. [launcher] JNI launching fails on aix.ppc (FIXED) + Bug 196890. Equinox 3.3 HttpService bundle not OSGi/Minimum-1.1 compliant. (ASSIGNED) + Bug 202496. [Launcher] Variable substitution in .ee files (FIXED) + Bug 204812. Exporters must not be counted as importers of their export. (FIXED) + Bug 205060. [app] testcase testDescriptorEvents01 fails intermittently (FIXED) + Bug 205990. [launcher] Invalid JVM options are silently ignored (ASSIGNED) + Bug 206377. Fix compiler warning in org.eclipse.osgi BundlePermissionCollection (FIXED) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.app org.eclipse.equinox.http org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [p2] p2 test case failure using 1015 head.
I successfully created a director application and launched it to provision the sdk using the -data C:\temp\workspace -configuration C:\temp\workspace\.config when there was still a configuration directory in the directory application install tree. However when I removed this configuration and depend only on the C:\temp\workspace\.config directory I get an error. bundles.txt and config.ini are located in the .config directory. It is finding the location of config.ini but it isn't finding the bundles.txt. org.osgi.framework.BundleException: Exception in org.eclipse.equinox.simpleconfigurator.internal.Activator.start() of bundle org.eclipse.equinox.simpleconfigurator. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.core.runtime.adaptor.EclipseStarter.startBundle(EclipseStarter.java:1140) at org.eclipse.core.runtime.adaptor.EclipseStarter.startBundles(EclipseStarter.java:1133) at org.eclipse.core.runtime.adaptor.EclipseStarter.loadBasicBundles(EclipseStarter.java:630) at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:303) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1170) at org.eclipse.equinox.launcher.Main.main(Main.java:1145) Caused by: java.io.FileNotFoundException: configuration\org.eclipse.equinox.simpleconfigurator\bundles.txt (The system cannot find the path specified.) at java.io.FileInputStream.(FileInputStream.java:135) at java.io.FileInputStream.(FileInputStream.java:95) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:85) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:176) at java.net.URL.openStream(URL.java:1041) at org.eclipse.equinox.internal.simpleconfigurator.utils.SimpleConfiguratorUtils.readConfiguration(SimpleConfiguratorUtils.java:131) at org.eclipse.equinox.simpleconfigurator.internal.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:75) at org.eclipse.equinox.simpleconfigurator.internal.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:96) at org.eclipse.equinox.simpleconfigurator.internal.Activator.start(Activator.java:47) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(AccessController.java:242) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 16 more Root exception: java.io.FileNotFoundException: configuration\org.eclipse.equinox.simpleconfigurator\bundles.txt (The system cannot find the path specified.) Launch command .\eclipse.exe -debug -data c:\temp\workspace -configuration c:\temp\workspace\.config -console -consolelog -noExit -vm C:/java50sr4/jre/bin/java.exe -application org.eclipse.equinox.p2.director.app.application -metadataRepository file:c:/tmp/equinox.p2/servers/metadataRepository/ -artifactRepository file:c:/tmp/equinox.p2/servers/artifactRepository/ -installIU sdk -destination c:/tmp/equinox.p2.bat/eclipseApp -flavor tooling -profile foo -vmargs -Declipse.p2.data.area=c:/tmp/equinox.p2.bat/agentData ___ 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 cc: Subject:Re: [equinox-dev] [p2] javascript Done |> | From: | |> >--| |Pascal Rapicault/Ottawa/[EMAIL PROTECTED] | >--| |> | To:| |> >--| |Equinox development mailing list | >--| |> | 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] [p2] javascript
Done |> | From: | |> >--| |Pascal Rapicault/Ottawa/[EMAIL PROTECTED] | >--| |> | To:| |> >--| |Equinox development mailing list | >--| |> | 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
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
Re: [equinox-dev] [prov] ECF partial file download implemented
This is excellent news. The version of the DownloadManagerStrategy I'm working on for M3 won't have the complexity to be able to take advantage of this new capability, but we will definitely be looking at using this in the M4 version which will have the more complex multi-threaded algorithm with automatic mirror switching. This should make the cost decision to switch to another mirror significantly easier. Thanks for the quick turnaround on putting in this feature. Cheers, Tim On Oct 15, 2007, at 12:32 PM, Scott Lewis wrote: FYI (especially Tim Webb), ECF has added the partial file download to the file transfer API as per these bugs from Equinox Summit: https://bugs.eclipse.org/bugs/show_bug.cgi?id=205011 https://bugs.eclipse.org/bugs/show_bug.cgi?id=204386 ECF 1.2 will be coming out this week, please consider voting for the release after review as described here: http://www.eclipse.org/ projects/ I suggest using ECF 1.2 release for Equinox Provisioning M3. Thanks, Scott ___ 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] 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] [prov] ECF partial file download implemented
FYI (especially Tim Webb), ECF has added the partial file download to the file transfer API as per these bugs from Equinox Summit: https://bugs.eclipse.org/bugs/show_bug.cgi?id=205011 https://bugs.eclipse.org/bugs/show_bug.cgi?id=204386 ECF 1.2 will be coming out this week, please consider voting for the release after review as described here: http://www.eclipse.org/projects/ I suggest using ECF 1.2 release for Equinox Provisioning M3. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: Re[2]: [equinox-dev] Graduation of Prosyst contributed bundles
We should develop some of our own testcases to get complete coverage. The OSGi test suite can be used by the committers (which are also OSGi members) during our test pass for each mile stone. The OSGi test cases should not be considered as a complete test suite, in many cases they will let bugs slip by. Every bug we fix which the OSGi test suite did not catch should likely have an automated testcase created. We have looked into running the OSGi TCK with each build during the junit tests, but the effort was high and in the end it was decided to run the OSGi TCK as part of our manual milestone test pass. Tom From: Pavlin Dobrev <[EMAIL PROTECTED]> To: Equinox development mailing list Date: 10/15/2007 10:11 AM Subject:Re[2]: [equinox-dev] Graduation of Prosyst contributed bundles All of the bundles that implement OSGi defined services: org.eclipse.equinox.ds org.eclipse.equinox.ip org.eclipse.equinox.wireadmin org.eclipse.equinox.io pass the corresponding OSGi test cases. How you proceed in this case because OSGi test cases are not publicly available? -Pavlin > We also will need to setup automated tests for the bundles which are > graduated. (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=206333) Tom Thomas Watson---10/15/2007 09:28:05 AM---The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production qu From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/15/2007 09:28 AM Subject: [equinox-dev] Graduation of Prosyst contributed bundles The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider:
Re[2]: [equinox-dev] Graduation of Prosyst contributed bundles
All of the bundles that implement OSGi defined services: org.eclipse.equinox.ds org.eclipse.equinox.ip org.eclipse.equinox.wireadmin org.eclipse.equinox.io pass the corresponding OSGi test cases. How you proceed in this case because OSGi test cases are not publicly available? -Pavlin > We also will need to setup automated tests for the bundles which are graduated. (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=206333) Tom Thomas Watson---10/15/2007 09:28:05 AM---The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production qu From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/15/2007 09:28 AM Subject: [equinox-dev] Graduation of Prosyst contributed bundles The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io (https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. Tom ___ 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] Graduation of Prosyst contributed bundles
We also will need to setup automated tests for the bundles which are graduated. (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=206333) Tom From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/15/2007 09:28 AM Subject:[equinox-dev] Graduation of Prosyst contributed bundles The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. Tom ___ 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] Graduation of Prosyst contributed bundles
The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev][prov] Staged update
ok but then "split phase" is too general. We need a term to talk about
the case where one downloads the stuff and then later does the
install/configure.
Jeff
John Arthorne/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/15/2007 08:56 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
We also have a "sizing phase" for computing the install size, which the UI
decouples from the other phases when a preview is shown to the user prior
to downloading. There will likely be other cases as the number of phases
grows.
I definitely don't suggest such terminology be exposed to end users. These
kinds of options can likely be posed to the user as simple questions or
radio button options - Download updates automatically (yes/no), Install
updates automatically (yes/no), etc.
Jeff McAffer/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/14/2007 11:08 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
That has nice feel at least for the general category of technical
discussions. It may be a too general though to capture just the
particular case of decoupling downloading and install/configure. Do you
see other instances of split phase scenarios?
Seems like there is a bit of a struggle between end-user terminology and
design/implementation ideas. Things like "split phase" may be a too
technical for end-user terminology ("phase" is unlikely to be exposed).
We'll probably have to look at that later in a larger context.
Jeff
John Arthorne/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 05:53 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
Another possibility is "split phase install" for the case of separating
the download from the configuration. This follows the engine terminology -
it's really splitting the phases into separate invocations of the engine.
That term would also capture any situation where the phases are broken
apart, rather than being specific to the separate download/configure case.
Jeff McAffer/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 04:05 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
Thanks for the clarification. Suggested terms
- deferred install or staged install
- sequenced install
I am not happy with the term following "deferred" or "sequenced". People
may read too much into it (e.g., does sequenced updating sequence installs
too?). perhaps * "operation".
Jeff
Pascal Rapicault/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 08:48 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
For context the item that Jim initially quoted came out of the questions
section of the wiki (http://wiki.eclipse.org/Equinox_p2_Plan). This
section
list questions that we need to answer by the end of M3 to decide what we
deliver in 3.4 will look like. The download before the installation is not
on this list because it is already decided that we will be doing it and
the
API work to allow that has been done as part of the refactoring of the
IDirector that got committed yesterday by Susan. I think I call that
"eager
download".
To avoid further confusion which terms do you think we should use for each
of these?
My proposal: "eager download" to refer to download before installation and
"staged updated" to refer to updates that must be happening.
Note that I'm not happy with any of these.
PaScaL
|>
| From: |
|>
>--|
|Jeff McAffer/Ottawa/[EMAIL PROTECTED] |
>--|
|>
| To:|
|>
>--|
|Equinox development mailing list |
>--|
|>
| Date: |
|>
>--|
|10/11/2007 06:38 PM|
>---
Re: [equinox-dev][prov] Staged update
We also have a "sizing phase" for computing the install size, which the UI
decouples from the other phases when a preview is shown to the user prior
to downloading. There will likely be other cases as the number of phases
grows.
I definitely don't suggest such terminology be exposed to end users. These
kinds of options can likely be posed to the user as simple questions or
radio button options - Download updates automatically (yes/no), Install
updates automatically (yes/no), etc.
Jeff McAffer/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/14/2007 11:08 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
That has nice feel at least for the general category of technical
discussions. It may be a too general though to capture just the
particular case of decoupling downloading and install/configure. Do you
see other instances of split phase scenarios?
Seems like there is a bit of a struggle between end-user terminology and
design/implementation ideas. Things like "split phase" may be a too
technical for end-user terminology ("phase" is unlikely to be exposed).
We'll probably have to look at that later in a larger context.
Jeff
John Arthorne/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 05:53 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
Another possibility is "split phase install" for the case of separating
the download from the configuration. This follows the engine terminology -
it's really splitting the phases into separate invocations of the engine.
That term would also capture any situation where the phases are broken
apart, rather than being specific to the separate download/configure case.
Jeff McAffer/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 04:05 PM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
Thanks for the clarification. Suggested terms
- deferred install or staged install
- sequenced install
I am not happy with the term following "deferred" or "sequenced". People
may read too much into it (e.g., does sequenced updating sequence installs
too?). perhaps * "operation".
Jeff
Pascal Rapicault/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 08:48 AM
Please respond to
Equinox development mailing list
To
Equinox development mailing list
cc
Subject
Re: [equinox-dev][prov] Staged update
For context the item that Jim initially quoted came out of the questions
section of the wiki (http://wiki.eclipse.org/Equinox_p2_Plan). This
section
list questions that we need to answer by the end of M3 to decide what we
deliver in 3.4 will look like. The download before the installation is not
on this list because it is already decided that we will be doing it and
the
API work to allow that has been done as part of the refactoring of the
IDirector that got committed yesterday by Susan. I think I call that
"eager
download".
To avoid further confusion which terms do you think we should use for each
of these?
My proposal: "eager download" to refer to download before installation and
"staged updated" to refer to updates that must be happening.
Note that I'm not happy with any of these.
PaScaL
|>
| From: |
|>
>--|
|Jeff McAffer/Ottawa/[EMAIL PROTECTED] |
>--|
|>
| To:|
|>
>--|
|Equinox development mailing list |
>--|
|>
| Date: |
|>
>--|
|10/11/2007 06:38 PM|
>--|
|>
| Subject: |
|>
>--|
|Re: [equinox-dev][prov] Staged update|
>
