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. 
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.

equinox-dev mailing list

Reply via email to