Paypal-Katatrophe

[Enteroctopus]

Hallo zusammen,
ich war einige Zeit inaktiv, musste nun einen neuen Account anlegen usw.

Da die Fragen sehr Allgemein sind und nur bedingt Java-Bezogen, bitte ich zu entschuldigen falls ich das falsche Forum gewählt habe.

Ich stehe grad ein wenig auf dem Schlauch.
Als ich zuletzt vor über 10J. Paypal nutzte, gab es noch eine schöne übersichtliche Java-API die heute nicht mehr funktioniert.
Irgentwann ging alles in Braintree über; Paypal selbst gab immer weniger API-Bestandteile heraus und setze vermehrt auf REST Calls ... zwischenzeitlich habe ich den Überblick verloren. Auch weil oft die "Standart-Buttons" bzw ein wenig JavaScript ausreichte.

Dennoch, ich blicke einfach bei Paypal nicht mehr durch. Alles wird nur per REST/Linux beschrieben. Da meine Erfahrung mit REST/Java sehr begrenzt sind fehlt mir leider oft der Ansatz um es auf die Paypal-Beschreibung umzusetzen.

Auch für die Umsetzung anhand der JavaScript-Buttons fehlt mir der Ansatz. Obwohl es eigentlich nur noch um die Referer-Zahlung geht.

Zu meinem vorhaben:
Kunde kann Produkt kaufen - funktioniert derzeit wie folgt:

Derzeit umgehe ich es (siehe weiteres Problem) indem ich in JSF Formen ausfüllen lasse; beim submit alles in ein zweites Projekt ohne JSF (also normale JSP-Seiten) werfe und die Werte/Variablen fange sodass ich damit das Javascript bzw den von Paypal generierten Button damit füllen kann.

Ich möchte jedoch Reseller/Refferers zulassen. Das heisst:
Ich möchte bei kauf von Produkt xy eine Zahlung an Referer r@paypal vornehmen. Oder Kundezahlt an mich und in einer zweiten transaktion zahle ich an den Referer.
Ich bin mir nicht sicher ob das überhaupt mit der "button-factory" von Palypal möglich ist. Obwohl es doch so simple erscheint. In Paypal selbst wird nunmal auch "Geld an email-senden" ermöglicht. Einzige Bedingung ist, das die Mail bei Paypal gemeldet ist.

Weiteres Problem:
Ich schaffe es nicht die Paypal-Javascript-Lib (die Button-Factory) mit JSF bzw. Primefaces zu vereinen. Meine letzten Versuche waren nicht besonders erfolgreich (ich habe es aufgegeben, daher kein konkretes Beispiel mit Fehlern).
Soweit wie ich mich erinnern kann konnte ich die API nicht mit
<hutputSkript ... /> laden bzw es gab Scope-Fehler.
Ich erstelle aber gerne ein weiteres Beispiel und reproduziere den Fehler.

Jetzt stehe ich vor der Entscheidung wie ich weiter vorgehen soll. Meine Lösung mit der Button-Factory von Paypal ist zwar ungewöhnlich, aber sehr portable.
Dennoch ist es unschön - zumal ich kein Freund von JavaScript (und On-The-Fly Lib-Nachladungen) bin.
Mir wäre es lieber ich könnte es besser in das gleiche Layout (also ohne Umweg über ein JSP-Projekt) integrieren. Ich tuhe mich aber wie gesagt schwer mit der REST-API.

