Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of bimargulies@gmail.com
 designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOdYfZW_Ui7XLQwwbNZ1gTru0hVJu7DpsVGCQ0Rx50zPTGvu6Q@mail.gmail.com>
References: 
 <CAL8PwkaMqw87E97gk49wqV7Jao5whpu+5yA2p754+2N8GcBksQ@mail.gmail.com>
	<008801cd2195$5daf5db0$190e1910$@thetaphi.de>
	<6C78E97C707B5B4C8CC61D44F87545861DD6BF@SUEX10-mbx-03.ad.syr.edu>
	<008c01cd2198$23677220$6a365660$@thetaphi.de>
	<CAOdYfZX3k1x_1Ue1PJkfyzeVpLZCvX-FBdin1ZotEKb4ouAQmg@mail.gmail.com>
	<CALhtWkfHC5L80G6XnMbieY3+MmvxoyRsO3pXjH1521trcCvB1A@mail.gmail.com>
	<CAOdYfZXjwe0F2viJKQDsGs5fC-43tA41fhYDkfSn1tRMS3T=Hg@mail.gmail.com>
	<CALhtWkemUhHxOkScke=OYt1ov5DHm5OT_yv4Eq1+7RFbwUHGJg@mail.gmail.com>
	<CAOdYfZW_Ui7XLQwwbNZ1gTru0hVJu7DpsVGCQ0Rx50zPTGvu6Q@mail.gmail.com>
Date: Mon, 23 Apr 2012 18:22:49 -0400
Message-ID: 
 <CALhtWkdbp3VcBLkLsE4=6ZKV5X-CGpTac+8WLAvU-udHFAQhcQ@mail.gmail.com>
Subject: Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
From: Benson Margulies <bimargulies@gmail.com>
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 23, 2012 at 6:15 PM, Robert Muir <rcmuir@gmail.com> wrote:
> On Mon, Apr 23, 2012 at 6:13 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>> On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir <rcmuir@gmail.com> wrote:
>>> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>>>
>>>> b) Create a patching process that grabs their release package, fixes
>>>> it, and builds it, renaming packages. Include the patching process in
>>>> your source release.
>>>>
>>> I would *love* to be able to have this option available, but how will
>>> the maven artifacts work? Can maven artifacts say "i depend on x.y.z
>>> but i need to download its source and patch it first" ?
>>
>> You publish it. No one objects to the process of changing the packages
>> and publishing it under a suitable descriptive name. Or, as Uwe
>> pointed out, it entirely possible to use a couple of maven plugins to
>> pull this off dynamically.
>>
>
> And now you hit the nail on the head. Because your 'option 2'
> (download+patch) with ivy doesnt involve 'publishing'. we just
> download and patch.

I think the answer to this is Uwe's suggestion. Set up Maven to do the
download+patch.

I can't promise 100% automation of this in a single top-level maven
build for every possible complex maven-built thing you might want to
patch. I can promise no worse than two steps: (1) run a script that
downloads, patches, and builds the patched items, and (2) run the
regular maven (or ant/ivy) build.  Step (1) puts its results in your
'local repository' (~/.m2/repository) and step 2 uses them there.

For many maven things, I could see how to do this with a maven plugin
folded inside your build, but since I think that would fail in some
cases, I don't think it is wise.


>
> But with maven you MUST publish. so this is really forcing us to your
> option 3 (its a published fork).
>
> Give me an option 2 for maven that doesnt have the word 'publish' and
> then its an option 2.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

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