Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (athena.apache.org: domain of boards@gmail.com designates
 209.85.223.181 as permitted sender)
From: Matt Sicker <boards@gmail.com>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-6E7C1AA0-0231-4EB6-8A21-20890E68AB59
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: Should we emphasize the usage of our Bill of Material pom?
Message-Id: <863291FE-5DC9-4FA7-99E5-A976E1CE976E@gmail.com>
Date: Fri, 7 Mar 2014 07:48:29 -0600
References: 
 <CACmp6koVDfObTcAX7uWsVP3DLG_JLSwNKk1mLPtJ2j2JF+QTcw@mail.gmail.com>
 <E6106D3A-3F4C-447C-A475-C4A9EEDB6739@apache.org>
In-Reply-To: <E6106D3A-3F4C-447C-A475-C4A9EEDB6739@apache.org>
To: Log4J Developers List <log4j-dev@logging.apache.org>

--Apple-Mail-6E7C1AA0-0231-4EB6-8A21-20890E68AB59
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Also, the BOM is handy when you want to use Flume. Our projects at work use v=
arious logger frameworks right now, so being able to pull in all the binding=
s consistently is a nice feature.

Also, if you use independent package or bundle versions in an OSGi environme=
nt, I could see a BOM being a handy concept.

Matt Sicker

> On Mar 7, 2014, at 6:09, Ralph Goers <rgoers@apache.org> wrote:
>=20
> Just for grins, do you know who added "import" scope (and hence, support f=
or BOM poms) to Maven?  =20
>=20
> BOM poms are quite useful when you have a set of projects that are indepen=
dently versioned, but when they all have the same version the usefulness dis=
appears as you will typically just define a variable such as log4j.version, a=
ssign it a value, and then use it on all the Log4j dependencies. Yes, you ca=
n just specify the BOM pom in the dependency management section, but in the v=
ast majority of cases I would expect users are only going to use 2 or 3 Log4=
j jars.
>=20
> Ironically, I created import scope because we had a project where the indi=
vidual subprojects were independently versioned. When we switched to have th=
em all use the same version we dropped the BOM pom.
>=20
> Fro these reasons I don't think we need to emphasize using the BOM pom. At=
 the same time, I don't see a problem mentioning it with an example in the M=
aven section of the doc.
>=20
> Ralph
>=20
>> On Mar 6, 2014, at 9:10 PM, Matt Sicker <boards@gmail.com> wrote:
>>=20
>> See for example any of the guides at Arquillian <http://arquillian.org/gu=
ides/>. Using a BOM pom is handy as a way to keep dependency groups in sync.=
 It also allows for smaller pom.xml files. I'm not sure what an equivalent s=
cript would be using Ivy, but that sort of documentation and support might b=
e rather useful as well.
>>=20
>> I'll make the changes in a branch to show what I mean.
>>=20
>> --=20
>> Matt Sicker <boards@gmail.com>

--Apple-Mail-6E7C1AA0-0231-4EB6-8A21-20890E68AB59
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Also, the BOM is handy when you want t=
o use Flume. Our projects at work use various logger frameworks right now, s=
o being able to pull in all the bindings consistently is a nice feature.</di=
v><div><br></div><div>Also, if you use independent package or bundle version=
s in an OSGi environment, I could see a BOM being a handy concept.<br><br>Ma=
tt Sicker</div><div><br>On Mar 7, 2014, at 6:09, Ralph Goers &lt;<a href=3D"=
mailto:rgoers@apache.org">rgoers@apache.org</a>&gt; wrote:<br><br></div><blo=
ckquote type=3D"cite"><div><meta http-equiv=3D"content-type" content=3D"text=
/html; charset=3Dutf-8"><div>Just for grins, do you know who added "import" s=
cope (and hence, support for BOM poms) to Maven? &nbsp;&nbsp;</div><div><br>=
</div><div>BOM poms are quite useful when you have a set of projects that ar=
e independently versioned, but when they all have the same version the usefu=
lness disappears as you will typically just define a variable such as log4j.=
version, assign it a value, and then use it on all the Log4j dependencies. Y=
es, you can just specify the BOM pom in the dependency management section, b=
ut in the vast majority of cases I would expect users are only going to use 2=
 or 3 Log4j jars.</div><div><br></div><div>Ironically, I created import scop=
e because we had a project where the individual subprojects were independent=
ly versioned. When we switched to have them all use the same version we drop=
ped the BOM pom.<br><br>Fro these reasons I don't think we need to emphasize=
 using the BOM pom. At the same time, I don't see a problem mentioning it wi=
th an example in the Maven section of the doc.</div><div><br>Ralph</div><div=
><br>On Mar 6, 2014, at 9:10 PM, Matt Sicker &lt;<a href=3D"mailto:boards@gm=
ail.com">boards@gmail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"ci=
te"><div><div dir=3D"ltr">See for example any of the guides at Arquillian &l=
t;<a href=3D"http://arquillian.org/guides/">http://arquillian.org/guides/</a=
>&gt;. Using a BOM pom is handy as a way to keep dependency groups in sync. I=
t also allows for smaller pom.xml files. I'm not sure what an equivalent scr=
ipt would be using Ivy, but that sort of documentation and support might be r=
ather useful as well.<div>
<br></div><div>I'll make the changes in a branch to show what I mean.<br cle=
ar=3D"all"><div><br></div>-- <br>Matt Sicker &lt;<a href=3D"mailto:boards@gm=
ail.com" target=3D"_blank">boards@gmail.com</a>&gt;
</div></div>
</div></blockquote></div></blockquote></body></html>=

--Apple-Mail-6E7C1AA0-0231-4EB6-8A21-20890E68AB59--