Jochem,David,Jörg, Barrie, Thanks for your contribution. I'm currently updating my article to take into account the feedback received. It look like ther is a consensus to invest more time on configuring the structure in API/IMPL projects because it's a one time effort offering indubitable benefits. It is clear as well that the configuration should enforce the clean separation for the api user point of view and for the implementation side not relying on the good intentions and paper design principles.
At that stage two questions remain in my mind : 1) Should we have a parent project for each tier: e.g.: Business tier project Business tier api project Business tier impl project 2) Should we use in that practical case a hierarchical maven project structure or a flat structure. On Thu, Apr 21, 2011 at 4:52 AM, Barrie Treloar [via Maven] < [email protected]> wrote: > On Thu, Apr 21, 2011 at 12:18 PM, Barrie Treloar <[hidden > email]<http://user/SendEmail.jtp?type=node&node=4329867&i=0&by-user=t>> > wrote: > > > On Thu, Apr 21, 2011 at 6:33 AM, Jörg Schaible <[hidden > > email]<http://user/SendEmail.jtp?type=node&node=4329867&i=1&by-user=t>> > wrote: > >> Jochen Wiedmann wrote: > >> > >>> On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 <[hidden > >>> email]<http://user/SendEmail.jtp?type=node&node=4329867&i=2&by-user=t>> > 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: [hidden > email]<http://user/SendEmail.jtp?type=node&node=4329867&i=3&by-user=t> > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=4329867&i=4&by-user=t> > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4329867.html > To unsubscribe from Article proposed for Maven Article Page, click > here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4315294&code=c3Vyc2luaUBnbWFpbC5jb218NDMxNTI5NHwtMTI5ODU1NTEw>. > > -- Best regards, Sébastien Ursini 17 avenue de la Croisette 1205 Genève M: +41 79 335 62 89 Skype : sursini E: [email protected] -- View this message in context: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4330237.html Sent from the Maven Developers mailing list archive at Nabble.com.
