Es freut mich, dass groovy wieder unterstützt wird, siehe groovy-callouts-in-metasfresh. In unserem heutigem Gespräch mit @metasnw habe ich zugesagt, die Schnittstelle zu ms-COM zu beschreiben. Als Beispiel nehme ich das Datenblatt (excel) mit Endkundendaten, das per Knopfdruck oder Callout erzeugt werden kann. Zunächst die Architektur als Skizze:
links die groovy engine, beispielsweise in mf swingUI
sie wird etwa beim Callout gestartet und interpretiert ein Skript, das aus Tabelle ad_rule geladen wird
dh. die notwendigen Komponenten werden zur Laufzeit benötigt
im script steht import org.codehaus.groovy.scriptom.ActiveXObject - diese Klasse bildet die api zwischen groovy und jacob (JAva-COM Bridge) und wird im scriptom.jar vom groovy Anbieter codehaus bereitgestellt
beide jars werden also zu Laufzeit geladen und von groovy angebunden
dazu muss das build in metasfresh erweitert werden, z.B. in metasfresh\de.metas.adempiere.adempiere\client\pom.xml:
<!-- runtime support for COM-api excel/outlook -->
<dependency>
<groupId>org.codehaus.groovy.modules.scriptom</groupId>
<artifactId>scriptom</artifactId>
<version>1.6.0</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.hynnet</groupId>
<artifactId>jacob</artifactId>
<version>1.18</version>
<scope>runtime</scope>
</dependency>
PS: die früheren jacob versionen hatten einen anderen Herausgeber jacob-1.14.3.jar : net.sf.jacob-project
um auf die COM-Komponenten von Windows zuzugreifen werden schliesslich noch zwei dlls aus der Java Desktop Integration benötigt jdic.dll und tray.dll : wie man die per maven definiert ist mir nicht klar (das können die metas-maven-Experten sicher ). So etwa habe ich es mir gedacht:
Liebe metas-Kollegen, gerne stelle ich Euch für Testzwecke ein groovy-Skript zur Verfügung.
Erstmal warte ich auf die nächste mf-Version mit groovy.
Gruß
Ja, wir konnten deinen PR es leider nicht nach master übernehmen weil es nicht den Entwicklungs- und Qualitätskriterien unserer Community enspricht. Tobias @metas-ts hatte dir vorab im Pull-Request die Situation beschrieben, einen Lösungsvorschlag gemacht und seine Hilfe angeboten. Nach einiger Zeit ohne Aktivität und Dialogaufnahme deinerseits im Pull Request wurde der PR geschlossen und begründet. Ich hoffe du hast Verständnis dafür, wir haben es halt gerne aufgeräumt.
Soweit ich sehen kann greift Deine o.g. Alternative den Vorschlag von @metas-ts vom 16.01. auf.
We think that the right way to go about this is to let the metasfresh client discover external libaries on startup and load them.
Ich denke damit ist eine gute Basis geschaffen um sich gemeinsam über eine gute Lösung abzustimmen.
Hi Mark,
wir haben gestern eine gute Lösung abgestimmt. @metasnw hat uns gestern zugesagt, dass er ein issue anlegen wird, damit ihr das feature implementieren könnt. Wie ist die issue id? Ich habe keine gefunden.
Hallo @homebeaver,
ich habe hier geantwortet.
Nach kurzer Recherche erscheint mir die Implementierung recht simpel. Es muss nur eine Datei bereitgestellt bzw. einige Kommandozeilenparameter hinzugefügt werden.
Bitte sag Bescheid, wenn ich etwas missverstanden oder übersehen habe.
Danke @metas-ts,
am Wochenende habe ich bei “interceptor” nicht an metasfresh gedacht .
Deine simple Implementierung habe ich nicht ganz verstanden, aber es sollte einfach sein.
Ich mache mal das typische, einfache “HalloWorld”- Beispiel.
ich kopiere ein HelloWorld.jar ins Verzeichnis %METASFRESH_HOME%/userlib
für ms-COM sind es jacob.jar und scriptom-1.6.0.jar, für openTRANS andere
HelloWorld.jar hat nur diese Klasse:
package my.local;
public class HelloWorld {
public static String helloWorld() {
return "Hello World!";
} ...
das groovy-Skript, dass die Klasse aus dem jar nutzt sieht so aus:
package de.mf.demo
import groovy.lang.Binding
import groovy.lang.Script
import my.local.HelloWorld
class Hello extends Script {
public Hello() { }
public Hello(Binding binding) {
super(binding);
}
@Override
public Object run() {
return HelloWorld.helloWorld();
}
}
ich kann das groovy in ad-rule speichern, ein mf-Prozess definieren und ausführen
Im aktellen mf-Release liefert der Prozess eine Exception, weil das jar ja keine mf-Komponente ist.
PS: Die demo habe ich lokal via eclipse erstellt, wo der PR #697 aktiv ist