Why does package naming violate Maven groupId?

[keilw]

While the POM contains a common groupId "com.squareup" and artifactId "dagger", the package name is simply "dagger".
This is highly uncommon and adds risk of package name or dependency clashes you'd avoid, if the package was properly named.

[cgruber]

You make it sound like a moral or legal issue. Lol.

Maven groupid naming isn't a formal spec that can be "violated". It is a
common practice. We were not permitted to have "dagger" as the groupid
and still put things into sonatype's maven repository, but java package is
a namespace choice that has other considerations. But that we may not
mirror our desired package name in our maven group id doesn't mean we must
mirror our group id in our package.

It is possible to have a package conflict. But dagger is an unusual name,
and it would surprise me that someone used dagger.Foo and had an overlap.
Also, short package names are convenient and make for more readable client
code where fully qualified names are used.

Regards,
Christian
Sent from my iPhone.

On Nov 8, 2012, at 8:54, Werner Keil notifications@github.com wrote:

While the POM contains a common groupId "com.squareup" and artifactId
"dagger", the package name is simply "dagger".
This is highly uncommon and adds risk of package name or dependency clashes
you'd avoid, if the package was properly named.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/97.

[swankjesse]

We anticipate forks. Suppose Google's fork of dagger used com.squareup.dagger in imports, but com.google.dagger in the Maven group ID. In either case we're vulnerable to naming collisions. But with dagger as the package name we don't degrade forks.

[keilw]

Fascinating, so would com.google.dagger use exactly the same package?!
If it does, that's the perfect case of Classpath Hell such a naming causes.

[swankjesse]

@keilw yeah, the exact same package! Scary right?

The upside is that forkers won't need to fork their dependencies and their dependencies' dependencies in order to change their internal imports from import com.squareup.dagger.Provides to import com.google.dagger.Provides.

As I understand it smart tools like Maven make it easy to express concepts like Google's dagger is incompatible with Square's dagger. It's similar to how we somehow avoid classpath hell even though Dagger 0.9 and Dagger 1.0 will share the same package name. Imagine if you needed to change imports every time your version changed!

[keilw]

Sure people did all kinds of strange things in Maven, remember those SpringSource OSGi-enabled Maven artifacts, which were repackaged into something like "com.springsource.org.apache.commons.logging";-D
Java Jigsaw still hasn't shown enough credible evidence how it wishes to solve this, but at least via OSGi, even if the package or bundle names were exactly the same you can tell your code whether to use Dagger 0.9 or 1.0;-)

So while OSGi has means of telling Dagger 0.9 and 1.0 apart even if both were in the same classpath, Maven itself isn't smart enough to do so.

[tonit]

The argument "we anticipate forks" for a simplistic namespace like
"dagger" instead of "com.squareup.dagger" is really interesting.
Usually i throw people out of the window not following (seemingly good)
conventions.
You increase the likelihood of collisions but increase certainty of forks.
Question is why?

As a "platform building guy" i like to spread the open for extension but
close to modification paradigm. But if you say you embrace forks your
really mean *open for modification, but close to extension *? This is a
fundamental question not suitable for this thread but i find the fact that
you do and the way you embrace it worth thinking about! (note to myself).

Speaking of OSGi, using Attribute Matching, OSGii subsystems or Capability
mechanisms you have a wealth of options to lock down competing providers of
Dagger in the same VM.
Just my 2cts.
Toni

Toni Menzel | Founder | Rebaze GmbH
toni.menzel@rebaze.com | www.rebaze.com
Access To Alien Technology: Great software needs a great foundation. We
help unlocking the next level in technology.
Rebaze Pass for Maven http://goo.gl/1YLlt, Rebaze Pass for
OSGihttp://goo.gl/WP8XT
, Rebaze Pass for Neo4j http://www.rebaze.com/services/, Rebaze Pass for
Jenkins http://www.rebaze.com/services/

On Thu, Nov 8, 2012 at 4:02 PM, Werner Keil notifications@github.comwrote:

Sure people did all kinds of strange things in Maven, remember those
SpringSource OSGi-enabled Maven artifacts, which were repackaged into
something like "com.springsource.org.apache.commons.logging";-D
Java Jigsaw still hasn't shown enough credible evidence how it wishes to
solve this, but at least via OSGi, even if the package or bundle names were
exactly the same you can tell your code whether to use Dagger 0.9 or 1.0;-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/97#issuecomment-10190827.

[keilw]

+1

[swankjesse]

The decision to go with a nonconvential package name was not made lightly! We had a very conventional package name for Guice and lived to regret it. In particular:

• Despite Guice's expansive SPI for configuration and extension, forks still happen! The most notable is sisu-guice, which is used in Maven. The forks' Maven groupId org.sonatype.sisu.inject disagrees with its package name com.google.guice. So if forks exist, violations of the naming pattern exist.
• It is the nature of dependency injection frameworks that you import them everywhere in your project. You need to import annotation types in every class that participates. With Guice we received complaints that developers didn't want to import a proprietary package com.google.inject in their core types.

