To me, this is more of a library in the first place. Like gson or others. At second it can be an eclipse plugin. The .core to me is more like a eclipse way of doing things. So, that's why I removed that part, because I think a jar is the primary use-case and distribution of this lib.

However, last night, I come up with the following: that some parts (the core) just desribe a API to manage a composer.json whereas the packages package to receive and search for packages lives on the same hierarchy level as the "core" (however such a package doesn't need to be named core).

At the end, I don't know which strategy sounds best.

However, can be easily refactored ;)