Bulky update sites

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Bulky update sites

ctrueden
Hi Oli,

[Subject changed from "How to add more than 38 counter types in Cell
Counter plugin"]

> having them all in the same update site makes it a bit bulky, as not
> all users want to get all our tools. Is there some suggestion as to
> how to address this? Should we split our packages in different update
> sites, for example?

What are we talking, here? Some megabytes? Or more in terms of too many
menu entries or something?

I do want to understand the real problems users might have along these
lines, but from my side just hearing that an update site is "bulky" is
nearly impossible to address in a way that pleases everyone. Why can't
users just ignore the features they don't need?

In any case, while you certainly could split up your update site, I would
caution against it since it creates an extra maintenance burden on you, and
makes it more likely that the dreaded "JAR skew" can occur.

Regards,
Curtis

On Wed, Mar 4, 2015 at 2:31 AM, Burri Olivier <[hidden email]> wrote:

> Hi Curtis
>
> > I would still strongly recommend automated or semi-automated counting if
> > possible. But if that is truly impossible for some reason, then that is
> a great
> > suggestion.
>
> I agree that some semi-automatic method could be very useful, however
> images like the ones processed by Pavica tend to have a lot of artifacts
> and uninteresting objects that are rather difficult to distinguish from
> useful ones. The only thing that I could think of is finding a way to
> rougly segment the images initially and then use something like Cell
> Profiler Analyst to hope and find some features to help classify the
> critters. The problem there is that without a dedicated image processing
> analyst the learning curve for a biologist to segment and is a bit steep
> until we can even assess whether the results are good or not... My two cents
>
> >
> > It would help users a lot to use an update site for distribution [1].
> > Distributing these things with Fiji is also a nice option [2]; just let
> me know if
> > you want to pursue that.
>
> We do have an update site and we can now pack the actionBars into JAR
> files. I just did not think it would be so relevant in this case (I did
> write it in 30 minutes). But I could put it on GIT or in a GIST if you
> thing that would be useful. It is just macro code in the end, not a full
> plugin...
>
> > [1] http://imagej.net/Distribution
> > [2] http://fiji.sc/Fiji_contribution_requirements
>
> Thanks a lot for the references!
>
> Regarding update sites, our group has one now and we have a few plugins
> and actionbars on it. The problem I have now is that as we start producing
> more and more tools, having them all in the same update site makes it a bit
> bulky, as not all users want to get all our tools. Is there some suggestion
> as to how to address this? Should we split our packages in different update
> sites, for example?
>
> Thanks again and all the best
>
> Oli
>
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html