<p dir="ltr">A package name change is a pretty minor inconvenience -- both Eclipse and IDEA support project-level 'Optimize Imports' functionality that will fix import statements across the entire project.</p>
<p dir="ltr">As for new package names -- I would avoid any package named 'bj' as it has rather rude connotations. ;-)</p>
<p dir="ltr">Mark </p>
<div class="gmail_quote">On Oct 13, 2014 10:59 AM, "Andreas Prlic" <<a href="mailto:andreas@sdsc.edu">andreas@sdsc.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I'd argue that a package name is just a name. Most of us use an IDE and auto-complete, rather than manually writing import statements. Most of the time I don;t even look at the imports of a class. It seems there is little to be gained by refactoring package names, besides causing work for everybody who would need to refactor the code to support any new names. </div><div><br></div><div>Going forward my favorite naming convention for new packages names for newly added classes would be</div><div><br></div><div>org.biojava.modulename.*</div><div><br></div><div>The structure modules are a slight exception to the rest of BioJava 3. They always have been mostly backwards compatible to biojava 1 and the fundamental interfaces have seen little change since the old days. </div><div><br></div><div>As such my vote would be not to change any package names, only the name of the jar files that are available for download.</div><div><br></div><div>Andreas</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 8:35 AM, Jose Manuel Duarte <span dir="ltr"><<a href="mailto:jose.duarte@psi.ch" target="_blank">jose.duarte@psi.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No, the pain is actually in the future.<br>
<br>
Consider:<br>
<br>
Project a has a dependency on biojava-legacy version 1.9.1, package<br>
names org.biojava.*<br>
Project b has a dependency on biojava3 version 3.1, package name also<br>
org.biojava3.*<br>
Project c has a dependency on projects a and b<br>
<br>
Project b updates their dependency on biojava3 to version 4.0, which<br>
doesn't necessarily mean a binary incompatible change for project b,<br>
but it means the transitive biojava3 packages are now org.biojava.*,<br>
same as biojava-legacy<br>
<br>
Project c now runs into RuntimeExceptions because some biojava3<br>
version 4.0 class clobbers a biojava-legacy version 1.9.1 class.<br>
</blockquote>
<br></span>
Alright, that is indeed a problem. So it means that for the new release we can't reuse any namespace ever used before.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Commons Math and Commons Collections are other projects that have had<br>
to deal with this<br>
<br>
<a href="http://commons.apache.org/proper/commons-math/" target="_blank">http://commons.apache.org/<u></u>proper/commons-math/</a><br>
<a href="http://commons.apache.org/proper/commons-collections/" target="_blank">http://commons.apache.org/<u></u>proper/commons-collections/</a><br>
<br>
Rather than move from package names org.biojava3 --> org.biojava<br>
perhaps we should consider going from org.biojava3 --> org.biojava4.<br>
</blockquote>
<br></span>
Instead of keeping a 3 or a 4, how about we use a new namespace, not used before and that doesn't refer to the release number?<br>
<br>
If I understand it correctly, legacy was using:<br>
<br>
org.biojava.bio.* and org.biojava.*<br>
<br>
then Biojava 3 was using:<br>
<br>
org.biojava3.* and org.biojava.bio.* (only in the structure module)<br>
<br>
So there's not much left, but we could be creative for Biojava 4 and successors, some possibilities:<br>
<br>
org.biojava.plus<br>
org.biojava.obf<br>
org.biojava.open<br>
org.open-bio.biojava<br>
org.obf.biojava<br>
org.nbiojava<br>
org.biojava.next<br>
org.biojavaplus<br>
<a href="http://org.biojava.bj" target="_blank">org.biojava.bj</a><br>
<br>
<br>
Or of course stay with the status quo and keep the 3 forever. I'm happy to compromise there, but surely one issue would have to be solved if taking that route: the structure module packages org.biojava.bio.* should be renamed to org.biojava3.* to be consistent. Also the tutorial would still need to be fixed in order not to mention Biojava 3, while explaining why the packages have the "3" in the name anyway.<span><font color="#888888"><br>
<br>
Jose</font></span><div><div><br>
<br>
______________________________<u></u>_________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org" target="_blank">biojava-dev@mailman.open-bio.<u></u>org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" target="_blank">http://mailman.open-bio.org/<u></u>mailman/listinfo/biojava-dev</a><br>
</div></div></blockquote></div><br><div dir="ltr"><div><div><div><div><div><br></div></div></div></div></div></div>
</div></div>
<br>_______________________________________________<br>
biojava-dev mailing list<br>
<a href="mailto:biojava-dev@mailman.open-bio.org">biojava-dev@mailman.open-bio.org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev" target="_blank">http://mailman.open-bio.org/mailman/listinfo/biojava-dev</a><br></blockquote></div>