Auf Git-hub gibt es auch einen nachfolger von dem, was ich mal vor über 10J umgesetzt habe (https://github.com/paypal/PayPal-Java-SDK). Aber ich finde ausser dem PayPal logo keinen direten Zusammenhang mehr zu Paypal. Und ich meine mich erinnern zu können das es dieses Projekt war, bei welchem ich bei Versuchsprojekten vor einigen Jahren musste ich feststellen musste, dass nicht auf JAVA-RestCall zurückgegriffen wurde sondern es zu cURL (linux) weitergereicht wurde.
Und Braintree wäre auch noch eine Option um es wieder Serverseitig zu halten - wobei ich das doch mit Kanonen auf spatzen schiessen empfinde.

Ich wäre daher um eine kleine Hilfestellung dankbar.
Wie sind die Anforderungen bei Nutzung:
- des genannten "Paypal-Java-SDKs". Sollten die Befehle z.B. an cURL durchgereicht werden, wäre es in der Entwicklung sehr aufwendig, da ich jedesmal erst auf einem Testserver deployen müsste.
- Braintree (Ich konnte bisher nichtmal einen SDK-Download-Button finden. Früher war es eine JAR die nutzbar war)
- RestAPI zB mit javax.jws.WebService?

Ich nutze übrigens Netbeans und Glassfish.

Mein Favorit wäre die Java-REST-Api zu nutzen. Drittanbieter APIs machen in meinem Augen alles nur umständlicher.
Vielleich kann mir jemand Hilfestellung geben oder mit Seiten nennen wo der Umgang mit Paypals REST+Java näher beschrieben wird, aber eben auch generelle Dinge wie die nötige Verschlüsselung - eben letzteres Problem umgehe ich derzeit mit Nutzung der Button-Factory. Seit dem eine JAR mit fertigen Schlüsseln rausgegeben wird find ich das extrem mühsam. Vor allem weil der Glassfish eben mit Java-Keystores arbeitet ist es mir aber zumindest Teilverständlich warum das Paypal-SDK (nach meinen letzen Versuchen vor ein paar Jahren ) zur Linux-Console durchreicht.

Wäre es mit der Button möglich eine Zahlung an eine bei Paypal bekannte Mail zu tätigen um einen Dritten als Referral zu zahlen? (das würde mir viel ersparen. Deren CMS möchte ich gar nicht .. ist in meinem Augen alles nur doppelt gemoppelt)
Was macht insg. weniger Aufwand bei der Arbeit mit Paypal? Dabei geht es mir wie gesagt insg. auch um die Einrichtung der Grundsysteme (mit SSL): Glassfish, Linux um eben später sauber mit der REST-API arbeiten zu können.

Ich blicke kaum noch durch...
Wie handhabt ihr das?

 

[Oneixee5]

JSP ist etwas sehr 90's. Ich kenne ehrlich keinen der (außer Mini-Hobby) noch so etwas macht. JSF ist imho auch so einzuordnen. JSF bringt eine Menge Overhead mit und ist nicht gerade praktisch und intuitiv zu entwickeln. Der Quasi-Standard für Webanwendungen im Frontend ist Javascript mit Frameworks wie React, Vue, AngularJS, u.a.. Die Kommunikation mit dem Backend wird normalerweise per REST abgewickelt. Ich denke keiner entwickelt mehr ein Frontend mit einer Abhängigkeit zum Backend wie bei JSF.
Selbst bei PHP trennt man das jetzt größtenteils sauber voneinander.
Mit cURL hast du was falsch verstanden. Schon aus Sicherheitsgründen wickelt kein Backend irgendwelche cURL-Befehle über ein Terminal ab. Ich denke cURL wird nur als als Beispiel aufgeführt um klar zu machen wie die Anfragen an die jeweiligen Server aussehen müssen.

 

[M.L.]

Weiterhin gibt es bei Paypal auch eine Dokumentation zum Thema REST und JavaScript: https://developer.paypal.com/docs/business/get-started/

 

[Enteroctopus]

JSP ist etwas sehr 90's. Ich kenne ehrlich keinen der (außer Mini-Hobby) noch so etwas macht. JSF ist imho auch so einzuordnen. JSF bringt eine Menge Overhead mit und ist nicht gerade praktisch und intuitiv zu entwickeln. Der Quasi-Standard für Webanwendungen im Frontend ist Javascript mit Frameworks wie React, Vue, AngularJS, u.a.. Die Kommunikation mit dem Backend wird normalerweise per REST abgewickelt. Ich denke keiner entwickelt mehr ein Frontend mit einer Abhängigkeit zum Backend wie bei JSF.
Selbst bei PHP trennt man das jetzt größtenteils sauber voneinander.
Mit cURL hast du was falsch verstanden. Schon aus Sicherheitsgründen wickelt kein Backend irgendwelche cURL-Befehle über ein Terminal ab. Ich denke cURL wird nur als als Beispiel aufgeführt um klar zu machen wie die Anfragen an die jeweiligen Server aussehen müssen.

Das JSP als Oldschool abgetan wird war mir fast klar, aber JSF mit oder ohne Erweiterung (wie PrimeFaces)?
Die sind noch voll in Entwicklung und sollen insb. dafür sorgen das nicht an jedem Layer selbst Hand angelegt werden muss.
Diese Art der Vereinfachung ist Quasi-Standart der weit über JAVA hinaus geht. Es ist eben eine Bindung die sich nicht nur durch Anbieterschicht(en) sondern auch in die Entwicklerschichten ziehen.
Jede moderne IDE bietet änliches (siehe z.B. Android-IDE, wo XML als Zwischenschicht änliches macht). Es ist das, was agiles Arbeiten erst ermöglicht. Selbiges bei Visual Studio - ansonsten könnte das Visual auch wieder gestrichen werden: Wenn kein automatisierte Zwischenlayer, dann händisch und ohne Visuelles Durchreichen bin in den Auslieferungszustand.
Wenn's auch bei kostenlosten Plattformen hinzugefügt werden muss...

Letztlich geht der Weg von JEE in den Präsentationsschichten eben diesen Weg.

Und zu PHP halt ich jetzt zurück - als ich die verbreitetsten System zuletzt sah, sah das noch nicht so aus. Auch weil PHP bisher keine durchschlagenen Anwendung bei Anwenungen findet - weil das ziel eines reinen Interpreters auch ein ganz anderes ist, eben das Abbilden auf wiederum andere Sprachen. Und daher immer noch mehr Drittsprachen auf Entwicklerseite braucht. Es ist eher absolutes Durcheinader mit Eigenbaumodulen dessen Modul Eigenbaumodule erfordert.... dessen Phyton-Module Linux-/System-Libs nutzen um dann wieder über fehleranfälliges Parsen zurück an PHP... so wäre es auch bei PHP-IDEs.

Schon deshalb ist Java im Geschäftsmodellen gut angekommen - Schnittstellenchaos vermeiden und alles aus einem Guss ermöglichen.

Dennoch, und damit zurück zum Thema:
Zuletzt konnte ich eben diesen Weg bei den Java-API (siehe GIT Link) feststellen. Um die Zertifikatsanbindung an einen einheitlichen Layer zu binden und so das Container-Caos zu umgehen (und die doppelte Haltung, PHP bzw Apache würde nunmal u.U. auf dem gleichen System laufen und u.U. die gleichen Zertifikate zugreifen).
Und eben genau da ist die einzige Schnittelle, die nicht Systemneutral ist. Java nutzt ein eigenes Zertifikatsmanagementsystem.
Zuletzt war es eben so, dass ein preparietes Linux vorliegen musste um die angegebene API zu nutzen. Um eben das aufsetzen verschiedener JEE-Systeme (Websphere, Glassfish...) zu vereinfachen.
Es kann sich aber auch schon wieder geändert haben.

Kann natürlich sein, das es mitlerweile anders ist. Dennoch würde es dem "mal eben schnell deployen" im Weg stehen.

Warscheinlich hab ich grad nur ein Brett vorm Kopf, weil ich es damals gewohnt war das einem eine JAR von Paypal in die Hand gegeben wurde die eben jede Rückmeldung mit entsprechenden Typen Vorverpackt - und eben dies SSL Javamanagement voraussetzte.

@Oneixee5
Das es eine Doku gibt ist mir klar. Dazu schrieb ich schon, das es mir eben schwer fällt dies auf REST/Java zu übertragen.
Gibt es irgentwo eine gute Doku wie Fremd-REST-APIs mit Java genutzt werden?

 

[mihe7]

Ich nutze übrigens Netbeans und Glassfish.

Wenn Du eh einen Glassfish am Laufen hast, hast Du die REST APIs schon dabei: https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/package-summary.html

 

[Enteroctopus]

OK, dann hab ich mich zusätzlich noch mit SOAP durcheinander gebracht.

 

[Enteroctopus]

Aber nur mal um sicher zu gehen:

Ist das GIT Projekt https://github.com/paypal/PayPal-Java-SDK das bei Paypal angesprochene SDK (https://developer.paypal.com/docs/checkout/reference/server-integration/setup-sdk/) ?

 

[Enteroctopus]

Ok, ich hab's mir grad nochmal selbst angeguckt.

Da es kein Paket namens "com.paypal.core." gibt wird es das nicht sein.

Auf was bezieht sich dann Paypal

Set Up Server-Side SDK

developer.paypal.com

beim Klick auf "Java"?

PS: Ich vermiss das alte merchant-SDK!
Bzw ich habs noch, aber es ist out of date.

 

[mihe7]

Ah, das sind Maven-"Koordinaten".

 

[mihe7]

Wenn Du Maven oder Gradle verwendest, wird die Lib automatisch heruntergeladen. Ansonsten kannst Du Dir die jars auch von Maven Central laden: https://mvnrepository.com/artifact/com.paypal.sdk bzw. dann die angesprochene checkout-sdk in der angegebenen Version: https://mvnrepository.com/artifact/com.paypal.sdk/checkout-sdk/1.0.2

 

[Enteroctopus]

OK. Soviel dachte ich mir schon, da das bei GIT angegebene SDK eine Batch mitbringt die wiederum meinen Rechner mit Maven zumüllt.
Müll deswegen, weil Maven bei Netbeans ein integrierter Bestandteil ist und in den meissten fällen einfacher ging Libs selbst zusammenzustellen.
Alles andere war meisst zu durcheinadender

Wobei mich ziemlich irritiert, das ich bei Netbeans unter central->com nichts finde.
Dennoch, ein schnelle Test-Project funktioniert.

Danke für die links zum maven repo.

Jetzt wird sich zeigen müssen ob ich beim (NetBeans-)Maven Project bleibe oder alles nochmal händisch nachlade. Das kommt darauf an wie gut sich das ganze mit JSF und Primefaces vertägt.
Ich find das Testproject ist vom zusammenklicken schon überladen. Da bekommt man noch mehr Angst vorm nächsten IDE-Version-Sprung...

Nochmals Danke.

 

[mihe7]

Überladen? Mach mal ein neues Maven-Projekt und dann ersetzt Du einfach mal die pom.xml (groupId und artifactId einfach anpassen):

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.javaforum.mihe7</groupId>
    <artifactId>ARTIFACT</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.paypal.sdk</groupId>
            <artifactId>checkout-sdk</artifactId>
            <version>1.0.2</version>
        </dependency>
    </dependencies>
    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
    </properties>
</project>

Danach Clean & Build, dann sollten die Abhängigkeiten alle da sein. Achtung: ich habs nicht getestet.

 

[Enteroctopus]

Naja, vieleicht etwas übertrieben ausgedrückt.
Aber ein Maven-Projekt in Netbeans bringt doch schon viel mit, was normalerweise nicht da wäre. Die unterscheidung Java-Dependencies zu (Maven) Dependencies...

Ist vieleleicht Gewohnheit, aber die Ausdrucksweise "Libraries" ist einheitlicher. (Hat also nicht unbedingt mit Maven zu tun, sondern wie Netbeans mit Mavenprojekten bzw Webahängigkeitsprojekten umgeht.)
Ich bin es halt gewohnt erst eine Librarie in Netbeans zu erstellen um sie dann (einheitlich) einzubinden.Jetzt kommt noch die Trennung von Lokalen zu Webbindungen + andere Wortwahl hinzu.

Biesher sioeht es so aus:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mycompany</groupId>
    <artifactId>PalPalMavenTest2</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>war</packaging>

    <name>PalPalMavenTest2</name>

    <properties>
        <endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
  
    <dependencies>
        <dependency>
            <groupId>com.paypal.sdk</groupId>
            <artifactId>paypal-core</artifactId>
            <version>1.7.2</version>
        </dependency>
        <dependency>
            <groupId>com.paypal.sdk</groupId>
            <artifactId>checkout-sdk</artifactId>
            <version>1.0.2</version>
        </dependency>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-web-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                    <compilerArguments>
                        <endorseddirs>${endorsed.dir}</endorseddirs>
                    </compilerArguments>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.3</version>
                <configuration>
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>2.6</version>
                <executions>
                    <execution>
                        <phase>validate</phase>
                        <goals>
                            <goal>copy</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${endorsed.dir}</outputDirectory>
                            <silent>true</silent>
                            <artifactItems>
                                <artifactItem>
                                    <groupId>javax</groupId>
                                    <artifactId>javaee-endorsed-api</artifactId>
                                    <version>7.0</version>
                                    <type>jar</type>
                                </artifactItem>
                            </artifactItems>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

Damit komm ich durchaus zurecht.

Es geht eher die Unterscheidung die auch hier zu finden ist:

Difference between Ant and Maven - javatpoint

Difference between ant and maven - maven, tutorial, example, plugin, pom, dependency, eclipse, repository, web, application

www.javatpoint.com

An deren Wortwahl erkennt man ganz deutlich, wie viel mehr Maven ist. Project Management-Framework statt reine Build-Tool. Letztlich ist Netbeans nunmal schon ein Projectmanagement tool.

Aber es ist wohl jetzt Kopfsache, ob mich jetzt auch noch in Maven rein arbeite. Irgentwie empfinde ich es als doppelt für's gleiche. Ich war eben ohne Maven immer glücklich - weil die IDE an sich nunmal schon im groben änliches bietet.
Ich bin froh das ich mit Ant gut zurecht komme...

Zumal diese Onlinebindung sehr zulasten der IDE-Geschwindigkeit geht (bzw gehen kann - muss sich zeigen). Dann könnte ich meine Projekte/Libraries auch wieder auf eine HDD statt SSD packen...

Aber mal sehen. Das nächste Projekt wird eben keine Renderengine wo PHP das GTK und u.w.U auch. X.org für bräuchte, sondern es wird eine RE genutzt.

Ich werde die nächsten Tage mal mein Prime-Projekt ins Maven-Testding übertragen. Vielleicht bleibt ich dabei - vielleicht auch nicht und alles kommt wieder in lokale Libs.
Jedenfalls hat mir der Link zum aktuellen Paypal-SDK schon weitergeholfen. Ich hab mich bei Paypal halbtot gesucht...

 

[mihe7]

Ich hab mich bei Paypal halbtot gesucht...

Das findest man heute sehr oft, dass nur noch die Maven-/Gradle-Abhängigkeit angegeben wird. Macht die Sache halt fürchterlich einfach: dependency rein -> fertig. Die Build-Tools laden den Spaß inkl. deren Abhängigkeiten automatisch aus einem Repository. Dieses ant-Rumgefrickel möchte ich nicht mehr haben.

 

[Enteroctopus]

Das mag sein, aber jede Onlineabhägigkeit bringt Latenzen - teilweise eben auch wärend der Arbeit. Wenn dann jemand (von nunmehr Apache) mal wieder nur minderwertig threaded oder auch nur einen hauch vergisst, gibts Zusatzraucherpausen - und ich rauch sowieso schon zuviel.
Und da war ich eben immer glücklich alles lokal vorliegen zu haben.

Ich will halt meinen Updatecheck beim IDE-Öffnen und mehr nicht. Das ist bei projektimplizierter Onlinebindungs-Projektmanagement halt nicht mehr wirklich gegeben bzw. kann nicht garantiert werden.
Oder schlimmer: Es kann in eine Art Autoupdate/Rollout alá Windows Update enden. Ohne WSUS ist auch kaum ein Geschäftsbetrieb denkbar, sofern es nicht das eigene Geschäft bzw das des IT Betriebs ist.
Wie sieht es denn da aus? Erfahrungen (Auch in Bezug: was aus Maven in Zukunft wird)?

Besten Beispiel in/bei Java sind Netzwerk(laufwerk)zugriffe bei einem Open-Dialog... das Problem ist uralt und dennoch vorhanden.
Insb. (auch) Netbeans hat damit enorme Probleme.

Mir graust es jetzt schon, sollten mal 20 Maven-Projekte in Netbeans nach dem Start geladen werden müssen, dessen Abhänigkeiten nachgeladen werden wollen.

Ich hab wohl deshalb einen Bogen um Maven gemacht. Und möglicherweise war der Bogen so groß das ich das Word Maven (wegen Onlinebindung) aus meinem Wortschatz gestrichen haben und es deswegen die ganze Zeit auf den Dev Seiten überlesen habe.
Ein Link von/bei Paypal wäre einleuchtender gewesen.
So muss man denken und das Wort inkl. def. im Wortschatz halten

Als Subversion-Nutzer umgehe ich auch GIT. Zuwenig Kontrolle über die Lokalität; die Latenz; ...

Aber wie gesagt, mal sehen wie es läuft... nur heute nicht mehr.
Bin froh auf die schnelle das SDK mit Sandbox-Acc. zum laufen gebracht zu haben.

 

[mrBrown]

Das mag sein, aber jede Onlineabhägigkeit bringt Latenzen - teilweise eben auch wärend der Arbeit. Wenn dann jemand (von nunmehr Apache) mal wieder nur minderwertig threaded oder auch nur einen hauch vergisst, gibts Zusatzraucherpausen - und ich rauch sowieso schon zuviel.
Und da war ich eben immer glücklich alles lokal vorliegen zu haben.

Mit Maven liegt das nach dem Runterladen auch lokal vor, und durch das automatische herunterladen ist das nahezu immer schneller, als das selbst inklusive aller transitiven Dependencies herunter zu laden.

Ich will halt meinen Updatecheck beim IDE-Öffnen und mehr nicht. Das ist bei projektimplizierter Onlinebindungs-Projektmanagement halt nicht mehr wirklich gegeben bzw. kann nicht garantiert werden.

Häh? Kein Build-Tool hat "Online-Zwang", außer es muss etwas heruntergeladen werden, aber masochistisch veranlagte Menschen können das auch per Hand machen.

Oder schlimmer: Es kann in eine Art Autoupdate/Rollout alá Windows Update enden. Ohne WSUS ist auch kaum ein Geschäftsbetrieb denkbar, sofern es nicht das eigene Geschäft bzw das des IT Betriebs ist.

Hä? Was hat Maven mit Windows-Updates zu tun?

Besten Beispiel in/bei Java sind Netzwerk(laufwerk)zugriffe bei einem Open-Dialog... das Problem ist uralt und dennoch vorhanden.
Insb. (auch) Netbeans hat damit enorme Probleme.

Bestes Beispiel dafür, dass es Bugs gibt, die offensichtlich zu irrelevant sind, um gefixt zu werden?

Mir graust es jetzt schon, sollten mal 20 Maven-Projekte in Netbeans nach dem Start geladen werden müssen, dessen Abhänigkeiten nachgeladen werden wollen.

Garantiert ist das deutlich schneller und problemloser, als für 20 Projekte die Dependencies und deren Dependencies per Hand rauszusuchen.

Als Subversion-Nutzer umgehe ich auch GIT. Zuwenig Kontrolle über die Lokalität; die Latenz; ...

Das schöne an git ist: es ist völlig problemlos rein lokal verwendbar, das ist ganz explizit so gedacht. Jede Kommunikation mit dem Server muss man ganz explizit mache, da hat man immer die völlige Kontrolle. Anders als Subversion...

 

[mrBrown]

Klingt jetzt vielleicht gemein, aber alles was du schreibst (und damit mein ich wirklich alles in diesem Thread) klingt danach, als wirfst du sehr viel Unwissen mit noch mehr Falschinformationen zusammen und hältst dich danach für gut informiert

 

[Enteroctopus]

Mit Maven liegt das nach dem Runterladen auch lokal vor, und durch das automatische herunterladen ist das nahezu immer schneller, als das selbst inklusive aller transitiven Dependencies herunter zu laden.

1. Das zum Thema Falschinformation.

Häh? Kein Build-Tool hat "Online-Zwang", außer es muss etwas heruntergeladen werden, aber masochistisch veranlagte Menschen können das auch per Hand machen.

2. Das "ausser" sagt alles. zurück zu Punkt 1

Hä? Was hat Maven mit Windows-Updates zu tun?

Weil die großen Schmieden alle nach änlichem Schema fahren. Der WSUS ist nichts weiter als ein Freigabesystem - nur eben in letzer Instanz (also eine Art lokales Maven), was es so bei Maven nur IDE-Intern, jedoch nicht JEE-Intern gibt - also von prinzip her gibt es das nicht!

Das bedeutet, das es unklar ist wann ein Rollout passiert. Deshalb meine Nachfrage und sorge, das ein Updateanstoß nicht von meiner Seite kommt!
Wer weiß schon wie Maven in Zukunft (in IDEs) implementiert wird - u.U. mit weitergabe von Nachladelibs zur Runtime - auch deshalb meine Nachfrage. Wenn du das Unwissen nennt - sage doch bitte die Zukunft voraus.

Aus Erfahrung weiß ich das Nachladesysteme genau das Ziel verfolgen, eben ein Rolloutsystem - möglichst zur Runtime. Und auch wenn der Status jetzt so ist, das Maven derzeit nur zur Compilezeit mit mitgegen wird heisst das nicht das Maven oder eben deren Erstanwender (was typischerweise Leute sind die es in IDEs einbinden) bzw. meine Lieferanten zukünftig anders einsetzen.

3. Zumal es immer dort am schnellsten ist wo das Netzwerk beginnt (der eigene Rechern/das eigene Netz) - und nicht wo es Endet. (Oder eine GIT-Nachlade-Kette) Springe zurück zu Punk 1

Garantiert ist das deutlich schneller und problemloser, als für 20 Projekte die Dependencies und deren Dependencies per Hand rauszusuchen.

Mir ist neu das das nötig ist - zumindest nicht mehr als einmal. Danach ist der eine Knopfdurch durchaus auch schneller als fehleranfällige Tipperei um danach zu suchen, was bei neuen Projeten eher bei Maven der Fall wäre. (ist erst 1 Std her wo ich es mir angeguckt hab ) Und sei es nur die eine Überlegung dazwischen ob nun Version 1.0 oder Version 1.0.1. Zumal die gegoogled werde muss bzw in Maven Repo nachgeschlagen werden muss.
Gute IDE's sind u.A. Projektmanagment-System. Hätte ich hier (eben einmalig) alles vorbereitet, wäre keine Tipperei nötig.

Das schöne an git ist: es ist völlig problemlos rein lokal verwendbar, das ist ganz explizit so gedacht. Jede Kommunikation mit dem Server muss man ganz explizit mache, da hat man immer die völlige Kontrolle. Anders als Subversion...

Das ist nur für Quellen nötig, die gar nicht geändert werden wollen aufgrund Lizenzen etc. Zudem müsste man dem gegenüber unterstellen, dass er/sie schlechte Arbeit gemacht hat, falls Quellen vorliegen müssen - ich denke da hab ich grad meine Meister gefunden, kann mich aber jederzeit auch Gerichtsfest selbst verteidigen u.W.

Wie wäre es als EU-Ratsmitglied im deutschen Sektor? Die stehen auf Quellenänderungen ohne wiederkehr... (und unnötige Arbeit/Kosten/...)

Alle anderen fassen quellen gar nicht erst an sondern verwenden (nur) das Produkt der Quelle.

 

[mrBrown]

2. Das "ausser" sagt alles. zurück zu Punkt 1

Maven hat genauso "Online Zwang" wie der Weg ohne Maven. Wenn was heruntergeladen muss, muss das eben heruntergeladen werden – das macht man aber nur ein einziger Mal, und wenn es dann lokal vorliegt, braucht Maven nie wieder Internet. Beim Entwickeln hat man da keinen Online-Zwang.
Und das herunterladen kannst du wie gesagt auch selbst "per Hand" machen. Du wirst du *deutlich* mehr Zeit benötigen.

Weil die großen Schmieden alle nach änlichem Schema fahren. Der WSUS ist nichts weiter als ein Freigabesystem - nur eben in letzer Instanz, was es so bei Maven nur IDE-Intern, jedoch nicht JEE-Intern gibt - also von prinzip her gibt es das nicht!

Hä?!

Das bedeutet, das es unklar ist wann ein Rollout passiert. Deshalb meine Nachfrage und sorge, das ein Updateanstoß nicht von meiner Seite kommt!
Wer weiß schon wie Maven in Zukunft (in IDEs) implementiert wird - u.U. mit weitergabe von Nachladelibs zur Runtime - auch deshalb meine Nachfrage. Wenn du das Unwissen nennt - sage doch bitte die Zukunft voraus.

Maven wird aus gutem Grund ziemlich sicher nie ein automatisches, nicht explizit auf irgendeine Art anzustoßendes, Updaten der Dependencies bekommen (außer eben für SNAPSHOT-Dependencies, bei denen das explizit gewollt ist). Und erst Recht wird da nicht ein automatisches Nachladen zur Laufzeit in deine Projekte eingebaut.

Wenn deine IDE sowas ungewollt automatisch macht, dann solltest du einfach eine vernünftige IDE benutzen...

Aus Erfahrung weiß ich das Nachladesysteme genau das Ziel verfolgen, eben ein Rolloutsystem - möglichst zur Runtime. Und auch wenn der Status jetzt so ist, das Maven derzeit nur zur Compilezeit mit mitgegen wird heisst das nicht das Maven oder eben deren Erstanwender (was typischerweise Leute sind die es in IDEs einbinden) bzw. meine Lieferanten zukünftig anders einsetzen.

Kannst du auch nur ein einziges Build-Tool nennen, bei welchem solche Bedenken berechtig waren?

Natürlich kann irgendwer auch Maven nutzen, um zur Laufzeit was nachzuladen, aber Maven selbst wird das nicht automatisch plötzlich in deinen Projekten machen.

Wenn deine IDE sowas irgendwann macht: such dir eine vernünftige IDE. Oder nutz einfach Maven direkt, so ist es gedacht.

Mir ist neu das das nötig ist - zumindest nicht mehr als einmal. Danach ist der eine Knopfdurch durchaus auch schneller als fehleranfällige Tipperei um danach zu suchen, was bei neuen Projeten eher bei Maven der Fall wäre. (ist erst 1 Std her wo ich es mir angeguckt hab )

Der Weg mit Maven: 1. Dependency-Koordinaten heraussuchen, 2. Dependency-Koordinaten in der pom eintragen, 3. noch nicht vorhandene Dependencies automatisch laden lassen (über explizites Bauen, "go-offline", die IDE, whatever), fertig. (Und auf jedem neuen System ist dann nur Schritt 3 nötig.)

Der manuelle Weg: 1. Dependency suchen, 2. Dependeny herunterladen, 3. Dependency in der IDE einbinden, 4. Schritt 1-4 für alle transitiven Dependencies wiederholen. (Und auf jedem neuen System potentiell alles wiederholen)

Keine Ahnung, was du dir angeguckt hast, aber der manuelle Weg ist nie schneller. Der kann höchstens gleichwertig sein, wenn die IDE das automatisch macht, und das zB im Hintergrund aus dem Maven-Repo lädt. Aber genauso macht die dann bei der Verwendung von Maven alles automatisch...


Irgendwie scheinst du auf den Gedanken fixiert zu sein, das Maven ständig Dinge runterlädt? Das lädt aber alle Dependencies nur genau einmal runter (für dein gesamtes System, nicht pro Projekt!), und danach nie wieder. Es lädt also genau die selben Dinge, die du manuell auch laden würdest.
Ja, das lädt auch benötigte Plugins, aber auch die nur ein einziges Mal, üblicherweise bei Projektstart (und auch da nur, wenn die auf dem System noch nie benutzt wurden, was üblicherweise nicht der Fall ist), und die ändern sich auch so selten, dass das bei den meisten alle paar Jahre mal vorkommt...

Das ist nur für Quellen nötig, die gar nicht geändert werden wollen aufgrund Lizenzen etc. Zudem müsste man dem gegenüber unterstellen, dass er/sie schlechte Arbeit gemacht hat, falls Quellen vorliegen müssen - ich denke da hab ich grad meine Meister gefunden, kann mich aber jederzeit auch Gerichtsfest selbst verteidigen.

Wovon zur Hölle redest du, hast du was schlechtes geraucht? Was sollen Lizenzen und Quellen mit der Verwendung von git und svn zu tun haben oder deinem "bei git hat mein keine Kontrolle über Lokalität" ????

Um das noch mal explizit mit einfachen Worten zu sagen: git ist für rein lokales Entwickeln gedacht und braucht kein zentrales Repository. Anders als svn.
Wenn wirklich "Kontrolle über die Lokalität; die Latenz; ..." dein Problem wären, würdest du sehr schnell Abstand von svn nehmen und zu git wechseln.

 

[kneitzel]

Also hier möchte ich mich eigentlich nicht einmischen, aber nur ein paar Dinge:

a) Eine Abhängigkeit, die Du nutzen willst und die du nicht auf dem Rechner hast, musst Du runter laden. Daran führt einfach kein Weg drum herum und auch Maven kann das nicht auf irgend eine magische Art und Weise auf Deinen Rechner zaubern.
Maven bietet aber eine sehr einfache Art und Weise, Dependencies anzugeben. Diese werden in einem Projekt angegeben das dann eingecheckt werden kann. Es müssen hier keine großen Binaries mit eingecheckt werden. Und auf allen Systemen läuft das Projekt dann problemlos, denn das System holt sich herunter, was es braucht.

