I would like to check for the presence of a valid license header in our Java source code using the com.mycila:license-maven-plugin
The issue is currently that most files contain additional text - besides the license - in the initial comment. Several programmers obviously added the class' name (plus an empty line) before the license (maybe that was also done automatically by an earlier IDE), others added additional details about the class after the license header.
Since I don't want to omit that extra text I am seeking for a possibility or option to check for the presence of the exact license header content but allow at least for additional leading text (which should be ignored otherwise).
The cases which contain additional text after the license are not too frequent, so here I could imagine to manually split those into two comments.
It would be great if the plugin would only check that the license header is contained in the first comment, not that the first comment it is completely identical to the predefined header.
Is that feasible?
Related
I want to place same externally signed signature container (signature value) at multiple places in a PDF.
I have referred the page 'How to place the Same Digital signatures to Multiple places in PDF using itextsharp.net'.
While working with the above mentioned work-around, I observed that whenever I tried to place multiple signatures on single page like 4-5 times, it never worked. Always shows only one valid signature field and other fields as unsigned (unsigned PDF form fields). So couldn't understand the problem.
Now I wanted to know whether any reference material is available to see how PdfLiteral and PdfIndirectReference works? I have gone through the itextsharp reference document but couldn't get enough information. In addition to this is there any limitation on how many annotations/signature fields one can add in a PDF?
And If I have to use BlankSignatureContainer and MakeSignature.SignDeferred then how the signature will get attached to all the fields because in,
MakeSignature.SignDeferred(pdfreader, "Sig", output, externalcontainer)
we have to pass only one signature field name.
Thank you.
You are asking for something of which mkl wrote:
Beware: While this procedure creates something which does not violate
the letter of the PDF specifications (which only forbid the cases
where the same field object is referenced from multiple pages, be it
via the same or via distinct widgets), it clearly does violate its
intent, its spirit. Thus, this procedure might also become forbidden as part of a Corrigenda document for the specification.
Actually, what you are asking does violate the specification. See section 12.7.5.5 of the ISO standard for PDF:
Allow me to repeat the last line of this screen shot:
signature fields shall never refer to more than one annotation.
There is a shall in this sentence, not a should. A should isn't normative. It means that you should or shouldn't do something, but that you are not in violation with the spec if don't or do. Not respecting results in a PDF document that is in violation with the PDF specification, and that in the strict sense isn't a real PDF file.
That is a path you don't want to go, because being in violation with the PDF specification voids your right to use a series of PDF patents owned by Adobe. Adobe owns patents that can be used by everyone for free (perpetual, non-exclusive, royalty-free,...) on condition that you respect the ISO specification.
For that reason, please do not expect an answer to your question, except for the recommendation to abandon your requirement. PDF viewers that comply with the PDF specification won't expect a single signature to be placed at different locations because that's not allowed by the spec, so even if you would adapt your software to create more than one widget annotation / appearance for a single signature field, there is no guarantee that a PDF viewer will understand what you're trying to do.
I'm surprised that 4 digit versioning is not allowed in npm ecosystem:
https://docs.npmjs.com/about-semantic-versioning
However, I have to merge my end product from npm to other systems where 4 digits are allowed. So, my question is:
(how) can we somehow make an exception for our own projects to use 4 digits?
You can kind of do it but you need to substitute the last . with a -.
However this is NON-standard and you should probably make sure to comply with npm's versioning in case you want to upload your project there (I don't think it can brake anything but it's still a good to keep the versioning consistent on the plattform.)
Eg. your version would look like 1.1.1-1.
I have seen in it other projects for alpha versions etcs and it allows for non standard version numbers too. Some examples from npm:
vue-class-component#8.0.0-rc.1
react-docgen#3.0.0-beta7
However be aware that when you use any of the npm version major / minor / patch commands it will not increase that number at first but simply truncate everything starting from the first - character. Example:
1.0.6-1
npm version patch
1.0.6
npm version patch
1.0.7
I think this is due to the fact that normally people use it to mark a version to be in alpha / beta / rc in that order and when the version is final you keep the version number but remove the suffix.
To automate this you would need to make your own versioning cli that knows how to handle your specific versioning scheme.
The direct answer to your question is a qualified yes. Some semver supporting package/versioning tools allow quad numeric version strings, but they can't parse them into fields and must use string comparisons or issue an error on comparison, which is usually what you don't want to happen when comparing version strings. In other words, you lose whatever semantics are supposed to be encoded in the four version fields. (See the Coercion topic for a description of NPM's behavior in this case)
Conversions may be possible, but are usually difficult to get right:
The semantics of various 1, 2, 3, 4,...n field version schemes varies, even when the number of fields match up. Where there is a version string such as "1.1.1" that correctly translates to another scheme as "1.1.1", the semantics of the two schemes are the same, or "1.1.1" is a special case. Where the number of fields varies, it's possible that the smaller scheme's field set can be positioned at a fixed offset within the larger schemes fields (with constant values for the remaining fields). It may also be possible to extract a subset of the larger schemes fields, to transfer into the smaller schemes fields. In any case, it is not possible to have a single version string that works in both the larger and smaller scheme without violating the semantics of one or both schemes.
Translating from one scheme to the other, requires a deep understanding of the semantics of both schemes. Many of the four digit schemes are essentially semver with an additional build counter:
X.Y.Z.B
X is major or breaking changes.
Y is minor or non-breaking feature changes.
Z is patch or non-breaking changes that do not add features.
B counts from zero after the last X/Y/Z change.
Translating from such a scheme to semver is not possible, without the entire release history from X'.Y'.Z'.0 - X'.Y'.Z'.n and some means of detecting new features and build breaks between any n and n+1. In cases such as Nuget/.NET, you can lock the B field to zero and apply semver to the remaining fields, then translation from Neget/.Net involves dropping the extra field and from semver implies appending a .0 to the version.
Either adopt semver or don't. If not, you'll just have to put up with various tools squawking about your non-compliant version strings.
I have a theoretical question about PAdES. I want to know if it is possible to revoke a signature in PDF or remove it?
I don't know what exactly you technically mean by revoking a signature.
But it clearly is possible to remove a signature: An integrated PDF signature usually consists of a signature form field with a value that contains a CMS signature container.
You have the choice of either removing only that value or the whole field with the value.
The former option leaves an empty signature field, which can easily be used for a new signature with a visualization at the same location as your original signature (if it has any to start with).
The latter option removes your signature completely.
Two caveats, though:
If you don't merely want the signature not to appear anymore, make sure that
you don't save this edit as an incremental update - if it was done as an incremental update, the document version with your signature could easily be restored;
you don't merely remove the reference to the the value from the signature field but that you actually clear the value object - the signature value object might be referenced from other locations in the PDF, too, so if you don't clear it, its information might remain accessible inside the PDF.
If your PDF contains multiple signatures or document timestamps, and if the signature you want to remove is not the newest one, manipulating it will break at least all newer signatures / time stamps. This is due to the way multiple signatures are applied to PDFs:
As you can recognize in this sketch, the bytes signed by newer signatures contain all older signatures.
In such a situation, therefore, don't only implement "remove a single target signature" but instead "remove all signature starting at a single target signature".
For some more technical backgrounds on integrated PDF signatures cf. this answer and documents referenced from there.
I need to copy org.apache.commons.net.ftp.FTPSClient and org.springframework.integration.ftp.session.DefaultFtpsSessionFactory, and refine some methods, What should I note in this case?
For example, do I need to copy the copyright? And is there anything else need attention?
Take a look at Apache License 2.0 . Under section 4 it's clearly defined what you have to do when you want to redistribute (changed) code.
You must give any other recipients of the Work or Derivative Works a copy of this License; and
You must cause any modified files to carry prominent notices stating that You changed the files; and
Include the Apache License 2.0 to your work and add to the changed file that you have changed it.
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
Don't remove existing copyright, patent, trademarks and attribution notices.
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
If the original work contains a NOTICE file you have to include a copy of it in your changed work.
If you follow these instructions you can modify code which is distributed under the Apache License as you pleased and distribute your work under every license you want without noticing anybody.
Im using doxygen outside of its design, but well within its capability. I have a bunch of essentially text files, appended with some doxygen tags. I am successfully generating doxygen output. However, somehow doxygen occasionally discovers what it assumes to be a variable, and proceeds to document it using surrounding text, causing a lot of confusing documentation. I cant see any direct relationship between these anomalies, only that they're reproducing the same output on each run, and what I can see is at least some are next to a ';' or a '='.
I only want doxygen to document what I've manually tagged. I am hoping to remove any occurrence of these anomalies, however I cannot alter existing text. I can only add doxygen tags, or alter the configuration file. Any ideas?
Many thanks.
Because in my particular case, I do not need any automatically generated documentation, only that which I have tagged with doxygen tags, setting
EXCLUDE_SYMBOLS = *
removes any instance of doxygen "finding" and documenting variables. This however may remove any ability to find any class declarations, namespaces or functions, however this is acceptable for me.