[Biojava-dev] Renaming BioJava3 packages & modules

[Andreas Prlic]

Hi,

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.

Going forward my favorite naming convention for new packages names for
newly added classes would be

org.biojava.modulename.*

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.

As such my vote would be not to change any package names, only the name of
the jar files that are available for download.

Andreas

On Mon, Oct 13, 2014 at 8:35 AM, Jose Manuel Duarte <jose.duarte at psi.ch>
wrote:

>
>  No, the pain is actually in the future.
>>
>> Consider:
>>
>> Project a has a dependency on biojava-legacy version 1.9.1, package
>> names org.biojava.*
>> Project b has a dependency on biojava3 version 3.1, package name also
>> org.biojava3.*
>> Project c has a dependency on projects a and b
>>
>> Project b updates their dependency on biojava3 to version 4.0, which
>> doesn't necessarily mean a binary incompatible change for project b,
>> but it means the transitive biojava3 packages are now org.biojava.*,
>> same as biojava-legacy
>>
>> Project c now runs into RuntimeExceptions because some biojava3
>> version 4.0 class clobbers a biojava-legacy version 1.9.1 class.
>>
>
> Alright, that is indeed a problem. So it means that for the new release we
> can't reuse any namespace ever used before.
>
>
>> Commons Math and Commons Collections are other projects that have had
>> to deal with this
>>
>> http://commons.apache.org/proper/commons-math/
>> http://commons.apache.org/proper/commons-collections/
>>
>> Rather than move from package names org.biojava3 --> org.biojava
>> perhaps we should consider going from org.biojava3 --> org.biojava4.
>>
>
> 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?
>
> If I understand it correctly, legacy was using:
>
> org.biojava.bio.* and org.biojava.*
>
> then Biojava 3 was using:
>
> org.biojava3.* and org.biojava.bio.* (only in the structure module)
>
> So there's not much left, but we could be creative for Biojava 4 and
> successors, some possibilities:
>
> org.biojava.plus
> org.biojava.obf
> org.biojava.open
> org.open-bio.biojava
> org.obf.biojava
> org.nbiojava
> org.biojava.next
> org.biojavaplus
> org.biojava.bj
>
>
> 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.
>
> Jose
>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biojava-dev/attachments/20141013/04c08d5d/attachment-0001.html>