Re: [equinox-dev] [prov] processing steps, restartable downloads and ECF
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 reception is done *then* > apply the ProcessingSteps. Is there something wrong with passing the data along immediate? I guess it would be a trade off. Some steps only work on whole files while others can be streamed. Streaming is more effecient since you have the bytes right there. there may be some buffering (e.g., performance) but there are several opportunities for optimization. We could also add a step at the beginning of a chain that buffers up the data in a file and then pumps it through. This sort of step could be used to do the restarting but if ECF already had (or could have) something, that seems like more fun. > But in any event, we can add impl support for pause/resume/caching > etc to the ECF receive implementations w/o changing API to support > required use cases. I would appreciate a little better > understanding of the existing ProcessingSteps and their function... > so could someone point me at the relevant packages/classes and I'll > take more of a look? The current code is in my workspace as I have been doing some significant reworking and have not finished. I will post to this list when it is released. > Seems like this would also be a good topic for the upcoming Equinox > Summit: what enhancements are needed for file transfer both at API > and impl: e.g. pause/resume enhancements, file caching, > monitoring/transfer statistics collection?, support more/other providers, etc. yes. I added this to the list. Under your name :-) Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [vote] graduating the new jar processor bundle
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 development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle 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 verification involves user participation(presenting certificates, asking if they trust the signer, etc), it may not work well as a processing step. An aside: it's already confusing me to have IProcessStep in the jar processor bundle, and IProcessingStep in the artifact repository. We should probably rename the former to IJarProcessStep, or some such. Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/10/2007 11:53 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle +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 check? Or would verifying the signed content continue to be a separate step as it is today in update? Tom Andrew Niefer ---09/10/2007 10:30:42 AM---+1 Andrew Niefer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/10/2007 10:29 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle +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.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/10/2007 09:54 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle 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 PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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://
Re: [equinox-dev] Reconciling two profiles
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) with all the consequences this could mean. Given that the current implementation of "become" analyzes the dependencies and adds what is necessary for satisfaction of the installation, what you may want to do is: - create a profile IU that refers to: 1 all the IUs referred to from the shared profile 2 all the user IUs, (maybe not all, but just the ones that were installed by the user in the first place (entry points)) - call become on the IU resulting from the previous computation. Another approach, that may not work with the current implementation but may worth thinking about is: - the user profile contains an IU representing the shared profile (if you were to list the IUs in the profile you would see this IU). - then, when the shared profile changes, the reconciliation operation consists in replacing (IDirector.replace()) the IU representing the old version of the shared profile by the new one and "let the magic happen" Pros of this approach: - it is really explicit that this profile is 'derived' from another one since there is a reference to it Cons: - the reference to the profile may turn out to be problematic when the user IUs need to cause changes in what is referred from it - reconciliation could only happen on such profiles, whereas the concept of reconciliation is interesting in other contexts (for example, I want to make my profile like Andrew's one but I want to keep the IUs that I had). HTH, PaScaL From: Andrew Overholt <[EMAIL PROTECTED]> To: equinox-dev@eclipse.org Date: 09/10/2007 03:16 PM Subject:[equinox-dev] Reconciling two profiles 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 "user" (for lack of better source/target mandatory/optional terminology) profile. Should we do just that: re-install the IUs that were previously there? That would be simple and we could just use Director.become and then a bunch of install operations. But will this mess up preferences or other things that may be stored in profiles? What about stuff that was configured in the profile? Ideally everything would be the same as it was before except if it _needed_ to be changed by the morphing of the underlying "base" profile. Thoughts? Andrew (See attached file: attayt6r.dat) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev attayt6r.dat Description: Binary data ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
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() method (FIXED) + Bug 201489. [osgi R5] multiple versions of a fragment should not attach to the same host (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi org.eclipse.equinox.common org.eclipse.equinox.supplement Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Comments on "Equinox Provisioning Engine" Wiki page
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@ IBMUS To Sent by: Equinox development mailing list equinox-dev-bounc [EMAIL PROTECTED] cc Subject 09/07/2007 10:14 Re: [equinox-dev] [prov] Comments AMon "Equinox Provisioning Engine" Wiki page Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> Most of these questions and requirements center on how to implement a multiuser implementation. I will post information on that in bug 185826 today, hopefully. Then we can continue the discussion as appropriate. Sorry I am so late to the party. Inactive hide details for Simon Kaegi <[EMAIL PROTECTED]>Simon Kaegi <[EMAIL PROTECTED]> Simon Kaegi To Sent by: equinox-de Equinox development mailing v-bounces@ list eclipse.or g cc 09/07/2007 09:31 AM Subject Re: [equinox-dev] [prov] Please respond to Comments on "Equinox Equinox development mailing list Provisioning Engine" Wiki page [EMAIL PROTECTED] wrote on 09/06/2007 10:28:55 AM: > Simon thanks for adding the info to the wiki. I have a lot of > questions and comments but will constrain myself to a few here. Once > these are clarified I will attack the remainder. > > In the section "Engine processing model and phases" > You list collect, validate, uninstall/unconfigure,... > Is this the order that an operation is asked if it wants to participate in? That's right, the engine will run over the phases in order. The list of phases provided on the wiki is really a starting point as they fit with the code we have in the engine. I'm hoping we will have stable set of phases sooner rather than later as this can affect operations and also the touchpoint action content in IUs when we get to that. > The uninstall/unconfigure is not clear. I view these as separate > phases. And unconfigure would come first. > In general I don't know what is meant by the use of the '/' means. The '/' was meant to denote uncertainty. Originally I did put in the various associated config phases however when I actually went to the coding it felt redundant. e.g. we *always* did the unconfig, migrate, initconfig when doing the paired up uninstall, update, or install phase. We can look at re-adding the phases however I'd like to have some rational. Perhaps the logical separation of the type of w
Re: [equinox-dev] [vote] graduating the new jar processor bundle
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 verification involves user participation(presenting certificates, asking if they trust the signer, etc), it may not work well as a processing step. An aside: it's already confusing me to have IProcessStep in the jar processor bundle, and IProcessingStep in the artifact repository. We should probably rename the former to IJarProcessStep, or some such. Thomas Watson <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/10/2007 11:53 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle +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 check? Or would verifying the signed content continue to be a separate step as it is today in update? Tom Andrew Niefer ---09/10/2007 10:30:42 AM---+1 Andrew Niefer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/10/2007 10:29 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle +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.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/10/2007 09:54 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle 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 PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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
[equinox-dev] Reconciling two profiles
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 "user" (for lack of better source/target mandatory/optional terminology) profile. Should we do just that: re-install the IUs that were previously there? That would be simple and we could just use Director.become and then a bunch of install operations. But will this mess up preferences or other things that may be stored in profiles? What about stuff that was configured in the profile? Ideally everything would be the same as it was before except if it _needed_ to be changed by the morphing of the underlying "base" profile. Thoughts? Andrew pgpHsr4btJKq2.pgp Description: PGP signature ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [vote] graduating the new jar processor bundle
I did not know it included some fixes that were necessary. +1 From: Andrew Niefer/Ottawa/[EMAIL PROTECTED] To: Equinox development mailing list Date: 09/10/2007 11:30 AM Subject:Re: [equinox-dev] [vote] graduating the new jar processor bundle +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.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: To [EMAIL PROTECTED] Equinox development mailing list cc 09/10/2007 09:54 AM Subject Re: [equinox-dev] [vote] Please respond tograduating the new jar processor Equinox development mailing listbundle 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 PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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
Re: [equinox-dev] [prov] processing steps, restartable downloads and ECF
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, ... All great stuff. Pascal just raised a very interesting question. How do we handle restarting? Some background. In the current prototype (in my workspace, not yet in CVS) there is a chain of ProcessingStep objects. Each step is actually an OutputStream that knows about the next step (output stream) in the chain. When a byte is written to step/stream N, it is processed (counted, transformed, ...) and then the result passed on to step N+1. This repeats until finally the content gets to the last stream in the chain which is usually a FileOutputStream of some sort and so the content is then written to disk. All is well. Now, what happens if we crash or the user somehow pauses the download? The content is partially processed/transformed but it would likely be too costly for each step to persist its intermediate results. It would be more likely that somehow the raw content coming in to the head of the chain of steps is cached and then when the download is restarted after a crash/exit, the chain is recreated and the download is effectively replayed through the chain from the cache. When that is done, the further content from the source would then be pushed through the chain. So, two questions. Does this make sense? and if so, how should we implement this? I wonder if ECF has some technology/support/designs in this area since it seems they support restartable downloads. Scott? Unfortunately not as much as we would like. We do have API support for pausing/resuming downloads (IFileTransferPausable), and the existing impls do naively support this interface, but we need/want to add further/better implementation support (e.g. direct protocol support for protocols that have pause/resume, partial file caching, etc). 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 reception is done *then* apply the ProcessingSteps. But in any event, we can add impl support for pause/resume/caching etc to the ECF receive implementations w/o changing API to support required use cases. I would appreciate a little better understanding of the existing ProcessingSteps and their function...so could someone point me at the relevant packages/classes and I'll take more of a look? Seems like this would also be a good topic for the upcoming Equinox Summit: what enhancements are needed for file transfer both at API and impl: e.g. pause/resume enhancements, file caching, monitoring/transfer statistics collection?, support more/other providers, etc. Scott Jeff ___ 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] [vote] graduating the new jar processor bundle
+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 check? Or would verifying the signed content continue to be a separate step as it is today in update? Tom Andrew Niefer <[EMAIL PROTECTED] om>To Sent by: Equinox development mailing list equinox-dev-bounc [EMAIL PROTECTED] cc Subject 09/10/2007 10:29 Re: [equinox-dev] [vote] graduating AMthe new jar processor bundle Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> +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.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: To [EMAIL PROTECTED] Equinox development mailing list cc 09/10/2007 09:54 AM Subject Re: [equinox-dev] [vote] Please respond to graduating the new jar Equinox development mailing list processor bundle 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 PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3
Re: [equinox-dev] [vote] graduating the new jar processor bundle
+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.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/10/2007 09:54 AM Please respond to Equinox development mailing list To Equinox development mailing list cc Subject Re: [equinox-dev] [vote] graduating the new jar processor bundle 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 PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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] [vote] graduating the new jar processor bundle
+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 bundle would be "a good thing"(tm). > So in the p2 work we did just that and created org.eclipse.equinox. > p2.jarprocessor. Bug > https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 > talks about updating update to use the new processor. Of course, > the current JarProcessor bundle is in the Equinox Incubator. To > date I think we have avoided cases where we build the mainstream SDK > based on content from an incubator. > > We have two choices, we can wait to move Update over or we can > graduate the current JARProcessor bundle. Here I popose the latter > since the code in the bundle is unchanged from the original that > shipped in 3.3. All we are doing is putting it in a separate > bundle. The only thing at issue is the shape of the API and that can > evolve until the API freeze just as any other bundle in HEAD. > > So consider this a formal call for voting on graduating the org. > eclipse.equinox.p2.jarprocessor bundle. > +1 from me. > > Jeff ___ > 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] [vote] graduating the new jar processor bundle
+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 McAffer/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/09/2007 11:05 PM Please respond to Equinox development mailing list To equinox-dev@eclipse.org cc Subject [equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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] [vote] graduating the new jar processor bundle
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 PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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] [vote] graduating the new jar processor bundle
+1 Jeff McAffer/Ottawa/IB [EMAIL PROTECTED] To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] [vote] graduating the 09/09/2007 11:05 new jar processor bundle PM Please respond to Equinox development mailing list <[EMAIL PROTECTED] pse.org> 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 bundle would be "a good thing"(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the code in the bundle is unchanged from the original that shipped in 3.3. All we are doing is putting it in a separate bundle. The only thing at issue is the shape of the API and that can evolve until the API freeze just as any other bundle in HEAD. So consider this a formal call for voting on graduating the org.eclipse.equinox.p2.jarprocessor bundle. +1 from me. Jeff ___ 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
