Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/10/2007 11:53 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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



Inactive hide details for Andrew Niefer ---09/10/2007 10:30:42 AM---+1Andrew Niefer ---09/10/2007 10:30:42 AM---+1
Andrew Niefer <aniefer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/10/2007 10:29 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>



To

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

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/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/10/2007 09:54 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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/IBM@IBMCA                                                                        
                                                                                                                 
To:         equinox-dev@xxxxxxxxxxx                                                                              
                                                                                                                 
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@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Back to the top