No worries, was just a suggestion, the build requirements on Gora is much less
involved and works great with mvn (compared to ivy), which is why I suggested
it. Didn't think about the jflex dependency, would probably be impossible
without custom plugins for mvn. I guess I will just have to learn to work with
ivy then :-).
I like Uwe's idea of a target that will download and copy all the jars to the
lib dir btw, that way there is no necessity for configuring the IDE to work
with the .ivy cache.
For Eclipse, I observed that paths relative to a path represented by a variable
(for example ${project.home}/foo/bar) declared in the ivy configuration file
was not recognized within Eclipse but worked fine from the command line. I
ended up replacing these paths in my local copy with hardcoded absolute path
names for my computer to get Eclipse to compile my project. Of course, this
may not be an ivy problem, just my ignorance of ivy features.
-sujit
On Mar 27, 2012, at 1:09 PM, Robert Muir wrote:
> Maven doesnt support all of our build features (e.g. jflex generation,
> and a number of other things). On the other hand our ant build is
> stable and supports all of our current needs.
>
> All of our tests dont even pass with maven (though I know steven works
> really hard at trying to make them all work, but still:
> http://svn.apache.org/repos/asf/lucene/dev/nightly/hudson-lucene-solr-maven-trunk.sh).
>
> So maven isn't really an option: it would be significantly more work.
> On the other hand, ivy is something we can plug into our existing
> working build system, its just another way of populating the
> classpath.
>
> On Tue, Mar 27, 2012 at 4:03 PM, SUJIT PAL <[email protected]> wrote:
>> Just a suggestion... why not use mvn instead? Based on personal experience
>> trying to get ivy working with NutchGora and gora, I think it is much more
>> intuitive to use mvn.
>>
>> -sujit
>>
>> On Mar 27, 2012, at 12:28 PM, Robert Muir wrote:
>>
>>> Hello everyone,
>>>
>>> There is currently a thread about jars going on another list, this
>>> isn't about that.
>>>
>>> But just reading over the thread and thinking about things, our svn
>>> checkout is quite large because of checked in jars. I don't think this
>>> is good for developers in Europe or Japan or elsewhere, because it
>>> makes the checkout huge.
>>>
>>> On the other hand I look at the example ivy file from the tutorial
>>> (http://ant.apache.org/ivy/history/latest-milestone/samples/build.xml)
>>> and it looks pretty nice. I know there is an eclipse plugin that works
>>> with this as well.
>>>
>>> I was thinking about experimenting with our build to remove these jars
>>> (at least: as many as possible) and see how ivy worked, purely as an
>>> optimization. It seems like maybe it really wouldnt be such a huge
>>> change... maybe something that could be done in a day or something
>>> like that.
>>>
>>> Does anyone have any opinions on this?
>>>
>>> --
>>> lucidimagination.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
