Robert Muir
2012-03-27, 19:28
Simon Willnauer
2012-03-27, 19:31
Michael McCandless
2012-03-27, 19:33
Steven A Rowe
2012-03-27, 19:37
Robert Muir
2012-03-27, 19:40
Dawid Weiss
2012-03-27, 19:41
Erick Erickson
2012-03-27, 19:43
Uwe Schindler
2012-03-27, 19:51
Uwe Schindler
2012-03-27, 19:52
Steven A Rowe
2012-03-27, 19:54
Greg Bowyer
2012-03-27, 19:58
Robert Muir
2012-03-27, 20:02
SUJIT PAL
2012-03-27, 20:03
Simon Willnauer
2012-03-27, 20:04
Uwe Schindler
2012-03-27, 20:05
Robert Muir
2012-03-27, 20:09
Steven A Rowe
2012-03-27, 20:33
SUJIT PAL
2012-03-27, 20:37
Robert Muir
2012-03-27, 20:38
Uwe Schindler
2012-03-27, 20:42
Steven A Rowe
2012-03-27, 20:50
Dawid Weiss
2012-03-27, 20:50
Robert Muir
2012-03-27, 20:59
Jan Høydahl
2012-03-27, 21:41
Grant Ingersoll
2012-03-28, 00:15
David Smiley
2012-03-28, 04:51
-
switch jars to ivy mechanism?Robert Muir 2012-03-27, 19:28
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Simon Willnauer 2012-03-27, 19:31
+1 from my side! I think this is worth exploring!
simon
On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
simon
On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Michael McCandless 2012-03-27, 19:33
+1
I could save a huge amount of disk space with this :)
Mike McCandless
http://blog.mikemccandless.com
On Tue, Mar 27, 2012 at 3:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
I could save a huge amount of disk space with this :)
Mike McCandless
http://blog.mikemccandless.com
On Tue, Mar 27, 2012 at 3:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Steven A Rowe 2012-03-27, 19:37
+1
When configuring Ivy, you can find dependencies' Maven coordinates in the POM templates under dev-tools/maven/.
Steve
-----Original Message-----
From: Robert Muir [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2012 3:28 PM
To: [EMAIL PROTECTED]
Subject: switch jars to ivy mechanism?
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
---------------------------------------------------------------------
When configuring Ivy, you can find dependencies' Maven coordinates in the POM templates under dev-tools/maven/.
Steve
-----Original Message-----
From: Robert Muir [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2012 3:28 PM
To: [EMAIL PROTECTED]
Subject: switch jars to ivy mechanism?
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
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Robert Muir 2012-03-27, 19:40
On Tue, Mar 27, 2012 at 3:37 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> +1
>
> When configuring Ivy, you can find dependencies' Maven coordinates in the POM templates under dev-tools/maven/.
>
Thanks Steve: this will be useful when experimenting! So it looks to
me that is possible for Ant and also Eclipse, what about Intellij? If
we do such a thing, will we break its IDE support or do we have some
mechanism where it will still be easy to configure if we don't have
these jars?
--
lucidimagination.com
---------------------------------------------------------------------
> +1
>
> When configuring Ivy, you can find dependencies' Maven coordinates in the POM templates under dev-tools/maven/.
>
Thanks Steve: this will be useful when experimenting! So it looks to
me that is possible for Ant and also Eclipse, what about Intellij? If
we do such a thing, will we break its IDE support or do we have some
mechanism where it will still be easy to configure if we don't have
these jars?
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Dawid Weiss 2012-03-27, 19:41
> 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)
He, he... this is one step from Maven, Robert. One day you'll be converted :)
Dawid
---------------------------------------------------------------------
> (http://ant.apache.org/ivy/history/latest-milestone/samples/build.xml)
He, he... this is one step from Maven, Robert. One day you'll be converted :)
Dawid
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Erick Erickson 2012-03-27, 19:43
I bet my i'net speed is slower than people in Europe or Japan ;(....
It's surely worth the experiment, I can see where it would make
checking out code for multiple JIRAs &etc. much less painful for us
people on slow connections....
Robert:
http://plugins.intellij.net/plugin/?id=2267
Ivy plugin for IntelliJ. I can help test that if-and-when.
+1
On Tue, Mar 27, 2012 at 3:31 PM, Simon Willnauer
<[EMAIL PROTECTED]> wrote:
> +1 from my side! I think this is worth exploring!
>
> simon
>
> On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
It's surely worth the experiment, I can see where it would make
checking out code for multiple JIRAs &etc. much less painful for us
people on slow connections....
Robert:
http://plugins.intellij.net/plugin/?id=2267
Ivy plugin for IntelliJ. I can help test that if-and-when.
+1
On Tue, Mar 27, 2012 at 3:31 PM, Simon Willnauer
<[EMAIL PROTECTED]> wrote:
> +1 from my side! I think this is worth exploring!
>
> simon
>
> On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Uwe Schindler 2012-03-27, 19:51
In my opinion we could also add an ant task for eclipse and intellij that puts all dependencies in one lib folder under build. This would solve the issue for IDEs without ivy support. And the classpath would be simple, too.
+1 to use Ivy!
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 9:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> On Tue, Mar 27, 2012 at 3:37 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > +1
> >
> > When configuring Ivy, you can find dependencies' Maven coordinates in the
> POM templates under dev-tools/maven/.
> >
>
> Thanks Steve: this will be useful when experimenting! So it looks to me that is
> possible for Ant and also Eclipse, what about Intellij? If we do such a thing, will
> we break its IDE support or do we have some mechanism where it will still be
> easy to configure if we don't have these jars?
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
+1 to use Ivy!
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 9:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> On Tue, Mar 27, 2012 at 3:37 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > +1
> >
> > When configuring Ivy, you can find dependencies' Maven coordinates in the
> POM templates under dev-tools/maven/.
> >
>
> Thanks Steve: this will be useful when experimenting! So it looks to me that is
> possible for Ant and also Eclipse, what about Intellij? If we do such a thing, will
> we break its IDE support or do we have some mechanism where it will still be
> easy to configure if we don't have these jars?
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Uwe Schindler 2012-03-27, 19:52
The JAR files are still in the cache of IVY. The classpath is simply
automatically generated by IVY and points to the JARs in the ivy cache. So
disk space is still used. But you spare lots of space if you have multiple
checkouts :-)
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Michael McCandless [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 9:34 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> +1
>
> I could save a huge amount of disk space with this :)
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Mar 27, 2012 at 3:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
---------------------------------------------------------------------
automatically generated by IVY and points to the JARs in the ivy cache. So
disk space is still used. But you spare lots of space if you have multiple
checkouts :-)
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Michael McCandless [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 9:34 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> +1
>
> I could save a huge amount of disk space with this :)
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Mar 27, 2012 at 3:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Steven A Rowe 2012-03-27, 19:54
Erick,
The IntelliJ Ivy plugin you pointed to looks like it hasn't had a release in a year or so. It may not even work under IntelliJ IDEA 11 (the most recent IntelliJ version).
In my Plugins dialog in IntelliJ, the Ivy plugin that's been updated the most recently (February 2012) and that has way more downloads than the others is IvyIDEA: <http://code.google.com/p/ivyidea/>. It has IntelliJ IDEA 11 support.
Steve
-----Original Message-----
From: Erick Erickson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2012 3:44 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: switch jars to ivy mechanism?
I bet my i'net speed is slower than people in Europe or Japan ;(....
It's surely worth the experiment, I can see where it would make checking out code for multiple JIRAs &etc. much less painful for us people on slow connections....
Robert:
http://plugins.intellij.net/plugin/?id=2267
Ivy plugin for IntelliJ. I can help test that if-and-when.
+1
On Tue, Mar 27, 2012 at 3:31 PM, Simon Willnauer <[EMAIL PROTECTED]> wrote:
> +1 from my side! I think this is worth exploring!
>
> simon
>
> On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
mmands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
The IntelliJ Ivy plugin you pointed to looks like it hasn't had a release in a year or so. It may not even work under IntelliJ IDEA 11 (the most recent IntelliJ version).
In my Plugins dialog in IntelliJ, the Ivy plugin that's been updated the most recently (February 2012) and that has way more downloads than the others is IvyIDEA: <http://code.google.com/p/ivyidea/>. It has IntelliJ IDEA 11 support.
Steve
-----Original Message-----
From: Erick Erickson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2012 3:44 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: switch jars to ivy mechanism?
I bet my i'net speed is slower than people in Europe or Japan ;(....
It's surely worth the experiment, I can see where it would make checking out code for multiple JIRAs &etc. much less painful for us people on slow connections....
Robert:
http://plugins.intellij.net/plugin/?id=2267
Ivy plugin for IntelliJ. I can help test that if-and-when.
+1
On Tue, Mar 27, 2012 at 3:31 PM, Simon Willnauer <[EMAIL PROTECTED]> wrote:
> +1 from my side! I think this is worth exploring!
>
> simon
>
> On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir <[EMAIL PROTECTED]> 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]
>
---------------------------------------------------------------------
mmands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Greg Bowyer 2012-03-27, 19:58
Last time I tried the ivy plugin it just didnt work, I didnt know about
ivyidea
On 27/03/12 12:54, Steven A Rowe wrote:
> Erick,
>
> The IntelliJ Ivy plugin you pointed to looks like it hasn't had a release in a year or so. It may not even work under IntelliJ IDEA 11 (the most recent IntelliJ version).
>
> In my Plugins dialog in IntelliJ, the Ivy plugin that's been updated the most recently (February 2012) and that has way more downloads than the others is IvyIDEA:<http://code.google.com/p/ivyidea/>. It has IntelliJ IDEA 11 support.
>
> Steve
>
> -----Original Message-----
> From: Erick Erickson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 3:44 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> I bet my i'net speed is slower than people in Europe or Japan ;(....
>
> It's surely worth the experiment, I can see where it would make checking out code for multiple JIRAs&etc. much less painful for us people on slow connections....
>
> Robert:
> http://plugins.intellij.net/plugin/?id=2267
> Ivy plugin for IntelliJ. I can help test that if-and-when.
>
> +1
>
>
> On Tue, Mar 27, 2012 at 3:31 PM, Simon Willnauer<[EMAIL PROTECTED]> wrote:
>> +1 from my side! I think this is worth exploring!
>>
>> simon
>>
>> On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir<[EMAIL PROTECTED]> 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]
>>
> ---------------------------------------------------------------------
> 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]
>
---------------------------------------------------------------------
ivyidea
On 27/03/12 12:54, Steven A Rowe wrote:
> Erick,
>
> The IntelliJ Ivy plugin you pointed to looks like it hasn't had a release in a year or so. It may not even work under IntelliJ IDEA 11 (the most recent IntelliJ version).
>
> In my Plugins dialog in IntelliJ, the Ivy plugin that's been updated the most recently (February 2012) and that has way more downloads than the others is IvyIDEA:<http://code.google.com/p/ivyidea/>. It has IntelliJ IDEA 11 support.
>
> Steve
>
> -----Original Message-----
> From: Erick Erickson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 3:44 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> I bet my i'net speed is slower than people in Europe or Japan ;(....
>
> It's surely worth the experiment, I can see where it would make checking out code for multiple JIRAs&etc. much less painful for us people on slow connections....
>
> Robert:
> http://plugins.intellij.net/plugin/?id=2267
> Ivy plugin for IntelliJ. I can help test that if-and-when.
>
> +1
>
>
> On Tue, Mar 27, 2012 at 3:31 PM, Simon Willnauer<[EMAIL PROTECTED]> wrote:
>> +1 from my side! I think this is worth exploring!
>>
>> simon
>>
>> On Tue, Mar 27, 2012 at 9:28 PM, Robert Muir<[EMAIL PROTECTED]> 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]
>>
> ---------------------------------------------------------------------
> 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]
>
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Robert Muir 2012-03-27, 20:02
On Tue, Mar 27, 2012 at 3:51 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> In my opinion we could also add an ant task for eclipse and intellij that puts all dependencies in one lib folder under build. This would solve the issue for IDEs without ivy support. And the classpath would be simple, too.
>
I like this idea (though, not sure about under build/ we can maybe
have a separate svn-ignore'd directory that isn't nuked on clean or
something like that? or maybe we force them to be downloaded to the
cache, and 'ant eclipse' etc just specify the full path to your cached
version). Anyway we could work out the kinks. this would prevent us
from having to deal with plugins.
--
lucidimagination.com
---------------------------------------------------------------------
> In my opinion we could also add an ant task for eclipse and intellij that puts all dependencies in one lib folder under build. This would solve the issue for IDEs without ivy support. And the classpath would be simple, too.
>
I like this idea (though, not sure about under build/ we can maybe
have a separate svn-ignore'd directory that isn't nuked on clean or
something like that? or maybe we force them to be downloaded to the
cache, and 'ant eclipse' etc just specify the full path to your cached
version). Anyway we could work out the kinks. this would prevent us
from having to deal with plugins.
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?SUJIT PAL 2012-03-27, 20:03
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]
>
---------------------------------------------------------------------
-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]
>
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Simon Willnauer 2012-03-27, 20:04
On Tue, Mar 27, 2012 at 10: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.
-1 and I skip the big rant this time!
simon
>
> -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]
>
---------------------------------------------------------------------
> 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.
-1 and I skip the big rant this time!
simon
>
> -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]
>
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Uwe Schindler 2012-03-27, 20:05
At some point we have to package them into binary ZIP files and WAR files. But that could be done from the cache dir, too. No need to copy before.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 10:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> On Tue, Mar 27, 2012 at 3:51 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > In my opinion we could also add an ant task for eclipse and intellij that puts
> all dependencies in one lib folder under build. This would solve the issue for
> IDEs without ivy support. And the classpath would be simple, too.
> >
>
> I like this idea (though, not sure about under build/ we can maybe have a
> separate svn-ignore'd directory that isn't nuked on clean or something like
> that? or maybe we force them to be downloaded to the cache, and 'ant eclipse'
> etc just specify the full path to your cached version). Anyway we could work out
> the kinks. this would prevent us from having to deal with plugins.
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 10:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> On Tue, Mar 27, 2012 at 3:51 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> > In my opinion we could also add an ant task for eclipse and intellij that puts
> all dependencies in one lib folder under build. This would solve the issue for
> IDEs without ivy support. And the classpath would be simple, too.
> >
>
> I like this idea (though, not sure about under build/ we can maybe have a
> separate svn-ignore'd directory that isn't nuked on clean or something like
> that? or maybe we force them to be downloaded to the cache, and 'ant eclipse'
> etc just specify the full path to your cached version). Anyway we could work out
> the kinks. this would prevent us from having to deal with plugins.
>
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Robert Muir 2012-03-27, 20:09
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Steven A Rowe 2012-03-27, 20:33
Robert,
I disagree with you: I think Maven really is an option. However, I do agree that it would be significantly more work, and I recognize that lots of devs here loathe Maven, so I will not tilt against this particular windmill.
On the technical arguments, though: a) there *is* a JFlex maven plugin; and b) if you follow the link you gave to the Jenkins Maven trunk build script, you'll see that the one test which was being ignored is no longer ignored -- that chunk of the shell script is commmented out -- Maven currently runs all tests and passes them just as often as the Ant builds. (BasicDistributedZkTest is now an unhappy camper no matter which camp it's in these days.)
Steve
-----Original Message-----
From: Robert Muir [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2012 4:09 PM
To: [EMAIL PROTECTED]
Subject: Re: switch jars to ivy mechanism?
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
---------------------------------------------------------------------
I disagree with you: I think Maven really is an option. However, I do agree that it would be significantly more work, and I recognize that lots of devs here loathe Maven, so I will not tilt against this particular windmill.
On the technical arguments, though: a) there *is* a JFlex maven plugin; and b) if you follow the link you gave to the Jenkins Maven trunk build script, you'll see that the one test which was being ignored is no longer ignored -- that chunk of the shell script is commmented out -- Maven currently runs all tests and passes them just as often as the Ant builds. (BasicDistributedZkTest is now an unhappy camper no matter which camp it's in these days.)
Steve
-----Original Message-----
From: Robert Muir [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2012 4:09 PM
To: [EMAIL PROTECTED]
Subject: Re: switch jars to ivy mechanism?
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
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?SUJIT PAL 2012-03-27, 20:37
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]
>
---------------------------------------------------------------------
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]
>
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Robert Muir 2012-03-27, 20:38
On Tue, Mar 27, 2012 at 4:33 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> Robert,
>
> I disagree with you: I think Maven really is an option. However, I do agree that it would be significantly more work, and I recognize that lots of devs here loathe Maven, so I will not tilt against this particular windmill.
>
> On the technical arguments, though: a) there *is* a JFlex maven plugin; and b) if you follow the link you gave to the Jenkins Maven trunk build script, you'll see that the one test which was being ignored is no longer ignored -- that chunk of the shell script is commmented out -- Maven currently runs all tests and passes them just as often as the Ant builds. (BasicDistributedZkTest is now an unhappy camper no matter which camp it's in these days.)
>
Maven refers to the maven build we have: it doesn't support all of our
features. This isn't really a debate, its a fact. I don't argue that
theoretically it can't in the future, but it does not do so right now.
There are a lot of missing tasks (jflex generation was just a simple
one, but there are lots of little things like this). Sure, it might be
possible they could be added, but thats a ton more work than just
addressing jar dependencies.
--
lucidimagination.com
---------------------------------------------------------------------
> Robert,
>
> I disagree with you: I think Maven really is an option. However, I do agree that it would be significantly more work, and I recognize that lots of devs here loathe Maven, so I will not tilt against this particular windmill.
>
> On the technical arguments, though: a) there *is* a JFlex maven plugin; and b) if you follow the link you gave to the Jenkins Maven trunk build script, you'll see that the one test which was being ignored is no longer ignored -- that chunk of the shell script is commmented out -- Maven currently runs all tests and passes them just as often as the Ant builds. (BasicDistributedZkTest is now an unhappy camper no matter which camp it's in these days.)
>
Maven refers to the maven build we have: it doesn't support all of our
features. This isn't really a debate, its a fact. I don't argue that
theoretically it can't in the future, but it does not do so right now.
There are a lot of missing tasks (jflex generation was just a simple
one, but there are lots of little things like this). Sure, it might be
possible they could be added, but thats a ton more work than just
addressing jar dependencies.
--
lucidimagination.com
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Uwe Schindler 2012-03-27, 20:42
E.g. backwards compatibility tests like we have currently are not possible with maven out of the box. With IVY it would work. We can simply refer to another lucene-core-3.5.jar as dependency.
-1 to use Maven!
+1 to use IVY
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 10:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> On Tue, Mar 27, 2012 at 4:33 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > Robert,
> >
> > I disagree with you: I think Maven really is an option. However, I do agree
> that it would be significantly more work, and I recognize that lots of devs here
> loathe Maven, so I will not tilt against this particular windmill.
> >
> > On the technical arguments, though: a) there *is* a JFlex maven
> > plugin; and b) if you follow the link you gave to the Jenkins Maven
> > trunk build script, you'll see that the one test which was being
> > ignored is no longer ignored -- that chunk of the shell script is
> > commmented out -- Maven currently runs all tests and passes them just
> > as often as the Ant builds. (BasicDistributedZkTest is now an unhappy
> > camper no matter which camp it's in these days.)
> >
>
> Maven refers to the maven build we have: it doesn't support all of our features.
> This isn't really a debate, its a fact. I don't argue that theoretically it can't in
> the future, but it does not do so right now.
> There are a lot of missing tasks (jflex generation was just a simple one, but
> there are lots of little things like this). Sure, it might be possible they could be
> added, but thats a ton more work than just addressing jar dependencies.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-1 to use Maven!
+1 to use IVY
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 27, 2012 10:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: switch jars to ivy mechanism?
>
> On Tue, Mar 27, 2012 at 4:33 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > Robert,
> >
> > I disagree with you: I think Maven really is an option. However, I do agree
> that it would be significantly more work, and I recognize that lots of devs here
> loathe Maven, so I will not tilt against this particular windmill.
> >
> > On the technical arguments, though: a) there *is* a JFlex maven
> > plugin; and b) if you follow the link you gave to the Jenkins Maven
> > trunk build script, you'll see that the one test which was being
> > ignored is no longer ignored -- that chunk of the shell script is
> > commmented out -- Maven currently runs all tests and passes them just
> > as often as the Ant builds. (BasicDistributedZkTest is now an unhappy
> > camper no matter which camp it's in these days.)
> >
>
> Maven refers to the maven build we have: it doesn't support all of our features.
> This isn't really a debate, its a fact. I don't argue that theoretically it can't in
> the future, but it does not do so right now.
> There are a lot of missing tasks (jflex generation was just a simple one, but
> there are lots of little things like this). Sure, it might be possible they could be
> added, but thats a ton more work than just addressing jar dependencies.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
-
RE: switch jars to ivy mechanism?Steven A Rowe 2012-03-27, 20:50
On 3/27/2012 at 4:38 PM, Robert Muir wrote:
> On Tue, Mar 27, 2012 at 4:33 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > Robert,
> >
> > I disagree with you: I think Maven really is an option. However,
> > I do agree that it would be significantly more work, and I recognize
> > that lots of devs here loathe Maven, so I will not tilt against this
> > particular windmill.
> >
> > On the technical arguments, though: a) there *is* a JFlex maven
> > plugin; and b) if you follow the link you gave to the Jenkins Maven
> > trunk build script, you'll see that the one test which was being
> > ignored is no longer ignored -- that chunk of the shell script is
> > commmented out -- Maven currently runs all tests and passes them
> > just as often as the Ant builds. (BasicDistributedZkTest is now an
> > unhappy camper no matter which camp it's in these days.)
>
> Maven refers to the maven build we have: it doesn't support all of
> our features. This isn't really a debate, its a fact. I don't argue
> that theoretically it can't in the future, but it does not do so
> right now. There are a lot of missing tasks (jflex generation was
> just a simple one, but there are lots of little things like this).
> Sure, it might be possible they could be added, but thats a ton more
> work than just addressing jar dependencies.
Agreed. And also besides plus additionally, Lucene/Solr has way more Ant hackers than Maven hackers.
Steve
> On Tue, Mar 27, 2012 at 4:33 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> > Robert,
> >
> > I disagree with you: I think Maven really is an option. However,
> > I do agree that it would be significantly more work, and I recognize
> > that lots of devs here loathe Maven, so I will not tilt against this
> > particular windmill.
> >
> > On the technical arguments, though: a) there *is* a JFlex maven
> > plugin; and b) if you follow the link you gave to the Jenkins Maven
> > trunk build script, you'll see that the one test which was being
> > ignored is no longer ignored -- that chunk of the shell script is
> > commmented out -- Maven currently runs all tests and passes them
> > just as often as the Ant builds. (BasicDistributedZkTest is now an
> > unhappy camper no matter which camp it's in these days.)
>
> Maven refers to the maven build we have: it doesn't support all of
> our features. This isn't really a debate, its a fact. I don't argue
> that theoretically it can't in the future, but it does not do so
> right now. There are a lot of missing tasks (jflex generation was
> just a simple one, but there are lots of little things like this).
> Sure, it might be possible they could be added, but thats a ton more
> work than just addressing jar dependencies.
Agreed. And also besides plus additionally, Lucene/Solr has way more Ant hackers than Maven hackers.
Steve
-
Re: switch jars to ivy mechanism?Dawid Weiss 2012-03-27, 20:50
> E.g. backwards compatibility tests like we have currently are not possible with maven out of the box.
I'm sure everything is possible with maven just as anything is
possible with ant/ivy. I personally like ant because it's explicit but
then I also use maven and I'm happy with it (not counting occasional
debugging sessions...).
The "out of the box" experience doesn't exist in either world -- I've
just pushed a build patch to SOLR-3272 and the build file scares the
crap out of me.
Dawid
---------------------------------------------------------------------
I'm sure everything is possible with maven just as anything is
possible with ant/ivy. I personally like ant because it's explicit but
then I also use maven and I'm happy with it (not counting occasional
debugging sessions...).
The "out of the box" experience doesn't exist in either world -- I've
just pushed a build patch to SOLR-3272 and the build file scares the
crap out of me.
Dawid
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Robert Muir 2012-03-27, 20:59
On Tue, Mar 27, 2012 at 4:50 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>
> Agreed. And also besides plus additionally, Lucene/Solr has way more Ant hackers than Maven hackers.
>
Believe it or not (you probably won't!) I seriously considered maven
when looking at how to address the jar dependency issue. Everyone
knows about my personal opinion on it, but for this issue, I'm trying
to only look at the least-invasive/least-risk change that solves the
problem.
As much as I hate to say it, I initially thought maven was the only
good alternative, but I took a moment to look at the documentation on
the ivy site and it seems like a nice solution for our needs: i guess
i'm hoping we can have a tiny initial non-invasive prototype patch
that starts attacking the problem iteratively (yeah that means
initially we still have the crazy xerces situation in lib/ until we
figure out some solution for that, etc).
--
lucidimagination.com
---------------------------------------------------------------------
>
> Agreed. And also besides plus additionally, Lucene/Solr has way more Ant hackers than Maven hackers.
>
Believe it or not (you probably won't!) I seriously considered maven
when looking at how to address the jar dependency issue. Everyone
knows about my personal opinion on it, but for this issue, I'm trying
to only look at the least-invasive/least-risk change that solves the
problem.
As much as I hate to say it, I initially thought maven was the only
good alternative, but I took a moment to look at the documentation on
the ivy site and it seems like a nice solution for our needs: i guess
i'm hoping we can have a tiny initial non-invasive prototype patch
that starts attacking the problem iteratively (yeah that means
initially we still have the crazy xerces situation in lib/ until we
figure out some solution for that, etc).
--
lucidimagination.com
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Jan Høydahl 2012-03-27, 21:41
+1 to test out Ivy, been thinking about it before as well
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 27. mars 2012, at 22:59, Robert Muir wrote:
> On Tue, Mar 27, 2012 at 4:50 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>>
>> Agreed. And also besides plus additionally, Lucene/Solr has way more Ant hackers than Maven hackers.
>>
>
> Believe it or not (you probably won't!) I seriously considered maven
> when looking at how to address the jar dependency issue. Everyone
> knows about my personal opinion on it, but for this issue, I'm trying
> to only look at the least-invasive/least-risk change that solves the
> problem.
>
> As much as I hate to say it, I initially thought maven was the only
> good alternative, but I took a moment to look at the documentation on
> the ivy site and it seems like a nice solution for our needs: i guess
> i'm hoping we can have a tiny initial non-invasive prototype patch
> that starts attacking the problem iteratively (yeah that means
> initially we still have the crazy xerces situation in lib/ until we
> figure out some solution for that, etc).
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 27. mars 2012, at 22:59, Robert Muir wrote:
> On Tue, Mar 27, 2012 at 4:50 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
>>
>> Agreed. And also besides plus additionally, Lucene/Solr has way more Ant hackers than Maven hackers.
>>
>
> Believe it or not (you probably won't!) I seriously considered maven
> when looking at how to address the jar dependency issue. Everyone
> knows about my personal opinion on it, but for this issue, I'm trying
> to only look at the least-invasive/least-risk change that solves the
> problem.
>
> As much as I hate to say it, I initially thought maven was the only
> good alternative, but I took a moment to look at the documentation on
> the ivy site and it seems like a nice solution for our needs: i guess
> i'm hoping we can have a tiny initial non-invasive prototype patch
> that starts attacking the problem iteratively (yeah that means
> initially we still have the crazy xerces situation in lib/ until we
> figure out some solution for that, etc).
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
-
Re: switch jars to ivy mechanism?Grant Ingersoll 2012-03-28, 00:15
I just started a project w/ Ivy and for the most part it was fine. I ended up sinking some time into the multimodule stuff and then abandoning it for a top level lib directory for simplicity. Under that, you can partition out pieces if you want using Ivy confs. I wasted a few hours on the multimodule stuff and it just left me frustrated given the amount of time I wanted to spend on it. That being said, I'm sure someone w/ more time could get it working.
The other nice thing is you can still check in jars if you want as well. For instance, for anything we build ourselves (after we change the namespace, of course! cough, cough).
At any rate, +1.
On Mar 27, 2012, at 3: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]
>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
The other nice thing is you can still check in jars if you want as well. For instance, for anything we build ourselves (after we change the namespace, of course! cough, cough).
At any rate, +1.
On Mar 27, 2012, at 3: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]
>
--------------------------------------------
Grant Ingersoll
http://www.lucidimagination.com
-
Re: switch jars to ivy mechanism?David Smiley 2012-03-28, 04:51
+1 absolutely. I'm not a fan of binaries in source control when it can be
avoided, and ivy (and maven) help.
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/switch-jars-to-ivy-mechanism-tp3862513p3863559.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
---------------------------------------------------------------------
avoided, and ivy (and maven) help.
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/switch-jars-to-ivy-mechanism-tp3862513p3863559.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
---------------------------------------------------------------------
