Duplicate class about jodd HOT 22 CLOSED

I think I slowly begin to understand the StreamGobbler issue.

HTTP uses Core (so far still all fine), where StreamGobbler is defined, however Core uses Util, where StreamGobbler is defined as well and that simply creates the observed conflict.

A few questions

• Assuming you moved a few things around between versions, could it simply be that Core 5.2 should not use Util 6.0 yet?
• Still not fully familiar with Java's package concept I am afraid, but could it be that the issue only appears on pre-9, because with 9+ the two StreamGobblers are kept separately due to the module concept, but on pre-9 they end up in the same classpath?

from jodd.

True, it's just my mistake, having 2 same classes. The thing is that the cut between jars should be clean; and therefore there should be no issues like that.

I belive today im going to fix this mess and promote http client too!

from jodd.

https://github.com/oblac/jodd-http
code is ready, need to release util first and then HTTP :)

from jodd.

With 6.0.1 the class clash seems to be fixed, however HttpException does not seem to work any more as it seems to be missing jodd.exception.UncheckedException.

https://search.maven.org/artifact/org.jodd/jodd-http/6.0.1/jar mentions a scope of "runtime". Could that be the reason?

from jodd.

Igor, really, no worries :) I am still perfectly fine with 5.1.6 for now

Do you see where is the error?

The error is with jodd.http.HttpException not being able to reference jodd.exception.UncheckedException.

from jodd.

Just release http 6.0.2 with api dependency on jodd-util.

from jodd.

I know what's going on :)

• jodd-util v6 can be used with jodd-* v5.2, but not others
• StreamGobbler seems to remain in new jodd-util, but should be removed!

I will remove the StreamGobbler today from jodd-util!

So to repeat: use jodd-* with jodd-util v6.

BTW, if you are using HTTP, I will be more than happy to promote it to v6!

from jodd.

Is there anything else you are using @neroux?

from jodd.

Thanks for the swift response :)

First of all, it is nothing urgent, I just noticed it and wanted to bring it up but no immediate action necessary, I am happy to stay on 5.1 for now.

The only thing, I do not explicitly import jodd-util anywhere. The project with the one warning only uses HTTP

implementation 'org.jodd:jodd-http:5.2.0'

there are a few other libraries included, but as far as I can tell they do not require Jodd on their end (which could introduce an incompatible version).

On the other hand the project with the 82 errors includes these three modules

implementation 'org.jodd:jodd-http:5.2.0'
implementation 'org.jodd:jodd-json:6.0.0'
implementation 'org.jodd:jodd-lagarto:6.0.0'

I am not sure where the clash of classes exactly occurs but it seems - at least on Android - one can't use HTTP 5.2 for the time being.

Again, at least on my side nothing urgent, really just a heads up :)

from jodd.

Not entirely sure, but it seems as if jodd.io.StreamGobbler was simply defined in jodd-core 5.2 and jodd-util 6.0.

jodd-http 5.2 seems to use both and that seems to create the conflict.

from jodd.

This:

implementation 'org.jodd:jodd-http:5.2.0'

uses jodd-core:5.2 -> uses jodd-util:6.0

This is weird:

implementation 'org.jodd:jodd-http:5.2.0'
implementation 'org.jodd:jodd-json:6.0.0'
implementation 'org.jodd:jodd-lagarto:6.0.0'

this pack should not have issues, besides that only one with StreamGobbler... This is weird, how come 5.1.6 gets included?

from jodd.

This:

implementation 'org.jodd:jodd-http:5.2.0'

uses jodd-core:5.2 -> uses jodd-util:6.0

But that will break too, because both define jodd.io.StreamGobbler, right?

This is weird, how come 5.1.6 gets included?

That, I haven't looked into yet. I noticed the issue first with the HTTP-only project.

from jodd.

But that will break too, because both define jodd.io.StreamGobbler, right?

True, gonna fix that

That, I haven't looked into yet. I noticed the issue first with the HTTP-only project.

Will check!

from jodd.

5.1.6 appears to come from jodd-bean. Not including that either tough, either json or lagarto.

from jodd.

Thanks! :)

Just for my overall understanding, based on this issue I'd understand that it is not a good idea to mix version numbers as there won't be any compatibility guaranteed, right?
It somewhat brings me back to #634 and my question why Jodd should be split up :)

Currently there is a similar issue with jodd-json, it uses jodd-bean and jodd-util and both have common classes.

from jodd.

jodd-json is promoted to v6, there should be no issues ;)

Check https://github.com/oblac/jodd for a list of promoted repos. I know it's a bit crazy now, but after a few iterations, most utilities will be at v6.

Issues I have with Jodd as it is now:

• releasing a new version requires a lot of time. Most of the time is spent on uploading to Maven Central, as it often fails. Actually, the upload works, but somehow Maven Central figures out its not one batch, but 2 or 3; so I have to repeat the upload.
• documentation is really stuck :(
• Lagarto and other utilities are used significantly more than anything else. And I want to give them the freedom to grow on their own. For example, I really would like to put more work on HTML parsing, as it is literally used the most. Therefore, it makes sense for people to just contribute to e.g. Lagarto and not to care about the rest.
• Jodd5 is stuck with Java8. Jodd6 is working on Java11 and GraalVM.
• That being said, all Jodd frameworks (Madvoc, Petite...) will probably just remain here, in low-maintenance mode... I would need a lot of energy to make them shine, afraid I don't have that :(

In short: by splitting I feel that new life can be given to the libraries and future contributors... that was the whole idea, to split so we can give focus to work on.

Hope that makes sense :)

from jodd.

All right, the JSON issue only seemed to occur when using HTTP 5.2, probably the same class clash then.

Does Jodd 6 still support Java 8 or does it require a new version? Especially on Android that can be tricky.

by splitting I feel that new life can be given to the libraries and future contributors

Do you mean splitting would allow for incompatibilities between versions and so other parts could move asynchronously and contributors would not need to take the whole stack into account?

from jodd.

Yap, both 8 and 11 and whatever LTE version Oracle puts will be supported ;)

allow for incompatibilities - issues

I truly hope not! There are not many dependencies, only 1-2 per single library. I will bump versions and update whenever it's needed. There are not many inter-dependencies in 6, don't expect much trouble. Most inter-dependencies are in the Jodd frameworks. Libraries are simple, and I can publish now everything from CLI, so it is easier. :)

For the old Jodd frameworks... well, I will see. So far I have updated it all as well. I was thinking of merging all frameworks (dboom, madvoc, petite...) into one single project; as again statistically I don't see that people are using them separately (those few who are using it at all :).

from jodd.

Damn, my bad, I had to put api in Gradle :((((

Sorry, this month I have like 10 parallel threads I am working on.
Can you put the dependency manually temporarily?

I need to release all repos, will do until the Monday!

from jodd.

Please sorry again, hate when I am sloppy.

from jodd.

Or wait, if HTTP does not use anything from UTIL in the public API, then the dependency is OK.

Not sure how can I check that with Gradle during the build?

Do you see where is the error? It would be cool to stay like this, so not to expose the UTIL if not needed.

from jodd.

Works like a charm and the brand new Android Studio 4.1 loves it :-D

Thanks!

from jodd.