> From: Leif Mortenson [mailto:[EMAIL PROTECTED]] > > Peter Donald wrote: > > >I would prefer to keep it out of framework for the simple > reason that > >it is > >not directly associated with commissioning or decommissiong > a component. It > >can standalone inside another excalibur component. > > > >FYI I also think that poolable threadsafe and friends should > not be in > >framework. > > > > > Ok. That is fine. So do you have an opinion on whether it should be > split back up again or not? > I think that it would be best to return it to the following directory > structure for the reasons > that I already covered. With the new short package names of course. > > excalibur/ > component/ > instrument/ > instrument-manager/ (client could live here as well) > instrument-client/ > zip/ > etc./ > > I think this would be much more maintainable than the > following as was > suggested by Stephen : > excalibur/ > component/ > instrument/ > core/ > manager/ > client/ > zip/ > etc./ > > Berin, you had merged them so if you have any input, I am listening.
As far as maintainability is concerned, it is maintainable no matter where you put it. The question is the dependency system. I personally am not happy with the dependency system--sure it automagically and recursively builds stuff, but I am not sure that is best. Take for instance the Maven way of doing things--jars are uploaded to a repository (it can even be automated to be a nightly release), and you update your local repository periodically. Things like where something lives is irrelevant. Now, part of the reason that I like Instrument living in one place is because it makes it a lot easier to manage a dependency. I understand that manager/client might use other packages which in turn are instrumented, but I can't help thinking there is a better way of doing things in general. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
