On 11/16/06, Jesus M. Rodriguez <[EMAIL PROTECTED]> wrote:
I agree with not gutting the architecture. As a new IVY user and a long time yum/linux user, I'm familiar with package (jar) dependencies. I'm in the process of trying to integrate ivy with jpackage rpms ( http://www.jpackage.org) to make it easier to create repositories.
Sounds interesting, keep us informed of your progress. The folks at jpackage have already
done lots of work defining rpm level dependencies. It seems to me, as a user, that there are no good tools for creating an ivy repo unless you're using a public repo to start from. Are there any tools projects out there? Just curious.
None that I'm aware of. Xavier Keep up the great work!
jesus rodriguez On 11/15/06, easyproglife <[EMAIL PROTECTED]> wrote: > On 11/14/06, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > On 11/14/06, easyproglife <[EMAIL PROTECTED]> wrote: > > > > > > > The next step is to create a simple, thin, flexible and scalable > > > architecture. > > > > > > I'm obviously biased, but I'm not sure we should create a brand new > > architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x, > > restarting from scratch with a brand new architecture seems very ambitious > > (and dangerous) to me, at least at the time being. Moreover, what does it > > mean to migrate Ivy to apache if it's only to create a brand new and > > redesigned version. Why not create a completely different project? I would > > be more for refactorings, with discussions about the target design, but > > with > > some respect to existing and working code - not because I'm sentimentally > > attached to this code, but simply because I think it's the better way to > > get > > a 2.0 version a reality, and not only a dream :-) > > > Sure! I agree. Ivy architecture is great! What I meant is to refactor where > needed and to invest some more work towards a stable API. > (One simple example: latest strategy API (on 1.3.1) gives you a list of > revisions and a date. I expected to get also the requested status - e.g. " > latest.integration" along as a parameter. This is a little refactor, not a > full redesign. ) > > What I mean flexible and scalable is for example evaluating how complicated > it is to write a DB based repository. It could be direct SQL driven or > wrapped by an HTTP server with dynamic content, in contrast to raw HTTP URLs > as today. Thinking about such possible enhancements can lead to better > design and architecture. That's what I meant and that's where I want to go > by collaborating ideas using the Wiki. > > easyproglife > >
