search

adobe / XMP-Toolkit-SDK

The XMP Toolkit allows you to integrate XMP functionality into your product or solution
BSD 3-Clause "New" or "Revised" License
193 stars 77 forks source link

Where is the XMP SDK for Java? #5

Open Lonzak opened 4 years ago

Lonzak commented 4 years ago

Sorry for posting this here but I didn't know any place else.

On your webpage https://www.adobe.com/devnet/xmp.html the old Java XMP version 5.1.3 is linked. Then on maven central one can find a slightly newer version 6.1.10 but still it is from 2016. But then here on github there is no java version at all. So please add repo for the Java SDK here - this would be highly appreciated!

Update in 2022, management summary: According to Pawan all version 6.X releases were accidentally been released. All users should continue to use the latest version 5.X. This "accident" continued over the course of 4 years with several version:

Update in Nov. 2022

Leonard Rosenthol the chief PDF architect commented on this thread (thank you Leonard for honoring us here) and stated the following:

The 6.1.11 [...] is an official Adobe distribution. You can/should use that as it also includes an updated license file.

I have to admit: I am (and probably the whole community is) now totally confused...

pawankishorsingh commented 4 years ago

Hi Lonzak Java XMP version 5.1.3 is indeed the last "officially released" SDK from Adobe. The newer ones which you are seeing on nexus are not official release yet. In fact it had inadvertently got posted due to an unknown issue. Hence we have not mentioned that in our https://www.adobe.com/devnet/xmp.html official page.

So, you are requested to proceed with 5.1.3 version only. Hope it helps.

Regards Pawan

Lonzak commented 4 years ago

Are there any plans to put the Java project also on github? This would really help and focus development/bug reporting etc...

pawankishorsingh commented 4 years ago

Hi Lonzak

We do not have any immediate plan to post our Java SDK onto github but we would definitely like to consider it in future. Publishing on github would require performing some necessary ground work, taking few approvals and most importantly a JDK upgrade. Considering the fact that last release had happened many years back, we might need to perform a JDK upgrade to JDK8 or JDK11 before going onto github. So, you can see that it'll take some effort to do all that.

Till then, please proceed with the way things are at present.

Regards Pawan

Lonzak commented 4 years ago

A release here on github would be quite a worthy goal. An upgrade to java 8 would also be nice. Since you already provided the XMP SDK for C++ here on github it isn't the first time you are walking down that path - even though there are things to be worked out, it is only consistent to do so.

For me there is no other way as to continue to use version 5.13. But I am really looking forward for the release of a newer version here on github. This post should just highlight that there are still people using the java version and appreciate what you are doing. (And looking forward for a release here)

arpitapanda05 commented 3 years ago

@pawankishorsingh Please check this.

Lonzak commented 3 years ago

Since I originally posted here a new version has been released: 6.1.11 in November 2020. So this version is also not official yet? This is really quite strange: You continue to release "inofficial" versions to maven central but how should people know that? I mean don't get me wrong: I am happy that the Java XMP SDK is still somehow maintained and not dead which I would think now if the last version would still be 5.1.3 (from 2016).

@Priyanka-Gupta

It has been nearly a year and I would like to encourage you (once again) to setup the java SDK here on github. It is really worth it and should be part of Adobe's open source strategy. Really looking forward to it.

Lonzak commented 2 years ago

@pawankishorsingh @arpitapanda05 @Priyanka-Gupta

One year has passed and I would like to ask and remind you about the status of the Java XMP SDK. Have you been able to take some steps in the mentioned direction? When I look at the official page it seems that the opposite is the case: https://www.adobe.com/devnet/xmp.html

