Bug 286387 - [fiximprove][Sign][api]: Refactor MTJ in order to separate signing common features
Summary: [fiximprove][Sign][api]: Refactor MTJ in order to separate signing common fea...
Status: RESOLVED WORKSFORME
Alias: None
Product: MTJ (Archived)
Classification: Tools
Component: Signing (show other bugs)
Version: 1.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 1.0.2   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: api, core, ui
Depends on:
Blocks:
 
Reported: 2009-08-12 09:19 EDT by Diego Madruga Sandin CLA
Modified: 2010-07-07 13:27 EDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Madruga Sandin CLA 2009-08-12 09:19:47 EDT
MTJ currently contains embedded  sign components which could be refactored to be more generic in order to be  move into TFM (Tools For Mobile) project:

* Signing Framework: A generic framework to digitally sign created packages like MIDlets
* Certificate Manager: A user friendly UI to create, store and share code signing certificates

Those components could be moved from MTJ to the new project, while MTJ would retain the "Mobile Java" specific code, like e.g. a MIDlet signing extension which plugs into the new "generic signing framework".

The first action should be requirements definition and then we should evaluate the code we already have(current MTJ impl and MTJ 0.7 signing Framework) in order to reuse at least some part of it.

We must start the discussion about the best approach to be followed.
Comment 1 Eric Cloninger CLA 2009-08-17 16:33:52 EDT
Diego,

My and Christian's requirements are below.  Mauren Brenner from the TmL team will supply the ones that she has.

1) re-use as much of the existing code as possible (Platform, MTJ, old MTJ)
2) make it as flexible as reasonable possible, cover at least MIDP and Android requirements
3) allow to register new "signing providers" with a Eclipse plug-in mechanism, so that support/customization for specific platform requirements can be added as separate packaged plug-ins.
4) try to anticipate a Symbian signing scenario. No need to develop it, but don't make it impossible to add.
5) Provide hooks in the UI into the Project Navigator (sign package, unsign package) and the main menu.
6) Provide hooks into the build process so that post-build signing can be easily included

-E
Comment 2 Diego Madruga Sandin CLA 2009-08-17 17:01:05 EDT
Thanks Eric.

for now, I'll start prototyping on the mtj repository. I'll reuse part of the old implementation from the mtj 0.7 for the "signing providers" and the UI from our latest Releases.

The Pre/Pos sign hooks could be similar to the one we have on the build process.
I'll also study about Symbian signing to anticipate this scenario.

I'll be waiting for Mauren's requirements and I would also like to hear the opinion from Jon about possible requirements. 

Thanks,
Diego
Comment 3 Gorkem Ercan CLA 2010-06-29 19:15:10 EDT
I am lowering the priority of this one. It does not seem that critical... 

Eric is this someting that is worked as part of sequoyah?
Comment 4 Gorkem Ercan CLA 2010-07-07 13:27:47 EDT
Resolving this one as MTJ has no immediate need to refactor the signing API.. We can use a refactored one if it is provided elsewhere though.