Add to maven

[Omnipresent]

Hi

What are the plans to push this to regular maven so that it can be used by not using the SNAPSHOT mentioned in the README.md.

I understand that you have the last call on this but we are making use of this library but can not use oss.sonatype.org/content/repositories/snapshots. Just wondering what are the plans to push this to regular maven? I believe the library works fantastically

[dragon66]

@Omnipresent Thanks for the suggestion. Yes, there has been quite a while since the first snapshot but there are a few items which I had been planning to put into the library before actually creating a release - TIFF reading support for CCITT and JPEG reading support as well as library to manage creation of XMP data. Currently TIFF and JPEG reading are still delegated to either Java ImageIO or a third party library. Without these features I am a bit reluctant to make a release.

[ben-manes]

This would be useful and you could use the semver strategy of releasing a 0.x to have no API stability, or move onto 2.x to break it gently. Either way this is a useful library and versions are cheap.

Because the naming convention matches jitpack.io's, it gets confused and tries to build it when Gradle queries the repositories for metadata. That seems to get stuck, with Gradle printing Redirecting to 'https://jitpack.io/com/github/dragon66/icafe/index.html?building=1' via {s}->https://jitpack.io:443 and the building=N value gradually increasing. This is fine in a normal jar download, but not when running dependencyUpdates which looks for versions. While arguably a bug in jitpack (https://github.com/jitpack/jitpack.io/issues/1251), a hard version might have kept this from occurring.

[dragon66]

@ben-manes thanks a lot for your suggestions. Will take a look and see how far I can make it.

[dicer]

Same here. I use a very specific feature which works fine. Unfortunately can't use snapshots as this would make future builds potentially unstable/breaking. So I always create a version like 1.0-gitsnap10021d73 (git commit referenced) and push it to a private nexus.

Would be a lot easier to have an official version. One thing that might cause problems though (just a thought, no experience): The javax.media.jai_imageio is currently only located in a 3rd party repo. Not sure what happens if icafe gets added to maven central and the dependency is not there.

[sinedsem]

@dragon66 I completely agree with @ben-manes You can use semantic versioning and create e.g. 1.0.1 release as is, without TIFF and JPEG reading. And when TIFF and JPEG reading will be implemented you can make 1.1 release.

Additionally it would be nice to refactor project structure a little to correspond typical maven structure:

.
|__ pom.xml    
|__ src
    |__ main
    |   |__ java
    |   |   |__ com
    |   |        |__ icafe4j
    |   |__ resources
    |__ test
    |   |__ java
    |   |__ resources

I've already done this locally and will create a fork and PR soon. Also I will clean up IDE files as it's not a good practice to store it in github.

[Omnipresent]

@sinedsem that would be a huge help. +1

[Omnipresent]

Hello - Just wondering whether icafe will be on maven soon and what the timeline looks like. Thank you for your continued work on this project.

[dragon66]

I am in the middle of doing the coding CCITT Group 3 and 4 decompression for TIFF but not sure when this will be done. I tried to restructure the code to conform to Maven a while ago after sinedsem's comment but had some issue and didn't got time to look at it further. I have trouble to reconcile the Eclipse and Ant build with Maven as well as split the code between test and main.

To be frank, I am very good at project manage. If you or someone could help and make sure everything is working fine for the current code, it would be great and I am more than happy to publish a real version on Maven.

[ben-manes]

I modified the pom.xml in #84 to build the project with its custom layout, so as to not change @dragon66's workflow. This builds enough to allow for a stable snapshot (by commit hash) using jitpack.io. I think that's a decent compromise, especially since snapshots are no longer being released anyways.