b) Dependencies heraus suchen
Das ist doch nun wirklich immer notwendig. Sonst wärst Du doch auch gar nicht erst hier gelandet. Deine bisherige Methodik hat ganz offensichtlich nicht gereicht, um auf (magische?) Weise an die richtigen Abhängigkeiten zu kommen. Und in einer Datei 5 Zeilen per Copy & Paste einzufügen soll jetzt plötzlich hoch kompliziert und lang andauernd sein?

c) Zu dem IDE Versions-Sprung:

Da bekommt man noch mehr Angst vorm nächsten IDE-Version-Sprung...

Also gerade Maven nimmt einem doch diese Angst komplett. Ich hänge mit meinem Projekt nicht an einer IDE. Wenn etwas nicht geht, dann bin ich nicht aufgeschmissen. Zur Not nehme ich eine andere IDE. Oder gar keine - Meine Maven Projekte haben alle einen Maven Wrapper: Nach dem herunter laden des Projekts kann man dies sofort bauen. (Nicht ganz - die Java Abhängigkeit hat man natürlich.)

d) Und das Rechner zumüllen:

Soviel dachte ich mir schon, da das bei GIT angegebene SDK eine Batch mitbringt die wiederum meinen Rechner mit Maven zumüllt.

Was für ein Script war das? Wenn es nur ein mvnw Script war, dann war es kein "zumüllen des Rechners". Es werden alle Abhängigkeiten geladen: ja. Aber die landen alle sauber im ~/.m2 Verzeichnis. Es wird ggf. Maven herunter geladen aber auch das landet im ~/.m2 Verzeichnis.
Das ist also kein zumüllen des Rechners. Wenn dein Netbeans ein Projekt baut, wird es ähnlich vorgehen. Du magst evtl. sagen: Maven wird evtl. nicht herunter geladen sondern das interne genutzt: Schlimm, wenn ich Dir sage, dass dies evtl gar nicht gut ist? Wenn Du mehrere Projekte hast - ein altes Projekt will noch ein älteres Maven und lässt sich nicht neuem Maven bauen? Und ein neues Projekt braucht zwingend ein neues Maven? Ja wie bildest Du das ab? Wobei ich hier sicher bin, dass Netbeans auch auf den Wrapper zurück greifen kann. Zumindest kann das IntelliJ.
==> Und schon macht auch Dein Netbeans nichts anderes. Es ruft genau das Gleiche auf.

