Hi Dscho,<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>So: full steam ahead, I'll merge service-parameters after lunch and take<br>

care of uploading stuff.</blockquote><div class="gmail_quote"><br></div><div class="gmail_quote">Rock on, thanks a lot!</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">

Curtis</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Aug 31, 2012 at 1:06 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:schindelin@wisc.edu" target="_blank">schindelin@wisc.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Curtis,<br>
<div><div class="h5"><br>
On Fri, 31 Aug 2012, Johannes Schindelin wrote:<br>
<br>
> On Thu, 30 Aug 2012, Curtis Rueden wrote:<br>
><br>
> > The service-parameters branch contains some improvements to how services<br>
> > declare their dependencies. It eliminates the need for those stupid<br>
> > no-arg constructors just to make SezPoz happy (because it eliminates the<br>
> > need for *any* explicit constructors). Rather, service dependencies are<br>
> > declared as @Parameters now, similar to declaring inputs in a<br>
> > RunnablePlugin.<br>
> ><br>
> > I tested and all seems to work well. However, as part of the refactoring<br>
> > I touched some code in core/updater. Is it still the case that code<br>
> > changes like this will break things for people with old versions of the<br>
> > updater, due to the fact that that updater updates only itself and not<br>
> > its dependencies? In this case, not updating<br>
> > imagej.service.ServiceHelper would cause a problem when creating the<br>
> > UploaderService in FilesUploader#createUploaderService().<br>
> ><br>
> > How do you think we should proceed? Wait a bit before merging to master?<br>
> > Or would these changes be OK?<br>
><br>
> I fear that the way I implemented the initialization of the UploadService<br>
> (it is done on *any* startup of the Updater, not just when an Uploader is<br>
> needed), we may run into trouble.<br>
><br>
> Having said that, the Fiji-Updater.jar I uploaded earlier this week should<br>
> remedy the problem by simply falling back to the Updater as uploaded this<br>
> past Monday, until a current and working Updater is available locally.<br>
><br>
> I will test with a setup as it would be when you updated two weeks ago but<br>
> not after that, but my guess is that we should maybe wait with *uploading*<br>
> a new Updater a couple of days.<br>
><br>
> Unfortunately, this would interfere with uploading beta4, right? Let's<br>
> discuss after my tests...<br>
<br>
</div></div>After testing a couple of times with different levels of "up-to-dateness",<br>
it seems as if my recent work to make the Updater more robust really paid<br>
off: there is no problem running the updater. I just need to make sure to<br>
upload a complete IJ2 (and remove the files that were renamed/made<br>
obsolete) so that the Fiji Updater does not *always* fall back to the<br>
hard-coded remote updater (which would be the version from this past<br>
Monday).<br>
<br>
So: full steam ahead, I'll merge service-parameters after lunch and take<br>
care of uploading stuff.<br>
<br>
Ciao,<br>
Dscho<br>
</blockquote></div><br>