Question about proper package naming


#1

Hi

Not a JME related question…

For a client/server ECS (Entity Component System) based game, which of the below package naming style is more suitable ?

For each module, I have 3 submodule : common, server, client.

ex:

  • Quest module:
    • quest-common.jar
    • quest-server.jar
    • quest-client.jar

package naming style 1:

com.{your_company_name}.{your_app_name}.common.quest.component
com.{your_company_name}.{your_app_name}.server.quest.system
com.{your_company_name}.{your_app_name}.server.quest.service // RMI services server side
com.{your_company_name}.{your_app_name}.client.quest.view
com.{your_company_name}.{your_app_name}.client.quest.service // RMI services client side

package naming style 2:

com.{your_company_name}.{your_app_name}.common.component.quest
com.{your_company_name}.{your_app_name}.server.system.quest
com.{your_company_name}.{your_app_name}.server.service.quest
com.{your_company_name}.{your_app_name}.client.view.quest
com.{your_company_name}.{your_app_name}.client.service.quest

#2

imo, more theoretically(machine logic) logical is style 2,

but i prefer style 1 here, because its more human readable. when you work on some “component” you dont usually want go each different folder(here you have only 3 trully, there 5), but have everything under one folder.

its like modules, each module have same dirs.

but i do style 1 only in almost leaf packages, not before. thats important.

thats just my opinion.

trully you should just look what will be more readable imo. (and predict if there will be later more subpackages, because then option 1 might be more readable)


#3

I’m in the camp of not creating packages unless there is more than 3 classes in them or there is truly an organizational requirement. On top of that, packaging trumps everything.

So if ‘quests’ are truly a separate thing then I’d put them at the root because if I’m a user of your API, I’d want to be able to look at all ‘quest’ stuff together.

Then under that server, client, view, common… and nothing else unless there are so many classes that further differentiation is necessary.

That’s just the way I might do it.


#4

A note on this. This is only necessary when you are competing with other namespaces… ie: you intend to publish your thing as a jar used by other applications that might be including other jars that have similarly named sub-packages and classes.

And in that case, the namespace should be based on something you own… generally a domain name. So only com.{your_company_name} if you own the {your_company_name}.com domain.

Else there isn’t a strong reason to have it at all. Might as well just start with {your_app_name}.


#5

Absolutely correct. For example, my company owns liquidcrystalstudios.com, thus our packages start with com.liquidcrystalstudios.{project_name} (yes it is annoyingly long). But I personally own tlf.io, thus my personal projects I use io.tlf.{project_name}


#6

Yep, and JME kind of messed up with the package naming. Did it for a while in the maven org ID also until I fixed that at least.


#7

Thanks guys for all your comments

I removed com.{your_company_name} as I do not own any domain.

Thanks, going to do as you said.


#8

B…but… I feel naked without a package name!


#9

I do, too… but it does feel super convenient when importing app classes not to have to type com.foo.bar.baz.bing.poo.pop all the time. And a little strange. Like walking around in your underpants I guess.

Note: if you are making open source software and do not have your own domain then presumable you are pushing that code somewhere (github, for example). Perfectly fine to use that + project as your root package in that case. com.github.mycoolproject.whatever.


#10

Take note, it does not always have to be a domain name, an example of this is the sun packages. There is no sun TLD. The same goes for my company, lots of our internal projects are lcs.{project_group}.{project_name} instead of com.liquidcrystalstudios.{...} This is because lcs is not a TLD (and not likely to ever be one). Some of my friends use their initials for example: smd.{something} It is just nice to have a package for all of your work just for organization.


#11

It’s true. The domain thing is suggested convention as it should 100% guarantee a lack of clashing in the namespace.

…consequently, many folks will use it to try to find the source of some piece of code. (That’s why JME’s is dangerous because jme3.com has nothing to do with us.)


#12

Good to know that

Actually I was using com.otm (abbreviation of OverTheMoon) just because I like it, I have had no intention to create a domain for it. Maybe I better to remove the com out of it and use otm.{my_app_name}.


#13

you really own it? its 3 letter long :smiley: hard one to get even for .io i think. :slight_smile:

i remember when was looking for domain 3 letter was really hard to get. (but i dont check .io)

gratz.


#14

Yep, you can check here:
https://www.godaddy.com/whois/results.aspx?checkAvail=1&tmskey=&domain=tlf.io

It is one of my favorites. I have a small (perhaps not that small) hobby of collecting domain names.