Live long to see. Can you tell org.jboss.netty from io.netty?

Hi, I’m here. I’m a bug programmer.

One day while I was working on a Bug, a colleague ran up to me.

There is a special three-party dependency library JAR package, there are some netty dependencies, but can not determine the specific version of Netty, let me help to look.

And this?

So I asked him to send the JAR to have a look, after receiving it, I quickly decompressed it, its directory structure is like the following:

So some treasure, some nail SDK looks like this? Is this the SDK for Big Factory?

At that time I will

This is totally unconventional. Where are the POM files? Where are the Gradle files? What kind of dark technology is this?

After staring at this JAR package unzipped file directory, rummaged several times, but did not find the relevant dependency library coordinate declaration file.

So ask colleagues have source documents, he said there, hemp slip of the hair over, than usually call him to eat fast.

When I opened it, there was still nothing.

Suddenly, this library is a little different!

How can I determine the version of a dependency library without its coordinates?

My colleague is still urging me, but I can only put the point why the library does not depend on the coordinates of the library first.

Then the first use of a version of the method to try to help him determine the dependence of the Netty version.

I opened a random file and found a lot of org.jboss.netty dependencies.

I then opened Maven’s central repository: mvnrepository.com and entered the netty keyword to search.

The search results are mostly filled with io.Netty information, and at number 7 are org.jboss.netty, which I circled in the image above.

Then I point inside: mvnrepository.com/artifact/or…

X, 3.1.x, 3.2.x.

For common sense, Netty references are usually Final versions, so I added a POm file to the source file of the library and tried 3.2.10.final first.

<! -- https://mvnrepository.com/artifact/org.jboss.netty/netty --> <dependency> <groupId>org.jboss.netty</groupId> < artifactId > netty < / artifactId > < version > 3.2.10. The Final < / version > < / dependency >Copy the code

After adding the above depend on the coordinate information, try to compile the source code, find org.jboss.net ty. The lack of handler. Codec. HTTP. Websocketx package.

Then tried 3.1.5 respectively. The GA ty. The lack of org.jboss.net handler. Codec. HTTP. Websocketx package, 3.0.0. GA ty. The lack of org.jboss.net handler. Codec. HTTP packets.

X, 3.1.x and 3.2.x are not suitable.

Undaunted, I searched the entire central warehouse again and couldn’t find any more org.jboss.netty packages.

So here mvnrepository.com/artifact/or… The road is dead.

But the central warehouse in org.jboss.net ty: mvnrepository.com/artifact/or… A paragraph on this page caught my eye.

Note: This artifact was moved to:

Io.net ty » netty

Yes, that’s the paragraph above, which I’ve circled in the picture below.

It tells us that org.jboss.netty >> netty has migrated to IO.netty >> netty. It also provides jump links:Mvnrepository.com/artifact/io…”So I clicked in.

3.3.x ~ 3.10.x and 4.0.x netty products are archived on this page.

I tried 3.10.6.final first

<! -- https://mvnrepository.com/artifact/io.netty/netty --> <dependency> <groupId>io.netty</groupId> < artifactId > netty < / artifactId > < version > 3.10.6. The Final < / version > < / dependency >Copy the code

After recompiling, we found that all the imports were fine, but some of the methods of some classes were missing.

At this time, I felt that the version was close to the relatively correct version, and then I chose the latest version 3.9.9.final. After compiling, I found that there was no problem. The missing (deleted) method in 3.10.6.final was indeed deleted in 3.9.9.final.

So it’s safe to assume that 3.9.9.final is most likely the version of Netty that this tripartite JAR relies on.

In 3.3.x ~ 3.10.x, although groupId is io.Net ty, the actual package path is org.jboss.netty.

And then there are the mvnrepository.com/artifact/io… There is also a paragraph on this page

Note: This artifact was moved to:

Io.net ty » netty – all

Io.netty >> Netty has migrated to io.Netty >> all.

This is also explained on the Netty website

Curiosity killed the cat, so I ran to mvnrepository.com/artifact/io… Take a look at this page.

I found that io.netty >> all archived 4.0.x, 4.1.x and the latest 5.0.x

After comparison, I found that the groupId of Netty in 3.2.x and its earlier versions is org.jboss.netty, artifactId is netty, and the package path is org.jboss.netty.

In 3.3.x to 3.10.x, the groupId of netty is io.Netty, artifactId is netty, and the package path is org.jboss.netty.

In 4.0.0.Final and later netty, groupId is io.Netty, artifactId is netty-all, and package path is io.netty.

So 3.9.9.final is the version of Netty that this tripartite JAR depends on, and should be as expected.

Then I used the source code corresponding to the JAR sent by my colleague and added the information of the POM file I added. I quickly re-typed a package and sent it to him to put out the fire.

He tested it out and came back with absolutely no problem.

This is the end of the netty dependent version journey for a three-party library project with no dependent coordinates.

Finally, back to the question at the beginning of the article, do you know how this jar package is generated without explicit dependency coordinate information? Why does this jar exist? Does it have any disadvantages?

See you in the next article!