Hm. The thing is: what's currently in Central wasn't put there by us. We don't use Maven here and we never planned to support it. We simply don't have the time to maintain another repository. Maybe the person who put the older version on Central will step in and upload the update. As I understand it, anyone can do that.
I'll leave this ticket open in case we decide to support Maven some time in the future, but it's very low on our priority list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I already started putting all 5.6 artifacts to JCenter (this is a superset of Maven Central). I'm progressing slowly because I have to request ownership for each package and to wait for approval in order to be able to upload their latest versions. Due to the fact that the person that has uploaded v5.5 to Maven Central seems to be currently unreachable/unknown, the JCenter repository is the only way for jPod 5.6 Maven integration.
Shipping binary artifacts and setting everything manually is a thing of the past. Unfortunately, it's still very common, especially in the enterprise world. Nowadays, open-source software is build upon a full-fledged dependency management system like Maven or Gradle.
Having such a dependency system for jPod would be a huge advantage for atracting more users to this powerful library which belongs to the best products of the art. Unfortunately, its support is rather weak but it can be improved without much effort by introducing a dependency managment and to move from SourceForge to said Github.
I'd like to offer a helping hand here if you wish...
Last edit: Maxim 2017-05-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
really sad to hear that our support leaves something to be desired... and thanks for the "best of art".
Anyway, we have discussed once more the topic and found that we WANT to support the repository approach a little better. We will switch to a gradle build and git repo with the next major release of our software. As a side effect i hope it will be much easier to handle our open source artifacts automatically. But still this will take some time and i have no idea of the effort to "take over" possession of our coordinates with the repo.To be honest, i do not want to invest much time at this point...
Maybe we come back with concrete support requests in this process, many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyway, we have discussed once more the topic and found that we WANT to support the repository approach a little better. We will switch to a gradle build and git repo with the next major release of our software.
Sounds good, thanks a lot!
I'm happy to anounce that jPodRenderer 5.6 is now available in JCenter.
Everyone can immediately use it in his Maven/Gradle project, provided that the JCenter repository is included. For Maven, it should look like that:
For an example of how to use jPodRenderer v5.6 in Gradle, please refer to the build script of Audiveris software.
I did my very best to fix/work around the following issues:
"weak" SWT dependency: Intarsys binary distributions don't include SWT but the source code won't build without it. I fixed this by making it compile-time dependency only.
corrected wrong iscwt version number ("isCWT.5.5.20131203" should be actually "isCWT.5.6.20131203").
updated the jPod license to include the APAFML license as well because jPod bundles 14 Adobe fonts in the distribution JAR.
included the old non-free JAI 1.1.3 dependency for the time being. This should be fixed ASAP by either switching to free JAI alternatives or by decoupling the rendering code.
jbig2 v5.5.1 could be fortunately reused because it's binary compatible with the jbig2 shipped with jPodRenderer v5.6. Unfortunately, it's not clear which original jBig2 version has been used to produce jbig2.jar in jPod/lib. There is no version tag in MANIFEST.MF. This should be also clarified and updated by switching, for example, to well-maintained alternatives.
Strikly speaking, all Intarsys Maven releases prior to 5.6 are broken in some way: missing dependencies, missing or wrong licences, broken links to sources etc. All users are therefore encouraged to update to v5.6.
Don't hesitate to contact me if you'll find any issues with Intarsys v5.6 packages.
Cheers
Maxim
Last edit: Maxim 2018-01-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm. The thing is: what's currently in Central wasn't put there by us. We don't use Maven here and we never planned to support it. We simply don't have the time to maintain another repository. Maybe the person who put the older version on Central will step in and upload the update. As I understand it, anyone can do that.
I'll leave this ticket open in case we decide to support Maven some time in the future, but it's very low on our priority list.
If you want you can use JAR and POM.xml from attached zip. Then it is very easy upload it to your company repository or public repostiory
Really sorry to tell you that we stiil don't put any effort into setting up maven infrastructure.
I already started putting all 5.6 artifacts to JCenter (this is a superset of Maven Central). I'm progressing slowly because I have to request ownership for each package and to wait for approval in order to be able to upload their latest versions. Due to the fact that the person that has uploaded v5.5 to Maven Central seems to be currently unreachable/unknown, the JCenter repository is the only way for jPod 5.6 Maven integration.
Shipping binary artifacts and setting everything manually is a thing of the past. Unfortunately, it's still very common, especially in the enterprise world. Nowadays, open-source software is build upon a full-fledged dependency management system like Maven or Gradle.
Having such a dependency system for jPod would be a huge advantage for atracting more users to this powerful library which belongs to the best products of the art. Unfortunately, its support is rather weak but it can be improved without much effort by introducing a dependency managment and to move from SourceForge to said Github.
I'd like to offer a helping hand here if you wish...
Last edit: Maxim 2017-05-06
Hi Maxim,
really sad to hear that our support leaves something to be desired... and thanks for the "best of art".
Anyway, we have discussed once more the topic and found that we WANT to support the repository approach a little better. We will switch to a gradle build and git repo with the next major release of our software. As a side effect i hope it will be much easier to handle our open source artifacts automatically. But still this will take some time and i have no idea of the effort to "take over" possession of our coordinates with the repo.To be honest, i do not want to invest much time at this point...
Maybe we come back with concrete support requests in this process, many thanks.
Sounds good, thanks a lot!
I'm happy to anounce that jPodRenderer 5.6 is now available in JCenter.
Everyone can immediately use it in his Maven/Gradle project, provided that the JCenter repository is included. For Maven, it should look like that:
For an example of how to use jPodRenderer v5.6 in Gradle, please refer to the build script of Audiveris software.
I did my very best to fix/work around the following issues:
Strikly speaking, all Intarsys Maven releases prior to 5.6 are broken in some way: missing dependencies, missing or wrong licences, broken links to sources etc. All users are therefore encouraged to update to v5.6.
Don't hesitate to contact me if you'll find any issues with Intarsys v5.6 packages.
Cheers
Maxim
Last edit: Maxim 2018-01-17