I've seen few practical drawbacks of this approach.

[tonit]

Fully agree. I just said its a nice angle that hasn't spread yet. I know
you'd mention the Sisu example. Good one.
About "not importing proprietary packages": I've seen both directions: *
com.company* looks proprietary, org.apache or org.ops4j *(shameless
plug) are seemingly *trust-building namespaces.

Toni Menzel | Founder | Rebaze GmbH
toni.menzel@rebaze.com | www.rebaze.com
Access To Alien Technology: Great software needs a great foundation. We
help unlocking the next level in technology.
Rebaze Pass for Maven http://goo.gl/1YLlt, Rebaze Pass for
OSGihttp://goo.gl/WP8XT
, Rebaze Pass for Neo4j http://www.rebaze.com/services/, Rebaze Pass for
Jenkins http://www.rebaze.com/services/

On Thu, Nov 8, 2012 at 4:42 PM, Jesse Wilson notifications@github.comwrote:

The decision to go with a nonconvential package name was not made lightly!
We had a very conventional package name for Guice and lived to regret it.
In particular:

Despite Guice's expansive SPI for configuration and extension, forks
still happen! The most notable is sisu-guicehttps://github.com/sonatype/sisu-guice,
which is used in Maven. The forks' Maven groupId
org.sonatype.sisu.inject disagrees with its package name
com.google.guice. So if forks exist, violations of the naming pattern
exist.

It is the nature of dependency injection frameworks that you import
them everywhere in your project. You need to import annotation types
in every class that participates. With Guice we received complaints that
developers didn't want to import a proprietary package
com.google.inject in their core types.

I've seen few practical drawbacks of this approach.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/97#issuecomment-10192378.

[keilw]

Yeah, beside trying to seem what it isn't (a "standard" like "java." or #javax." packages) it has the side-effect, that it hides which company is behind it, at least on a Java level. Whether intentional or not, I don't know, Bob though he doesn't seem involved in Dagger is (former) Spec Lead of 330 after he left Google, but unlike Guice JSRs are always supposed to be vendor-neutral. If some of you may keep maintaining these projects even after eventually leaving Square, let's see, at least Twitter in some cases seems a bit like a "Rotating Door" for developers;-)

[cgruber]

On 8 Nov 2012, at 11:05, Werner Keil wrote:

Yeah, beside trying to seem what it isn't (a "standard" like "java."
or #javax." packages) it has the side-effect, that it hides which
company is behind it, at least on a Java level. Whether intentional or
not, I don't know, Bob though he doesn't seem involved in Dagger is
(former) Spec Lead of 330 after he left Google, but unlike Guice JSRs
are always supposed to be vendor-neutral. If some of you may keep
maintaining these projects even after eventually leaving Square, let's
see, at least Twitter in some cases seems a bit like a "Rotating Door"
for developers;-)

I am employed by Google and contributing to Dagger as part of my day
job, which is "making dependency injection better at Google". I also
contribute to Guice. Square initiated Dagger, from a fork of Miniguice
(written by Jesse).

Put another way - Square is putting dollars behind this in the form of
time, and deserves credit… but non-Square folks are involved, and that
was always the intention. There's no "hiding the company behind it" -
many companies are behind it. And as to trying to seem what it isn't (a
standard) is a matter of perspective. Whether it becomes a standard
depends on market forces - who uses it.

This is beyond the scope of this conversation - de-jure vs. de-facto
standards, but the package dagger means that I can make a google fork of
Dagger if I want, and, to the extent that we all collaborate to keep
client-side incompatibilities small or nonexistent, we can benefit from
a single java namespace for what are, in fact, replacement products.

[keilw]

Thanks for the input, I know, some of it may even be worth more a blog or something.
I can't name them, but companies involved in or evaluating Agorava are looking at some of these implementations, Dagger, Guice itself or various forks and derived projects, and when one of them is found appropriate, they are also considering to put further resources behind it.

[levonk]

I know this issue has been put to rest for a while. But, It seems to me that it would have been preferable to just purchase us.dagger instead of violating the convention. Interesting discussion happening here as well https://www.reddit.com/r/java/comments/5sh96o/packaging_java_is_it_time_to_stop_beginning_with/

[JakeWharton]

We won't be doing this.

[keilw]

Wow after 4 1/2 years ;-) Thanks for feedback nevertheless. A few highly regarded projects like FitNesse also don't give a damn about the package name or artifactId.

[JakeWharton]

The groupId and artifactId follow convention which are much more important (as do all our single package name projects).

[keilw]

If it's just an internal, project-specific package and library, I certainly agree. If it contains public API or SPI to be used by other projects or products that's a different story.