Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: discussion about release frequency.
From: Grant Ingersoll <gsingers@apache.org>
In-Reply-To: <AANLkTintc+A=ncTOUWGZO43Y-hgwu47dA+bTB5KYux0m@mail.gmail.com>
Date: Mon, 20 Sep 2010 14:31:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC1FD941-4709-4015-91B6-BD02509201EE@apache.org>
References: <AANLkTinx18uNyGRq5pF90OkU+H2jFT2WC1DYagiGWrqQ@mail.gmail.com>
 <C8BA6C96.1ECE3%Chris.A.Mattmann@jpl.nasa.gov>
 <AANLkTinQWhSnxWbzjBMem78qhVJpXz9K7Frg1yh5mxVe@mail.gmail.com>
 <AANLkTi=E2vEGVm5dF1EbmFiitTJd=gWOW+Basp3yRm8U@mail.gmail.com>
 <7A5D88B2-EC13-43E3-A175-7A8C550FC9F8@apache.org>
 <4C975ADB.2080607@gmail.com>
 <AANLkTimqUWMm5be7SJn0zwnALHUEeGT-tje_wEU+=Wmc@mail.gmail.com>
 <4E5D3286-141F-4422-8D0A-CB48623DD2CD@apache.org>
 <AANLkTinFJFwEG8wyZKc49x_x4XP7VWDmgOe5TK_T1XM7@mail.gmail.com>
 <AANLkTino9y1_u7fmpVS9_4cQ+1g31TjEyEKjBTfyWqFx@mail.gmail.com>
 <AANLkTinakvAMhGShLzcjGB-9Tiv7d=Z6w3wtK97QtR6m@mail.gmail.com>
 <AANLkTimrcUub8MACK0PFguSfS8x2VX1w9Sj8D4nupoUH@mail.gmail.com>
 <004501cb58e4$8886bb30$99943190$@thetaphi.de>
 <AANLkTintc+A=ncTOUWGZO43Y-hgwu47dA+bTB5KYux0m@mail.gmail.com>
To: dev@lucene.apache.org


On Sep 20, 2010, at 1:07 PM, Robert Muir wrote:

>=20
>=20
> On Mon, Sep 20, 2010 at 12:54 PM, Uwe Schindler <uwe@thetaphi.de> =
wrote:
> If somebody reorders the directory structure, I will shout =93revert =
revert revert=94 J
>=20
>=20
> I wouldn't shout "revert revert revert" if by renaming stuff from =
src/java to src/main/java etc, Grant's idea would work, in that we still =
use ant for our build, but we have some way to automagically generate =
IDE configuration files for eclipse, idea, netbeans, emacs, whatever, =
via some maven tool.
>=20
> If this was the benefit, and the tradeoff being more difficult =
merging, and having to ignore some path segments on existing patches, I =
might consider it worth the cost.
>=20
> but again, i have serious questions about maven in general. for =
example, what if I wanted to add/modify a contrib that depends on a =
library that is not "mavenized"?   Is it my responsibility to "mavenize" =
that dependency, too? Does it make the release artifact invalid? is it a =
valid reason against adding that contrib, since its dependencies are not =
all mavenized?

Typically, this is done by adding the library in question to the =
release, renamed appropriately.  For instance, in Solr, we had a trunk =
based version of Commons CSV at one point, so we put it up w/ the Solr =
artifacts and had the POM reflect that.  But yeah, it can be a pain.

>=20
> the fact that maven acts like a computer virus, but requires special =
things of its hosts, means that i am pretty hesitant to vote for "full =
support of it" without knowing exactly what the tradeoffs are.

I'm not saying we have to support it, but, in my view, it's pretty hard =
to take back a feature, admittedly only for some, that we have supported =
for a long time.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org