Open koppor opened 9 years ago
Yes, I can see a chance for this. Especially because of all the cleanup and class sorting we are doing right now. The data model is now placed into the model
package and core functionality is moved into logic
. These two packages could be turned into a JabRef functionality library.
JabRef itself could benefit a lot from this separation of concerns. Unfortunately, there is still quite some way to go...
As of 86f635c855b83ee94230a72afcab15c7f3cd51e8 the dependencies of the model package are limited to logic classes, classes from the Java API and the infamous global classes (Globals
, JabRefPreferences
). This is one step towards extracting a library
@lenhard Didn't you remove the dependency on Globals in BibtexEntryType
before?! It breaks my tests as I now? need an instance of JabRefPreferences
in any test.
You mean BibtexEntryType, right?
In that case, no I did not. Neither now nor before. Not sure why JabRefPreferences should be a sudden dependency.
BibtexEntryType sorry. Hm strange...we need to get rid of this, else any new BibTexEntry()
calls will fail with NullPointerException
if JabRefPreferences
are not set.
Yes, classes like JabRefPreferences or Globals are a pure mess, but tied so closely into the code that they are close to impossible to remove.
I'll have a look at the constructor of BibTexEntry. Who know's, maybe I broke some kind of invisible static dependency ;)
Though we are much much closer to being able to extract libraries now, there is no tangible benefit for the JabRef project at the moment. Therefore, we'll put this issue on hold.
If you think your project would benefit from JabRef libraries, get in touch with us!
JabRef librarias whould be nice. The point is how to access them. Do I need to use Java here? That it is no choice for me.
There should be a plattform/language independed way. When the functionality of the library whould be accessiable via a binary I can call as an extern program (e. g. from my python script)...
Yes, we are talking about Java libraries here, available on a source repository such as maven central or jcenter. Since JabRef is written in Java, whatever we are extracting from it will also be Java.
So if you want to use such an extracted library, you would have to write a small Java wrapper that processes command line calls and invokes the library. Then you can call this wrapper from whatever. That would be pretty much the same that you can already do with JabRef's command line interface anyway, just at a (much) smaller scale.
I am going to experiment with jsweet of transpling Java to TypeScript. Not sure whether there is a transpiler for python.
As python user, I would just have a look at Py4J: https://stackoverflow.com/a/3793496/873282. Does that help?
Why is this closed? Any success in that issue?
We dont have the resources to do this in foreseeable future. Please keep in mind we all do this in our free time without any payments.
@Codeberg-AsGithubAlternative-buhtz We are working on releasing a Java 11-based version. In parallel, we worked on CloudRef: https://jabref.github.io/cloudref/ (which has less support than JabRef in case you wonder where our priorities are 👼).
For good CLI design: https://clig.dev/
I re-open, because this should be possible in "the near future"
Bioclipse has used JabRef in the past for the BibTeX data model, and there has been talk for reusing JabRef in PathVisio too for working with biobliograph data... do you see any chance of splitting out a JabRef functionality library with core functionality (data model, look up of data based on DOI or PubMed ID, ...)?
Source message 32103878 from @egonw
net.sf.jabref.bst.VM
(see https://github.com/JabRef/jabref/issues/119#issuecomment-152326777) - refs https://github.com/JabRef/jabref/pull/5702