<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-text-html" lang="x-unicode"> <font size="-1">Hi
        Mark (resending I did not cc the list),</font><br>
      <blockquote
cite="mid:CA+B=mGpGuQ+B1+bn2cQj8sz=mnbt-X3zaUYv6C35HN3=R+x5Xg@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div>> Are there guidelines for plugin developers to
            follow?<br>
            <br>
          </div>
          <div>The development section[1] of the wiki is, in general,
            intended to provide these guidelines. The versioning page[2]
            in particular is relevant here, along with the Fiji
            contribution requirements[3].<br>
          </div>
        </div>
      </blockquote>
      That page refers to plugins exposing APIs.  What if I do not want
      others to use my code as a library?  Should I put everything in an
      "internal" package?<br>
      <br>
      <blockquote
cite="mid:CA+B=mGpGuQ+B1+bn2cQj8sz=mnbt-X3zaUYv6C35HN3=R+x5Xg@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div>>Will the updater figure it out that this is the same
            plugin?<br>
            <br>
          </div>
          <div>Yes - if you use one of the patterns on the versioning
            page then the updater will do the right thing and determine
            it's a new version of the same jar.<br>
          </div>
        </div>
      </blockquote>
      How does it deal with the "SNAPSHOT" designation?  Does it see
      that as a separate plugin?<br>
      <br>
      <br>
      Best,<br>
      <br>
      Nico<br>
      <br>
      <br>
      <blockquote
cite="mid:CA+B=mGpGuQ+B1+bn2cQj8sz=mnbt-X3zaUYv6C35HN3=R+x5Xg@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div><br>
          </div>
          <div>Hope that helps.<br>
            <br>
          </div>
          <div>Best,<br>
          </div>
          <div>Mark<br>
          </div>
          <div><br>
            [1] <a moz-do-not-send="true"
              href="http://imagej.net/Development">http://imagej.net/Development</a><br>
            [2] <a moz-do-not-send="true"
              href="http://imagej.net/Versioning">http://imagej.net/Versioning</a><br>
            [3] <a moz-do-not-send="true"
href="http://imagej.net/Fiji_contribution_requirements#Versioning_and_dependency_convergence">http://imagej.net/Fiji_contribution_requirements#Versioning_and_dependency_convergence</a><br>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Jul 30, 2015 at 2:38 PM, Nico
            Stuurman <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:nico.stuurman@ucsf.edu" target="_blank">nico.stuurman@ucsf.edu</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">What is
              the recommended strategy for versioning of plugins?  For
              instance, I set up a maven project for my plugin, create a
              jar (named myplugin_-0.1-SNAPSHOT.jar) and make that
              available through the Fiji updater.  I then make some
              changes and want to increase the version in my pom.xml
              file (lets say to 0.1.1-SNAPSHOT).  This will change the
              name of the jar.  Will the updater figure it out that this
              is the same plugin?  Are there guidelines for plugin
              developers to follow?<br>
              <br>
              Thanks!<br>
              <br>
              Nico<br>
              <br>
              _______________________________________________<br>
              ImageJ-devel mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
              <a moz-do-not-send="true"
                href="http://imagej.net/mailman/listinfo/imagej-devel"
                rel="noreferrer" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
            </blockquote>
          </div>
          <br>
        </div>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Nico Stuurman
Vale lab, UCSF/HHMI
Genentech Hall, N316, MC2200
600 - 16th Street
San Francisco, CA 94158-2517
415 514 3927
<a class="moz-txt-link-abbreviated" href="mailto:nico.stuurman@ucsf.edu">nico.stuurman@ucsf.edu</a></pre>
    </div>
  </body>
</html>