Re: UpdaterConfig
> Sorry, a little to hasty. rebuild the stuff. right now i still have the > artifacttest where some work has to be done. Not sure I follow these sentences. > to recover (resurrect) a deleted file, you have to find out the old > revision number and copy it (svn copy) to the working copy. then just > add it once again. pretty straight forward, i think :-) I think I follow, although I don't know how to query history. BTW: I gve up on Subclipse yet again, can't whittle well with it... Q: Did you merge w/ any changes I've jsut made, or does SVN allow you to copy over w/o a merge? > sorry once again. Nope, don't be. If our unit tests were all working before you did that, maybe regards Adam
Re: UpdaterConfig
Sorry, a little to hasty. rebuild the stuff. right now i still have the artifacttest where some work has to be done. to recover (resurrect) a deleted file, you have to find out the old revision number and copy it (svn copy) to the working copy. then just add it once again. pretty straight forward, i think :-) sorry once again. Markus Adam R. B. Jack wrote: That said, I suspect this is used more than we realize. We'll see. FWIIW: UpdaterConfig would read the local depot-update.xml resource (from JAR or otherwise) and would configure a bunch of named repositories, and such. This is kinda like the types in ant, but it allows us to ship (or locally configure) a default set of things. Right now we have code that tries to get named entities from the ReferenceManager. I am +1 to get rid of stuff in the way, or not being used, but not stuff that is used. regards, Adam
Re: svn commit: rev 23090 - incubator/depot/trunk/update/src/java/org/apache/depot/update/config
incubator/depot/trunk/update/src/java/org/apache/depot/update/config/Updater Config.java > - copied unchanged from rev 22913, incubator/depot/trunk/update/src/java/org/apache/depot/update/config/Updater Config.java > Log: > Resurrected UpdaterConfig.java from old Revision Thanks, how and how old? regards Adam
Re: UpdaterConfig
> > That said, I suspect this is used more than we realize. We'll see. FWIIW: UpdaterConfig would read the local depot-update.xml resource (from JAR or otherwise) and would configure a bunch of named repositories, and such. This is kinda like the types in ant, but it allows us to ship (or locally configure) a default set of things. Right now we have code that tries to get named entities from the ReferenceManager. I am +1 to get rid of stuff in the way, or not being used, but not stuff that is used. regards, Adam
Re: UpdaterConfig
> > +1 for removal of everything unused and not needed right now. after we > > have cleared the API we could add this once again. there is still svn > > which takes care about backups :-) > > Yup, we have enough to do to get all we want in context w/o extras, I agree. > +1. > > That said, I suspect this is used more than we realize. We'll see. Sorry, I worded this poorly. I meant, I agree we ought trim but I don't think we can trim this, it is used. Running the unit tests (and them not working) tells me we can't. 1) Who did this? 2) Did they run unit tests before and/or afterwards? 3) Anybody know how to recover stuff from SVN? Daft as it sounds, I don't know how to (I don't know if a concept of ATTIC exists.) regards, Adam
Wrappers & Context
We have an updater 'context' (which holds things like the protocol provider, and 'base directory', and such. Later it might have some user credentials.) http://svn.apache.org/repos/asf/incubator/depot/trunk/update/src/java/org/apache/depot/update/impl/ArtifactUpdaterContext.java This context is important when doing work, in the main 'cos repo work can't be done w/o it. A Repository is (to use a non-Java term) a 'abstract' thing (i.e.a repository out of context). Combined with the (user) context it can do work. I create a RepositoryWrapper to combine the two (and do a few 'above of the interface checks' such as checking if a repository has a capability before calling it to do something.) This RepositoryWrapper seemed to be a nice useful helper, it combined some things. http://svn.apache.org/repos/asf/incubator/depot/trunk/update/src/java/org/apache/depot/update/impl/RepositoryWrapper.java With RepositorySets we have N Repositories. I created RepositorySetWrapper (a better name might be RepositoryWrapperSet) that constructs wrappers for a while set of repositories. http://svn.apache.org/repos/asf/incubator/depot/trunk/update/src/java/org/apache/depot/update/impl/RepositorySetWrapper.java When we provide a query we can specify a RepositorySet. For us to use it we need to convert it to a RepositorySetWrapper. This gets tedious, unless we cache some of these things. I don't want the user to know about these wrappers, they have to be hidden. Something tells me something is wrong, something is out of control. Any thoughts (i.e. 'I've seen that mistake before and ...' come to mind?) Thanks in advance for any help. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
