<kaga...@gmail.com> wrote:
> actually, you know what type of dependencies are bugging me? i
> don't know when i should do an update on the source code. for
> example, i just noticed sensorbase changed.  so, i tried to jar a
> new version. but, i had to get utilities next.  (getting the
> developer distros are too slow and painful some times)

> i don't remember the exact situation, but i had a little problem
> with using the utilities api.  i didn't quite understand what the
> problem was.  then i noticed that utilities was jar'd up in
> sensorbase (sensor shell does that too).  are we sure we want to do
> that?

> i don't understand the dependencies enough, but what happens if i
> write a service that uses sensorshell, which uses utilities X.1,
> and but my service requires utilities X.7.  then it becomes a
> classpath issue which tends to always be a little confusing when
> you have no idea its a classpath issue.

> anyway, thats sort of dependencies that might become a problem when
> services get installed all over the place. not to mention the
> service jar file name probably should have the version number in it
> (i think ivy requires that and maven too).

> thanks, aaron

> On 10/12/07, Aaron Kagawa <kaga...@gmail.com> wrote:

> Ivy is pretty cool.  I tried it a while back.

> Here is what I can remember:
> 1) it does a really good job on jar dependencies. it's almost like
> how Maven manages dependencies.
> 2) i didn't figure out how to do manage resources like Ant, Java,
> Tomcat, etc. Furthermore, i'm not sure i could do something like
> SCLC.  I'm not sure how it works for tools like checkstyle, because
> i want the installation not just the jar file .

> so, i decided not to use ivy.  i didn't want to maintain another
> server.  you would have to maintain the jars in the server and then
> make sure that you specify what dependencies you wanted to be used
> in the build process.  i suppose, i just thought that committing
> the jars to the subversion project was easier.  but this was in an
> multi-project environment; so it i would have to deal with a lot of
> jars and different versions of jars.  not to mention that everyone
> in the organization would have to access to the ivy server.

> anyway.... i still think ivy is pretty cool. i actually would want
> to use it if someone else was responsible for it.  but, being that
> it would be me.  i decided not to introduce it.  it would be cool
> if we used it for hackystat so i could learn how to use it
> effectively.

> thanks, aaron

> On 10/11/07, Robert Brewer < rbre...@lava.net> wrote:

> I just came across this because it is listed on the Ant homepage
> (it is
> being folded into Ant in a future version):

> < http://incubator.apache.org/ivy/>

> While I'm not sure I fully understand it, I think this would make
> some of
> the inter-project jar dependencies easier. Maybe it could also help
> out
> with the ever-growing environment variable list.

> --
> Robert Brewer
> Perpetual Student
> http://excitedcuriosity.wordpress.com/