Also wenn Du von Maven Projekten in Netbeans bisher positiv angetan warst oder diese zumindest in Ordnung fandest, dann kann ich Dein Urteil zu Maven jetzt nicht verstehen. Alles, was sich ändert, ist doch: Du schaust jetzt hinter die Kulissen, die Netbeans aufgebaut hat. Aber an den Abläufen ändert das nichts.

e) svn vs. git - jedem das seine. Es hängt immer von den Anforderungen ab, die es so gibt. Das muss man ganz klar so sehen. Wenn man keine Anforderungen außer einer Archivierung hat, dann ist evtl. auch ein Job ausreichend, der jede Nach den Source einfach in ein ZIP packt und dieses dann auf ein WORM schreibt. Und jede Anforderung muss betrachtet werden: Ja, svn hat eine bessere Performance. Aber was machst Du, so dass dies problematisch wurde / wird? Die Unterschiede sind da, aber nicht wirklich merkbar. Da könnte der Use-Case interessant sein. Repository über ein langsames Medium angeschlossen? Also zentrales Repository liegt auf einem entfernten Rechner über ein langsames Netz und das lokale git macht den Zugriff. So ein Szenario wäre denkbar. (Also kein "git server" der etwas einmal entgegen nimmt und dann alles lokal macht)

 

