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
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
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.e
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 or
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
Re: [equinox-dev] [vote] graduating the new jar processor bundle
lots of opportunities for exploiting jar processor +1 - Dave Jeff McAffer <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/09/2007 08: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
[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
