[seam-dev] Removing the combined jar

[Dan Allen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110609/e2dca0a2/attachment.html