msgpack android,MessagePack For Android

Hi!

Again, I'm glad you like it :).

Regarding the proposed structure - I'm all for modularization of course. However, I'm afraid I haven't encountered the sort of approach you propose here. Usually what I've seen in configurations like this is one of the two:

Either split the platform-specific code into separate projects, and have two effective dependencies, i.e. something like:

msgpack-java/

msgpack-core/

# a core library of msgpack-java

# includes org.msgpack.{packer,template,type,unpacker} packages

msgpack-template-generator/

# includes org.msgpack.template.builder packages

msgpack-default/

# all-in-one project

msgpack-beans/

# includes Beans library of the existing msgpack-java

msgpack-android/

# includes custom beans (your code is here)

...

or, create two profiles activated by a property, one adding an "android" classifier to the build artifact, when applicable, something like this (in the POM of msgpack-java):

general

!android.build

android

android.build

org.apache.maven.plugins

maven-jar-plugin

android

The problems I see with the original approach:

I'm afraid there would have to be some configuration duplication between msgpack-default and msgpack-android.

The way I understand it, Maven interprets subfolders with a POM as modules. All modules of a project (msgpack-java, in this case) are built whenever it is built - but the reverse does not hold. So, you would have to trigger the build and install of msgpack-core etc. manually when building either msgpack-default or msgpack-android.

But I may be wrong, feel free to correct me in this case :).

Cheers,

Mikołaj

PS. By the way, how should I properly address you on a "first-name" basis?