Jenkins build is back to normal : PDFBox-sonar #189

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16065286#comment-16065286
 ] 

ASF subversion and git services commented on PDFBOX-2852:
-

Commit 1800081 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1800081 ]

PDFBOX-2852: Sonar fix

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: explicit_array_creation.patch, fix_javadoc.patch, 
> foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, 
> PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, 
> stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, 
> usestatic.patch, winansiencoding2.patch, winansiencoding.patch, 
> XMPSchema.java.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2852) Improve code quality (2)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16065287#comment-16065287
 ] 

ASF subversion and git services commented on PDFBOX-2852:
-

Commit 1800082 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1800082 ]

PDFBOX-2852: Sonar fix

> Improve code quality (2)
> 
>
> Key: PDFBOX-2852
> URL: https://issues.apache.org/jira/browse/PDFBOX-2852
> Project: PDFBox
>  Issue Type: Task
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: explicit_array_creation.patch, fix_javadoc.patch, 
> foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, 
> PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, 
> stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, 
> usestatic.patch, winansiencoding2.patch, winansiencoding.patch, 
> XMPSchema.java.patch
>
>
> This is a longterm issue for the task to improve code quality, by using the 
> [SonarQube 
> report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor],
>  hints in different IDEs, the FindBugs tool and other code quality tools.
> This is a follow-up of PDFBOX-2576, which was getting too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: Contributing the JBig2 ImageIO Plugin to PDFBox

[Andreas Lehmkühler]

Hi Jörg,

> Jörg Henne  hat am 26. Juni 2017 um 15:36 geschrieben:
> 
> 
> Hi all,
> 
> 
> Apache PDFBox currently uses the JBig2 ImageIO-Plugin at 
> https://github.com/levigo/jbig2-imageio as an optional component and 
> recommends the use of it at https://pdfbox.apache.org/2.0/dependencies.html. 
> I am writing this as a representative of the ISV levigo, the owner and 
> publisher of this component. Besides being an open source component we use 
> the component on our own software suite. Over the years we have invested 
> significant time into it and have been maintaining it for many years so that 
> I would consider its code-base reasonably mature and stable. However, we 
> continue to address any bugs reported to us and have accepted several 
> community-provided fixes.
> 
> 
> The plugin in question is currently licensed under the GNU General Public 
> License V3 with other licensing options available, including commercial 
> licensing. Having PDFBox under the ASL and the plugin under a different 
> license has long been a nuisance for PDFBox users which has deterred many 
> users fron using it. On the other hand, many users have a strong need for it 
> as our plugin is (IMHO) still the highest quality pure-Java open source 
> decoder available.
> 
> We would like to change this situation by licensing the plugin under the ASL. 
> At the same time, however, we think that it would make sense to move the code 
> base over to a new home that makes it independent of a single vendor. That's 
> where the ASF and the PDFBox project comes into play :-)
> 
This is good news and higly appreciated!

> We are currently in the very early stages of evaluating such a transition. A 
> few random thoughts:
> 
> - All of those thoughts are subject to the PDFBox community​ being willing to 
> do this and accepting the contribution, obviously.
> 
I can think about 2 possible new homes within the ASF, Apache PDFBox and Apache 
Commons. The first option might be the easier way if it comes to the 
"paperwork".

> - One of the reasons for us to favor the ASF as a new home is that the ASF 
> has strong provisions in place to ensure that a project can thrive without it 
> being dependent on life-support by a single vendor.
> 
+1

> - We need to do proper IP vetting: while the vast majority has been done by 
> levigo there is one other GitHub committer who has provided bug fixes and 
> whom we need to talk to.
> 
Good catch, these are the important bits which have to be resolved first. After 
that you have to provide a Software Grant Agreement, see [1] for details, so 
that we can start the IP clearance process, see [2] and [3]

> - Package names and maven coordinates will have to be updated to reflect the 
> transition
+1

> - After a transition colleagues of mine would continue to contribute to the 
> maintenance of the component. The necessary committer rights would need to be 
> bestowed upon them. I myself have been an Apache committed for many years, 
> albeit almost completely inactive.
> 
As an apache committer you might know that nobody can request committer rights 
but has to be voted in. But that is maybe just a formality. About how many devs 
are we talking here?

> - It would make sense (and is required by the Apache rules) to have 
> additional know-how about the component outside of levigo. I don't know 
> whether there is enough interest in the PDFBox community to ensure this.
> 
Yes, diversity is an important aspect. I'm pretty sure that the code will 
attract other (pdfbox) developers once it is under the apache umbrella. The 
imaging [4] devs might be interested in the code as well.

> So that's it for now, I guess. Please let me know what you think.
I support your plan to integrate the plugin with pdfbox. We, the PDFbox PMC, 
have to discuss that topic first and have to perform a vote, but I guess this 
is just a formality.

Feel free to ask if there are any further questions.

> Jörg Henne
> 

Andreas

[1] http://www.apache.org/licenses/
[2] http://incubator.apache.org/ip-clearance/pdfbox-padaf.html
[3] https://issues.apache.org/jira/browse/PDFBOX-1056
[4] http://commons.apache.org/proper/commons-imaging/

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org