On Thu, Apr 21, 2011 at 12:18 PM, Barrie Treloar <baerr...@gmail.com> wrote: > On Thu, Apr 21, 2011 at 6:33 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> Jochen Wiedmann wrote: >> >>> On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 <surs...@gmail.com> wrote: >>> >>>> The client api is a separate artifact. You can reuse it as you want. In >>>> your repository you will get in the same release folder two artifacts : >>> >>> That's completely understood. But as a separate jar file, you should >>> ensure that it is compilable without any of the other classes. For >>> example, it might accidentally import something from the rest of the >>> packages. You don't get that safety by just repackaging a bunch of >>> class files in another jar file. >> >> Even more, the implementation may require dependencies, that are absolutely >> uninteresting (and unwanted) for the client. This itches me already for the >> ejb-client artifact. Separate projects can have different dependencies, >> attached artifacts share them always with the main artifact. > > +1 for all the reasons to separate client/api jars. >
I was just trying to think of another way to articulate why letting the build system do it is better than relying on the developers. Using Big O notation: Effort for build system: Configuring the project structure: O(1) Configuring your IDE/dev setup: O(1) Effort to enforce clean separation: O(0) Effort for developers: Configuring the project structure: O(1) - its a once of to have one module or two modules Configuring your IDE/dev setup: O(1) Effort to enforce clean separation: O(n) - i.e. every release you need to manually validate that this has not been accidentally broken. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
