Use iipc-web-commons consistently as the project name

[nlevitt]

This project should be named consistently. If the github repository is called "iipc-web-commons", it can only cause confusion to make the artifact name "commons-web", since that will be the name of the distribution jar and/or tar.gz. Having a third name, "OpenWayback Web Commons", in the readme, is even more confusing.

The most important thing, imho, is that the names be consistent. So if it has to be "commons-web", let's make it commons-web everywhere. Likewise if it has to be "OpenWayback Web Commons". But I think "iipc-web-commons" is the most appropriate name.

"commons-web" doesn't make sense to me in English, "web-commons" does. The only reason to reverse that ordering is if it's a subproject of something called "commons". And "commons-web" invites confusion with the http://commons.apache.org/ subprojects. Also commons-web is very generic sounding, it could be a lot of things, so I think qualifying it with "iipc" is appropriate.

I don't particularly like "OpenWayback Web Commons" either, because the library is used for more than just openwayback.

But the most important thing in my mind is that the names be consistent.

Edit: I just noticed that if you do a maven build currently, you end up with two jars, "commons-web-1.1.1-SNAPSHOT.jar" and "iipc-web-commons-jar-with-dependencies.jar"!

[ikreymer]

Agreed. Looking at other artifacts out there, there are others with names like X-web-commons so this would fit an existing paradigm. Looking through a listing of jars (say in a war file) and seeing one named commons-web is only going to lead to confusion. IIPC/OpenWayback related jars should be named in a way that clearly defines their association with the project.

[adam-miller]

Can someone please comment on the status of this? It would be nice to get this sorted out soon.

[anjackson]

So, the current form seemed like a good idea because that's how Apache do it. i.e. It's Apache Commons IO, etc. This is the only consistent naming strategy for 'commons' that I'm aware of. However, it seems to have confused people, so perhaps it's not worth adopting their naming strategy.

I think putting the IIPC in the artifact name is unnecessary - the fact that it is under the org.netpreserve groupId is entirely sufficient, and I think is a much cleaner way of doing it. Similarly, having it in the repository name is also redundant, due to the /iipc/ prefix. It also ensures forks have what I would consider to be more sensible names, i.e. internetarchive/web-commons rather than internetarchive/iipc-web-commons.

I would personally rather compromise on calling the artefact 'web-commons' and renaming the repository to match. (note that GitHub honours the repositories previous endpoints, so this should not break anything.)

I will also add send this issue around the mailing list to check if anyone else wants to comment.

[egh]

I agree with Andy, though perhaps I would prefer webarchive-commons to web-commons.

[nlevitt]

Thanks! I'm fine with either of those names, myself.

[ikreymer]

Would prefer webarchive-commons as well. The other part to this is that the artifact id names also transfer to jar names without the group-id (by default anyway), so you end up with webarchive-commons.jar in your lib dir. Without a group-id as part of the name, artifact id names can be much more ambigous, but webarchive-commons.jar is much better than web-commons.jar

[adam-miller]

I agree, webarchive-commons seems descriptive enough to handle the ambiguity here.

[kris-sigur]

I agree with Eric, webarchive-commons is more accurate than web-commons.

I'm also thinking that the generated JAR's name should be prefixed with IIPC- even if we do not include it in the artifactId. Would make it easier to identify the JAR file in the lib folder of a project that depends on this one. The current JAR name web-commons.jar is painfully generic.

[anjackson]

@kris-sigur do you have an example? All the projects I'm aware of use Maven or Ivy rather than the old 'stuff some libs in a folder' approach.

Also, if the iipc- prefix is deemed appropriate, shouldn't it also apply to Wayback itself, i.e. should it be called iipc-openwayback?

[kris-sigur]

@anjackson Even if you use Maven to manage it, the JAR file still winds up in a lib folder somewhere when the software is packaged. You hope never to have to worry about it at that level but Murphy's law usually bites you sooner or later.

If renamed to webarchive-commons this is less an issue.

To be clear, I don't see a need for including iipc- in the artifactId. Just in the generated JAR filename.

[anjackson]

Okay, so I merged, then modified to use the webarchive-commons naming scheme (2d5ab076e8d440f2352c8fed0874f5eb5c548383). GitHub then automatically closed the request, but it can be re-opened if folks are not happy with how things are right now (or you can open a new issue/pull request of course).

I have not yet changed the name of the generated JAR, as I've not had a chance to look up how to do that.

[nlevitt]

Thanks Andy!

I feel pretty strongly that the artifactId, github project name, and jar name should match. I'm thinking webarchive-commons is specific enough that additionally qualifying with iipc- is unnecessary, but I don't care too much if it's webarchive-commons or iipc-webarchive-commons or iipc-web-commons as long as it's consistent.

If we're sticking with webarchive-commons, can we change the github project name too?

[anjackson]

Yes, we should change the GitHub project/repo name too, I just wanted to hold off doing that for a few days in case anyone wants to object to the new name.