The java XMP SDK Link is dead - so it seems adobe is abandoning its Java support :-( People and projects are using this - so this is definitely the wrong decision!

lrosenthol commented 1 year ago

The 6.1.11 that was posted at https://search.maven.org/artifact/com.adobe.xmp/xmpcore/6.1.11/bundle is an official Adobe distribution. You can/should use that as it also includes an updated license file.

Lonzak commented 1 year ago

The 6.1.11 that was posted at https://search.maven.org/artifact/com.adobe.xmp/xmpcore/6.1.11/bundle is an official Adobe distribution. You can/should use that as it also includes an updated license file.

Hi Leonard,

thank you for your post however now I am really confused: First someone (from adobe) tells me, that all those 6.X version have been accidentally released and should not be used. Thus I went back using 5.X. Then this "accident" continues to happen over a period of 4 years. Ok now you tell me it is the official version and not an accident. It would be really good if you could create a Java XMP github project (same as for the XMP-Toolkit). This would massively help building trust in the project and there would be a central place for bugs, fixes and so on. Other developers would help with fixes and everybody is happy ;-)

Since I know you for a long time I trust you. Thank you for the clarification... Lonzak

PS: Also the Java link on your official XMP page is dead - which doesn't help either...

stechio commented 1 year ago

I totally agree with @Lonzak.

I'm glad that a senior Adobe representative made a clear statement on this topic, yet it's quite bewildering that, previously, another employee confidently claimed that 6+ releases on maven central were "not official" and "inadvertently got posted due to an unknown issue" (WHAT!?!).

As suggested, a Java XMP github project would be the obvious way to go for the benefit of both maintainers and users.

Update: inspecting com.adobe.xmp:xmpcore:6.1.11 artifact, I noticed its root package (com.adobe.internal.xmp) actually feels strangely unofficial compared to com.adobe.xmp:xmpcore:5.1.3 (com.adobe.xmp); furthermore, no license file is included under META-INF (whilst 5.1.3 contains META-INF/LICENSE). Now I'm even more confused...

tsmock commented 11 months ago

Publishing on github would require performing some necessary ground work, taking few approvals and most importantly a JDK upgrade.

As a stupid question, is a JDK upgrade absolutely necessary? The java library is currently (as of 6.1.11) compiled against Java 6, and there is probably no reason to change that (caveat: Java 17 does not support compiling against Java 6).

For everyone else, I was able to generate a pom file fairly easily for https://github.com/drewnoakes/adobe-xmp-core (6.1.10 source code).

Probably the "biggest" thing that needs to be done is converting new <Number> to <Number>.parse<Number>. But that still doesn't require a JDK upgrade. The parse methods were largely added in Java 1.5.

pom.xml.zip -- stick the source code from https://github.com/drewnoakes/adobe-xmp-core in src/main/java. I used git submodule add https://github.com/drewnoakes/adobe-xmp-core.git src/main/java.

Lonzak commented 11 months ago

I agree. A java update would (hopefully) mean updating it to Java 8. We have lots of customers which still uses that version. And in the end it is a library where Java 8 should suffice imho.

tsmock commented 11 months ago

I probably should have added that we (JOSM) are using this library in Java 8-20 via metadata-extractor. When I was testing the pom.xml I generated, I compiled against Java 6 (using a Java 8 install) and against Java 20. The only warnings are due to new <Primitive> calls.

With that said, updating to Java 8 would let the library use streams and callback functions. But it is not (IMO) necessary for making the library available on GitHub.

Lonzak commented 11 months ago

@pawankishorsingh @arpitapanda05 @Priyanka-Gupta

One and a half year passed and I would like to remind you about the status of the Java XMP SDK. Have you been able to take some steps in the mentioned direction? When I look at the official page it seems that the opposite is the case - the java download has been removed. https://www.adobe.com/devnet/xmp.html

StefanOltmann commented 10 months ago

I have ported the source code from the most recent official release, version 5.1.3, to Kotlin Multiplatform. This was necessary to integrate it into my application. It should be compatible with plain Java usage. Feel free to explore it further to determine if it aligns with your needs.

https://github.com/Ashampoo/xmpcore

mlemnian commented 9 months ago

There is a reconstruction of the source code using the maven source code artifacts: https://github.com/drewnoakes/adobe-xmp-core

But this is unofficial.

I do wonder (like @Lonzak) why there is no official repo of the Java source code, and if not wanted, why is the official project page https://www.adobe.com/devnet/xmp.html only linking to the old source zip file https://download.macromedia.com/pub/developer/xmp/sdk/XMPCoreJava-5.1.3.zip and not all versions.

