Hi Curtis, On Thu, 30 Aug 2012, Curtis Rueden wrote:
> The service-parameters branch contains some improvements to how services > declare their dependencies. It eliminates the need for those stupid > no-arg constructors just to make SezPoz happy (because it eliminates the > need for *any* explicit constructors). Rather, service dependencies are > declared as @Parameters now, similar to declaring inputs in a > RunnablePlugin. > > I tested and all seems to work well. However, as part of the refactoring > I touched some code in core/updater. Is it still the case that code > changes like this will break things for people with old versions of the > updater, due to the fact that that updater updates only itself and not > its dependencies? In this case, not updating > imagej.service.ServiceHelper would cause a problem when creating the > UploaderService in FilesUploader#createUploaderService(). > > How do you think we should proceed? Wait a bit before merging to master? > Or would these changes be OK? I fear that the way I implemented the initialization of the UploadService (it is done on *any* startup of the Updater, not just when an Uploader is needed), we may run into trouble. Having said that, the Fiji-Updater.jar I uploaded earlier this week should remedy the problem by simply falling back to the Updater as uploaded this past Monday, until a current and working Updater is available locally. I will test with a setup as it would be when you updated two weeks ago but not after that, but my guess is that we should maybe wait with *uploading* a new Updater a couple of days. Unfortunately, this would interfere with uploading beta4, right? Let's discuss after my tests... Ciao, Dscho _______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
