I don't see any problems at all. The classes that are truly common (i.e. shared between your client code and server code) goes into a shared library. This is one of the modules and let's call it "common". Then you put the client specific code in a separate module, which has a dependency to "common". And then you put the server specific code in the server module, which also has a dependency to "common". Thus, three modules which are handled by one aggregating pom. This is what we call a multi-module build and this is standard procedure for most dev projects.
/Anders On Wed, Sep 12, 2012 at 5:12 PM, Julian Wiesner <[email protected]> wrote: > Dear Maven Users Community, > > Thank you for your responses so far. > > @Anders: I'm aware that generally speaking the method I suggested is > unconventional. However, the nature of my project is very unconventional > itself. To give you a further idea of my Project: It is a Mod to an existing > application. The server side (i.e. packet handling, port management, etc) is > all dependent on an API which is different from the client side. The client > side will mostly entail functions that will only be useful to the user. I'm > trying to reduce the amount of unnecessary code to have a more efficient > application. Sure, it'd be easy to just write all the code for the client > and server in one jar, but half of it won't be used in either environments. > > @Wayne: By adjusting I mean either omit or add functions that are required > by the provided API. The way this application, for which I'm creating this > Mod, is set up so that there are 2 different APIs for the Client and the > Server. (Probably due to the fact there is a large community developing Mods > for it.) For my Mod to work on the server I will have to integrate it into > its API and the same with the client. Thus, I have different imports and > different functions for each version. Currently how I'm managing my code is > by strictly working on the common classes that are shared between the 2 > versions. However, I have problems setting my project up in the way I > described earlier. > > I hope this may have clarified some questions. > > Sincerely, > > Julian Wiesner > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
