On Fri, Apr 30, 2010 at 10:00 AM, infinity2heaven <infinity2hea...@gmail.com > wrote:
> You are now asking me to learn these things which has nothing to do with my > original problem -- new macros (500 page macrodef file), Ivy 2.0 features > called packager (apart from the already existing concepts around ivy). > > Think for yourself. I am not a framework developer (I can be but that's not > what I do). I'm just a framework/library user and I'm looking for a key > abstraction here. I don't know if I want to know the internals or want to > read a 200 page manual for something like that. > Just to be clear, I'm not asking you to do anything. I'm just offering this "for what it's worth". In your case, it may very well be worth exactly what you paid for it :-) > Is what I'm asking that hard? If there is no straight answer, I'd imagine > it > is and maybe I should go back and stick to copy/paste jars. (Mind you, I > use > Maven for my hobby projects) but I work for a large corporation that are > resistant to change for this exact reason. > I have been in the same place before and understand your frustration. But realize that most of the complexity of ivy derives from the inherent complexity of the problem domain that it is trying to address. If ivy were a lot simpler, it simply would not completely work. It's a short term/long term trade-off kindof thing. You use ivy if you want to invest in a short term cost (learning curve) for a longer term payoff in future maintainability. At some point in the past I was in a similar situation as yours and decided to "bite the bullet' and go ahead and try to understand this stuff and put it into a form that I could use efficiently... the example given is what I eventually came up with that works for me. Of course up to you to decide whether this kindof thing is worth the trouble in your own situation. -Archie -- Archie L. Cobbs
