+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 <equinox-dev@eclipse.org>
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
