Twitter Ads API Java SDK (twitter4j-ads) support for version 2

[LuisPereira]

Hi there,

As you know all partners and developers are “invited” to migrate to v2 of the Ads API as soon as possible, and by January 10, 2018, v1 of the Ads API will be turned off.

We made a significant investment integrating the Ads API with the Java SDK twitter4j-ads. Could someone please clarify if the current twitter4j-ads library (1.1 version) supports Twitter ADS API v2? Or a new special twitter4j-ads library version will be released to support the Twitter ADS API v2?

The deadline is getting closer and closer, but the Java SDK doesn’t seem to be very active. We would really appreciate if someone could tell us if the Java SDK is dead and if we should rebuild our integration without the twitter4j-ads library in order to support v2.

Many thanks in advance,
Luis

[JBabichJapan]

Hi,

Thanks for raising this concern. To be transparent the Maven release process is a little bit unwieldy right now and causing some of the headaches with keeping it updated. If you or anyone else has experience in improving CI for this please let me know.

I’m trying to figure out on how to incentivize or re-kickstart the open source component of this but it will become a lot easier if the base state is maintained to a certain degree as you can probably agree with. Currently MVPs for helping maintain/improve SDKs are sometimes receiving Swag, 1 on 1 support and may be benefits so feel free to jump into the Java one and we can try to reward in similar way.

A pull request should be submitted over the next few days to fix those basic issues and get it back to a healthier state, as well as implement the core of v2 support.

After that, I will try to make sure the work that maintainers are not able to complete in short term is clearly called out in GitHub so that anybody in community can feel free to change the repo as much as needed. Right now the release process is very manual and time intensive so I’d like to figure out how to implement something similar to Travis which we have in our Ruby/Python SDKs.

We don’t have any work in progress for an ‘in house’ Java SDK so in short term this is an option to rally behind. The feedback about not being happy about speed of updates is duly noted, feel free to continue to give feedback and help spur the community part on directly on GitHub.

Thanks,

John

[LuisPereira]

Hi John,

Thanks a lot for your straight response. I would really love to get involved for helping maintain / improve, but honestly I don’t have the experience and skills to do it (you would get scared about the way I work).

You mentioned a new version would be available over the next few days. I’m sorry to ask again, but could you please be a bit more specific? Would it be next week? The week after? The level of uncertainty around the twitter4j-ads is really high, and as you can image we are not feeling very comfortable, specially with that deadline around the corner.

Many thanks,
Luis

[JBabichJapan]

A pretty big commit was just made today, I’m going to help test it a bit and ‘kick the tires’ but it should definitely be ready for a version bump within the next week. The process of putting the release / JAR onto http://central.sonatype.org/ is the step remaining and shouldn’t take more than a few days, so I am aiming for it to be released by the end of the November. Hope that can alleviate some of the concern - the goal of this release will be to cover breaking changes and adapt to v2 part, some specific new functionality might not be included but those can be added relatively easily.

[LuisPereira]

We do appreciate your effort with this.

Many thanks,
Luis

[JBabichJapan]

I just tagged a release for v2 and we are pushing to Maven today as well, would appreciate your help to let us know if there are any problems as the testing suite is limited for this SDK and I haven’t had too much time to test it manually:

sprinklr-inc/twitter4j-ads

[LuisPereira]

That’s great! This file is now available in Maven. I will conduct some tests during this week and the following one, and I’ll let you.

Many thanks again,
Luis

[JBabichJapan]

Just FYI - some file path issues with Git during commit and had to fix those, so now there is a 2.1 on Maven too…

[LuisPereira]

Hi John,

We have been testing twitter4j-ads v2.1 with our project, upgrading from v1.0, and it has been quite a frustrating experience so far. Originally when we integrated in our project twitter4j-ads v1.0 we were already using twitter4j v4.0.5, so it was a kind of natural step for us, as twitter4j ads was based and used twitter4j-core. Literally the GitHub project for Twitter4j-ads states the following: “The Twitter4j-ads Java SDK is built on top of design of Twitter4j to allow for easy integration with both Ads API and Organic (REST) API.”

To our surprise twitter4j-ads v2.1 literally replicates many of the classes in twitter4j-core. An example of this (the first that came up in our tests) is the class TwitterException, but this is not problematic as that class is in different packages in twitter4j-core (twitter4j.TwitterException) and in twitter4j-ads (twitter4j.internal.models4j.TwitterException).

The real problem is when the replicated classes are located in the same package in both twitter4j-core and in twitter4j-ads. This happens for instance with twitter4j.conf.ConfigurationBuilder. We are using now twitter4j-core v4.0.6 (the latest available version) and we started to suffer runtime exceptions, so the replicated classes from twitter4j-core belong to an older version.

As a result we are not able to use the Ads API and Organic (REST) API simultaneously in our project as we could previously do. I guess using both APIs is quite a common scenario.

I can understand that replicating / adapting a large part of the twitter4j-core code could be required for a given reason, but I also understand that it could be done using a different package name (as it was done with TwitterException). Rightnow, it is not possible to use the Ads API and Organic (REST) API simultaneously, something that doesn’t make much sense.

I hope you can understand the current problem for both APIs users.

Many thanks,
Luis

[JBabichJapan]

Hi,

Sorry to hear about those troubles - actually my understanding was that part of the twitter4j core code was forked off ‘on purpose’ to modify it to be more appropriate for ads related scenarios - but I don’t have 100% of the details about it.

Is it possible as interim solution to keep two separate executables or services? Within many Ads API implementations we see that most of the REST API needs are covered by the Tweet proxy endpoint and scoped_timeline endpoint, but I understand if you want to have extra functionality on top of that and built seamlessly instead of different services internally.

I need to take a closer look at exactly what is causing runtime errors but my gut reaction was that the twitter4j-ads one should somehow wrap everything under “twitter4j-ads” namespace or basically change to be non-clashing.

I would post about this to Issues on the GitHub page, and possibly if there is an easy fix we can definitely simply change it within the next week or two.

Thanks,

John