Understandable, but is it really a concern of most deployments? Especially
if the application is deployed on a servlet container (we all know this
happens way too often) a few extra jars for an API / impl probably won't be
noticed anyway.
On Thu, Jun 9, 2011 at 16:08, John D. Ament <john.d.ament(a)gmail.com> wrote:
-1
In my opinion the combined jar helps keep the number of JAR files down in
deployments.
On Thu, Jun 9, 2011 at 12:54 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> +1
>
> -Dan
>
>
> On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com>wrote:
>
>> +1
>>
>>
>> On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)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(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
>
>
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: