Eclipse makefile export

[CLSK]

Hallo,

kennt jemand ein gutes Beispiel für ein java - makefile. Ich stelle mir da sowas vor, wie man es in C++ macht. (C++ habe ich das im gegensatz zu Java schon einmal geamcht/ausprobiert.)

Es geht nicht um ein tolles optimiertes makefile, sondern um unabhängigkeit von Entwicklungsumgebung und Betribssystem.
Optimal währe ein makefile - Export aus Eclipse. (Habe da leider nichts gefunden.)

Thx
CLSK

 

[XHelp]

Java and Makefiles
hat google als erstes rausgesprocht. sieht ganz brauchbar aus.

 

[Marcinek]

Wir benutzen dafür Antskripte um die Software zu bauen.

Dort werden die benötigten Bibliotheken genau angegeben. Obwohl das eine Projekt Server/Client und Plugins enthält, ist das Ergebnis x JARs, die jeweils nur Client / Server und oder Plugins enthalten.

Gibt es ein Grund, wieso genau makefiles benutzt werden sollen?

 

[maki]

Wie Marcinek bereits sagte, make macht keinen Sinn für Java, Ant kann das auch & Plattformunabhängig, sogar Tabs sind Ant egal (anders als bei make).

Ansonsten kann man auch gleich was modernes nehmen (Ant ist auch nicht mehr Stand der Dinge), wie Maven2/Gradle/Gant/etc. pp.

 

[bygones]

Ansonsten kann man auch gleich was modernes nehmen (Ant ist auch nicht mehr Stand der Dinge), wie Maven2/Gradle/Gant/etc. pp.

mhm... Ant als überholt anzusehen halt ich für falsch, ausserdem ist genaugenommen Gant in deiner Auflistung auch nicht richtig. Maven3 ;-) und Gradle sind komplette Lifecycle-build-dependency tools. Gant ist einfach Ant in Groovy und Ant ist eben Ant.

 

[Cru]

Empfehlen könnte ich auch Maven (mittlerweile 3.0), damit lassen sich recht einfach auch modularisierte Projekte bauen

 

[Marcinek]

Ich sehe keinen falls Ant als überholt an. Ganz im Gegenteil.

Vieleicht würden die meisten Leute dies nicht gerade zum bauen von Anwendungen nutzen, weil es da vermeidlich bessere Werkzeuge, wie auch Maven, gibt.

Leider kann ich niemanden zu Maven raten, es sei den er baut gerade sein Projekt auf und ist in der Planungsphase. Andernfalls erstickt man in Konfigurationen.

Auch kann das automatische zuladen von Depedencies ganz schnell nach hinten losgehen. Und dann hat man eine Software, die eigenltich nur 1 MB hat, mit einer 100 MB Auslieferung.

Wenn man Maven benutz, dann sollte man es voll integrieren und den kompletten Projekt Lifecycle (nenne ich es mal) umsetzen. Auf keinen Fall nur fürs bauen (builden) nutzen und dann für JUnits was anders.. etc..

 

[maki]

Leider kann ich niemanden zu Maven raten, es sei den er baut gerade sein Projekt auf und ist in der Planungsphase. Andernfalls erstickt man in Konfigurationen.

Ja, die Migration von Projekten nach Maven ist nie schön.

Auch kann das automatische zuladen von Depedencies ganz schnell nach hinten losgehen. Und dann hat man eine Software, die eigenltich nur 1 MB hat, mit einer 100 MB Auslieferung.

Sorry, aber das ist quatsch

Wenn man Maven benutz, dann sollte man es voll integrieren und den kompletten Projekt Lifecycle (nenne ich es mal) umsetzen. Auf keinen Fall nur fürs bauen (builden) nutzen und dann für JUnits was anders.. etc..

Nö, Maven ist ein Build Tool und zB. kein Deployment Tool, da gibt es nämlich andere Anforderungen.
Das ausführen der tests etc. gehört doch zum einen modernen/"agilen" Build, selbstprüfend eben

 

[Marcinek]

Sorry, aber das ist quatsch

Du hast eine Dependency X im Artifactory. Diese hat Dep X1 und X2

Dan hast du eine Y mit X1 und X2

Y wird weiterentwickelt und wird zu Y_ und benötigt nun X1 und eine neue Version von X2 nämlich X2_

Nun wirst du in deinem resultierenden Packet

X, Y_ X1, X2, und X2_ haben.

Ich selber benutze kein Maven, aber andere Abteilungen bei uns und das sind die Erfahrungsberichte.

 

[bygones]

Leider kann ich niemanden zu Maven raten, es sei den er baut gerade sein Projekt auf und ist in der Planungsphase. Andernfalls erstickt man in Konfigurationen.

falsch - wenn man es richtig macht nicht... Ich habe gerade das Umbauen von über 100 Einzelprojekte hinter mir. Es ist je nach existierender Struktur schwerer, aber ersticken in Konfiguration ist dann meist aufgrund unverständnis oder falscher herangehensweise

Auch kann das automatische zuladen von Depedencies ganz schnell nach hinten losgehen. Und dann hat man eine Software, die eigenltich nur 1 MB hat, mit einer 100 MB Auslieferung.

Auch falsch. Keiner unserer Projekte ist durch das Umstellen in irgendeiner Form angeschwollen... wieder gilt es hier eben nicht falsch das anzugehen

 

[maki]

Du hast eine Dependency X im Artifactory. Diese hat Dep X1 und X2

Dan hast du eine Y mit X1 und X2

Y wird weiterentwickelt und wird zu Y_ und benötigt nun X1 und eine neue Version von X2 nämlich X2_

Nun wirst du in deinem resultierenden Packet

X, Y_ X1, X2, und X2_ haben.

Sorry, aber ich denke du verwechselst da etwas.

Wenn diese Dependencies zur Laufzeit gebraucht werden, dann müssen sie dabei sein, punkt.
Wenn nciht, dann nciht.

Also: Vor Maven 1 MiB, nach Maven 1 Mib, kein Unterschied.

 

[Marcinek]

falsch - wenn man es richtig macht nicht... Ich habe gerade das Umbauen von über 100 Einzelprojekte hinter mir. Es ist je nach existierender Struktur schwerer, aber ersticken in Konfiguration ist dann meist aufgrund unverständnis oder falscher herangehensweise

Möglicherweise war meine Wartwahl einfach ungeschickt. Aber ich denke im Prinzip sind wir uns hier einig, das es Know-How benötigt und nicht trivial ist.

Auch falsch. Keiner unserer Projekte ist durch das Umstellen in irgendeiner Form angeschwollen... wieder gilt es hier eben nicht falsch das anzugehen

Bei einem Build per Hand mit Ant, kann ich die Dependencys viel einfacher bestimmen und steuern. Bei einem vergleichbaren Aufwand, könnte es zu den von mir beschriebenen Auswirkungen kommen, wobei der Umfang , den ich nannte ich eher für übertrieben halte, als tatsächlich anzunehmen ist.

 

[bygones]

wie du selbst sagst hast du keine Erfahrung mit Maven und gelinde gesagt, von denen du dies alles gehört hast auch nicht.

Somit sind solche Aussagen immer mit vorsicht zu geniessen - natürlich ist das einem bekannte immer leichter und einfacher.

Man sollte daraus aber nicht die Schlussfolgerung ziehen, dass es bei Unbekanntem dann deswegen anders ist....

Natürlich bedarf es bei maven Know-How... das braucht man aber auch bei Ant

 

[maki]

Bei einem Build per Hand mit Ant, kann ich die Dependencys viel einfacher bestimmen und steuern. Bei einem vergleichbaren Aufwand, könnte es zu den von mir beschriebenen Auswirkungen kommen, wobei der Umfang , den ich nannte ich eher für übertrieben halte, als tatsächlich anzunehmen ist.

Falsch.
Ich hab keine Ahnung woher du diese falsche "Wissen" nimmst, aber sicherlich nicht aus Erfahrung mit Maven2.

Mit Ant kann man die Dependencies nur mit mehr Aufwand bestimmen & steuern, dazu braucht man nämlich Ivy, sonst hat man mit Ant gar kein Dependency Management und muss alles (!) manuell machen, und dann auch noch ohne Metainformationen über Dependencies, oder siehst du einer Jar an welche anderen Jars es braucht?

Nutzt ihr denn Ant + Ivy, oder habt ihr gar kein Dependency Management?