For those who wonder why I care? In my project, my client wants a list of all open-source libs that are in use. Including:

  1. Link to the project page
  2. Link to the source code (in case we or the client need to fix something on their own)
  3. Link to the license file of that used version(s)

The last two requirements can (currently) not be fulfilled.

StefanOltmann commented 9 months ago

@mlenmian, I acknowledge your concern.

I encountered similar challenges with my port, prompting me to adopt the following strategy: I linked to the most recent version of the project page on archive.org. To add an extra layer of precaution, I also included a screenshot of the original page (https://github.com/Ashampoo/xmpcore/tree/main/original_source) in case archive.org experiences any downtime.

Given the uncertain durability of the original source code link, I took the initiative to create a backup copy of it.

Regarding the usage of https://github.com/drewnoakes/adobe-xmp-core, it's important to note that the Maven source code artifacts come with a proprietary license, even though the POM file suggests it's BSD. Despite my multiple attempts to seek clarification from Adobe, I received no response. Therefore, if you prioritize safety, it would be prudent to opt for the older 5.1.3 version, which is explicitly BSD. This is precisely why I based my fork on that particular version.

Lonzak commented 7 months ago

Happy and sad 3rd birthday to the last (official but unofficial) version 6.1.11.

@pawankishorsingh @arpitapanda05 @Priyanka-Gupta @lrosenthol

Wouldn't you agree that an official Java XMP-SDK Github repo would be a fitting birthday present to the project?

StefanOltmann commented 7 months ago

I don't care anymore. My fork does what I need. :)

StefanOltmann commented 3 months ago

I just added a sample how to use my fork with Java: https://github.com/Ashampoo/xmpcore/blob/main/examples/xmpcore-java-sample/src/main/java/Main.java

Lonzak commented 1 month ago

@StefanOltmann Nice. However for us it would be easier to use the official code from the official repo. Otherwise lots lots of checking, verifying and other manual steps necessary (securitywise) ...

StefanOltmann commented 1 month ago

@Lonzak Can you explain what you need to check securitywise?

The license is the same. No risk there.

Lonzak commented 1 month ago

Sure. I assume you are a nice guy without any bad intent. But lets draw another, purely hypothetical scenario: You are not and your repo is not from an organization like eclipse foundation, Apache or some company like *dobe. The only chance I have is to compare the original source code with your changes (e.g. your initial commit). Then afterwards all your commits need to be rechecked and verified that you didn't add a backdoor or did some license-poisoning or other bad stuff. And maybe everything checks out, but what about future commits when the project is used by more and more developers?

I don't like this thinking however due to recent events the policy regarding 3rd party dependencies has been changed (for us).

And another aspect comes to mind: You maybe maintain the library (updating dependencies, new Kotlin or Java versions etc) but do you continue developing it? E.g. adding new versions of the XMP standards etc? This would be an advantage if adobe would offer an official branch. Don't get me wrong - I don't want to belittle your efforts of sharing the code ...

StefanOltmann commented 1 month ago

your repo is not from an organization like eclipse foundation, Apache or some company like *dobe

It's not my private pet project, it's an official Ashampoo repo.

I don't like this thinking

I see that you want to be careful and that's a good thing I can relate to. I also like to take a closer look at my dependencies.

however due to recent events the policy regarding 3rd party dependencies has been changed (for us).

And what are your policies now? I'm curious.

Only official Apache & Google projects? That's quite restrictive and will lead to re-inventing the wheel, which can be quite costly.

You maybe maintain the library (updating dependencies, new Kotlin or Java versions etc) but do you continue developing it? E.g. adding new versions of the XMP standards etc?

No, not in that sense. I keep it functional, but I likely won't extend it to new versions of the XMP standard - if there should be any one day. It will take very long until a majority of apps will use a new standard anyway.

To be honest I even do not believe that there will be new versions. At least not anytime soon.

This would be an advantage if adobe would offer an official branch.

Yes, personally I would prefer that Adobe continues supporting the Java version or even better provides an official Kotlin Multiplatform SDK.

But for me it was time to realize that this won't happen. It's obvious that Adobe lost interest, but I needed my photo organizer app to handle XMP content. So I took action.