Scott Lewis wrote on 09/10/2007 12:58:10 PM:
> Actually, I'm a little surprised that you have so far passed the
> ProcessingSteps as output streams directly to the ECF OutputStream,
> as I was expecting that you would have a temporary file to receive
> the file contents, and then when the file
yes! re confusing names. Renaming the JarProcessor one sounds good to
me. Unless of course the p2 artifact repo processing steps make sense in
the JAR processor. :-)
Jeff
John Arthorne/Ottawa/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/10/2007 03:59 PM
Please respond to
Equinox de
Hi,
As you guessed, doing a "become" followed by an installation of the bits
installed in the user profile will cause a loss of information, since after
the completion of the become the profile will have completely forgotten
about the user IUs (the IUs that had been installed in the user profile)
The map file has been updated for the following Bug changes:
+ Bug 165964. Process Bundle-NativeCode at resolve time (FIXED)
+ Bug 200068. AdapterManager fails to find correct IAdapterFactory if the
IAdapterFactory implementation class loader cannot load the class returned
by the getAdapterList()
I have posted a new page "Multi-User Proposal for P2"
http://wiki.eclipse.org/Multi-User_Proposal_For_P2
James D
Miles/Austin/IBM@
I'm not sure it will be necessary to use JarProcessor for this. The main
benefit of using the JarProcessor is when doing modifications recursively
on nested jars. To verify during install, I think it's sufficient to
verify the top level artifact, so recursion isn't needed. Also, since
verific
Hi,
As we discussed on the call today, Tim and I have been working on a
Reconciler. Pascal mentioned his contentiously-named become operation
in the Director. This is very similar to what I wrote in our Reconciler
but now I'm at the stage where I want to "re-install" what was initially
in the "u
I did not know it included some fixes that were necessary.
+1
From: Andrew Niefer/Ottawa/[EMAIL PROTECTED]
Hi Jeff,
Jeff McAffer wrote:
Thanks to Stefan we have been introducing the notion of
ProcessingSteps to munge the content as it is downloaded from an
artifact repository. This allows for things like inline MD5 digest
checking, unpack200 processing, delta merging, signature checking, ...
+1
There is currently provisional API in the org.eclipse.osgi which is
currently used by update to check the certificate trust and to verify the
content of signed bundles. I assume the jar processor API can use an
IProcessStep to which uses the API from the framework to perform this type
of chec
+1
As for doing it now, is there any benefit to waiting?
There is some amount of work that will depend on this change. Both
update.core and pde.build will need to be updated after this change. As
well, the p2.jarprocessor is considered HEAD for bug fixes (there is at
least https://bugs.eclips
+1
[EMAIL PROTECTED] wrote on 09/09/2007 11:05:07 PM:
>
> As you may know, we used to have the JARProcessor embedded in the
> bowels of Update manager. Turns out that there are several uses for
> the processor (pack200 support, signing, verifying, ...) and having
> this function as a stand-alone
+1. This is release-hardened code, and deserves graduation. It is in wide
production use today in Eclipse 3.3, and in the eclipse.org jar signing
infrastructure. It needs a bit of cleanup (such as javadoc for its API),
but there is plenty of time for that in the 3.4 release cycle.
Jeff McAf
In the long, there is no discussion about doing this change. However the
benefits of doing it right away are not clear to me.
+0
PaScaL
From: Jeff McAffer/Ottawa/[EMAIL
+1
Jeff
McAffer/Ottawa/IB
[EMAIL PROTECTED]
15 matches
Mail list logo
