Trennung Komponenten Basisextratoren
Stefan Schramm
ich drehe mich momentan im Bezug auf die Basisextraktoren-Integrierung
ein bisschen im Kreis:
Das Problem ist, dass die Anbindungen an die Pipeline (Max) und an das
Webgui (Oleg) unterschiedlich aussehen. - Bzw. ist weniger die Anbindung
das Problem, sondern eher ein sinnvolles Packaging.
Oleg brauchte von mir ein Jar, wo ausschlie�lich die Metrik-Annotatoren
enthalten sind, weil er das POS-Tagging (was f�r Metrik erforderlich
ist) bereits selber irgendwie aufruft (das wird anscheinend
redundant/unabh�ngig gepflegt?).
F�r die Pipeline muss dieser Part jedoch in dem Paket, was ich erstelle,
enthalten sein. Dort soll au�erdem noch NER gemacht werden. Max meinte
ich solle das lieber zusammenlassen (und nicht zig Maven-Artefakte
anlegen), weil es vermutlich zu viel Arbeit ist das alles zu sortieren.
Es sind leicht gegens�tzliche Herangehensweisen. Es geht nat�rlich per
Hand mal entsprechende Jars zu erstellen, aber ich habe auch den
Anspruch, dass das ganze wartbar bleibt und "nach mir" auch wieder
automatisch neu erzeugt werden kann.
Was ich mir vorstellen k�nnte ist zwei Maven Projekte/Artefakte
anzulegen: enjoy-metric und enjoy-baseextractors, wobei letzteres von
enjoy-metric abh�ngt. Scheint das sinnvoll und sollte ich die dann doch
mit in enjoy-rep legen?
In jedem Fall muss wohl der JOYAnalyzer-Pfad im Repository aufgegeben
werden, weil da so viel Altlasten/Tests drin zu sein scheinen, dass
daraus kein sinnvolles Packaging m�glich ist. Au�erdem sollte das
Management der 3rd Party Dependencies Maven �berlassen werden (statt wie
jetzt ein lib/-Verzeichnis innerhalb von JOYAnalyzer/). Das ist ziemlich
h�bsch, wie es in enjoy-rep funktioniert (ich hatte Maven bisher noch
nie benutzt).
Es ist eigentlich eine typische Architekturfrage, daher auch eine Kopie
der Mail an Robin und Sebastian. Aber ich bef�rchte sie haben da in den
ENJOY-Komponenten auch nicht mehr �berblick als ich.
Hat wer Ideen/Meinungen dazu?
Gr��e
Stefan
--
Stefan Schramm | Schliemannstr. 3 | 10437 Berlin
Tel.: +49 30 20236399 | Mobil: +49 163 7736399
Skype: stefanschramm | XMPP: stefan...@jabber.ccc.de
Oleg Mayevskiy
lieber wenige und kleine als viele und gro�e Schritte.
Die Sicht von Max: "joy" = "JoyAnalyzer" = ein gro�es Modul .
Meine Sicht : Einzelteile von JoyAnalyzer die unteranderem im
EnjoyExtraktor benutzt werden, also viel feingranularer als die Sicht
von Max.
Dementsprechend reicht es Max aus, wenn alles zusammengefasst ist, mir
nicht.
Zwei Abh�ngigkeiten bereitstellen ist eine Option. Viele OpenSource
Projekte machen dies bereits so.
Vorschlag :
metrics-all (enth�lt alles damit der aggregate standalone l�uft)
metrics-core (enth�lt nur die eigentlichen metrics klassen)
Dass das Management der Dependencies Maven �berlasen werden soll, ist
der Grund daf�r, warum wir �berhaupt maven einsetzen.
Ich denke auch nicht, dass Robin und Sebastian da durchblicken.
LG
O.
Stefan Schramm
On 02/03/2011 01:46 AM, Oleg Mayevskiy wrote:
> Zwei Abh�ngigkeiten bereitstellen ist eine Option. Viele OpenSource
> Projekte machen dies bereits so.
>
> Vorschlag :
> metrics-all (enth�lt alles damit der aggregate standalone l�uft)
> metrics-core (enth�lt nur die eigentlichen metrics klassen)
metrics-core (die Metrik-Klassen) h�ngt ja auch von POS ab, woher soll
ich daf�r dann diese Dependency nehmen? Also es l�sst sich ja nicht
kompilieren, wenn die nicht richtig angegeben ist.
Existieren die POS-Tagger sachen (inklusive StanfordPOSWrapper) schon
als Artifacts?