[mihe7]

Wenn dein Netbeans ein Projekt baut, wird es ähnlich vorgehen.

NetBeans liefert einfach ein Maven mit aus und man kann natürlich auch ein anderes angeben. Schön ist, dass man mit Maven unter NB keine IDE-spezifischen Verzeichnisse mehr im Projekt hat; es gibt ggf. noch eine Datei für abweichende IDE-Konfigurationen (z. B. für -DskipTests=true ), die man dann nicht eincheckt und das wars.

Ein mit NB erstelltes ant-Projekt ist zwar vom Handling aus der IDE heraus für den Entwickler auch schön (z. T. sogar schöner), aber ansonsten eine mittlere Katastrophe. Mehrere Build-Scripts, mind. einen NetBeans-Ordner, zig Properties-Files, alles schön verwoben und als wäre das nicht schon schlimm genug: man braucht NB-spezifische ant-Plugins, um das Projekt außerhalb von NB bauen zu können. Zumindest war das vor 10 Jahren noch so

 

[kneitzel]

NetBeans liefert einfach ein Maven mit aus und man kann natürlich auch ein anderes angeben. Schön ist, dass man mit Maven unter NB keine IDE-spezifischen Verzeichnisse mehr im Projekt hat; es gibt ggf. noch eine Datei für abweichende IDE-Konfigurationen (z. B. für -DskipTests=true ), die man dann nicht eincheckt und das wars.

Das hört sich interessant an. Bei IntelliJ bekommt man auch immer den ganzen IntelliJ Kram (den man dann per .gitignore natürlich nicht eincheckt) und wenn da etwas "quer" sitzt, dann hat man ein Problem. (Etwas, das ich auch bei Eclipse schon erlebt habe) Daher kommt halt bei Problemen oft der manuelle Aufruf um zu sehen, ob es am Maven Projekt liegt oder an der IDE. So kommt es halt durchaus vor, dass man ein
rm -rf .idea && find . -name \*.iml -exec rm {} \;
machen darf. (Bei eclipse ändert sich das etwas, aber auf SO findet man ja oft genug die Hinweise, mal das Problem mit manuellem Löschen von Dateien anzugehen...)

Daher klingt das auf jeden Fall interessant und ich sollte NB evtl. noch einmal mehr im Detail betrachten / testen.

Aber da sind wir jetzt natürlich vom eigentlichen Thema weg - aber ich Danke Dir natürlich für diesen interessanten Hinweis.