This would be in addition. Not everyone needs all the bridges or additional
framework support.

On 11 December 2015 at 11:08, Gary Gregory <[email protected]> wrote:

> In my mind, any kind of fat jar would be a new module. Matt?
>
> Gary
>
> On Fri, Dec 11, 2015 at 9:00 AM, Mikael Ståldal <[email protected]
> > wrote:
>
>> I certainly hope that this will not replace the different modules we have
>> today.
>>
>> On Thu, Dec 10, 2015 at 10:36 PM, Ralph Goers <[email protected]
>> > wrote:
>>
>>> I understand what this does in the non-OSGi case and I’m not in favor of
>>> it and haven’t been each time it has been brought up.
>>>
>>> Ralph
>>>
>>> On Dec 10, 2015, at 12:55 PM, Matt Sicker <[email protected]> wrote:
>>>
>>> Ralph, this doesn't affect OSGi. It's just specifying a single
>>> dependency for each project rather than specifying several. Also, using
>>> log4j-bom does reduce the amount of XML required to use log4j, but it
>>> doesn't help this use-case.
>>>
>>> On 10 December 2015 at 13:18, Gary Gregory <[email protected]>
>>> wrote:
>>>
>>>> Also, we use Ant in some of our products, I'm not going to write a POM
>>>> to be used from Ant...
>>>>
>>>> Gary
>>>>
>>>> On Thu, Dec 10, 2015 at 11:17 AM, Gary Gregory <[email protected]>
>>>> wrote:
>>>>
>>>>> The whole point here is to provide a jar...
>>>>>
>>>>> Gary
>>>>>
>>>>> On Thu, Dec 10, 2015 at 10:40 AM, Paul Benedict <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> You can also achieve the same thing by creating a "fat POM" that
>>>>>> lists all the dependencies (or the ones you're interested in). My point 
>>>>>> is
>>>>>> you don't have to build another jar; you can achieve this by building
>>>>>> another POM.
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>> On Thu, Dec 10, 2015 at 12:38 PM, Gary Gregory <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> To the point of conveniences, the convenience is GREAT when I use
>>>>>>> cxf-bundle, hamcrest-all, activemq-all, jetty-all, mockito-all, and so 
>>>>>>> on,
>>>>>>> instead of being forced to list out 50 or who-knows-how-many modules. 
>>>>>>> For
>>>>>>> our big app server, I just use bundles and be done with it unless a
>>>>>>> specific dependency problem arises.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Dec 10, 2015 at 10:28 AM, Ralph Goers <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> My understanding is that most of the people who combine jars like
>>>>>>>> this also include the classes from their application. For that reason I
>>>>>>>> don’t think it would be helpful.
>>>>>>>>
>>>>>>>> Beyond that, I am not sure combining them makes it
>>>>>>>> “super-convenient”. The only place this might be helpful is in OSGi, 
>>>>>>>> and
>>>>>>>> even then I am not sure as I don’t really know enough about OSGi. 
>>>>>>>> Also, we
>>>>>>>> need to look at the new module system in Java 9.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 10, 2015, at 11:13 AM, Matt Sicker <[email protected]> wrote:
>>>>>>>>
>>>>>>>> Most projects where I use log4j2, I include all the following
>>>>>>>> dependencies thanks to framework logging divergence:
>>>>>>>>
>>>>>>>> log4j-api
>>>>>>>> log4j-core
>>>>>>>> log4j-jcl
>>>>>>>> log4j-jul
>>>>>>>> log4j-slf4j-impl
>>>>>>>> log4j-1.2-api
>>>>>>>>
>>>>>>>> Shading these together would be super-convenient. Would anyone else
>>>>>>>> be interested in such a thing? I usually see this sort of thing in 
>>>>>>>> testing
>>>>>>>> frameworks (like mockito-all, hamcrest-all, etc.), but calling this
>>>>>>>> log4j-all would be incorrect.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <[email protected]>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: [email protected] | [email protected]
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: [email protected] | [email protected]
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: [email protected] | [email protected]
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <[email protected]>
>>>
>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> [email protected]
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
>
> --
> E-Mail: [email protected] | [email protected]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker <[email protected]>

Reply via email to