[equinox-dev] [p2] Milestone update site for 3.4
Apologies for the persistence on this issue, but we are actively using the 3.4 milestones site for provisioning to clients and the current corruption is causing an outage to our users. https://bugs.eclipse.org/bugs/show_bug.cgi?id=232352 The current mismatch as described in the bug above guarantees that no provisioning can be performed using the milestone site with p2 (the artifacts.jar has M7 artifacts while the content.jar has M6a and earlier IUs -- never the two shall meet). Is the expectation that this site should be available for provisioning? Is there a better site to use that contains the 3.4 milestone builds? Any assistance in cleaning up the site would be appreciated. Thanks, Tim___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] manifest changes
My thought too. Unfortunately PDE Update Classpath didn't seem to help. On Feb 21, 2008, at 7:15 PM, Jeff McAffer wrote: Feels like a missing "Update classpath" or some such. This all works fine for me though I do have foundation 1.1 installed. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:equinox-dev- [EMAIL PROTECTED] On Behalf Of Timothy Webb Sent: Thursday, February 21, 2008 6:07 PM To: Equinox development mailing list Subject: Re: [equinox-dev] [prov] manifest changes The errors I receive are all due to "is not accessible due to restriction on required library jre..\lib\rt.jar". It appears that PDE is still attempting to include those values from my JRE. My guess would be that since I don't have a foundation 1.1 compatible JVM installed, it is continuing to try and resolve the classes from the 1.6 JRE that I have configured for this workspace instead of using the org.apache.xerces project that is available. I do indeed see org.apache.xerces listed in the Plug-in Dependencies for this project. As a complete guess, I modified by hand the .classpath file. I moved the Plug-in Dependencies library prior to the JRE one. Doing this fixed the compile errors for me. I'm guessing we probably shouldn't be dependent on the ordering of the build path for something like this...? On Feb 21, 2008, at 4:44 PM, DJ Houghton wrote: This is strange... I'm not sure why you would get errors. What type of errors do you see? Are they to the effect of "...can't see due to access restriction on org.apache.xerces"? Either way, the code has been checked out for the test build so I have reverted the change in HEAD so if you reload you should be ok. But we still need to figure out why you are getting these errors. [EMAIL PROTECTED] wrote on 02/21/2008 04:28:19 PM: When I picked up this change on two different systems, I receive build errors on the artifact repository about not being able to find the various XML files. I do have xerces in my workspace and doing the normal tricks to get the project building seem to be failing. Any suggestions on why this change would break compilation? Thanks, Tim On Feb 21, 2008, at 2:47 PM, DJ Houghton wrote: I have released a change to the manifest file for the org.eclipse.equinox.p2.artifact.repository project so Kim can test the Foundation EE in the build. If you have this project (and this change) loaded into your workspace and a Foundation 1.1 VM set up, it will also require that you have a project like Xerces also in your workspace. Xerces is already in the project set file so you should be good, but I just wanted to give you a heads up in case you see strange errors about not finding XML classes. ___ 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 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] manifest changes
The errors I receive are all due to "is not accessible due to restriction on required library jre..\lib\rt.jar". It appears that PDE is still attempting to include those values from my JRE. My guess would be that since I don't have a foundation 1.1 compatible JVM installed, it is continuing to try and resolve the classes from the 1.6 JRE that I have configured for this workspace instead of using the org.apache.xerces project that is available. I do indeed see org.apache.xerces listed in the Plug-in Dependencies for this project. As a complete guess, I modified by hand the .classpath file. I moved the Plug-in Dependencies library prior to the JRE one. Doing this fixed the compile errors for me. I'm guessing we probably shouldn't be dependent on the ordering of the build path for something like this...? On Feb 21, 2008, at 4:44 PM, DJ Houghton wrote: This is strange... I'm not sure why you would get errors. What type of errors do you see? Are they to the effect of "...can't see due to access restriction on org.apache.xerces"? Either way, the code has been checked out for the test build so I have reverted the change in HEAD so if you reload you should be ok. But we still need to figure out why you are getting these errors. [EMAIL PROTECTED] wrote on 02/21/2008 04:28:19 PM: When I picked up this change on two different systems, I receive build errors on the artifact repository about not being able to find the various XML files. I do have xerces in my workspace and doing the normal tricks to get the project building seem to be failing. Any suggestions on why this change would break compilation? Thanks, Tim On Feb 21, 2008, at 2:47 PM, DJ Houghton wrote: I have released a change to the manifest file for the org.eclipse.equinox.p2.artifact.repository project so Kim can test the Foundation EE in the build. If you have this project (and this change) loaded into your workspace and a Foundation 1.1 VM set up, it will also require that you have a project like Xerces also in your workspace. Xerces is already in the project set file so you should be good, but I just wanted to give you a heads up in case you see strange errors about not finding XML classes. ___ 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] manifest changes
When I picked up this change on two different systems, I receive build errors on the artifact repository about not being able to find the various XML files. I do have xerces in my workspace and doing the normal tricks to get the project building seem to be failing. Any suggestions on why this change would break compilation? Thanks, Tim On Feb 21, 2008, at 2:47 PM, DJ Houghton wrote: I have released a change to the manifest file for the org.eclipse.equinox.p2.artifact.repository project so Kim can test the Foundation EE in the build. If you have this project (and this change) loaded into your workspace and a Foundation 1.1 VM set up, it will also require that you have a project like Xerces also in your workspace. Xerces is already in the project set file so you should be good, but I just wanted to give you a heads up in case you see strange errors about not finding XML classes. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] p2 test repo working?
Can you confirm what URL you are using to connect? I receive 404 accessing the following URLs for a browser: http://update.eclipse.org/eclipse/testUpdates/content.jar http://update.eclipse.org/eclipse/testUpdates/content.xml http://update.eclipse.org/eclipse/testUpdates/site.xml Or is p2 caching what was the last known good configuration for these sites? Tim On Feb 1, 2008, at 4:43 AM, DJ Houghton wrote: There must have been something temporarily wrong with the server because it seems to be corrected now... the content is there. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] p2 provisioned eclipse missing companion library
Pascal, I'm close now but after a number of hours in the debugger, I'm finding that the resolver isn't correctly finding the IU fragments for some of the bundles. Are others attempting to do installation of things other than the SDK or other pre-configured line-ups? All my meta data now looks correct but it still am having issues having the install of IUs work. Tim On Jan 31, 2008, at 3:14 PM, Pascal Rapicault wrote: John and I have been doing that since M3 (some hickups of course occured) and that worked and I confirm that yesterday's build works as well. However we are deploying a 3.4 eclipse and not a 3.3. Normally when p2 installs the SDK, a -startup and -launcher.library arguments are being set to point ot the jar. You say: In our eclipse.ini file we drop down next to the exe, Do you actually drop the ini file? If so this is the pb. The ini files are no longer file that you lay down. Instead they result from the installation of some IUs (for example, see the toolingorg.eclipse.equinox.launcher IU) HTH, PaScaL |> | From: | |> ------| |Timothy Webb < tim @trwebb .com > | --| |> | To:| |> --| |Equinox development mailing list dev @eclipse .org > | --| |> | Date: | |> --| |01/31/2008 03:47 PM | --| |> | Subject: | |> --| |[equinox-dev] [prov] p2 provisioned eclipse missing companion library | --| Are others having success using p2 to provision an Eclipse where the cache directory is not collocated with the eclipse exe? I'm running into an issue where despite having what appears to be the right set of software downloaded in the cache, configured in the platform.xml / config.ini, etc., each time I try to run the eclipse.exe, I receive "The eclipse executable launcher was unable to locate its companion launcher jar." In looking through the C code for the launcher, it looks like Eclipse is designed to search for the companion library in the plugins area, located near the exe, or by specifying --launcher.library on the command line. In our eclipse.ini file we drop down next to the exe, I don't see a --launcher.library argument configured. Is this something that should be setup by default in the normal touchpoints? Or, is there a branch of the Eclipse.exe that is designed to work better with p2-style deployments? Thanks, Tim ___ 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 test repo working?
I'm seeing the same thing. When I access the URLs directly, I see a 404 error. http://update.eclipse.org/eclipse/testUpdates/content.jar http://update.eclipse.org/eclipse/testUpdates/content.xml Neither work for me. Tim On Jan 31, 2008, at 9:20 PM, Susan Franklin McCourt wrote: Am I the only one seeing this when I try to use the URL below? I haven't been able to connect to the test updates URL since it was repopulated !ENTRY org.eclipse.equinox.p2.ui 4 0 2008-01-31 19:21:01.156 !MESSAGE Error loading repository http://update.eclipse.org/eclipse/testUpdates/ !STACK 1 org.eclipse.equinox.p2.core.ProvisionException: No repository found at http://update.eclipse.org/eclipse/testUpdates/ at org .eclipse .equinox .internal .p2 .metadata .repository .MetadataRepositoryManager.fail(MetadataRepositoryManager.java:160) at org .eclipse .equinox .internal .p2 .metadata .repository .MetadataRepositoryManager .loadRepository(MetadataRepositoryManager.java:292) at org .eclipse .equinox .p2 .ui .operations .ProvisioningUtil.loadMetadataRepository(ProvisioningUtil.java:57) at org .eclipse .equinox .p2 .ui .model .MetadataRepositoryElement .getMetadataRepository(MetadataRepositoryElement.java:83) at org .eclipse .equinox .p2 .ui .model .MetadataRepositoryElement .getQueryable(MetadataRepositoryElement.java:72) at org .eclipse .equinox .internal .p2 .ui .sdk .ProvSDKQueryProvider.getQueryDescriptor(ProvSDKQueryProvider.java:60) at org .eclipse .equinox .internal .p2 .ui .model.RemoteQueriedElement.fetchChildren(RemoteQueriedElement.java: 44) at org .eclipse .equinox .internal .p2 .ui .model .RemoteQueriedElement .fetchDeferredChildren(RemoteQueriedElement.java:33) at org.eclipse.equinox.internal.p2.ui.viewers.AvailableIUContentProvider $2.run(AvailableIUContentProvider.java:159) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) ___ 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] p2 provisioned eclipse missing companion library
Ok, after debugging through the generator code, the issue was what I
was pointing the generator to. As I wanted to generate multiple
platforms, I copied the feature / plugin folders from multiple Eclipse
downloads into a directory along with the RCP delta pack. When I ran
the generator, since it didn't know the configuration, the generator
didn't generate some of the necessary instructions including the
addProgramArg that would be needed for the launcher to work. Is it
expected that the generator should just continue on in this situation?
Anyway, looks like I'm underway again.
Thanks,
Tim
On Jan 31, 2008, at 3:43 PM, Timothy Webb wrote:
Pascal,
Thanks for the pointers. The eclipse.ini as well as other files are
indeed being dropped down by p2. Perhaps this is an issue that
relates to the metadata generator producing output that is not
expected. How and when did you last generate the p2 metadata you
are running against?
Here's what I see for the toolingorg.eclipse.launcher...'s
touchpoints:
cleanupzip(source:@artifact, target:${installFolder});
unzip(source:@artifact, target:${installFolder});
And for the org.eclipse.launcher...'s touchpoints:
(and that's it)
Is there a public "known good" p2 site that I can validate against?
It looks like the milestone site still doesn't have p2 format data
available.
From what I'm seeing, the currently checked-in metadata generator is
not including the addProgramArg instructions to the
org.eclipse.launcher... IUs' touchpoints as should be indicated by
the code in EclipseInstallGenerator. I will continue digging but I
am curious what version of the generator others are using to perform
their testing.
I've tested regenerating the meta using the current code against
both an Eclipse 3.3 as well as 3.4M4 build with the same result.
Thanks,
Tim
On Jan 31, 2008, at 3:14 PM, Pascal Rapicault wrote:
John and I have been doing that since M3 (some hickups of course
occured)
and that worked and I confirm that yesterday's build works as well.
However we are deploying a 3.4 eclipse and not a 3.3.
Normally when p2 installs the SDK, a -startup and -launcher.library
arguments are being set to point ot the jar.
You say: In our eclipse.ini file we drop down next to the exe,
Do you actually drop the ini file? If so this is the pb. The ini
files are
no longer file that you lay down. Instead they result from the
installation
of some IUs (for example, see the
toolingorg.eclipse.equinox.launcher IU)
HTH,
PaScaL
|>
| From: |
|>
------|
|Timothy Webb
<
tim
@trwebb
.com
>
|
--|
|>
| To:|
|>
--|
|Equinox development mailing list dev
@eclipse
.org
>
|
--|
|>
| Date: |
|>
--|
|01/31/2008 03:47
PM
|
--|
|>
| Subject: |
|>
--|
|[equinox-dev] [prov] p2 provisioned eclipse missing companion
library
|
--|
Are others having success using p2 to provision an Eclipse where the
cache directory is not collocated with the eclipse exe?
I'm running into an issue where despite having what appears to be the
right set of software downloaded in the cache, configured in the
platform.xml / config.ini, etc.,
Re: [equinox-dev] [prov] p2 provisioned eclipse missing companion library
Pascal,
Thanks for the pointers. The eclipse.ini as well as other files are
indeed being dropped down by p2. Perhaps this is an issue that
relates to the metadata generator producing output that is not
expected. How and when did you last generate the p2 metadata you are
running against?
Here's what I see for the toolingorg.eclipse.launcher...'s touchpoints:
cleanupzip(source:@artifact, target:${installFolder});
unzip(source:@artifact, target:${installFolder});
And for the org.eclipse.launcher...'s touchpoints:
(and that's it)
Is there a public "known good" p2 site that I can validate against?
It looks like the milestone site still doesn't have p2 format data
available.
From what I'm seeing, the currently checked-in metadata generator is
not including the addProgramArg instructions to the
org.eclipse.launcher... IUs' touchpoints as should be indicated by the
code in EclipseInstallGenerator. I will continue digging but I am
curious what version of the generator others are using to perform
their testing.
I've tested regenerating the meta using the current code against both
an Eclipse 3.3 as well as 3.4M4 build with the same result.
Thanks,
Tim
On Jan 31, 2008, at 3:14 PM, Pascal Rapicault wrote:
John and I have been doing that since M3 (some hickups of course
occured)
and that worked and I confirm that yesterday's build works as well.
However we are deploying a 3.4 eclipse and not a 3.3.
Normally when p2 installs the SDK, a -startup and -launcher.library
arguments are being set to point ot the jar.
You say: In our eclipse.ini file we drop down next to the exe,
Do you actually drop the ini file? If so this is the pb. The ini
files are
no longer file that you lay down. Instead they result from the
installation
of some IUs (for example, see the
toolingorg.eclipse.equinox.launcher IU)
HTH,
PaScaL
|>
| From: |
|>
------|
|Timothy Webb
<
tim
@trwebb
.com
>
|
--|
|>
| To:|
|>
--|
|Equinox development mailing list dev
@eclipse
.org
>
|
--|
|>
| Date: |
|>
--|
|01/31/2008 03:47
PM
|
--|
|>
| Subject: |
|>
--|
|[equinox-dev] [prov] p2 provisioned eclipse missing companion
library
|
--|
Are others having success using p2 to provision an Eclipse where the
cache directory is not collocated with the eclipse exe?
I'm running into an issue where despite having what appears to be the
right set of software downloaded in the cache, configured in the
platform.xml / config.ini, etc., each time I try to run the
eclipse.exe, I receive "The eclipse executable launcher was unable to
locate its companion launcher jar." In looking through the C code for
the launcher, it looks like Eclipse is designed to search for the
companion library in the plugins area, located near the exe, or by
specifying --launcher.library on the command line. In our eclipse.ini
file we drop down next to the exe, I don't see a --launcher.library
argument configured. Is this something that should be setup by
default in the normal touchpoints? Or, is there a branch of the
Eclipse.exe that is designed to work better with p2-style deployments?
Thanks
[equinox-dev] [prov] p2 provisioned eclipse missing companion library
Are others having success using p2 to provision an Eclipse where the cache directory is not collocated with the eclipse exe? I'm running into an issue where despite having what appears to be the right set of software downloaded in the cache, configured in the platform.xml / config.ini, etc., each time I try to run the eclipse.exe, I receive "The eclipse executable launcher was unable to locate its companion launcher jar." In looking through the C code for the launcher, it looks like Eclipse is designed to search for the companion library in the plugins area, located near the exe, or by specifying --launcher.library on the command line. In our eclipse.ini file we drop down next to the exe, I don't see a --launcher.library argument configured. Is this something that should be setup by default in the normal touchpoints? Or, is there a branch of the Eclipse.exe that is designed to work better with p2-style deployments? Thanks, Tim ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] Data produced from metadata generator has wrong touchpoint?
Are things in churn right now with the metadata generator? It seems
to be producing meta with the wrong touchpoint type. Here's a snippit
from the generated content.xml that I received:
uninstallFeature(feature:$
{artifact},featureId:default,featureVersion:default)
installFeature(feature:$
{artifact},featureId:default,featureVersion:default)
As I understand it, certain instructions like installFeature and
installBundle require use of the "eclipse" touchpoint. If you run the
above code, I get exceptions about unknown action (installFeature /
installBundle) when it tries to execute the install phase.
Tim___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Trick to using repo optimizer?
Thanks, the optional flag was indeed the trick. Once I asked for optional bundles to be included, the add required picked up 3 additional bundles and the launch configuration worked as expected. Cheers, Tim On Jan 30, 2008, at 10:48 AM, DJ Houghton wrote: We've recently updated ECF to a new version and it brings in the core.net bundle. Try updating your launch config to add this new bundle with the "add required bundles" button. (yes, ECF's dependency on core.net is optional but not really yet... this will be fixed in the next release of ECF) [EMAIL PROTECTED] wrote on 01/30/2008 11:41:59 AM: Is there a trick to using the repo optimizer for p2 to generate the pack200 files? When I run the optimize OSGi app off of HEAD, I receive the following error. Validating the bundle hierarchy seems to show no issues. I've tried running the workspace off of 3.4M4 as well as the latest integration build. Thanks, Tim osgi> !SESSION 2008-01-30 10:32:31.658 --- eclipse.buildId=unknown java.version=1.5.0_11 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -application org.eclipse.equinox.p2.artifact. optimizers.pack200optimizer -artifactRepository file:d:/prov/repo Command-line arguments: -dev file:C:/devel/genuitec/.metadata/. plugins/org.eclipse.pde.core/optimizer/dev.properties -console - consolelog -application org.eclipse.equinox.p2.artifact.optimizers. pack200optimizer -artifactRepository file:d:/prov/repo -console !ENTRY org.eclipse.osgi 4 0 2008-01-30 10:32:35.377 !MESSAGE Application error !STACK 1 java.lang.NoClassDefFoundError: org.eclipse.core.net.proxy.IProxyService at org .eclipse.ecf.internal.provider.filetransfer.Activator.getProxyService( Activator.java:91) at org.eclipse.ecf.provider.filetransfer.retrieve. AbstractRetrieveFileTransfer.setupProxies( AbstractRetrieveFileTransfer.java:540) at org.eclipse.ecf.provider.filetransfer.retrieve. AbstractRetrieveFileTransfer.sendRetrieveRequest( AbstractRetrieveFileTransfer.java:488) at org.eclipse.ecf.provider.filetransfer.retrieve. AbstractRetrieveFileTransfer.sendRetrieveRequest( AbstractRetrieveFileTransfer.java:309) at org.eclipse.ecf.provider.filetransfer.retrieve. MultiProtocolRetrieveAdapter.sendRetrieveRequest( MultiProtocolRetrieveAdapter.java:95) at org .eclipse .equinox.internal.p2.artifact.repository.ECFTransport.transfer( ECFTransport.java:106) at org .eclipse .equinox.internal.p2.artifact.repository.ECFTransport.download( ECFTransport.java:67) at org.eclipse.equinox.internal.p2.artifact.repository.simple. SimpleArtifactRepositoryFactory .load(SimpleArtifactRepositoryFactory.java:44) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager .loadRepository(ArtifactRepositoryManager.java:305) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager .loadRepository(ArtifactRepositoryManager.java:287) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager .createRepository(ArtifactRepositoryManager.java:148) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager.restoreDownloadCache( ArtifactRepositoryManager.java:401) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager.restoreRepositories( ArtifactRepositoryManager.java:462) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager .getRepository(ArtifactRepositoryManager.java:238) at org.eclipse.equinox.internal.p2.artifact.repository. ArtifactRepositoryManager .loadRepository(ArtifactRepositoryManager.java:281) at org.eclipse.equinox.internal.p2.artifact.optimizers.pack200. Application.setupRepository(Application.java:47) at org.eclipse.equinox.internal.p2.artifact.optimizers.pack200. Application.start(Application.java:35) at org.eclipse.equinox.internal.app.EclipseAppHandle.run( EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher. runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start( EclipseAppLauncher.java:76) at org .eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 362 ) at org .eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 175 ) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:561) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501) at org.eclipse.equinox.launcher.Main.run(Main.java:1239) at org.eclipse.equinox.launcher.Main.main(Main.java:1215) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclips
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
