Re: [seam-dev] Removing the combined jar

On Thu, Jun 9, 2011 at 18:08, John D. Ament <john.d.ament(a)gmail.com&gt; wrote: -1 In my opinion the combined jar helps keep the number of JAR files down in deployments. # of jars really doesn't matter, it's the size of the war that matters (when we are talking about sizes). The problem with the combined JAR is that it's too easy for a developer to inadvertently *also* add the implementation and api jars separately, and then the application goes haywire. This is a slippery slope because of transitive dependencies. The other point that a colleague of mine pointed out is that by making a combined jar, you undermine the whole effort of having an api/impl split. And seeing how we are trying to encourage interface-based development and separation of these concerns, it's the right thing to do. I'll also add that scanning behaves differently when you have a combined jar vs individuals. So you are introducing subtle differences that could lead to bugs. -Dan On Thu, Jun 9, 2011 at 12:54 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: +1 -Dan On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com&gt; wrote: +1 On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: We discussed this briefly on IRC, however I thought we should discuss it on seam-dev before we make any concrete decision. To summarise the plan: 1. Remove the combined jar file from each of the modules 2. If the module has a single implementation, rename it to whatever the combined jar was called. E.g. for Seam Catch, the impl module would be called seam-catch. 3. If the module has multiple implementations, then add a suffix to the artifact name that reflects the individual implementation. E.g. Seam Reports has two implementations, which would be called seam-reports-jasper (for Jasper reports) and seam-reports-pentaho (for Pentaho). 4. Leave the API naming as it is, e.g. seam-reports-api. The idea is that by importing the simplified module artifact name (i.e. "seam-xxx") you would get the default implementation, which in turn depends on the API. The advantage of this is that we won't break backwards compatibility - e.g. someone currently declaring a dependency on "seam-catch" in their pom file won't have their app broken when we rename the modules. Also we remove the complexity introduced by having a combined jar in the first place. If you can spot any issues with this, please speak up now ;) Shane _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev