Never mind about the first patch, I did worse, when I started with Mercurial
I have started to look over your patch. As well I have read the ODF 1.2 package specification/schema and took a look into the W3C XML Digital Signature specification (ie. http://www.w3.org/TR/xmldsig-core ).
So much I understand: you have really not started with something trivial to contribute, Aziz.
As I am not an expert on signing, perhaps you might summarize in short what kind of subfeatures, the feature package signature does have from your point of view.
Certain is that I need more time to work myself further into your work, but even from a bird perspective I am already able to give suggestions of slight modifications, how your patch be adapted to the existing ODFDOM architecture:
to make, to adapt your work into the existing design:
1) As signatures are a package feature, all the classes might be moved into a directory, beyond org.odftoolkit.odfdom.pkg.signature
(I had done some refactorings using Netbeans refactoring feature and will add them as suggestion/patch soon.)
2) As signature depend on an XML schema, perhaps it makes sense to create a DOM representation of the signature XML elements/attributes as well?
I have not seen through the complete structure yet to be certain about it.
It might be possible by generating the DESIG DOM via the new generator (that might delay this patch a little more, but its definitely a feature for the next 0.8 release.
The generated classes might reside beyond:
The class Constants.java hold some values, that already exist in ODFDOM and might be hidden/refactored away. For now I used the package modifier to remove them from the JavaDoc API. (Similar works for FileEntryIdentifier.java, which is as well something not dependent on signature, but is a common package thing, that most likely exist (latest when we generate a DOM for the manifest.xml).
I was wondering that there was no new methods on the OdfPackage class to sign files from the package.
Regarding the methods we might add OdfPackage, we might orientate ourselves on the subfeatures that are offered on having a signature.
You are much more an expert on signature than I am, I simply read quickly some examples to identify a start for the (sub)features of the signature feature.
SIGN Package or subset with one or more SIGNATURE
The file have to be existent!!
The signature: Have to existent on some trusted site.
5) Finally, I have realized that some of the public/protected methods have not complete JavaDoc (e.g. return value was not explained). Well, you might call me picky on this, but on the other hand, if we do not add it from the beginning, who will ever add it and it should look 100% professional, don't you think
Good work! It's much easier to review, and slightly refactor than to write such code on oneself.
Thanks again for your contribution, looking forward to look further into your patch (although this week the generator has precedence)..