Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich habe ein Java Projekt für die Codegenerierung mit EMF, für die benötigten Plugins habe ich eine Manifest Datei angelegt und den Classpath mit der Plugin-Libray erweitert. Nun will ich einige interne jars mit Maven herunterziehen und den Classpath erweitern. Wie kann ich Maven sagen, dass er den bestehenden Classpath erweitern soll und nicht immer neu anlegt, weil dadurch ist jedes mal eine Plugin-Libray von Eclipse weg.
schade funktioniert nur beim refresh, aber beim deployen findet er die Klassen nicht
Java:
cannot find symbol
symbol : class EList
Aber so wie das verstanden habe müssen die verwendetetn Plugins nicht im repo liegen oder?
ein eclipse:eclipse funktioniert und mein classpath sieht richtig aus.
Jetzt will ich einfach eine jar bauen und die ins repo hochladen in der jar sind nur utils klassen drin.
Kann ich notfalls die jar mit Ant bauen und in ein repo hochladen? Geht sowas mit Ant?
Ich hab jetzt eclipse:to-maven ausgeführt und die ganzen Eclipse-Plugins wurden in mein repo hochgeladen.
Nun habe ich die benötigten dependency angegeben
[XML]
<dependency>
<groupId>org.eclipse.emf</groupId>
<artifactId>common</artifactId>
<version>2.6.0-v20100914-1218</version>
<optional>false</optional>
</dependency>
[/XML]
ABER die generierten pom.xml kann seine eigenen versionen nicht finden.
Java:
[ERROR] An error occurred during dependency resolution of the following artifact:
org.eclipse.core:runtime:null
Caused by: Couldn't find a version in [3.6.0-v20100505] to match range [3.6.0,4.0.0)
org.eclipse.core:runtime:jar:null
from the specified remote repositories:
central ([url=http://repo1.maven.org/maven2]Index of /maven2/[/url]),
test ([url]http://my//m2repository[/url])
Path to dependency:
1) xxx.utils:jar:1.0.0
2) org.eclipse.emf:common:jar:2.6.0-v20100914-1218
Irgendwie funkonieren die die Range angaben nicht und ich weiß nicht warum
z.B. wenn ich als version 2.6.0 schreibe klappt alles.
aber wenn ich eine range angebe <version>[2.6.0,4.0.0)</version> dann wird nichts mehr gefunden, verstehe nicht warum weil die range ja aussagt 2.6.0 <= x >4.0.0
Jeman eine idee?
aber wenn ich eine range angebe <version>[2.6.0,4.0.0)</version> dann wird nichts mehr gefunden, verstehe nicht warum weil die range ja aussagt 2.6.0 <= x >4.0.0
Jeman eine idee?
Eclipse hat ein ganz anderes Verständnis von Releases & Snapshots als Maven, aus Maven Sicht sind das alles nur SNAPSHOTS, dazu kommt das Maven und OSGi unteschiedliche Sortierungsverfahren für Versionen nutzen (. und -), daran kann auch das eclipse :to-maven Plugin goal nichts ändern.
Vergiss also Ranges wenn du mit Maven ein Eclipse RCP bauen willst, würde sowieso nicht wirklich funktionieren imho, jede Eclipse Release hat seine eigenen, spezifischen Abhängigkeiten die zwar als OSGi Ranges angegeben sind, aber sicherlich nciht einfach so funktoinieren werden wenn man die Bundles verschiedener Eclipse RCP Releases mischt.
D.h., wenn das Projekt auf Eclipse 3.5.1 aufbaut, dann ist das etwas anderes als auf Eclipse 3.5.2.
Wenn man mal darüber anchdenkt was sich zwischen Eclipse 2.6 und 3.9 alles ändern würde, kann man sich über eine range ala >= 2.6 && < 4.0 nur wundern
Du könntest zwar die qualifier per Kommandozeilenoption weglassen beim eclipse:to-maven, aber das würde das Problem nur verschleiern.
Hi kama, er hat sein eigenes repo erstellt, basierend auf einer Eclipse Installation ([c]mvn eclipse:to-maven[/c]).
Nebenbei, es kann gar kein funktionierendes öffentliches Eclipse Maven Repo geben welches auf ranges arbeitet aus den oben genannten Gründen.
Abhängigkeiten die zwar als OSGi Ranges angegeben sind, aber sicherlich nciht einfach so funktoinieren werden wenn man die Bundles verschiedener Eclipse RCP Releases mischt.
D.h., wenn das Projekt auf Eclipse 3.5.1 aufbaut, dann ist das etwas anderes als auf Eclipse 3.5.2.
Die OSGi Versionierung funktioniert nach dem Prinzip major.minor.micro.
Micro: Keine Änderung in den Schnittstellen
Minor: Abwärtskompatible Änderungen
Major: inkompatibel
Einige der Kern Bundles in Eclipse verwenden keine Ranges sondern referenzieren eine explizite Version, aber je weiter man in die 'Peripherie' vordringt umso looser sind die Bundles üblicherweise gekoppelt.
Wenn man eigene Bundles entwickelt ist man normalerweise von der Micro Version unabhängig und in vielen Fällen (wenn man eine neue Funktionalität nicht braucht) kann man auch problemlos mehrere minor Versions gleichzeitig unterstützen.
Bei Eclipse selbst wird die Einhaltung dieses Versionierungsvertrags normalerweise auch strikt durch Tooling forciert (API-Baseline aus PDE).
Schon klar, und zum Schluss kommt ein Timestamp (das alleine macht es für Maven schon zum Snapshot), damit gibt es dann u.U. mehrere ausgaben eines Bundles mit denselben major, minor & micro Versionenen die aber dennoch unterschiedlich sind (schon klar dass diese kompatibel sein sollten)
Einige der Kern Bundles in Eclipse verwenden keine Ranges sondern referenzieren eine explizite Version, aber je weiter man in die 'Peripherie' vordringt umso looser sind die Bundles üblicherweise gekoppelt.
Dazu kommt, dass die Version Ranges in der Manifest imho oft schon fahrlässig optimistisch sind (>=3.0, <4.0) dass man daraus leider keine zuverlässigen Infos extrahieren kann, und genau das versucht eclipse:to-maven.
Eclipse baut erstmal Snapshots, diese werden später zum Release promoted wenn alle zufrieden sind, allerdings bleiben die Timestamp infos erhalten.
In Maven macht man es anders, wenn man da ein Release machen will, dann macht man das direkt, inkl. Tag im SCM.
Hat beides Vor- und Nachteile, leider sind u.a. dadurch eben bestimmte Eclipse RCP und Maven konzepte nicht wirklich kompatibel.
Dazu kommt, dass die Version Ranges in der Manifest imho oft schon fahrlässig optimistisch sind (>=3.0, <4.0) dass man daraus leider keine zuverlässigen Infos extrahieren kann
Nein, die passen eigentlich wenn man sich an das OSGi versioning scheme hält und keine internal packages verwendet werden (wenn doch, darf man nicht mit solchen Ranges arbeiten). Die API von 3.9.9 muss abwärtskompatibel bis 3.0.0 sein und das PDE Tooling würde inkompatible Änderungen auch verbieten wenn eine API Baseline verwendet wird.
Hat beides Vor- und Nachteile, leider sind u.a. dadurch eben bestimmte Eclipse RCP und Maven konzepte nicht wirklich kompatibel.
Absolut, sehe ich genauso. Die Sache ist schon von Anfang an inkompatibel da es bei OSGi Dependencies primär um runtime und bei Maven Dependencies primär um compile time geht.
Sind halt sehr unterschiedliche Konzepte.
Warum sollten ranges nicht funktionieren???
Ich will keinen Eclipse RCP bauen!!!
Ich habe habe eclipse:to-maven aufgerufen, damit die Eclipse-Plugins mavensiert wurde. Maven Eclipse plugin - eclipse:to-maven
Dort habe ich stripQualifier auf true gesetzt, damit der Timestamp wegelassen wird und in mein Repo hochgeladen. Die Eclipse Plugins, welche mavensiert wurden, sehen gut aus. Außer das dort version ranges s.o. in den poms angegeben sind, welche das eclipe:to-maven erstellt haben.
Was aber eigentlich ja nicht schlimm sein sollte, da es ganz normale Maven-Artefakte sind.
Wenn man mal darüber anchdenkt was sich zwischen Eclipse 2.6 und 3.9 alles ändern würde, kann man sich über eine range ala >= 2.6 && < 4.0 nur wundern
Du könntest zwar die qualifier per Kommandozeilenoption weglassen beim eclipse:to-maven, aber das würde das Problem nur verschleiern.
Hi kama, er hat sein eigenes repo erstellt, basierend auf einer Eclipse Installation ([c]mvn eclipse:to-maven[/c]).
Nebenbei, es kann gar kein funktionierendes öffentliches Eclipse Maven Repo geben welches auf ranges arbeitet aus den oben genannten Gründen.
Ja das macht ja das eclipe:to-maven, ich will ja jetzt nicht alle Bundles die erstellt wurden selber anfassen sonst hat das Maven Plugin ja keinen sinn. Die poms werden mit ranges generiert.
Das Maven Eclipse Plugin ist version 2.8
@maki hast du es hinbekommen, dass das eclipe:to-maven etwas poms generiert OHNE version ranges?
ich denke mal er nimmt die infos aus dem manifest und wenn dort eine range drin ist kann ich ja daran nichts ändern.
Nein, die passen eigentlich wenn man sich an das OSGi versioning scheme hält und keine internal packages verwendet werden (wenn doch, darf man nicht mit solchen Ranges arbeiten). Die API von 3.9.9 muss abwärtskompatibel bis 3.0.0 sein und das PDE Tooling würde inkompatible Änderungen auch verbieten wenn eine API Baseline verwendet wird.
Die API könnte im besten Falle kompatibel sein, aber das (interne) verhalten ist dann doch oft anders.
Die tatsache dass Eclipse das sehr oft noch Split Packages verwendet macht es imho nicht einfacher.
Absolut, sehe ich genauso. Die Sache ist schon von Anfang an inkompatibel da es bei OSGi Dependencies primär um runtime und bei Maven Dependencies primär um compile time geht.
Sind halt sehr unterschiedliche Konzepte.
Das meinte ich nicht, OSGi und Maven sind sehr wohl "kompatibel", die Tatsache dass es bei OSGi um Runtime Dependencies (und mehr) geht ist dabei gar kein Problem.
Das Problem ist imho speziell bei Eclipse RCP die Versionierung und deren ranges, diese sind nicht wirklich kompatibel mit Maven.
@maki hast du es hinbekommen, dass das eclipe:to-maven etwas poms generiert OHNE version ranges?
D.h. aber nicht dass man selber die ranges verwenden kann, das geht eben nicht, muss es auch nicht, wenn man darüber nachdenkt
Am besten IME:
Pro mavenisierte Eclipse Version ein Repo in deinem Repo manager anlegen, jedes Projekt welche Eclipse RCP Artifakte braucht darf nur in einziges dieser Repos verwenden, ansonsten würde es früher oder später krachen.
Keine Ranges verwenden bei dependecies, Begründung s.o.
Jop hab ich gemacht!
Ich glaub ich generier es mal auf meine Lokale Platte und schieb die Plugins von Hand ins repo.
EDIT: Also wenn ich die Eclipse-Plugins erst auf die lokale Platte generiere und dann hochlade klappt alles.
Ich kann zwar immer noch keine version ranges angeben, aber die generierten pom's, die die version ranges enthalten funktionieren nun. Mysteriös :noe:
