[seam-dev] Removing the combined jar

[Pete Muir]

The number of jars doesn't matter so much when you use Maven, or a similar approach with managed dependencies. If you use unmanaged dependencies (ala Ant), then it becomes a royal pita.

On 9 Jun 2011, at 23:16, Dan Allen wrote:

> On Thu, Jun 9, 2011 at 18:08, John D. Ament <john.d.ament at gmail.com> 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 at gmail.com> wrote:
> +1
> 
> -Dan
> 
> 
> On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp at gmail.com> wrote:
> +1
> 
> 
> On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak at redhat.com> 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 at 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev