Hi, Okay, in any case I just now also published (to Maven) the plugins/jars with the 2.11.2 and 2.12.0 versions. They should be visible on Maven in a couple of hours.
gr. Martin On Sun, Dec 18, 2016 at 9:35 PM Stephan Herrmann <[email protected]> wrote: > Sorry for slow response, > > Yes, 2.11.1 can be successfully used from Maven Central. > > The only reason I was hesitating, is the observation that > [2.11.1,) > still resolves to > 2.11.1-v20150805-0538 > > Even by consulting the "document" at > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning > it's beyond me to clearly see the semantics of such ranges. > > Only deep down in that document I find > "If the string is not present, then qualifiers.size() + "-" + string is > returned." > which seems to imply that any unknown qualifier is considered greater than > all > known qualifiers including the empty qualifier standing for release. > > So a definitely final 3-part version would need as its qualifier an > infinite > sequence of "last character in charset", go figure. > > I'm probably trying to read more meaning in Maven's design than there is. > > Anyway, yes, absent qualifier represents release / ga / final, > and that's what we want. > > Being able to include EMF as <version>2.11.1</version> is a step forward > in its own right. > (this wasn't possible before). > > And for new versions only having the 3-part version on Maven Central > should avoid some confusion in the future, I hope. > > thanks! > Stephan > > > > On 12/17/2016 03:21 PM, Martin Taal wrote: > > Hi Stephan, > > I published 2.11.1 (might take a couple of hours before on maven > central) without the qualifier. Note that even it is the 2.11.1 > > release some plugin jar files within the release have an older/lower > version number (e.g. 2.11.0), I assume because they haven't > > changed since the previous version. > > > > Let me know if this works for you, if so then I will publish 2.11.2 and > 2.12.0. > > > > gr. Martin > > > > > > On Sat, Dec 17, 2016 at 3:03 PM Martin Taal <[email protected] <mailto: > [email protected]>> wrote: > > > > Hi Stephan, > > I had no particular reason to include the qualifier other than this > allows to publish multiple 2.11.1 versions. So no problem > > for me to publish without a qualifier for the versions which are > part of a real release. > > > > The script I have takes a downloaded EMF update site and creates the > maven artifacts, then I have a separate publish ant script > > and go to the maven central repo to manually release the jars. The > maven artifacts are quite bare/simple but they worked until now. > > > > Since 2.11.1 there are 2 new versions: 2.12.0, 2.11.2, and there is > also 2.11.1 (without qualifier). Will publish all three of them. > > > > gr. Martin > > > > > > > > > > On Sat, Dec 17, 2016 at 12:57 PM Stephan Herrmann < > [email protected] <mailto:[email protected]>> wrote: > > > > Hi Martin, > > > > Looking at existing emf artifacts in Maven Central, I see that > > those have versions in the format like 2.11.1-v20150805-0538 > > > > First it's great to see that the qualifier is separated by '-', > > not '.', so these are indeed parsable maven versions. > > > > For the Eclipse Project we decided to publish our artifacts > > with 3-part versions, i.e., no qualifier at all, in order > > to avoid interpretation as snapshots (we are not publishing > > any snapshots to maven). > > > > I quickly made the test that > > <dependency> > > <groupId>org.eclipse.emf</groupId> > > <artifactId>org.eclipse.emf.ecore</artifactId> > > <version>2.11.1</version> > > </dependency> > > cannot be resolved from Maven Central, although EMF 2.11.1 > > clearly has been published. > > > > Do you see particular reasons why the qualifier would be > > important for users? Or is this just an artifact of the > > build tools being used? > > In my current reading maven would parse "2.11.1-v20150805-0538" > > as [2, 11, 1, v, 20160805, 0538] and I have only vague guesses > > what this could mean semantically. > > > > If by chance you are using the cbi aggregator (formerly > > b3 aggregator), you could actually set a newly introduced > > property "Version Format=Maven Release" [1]. > > > > From my p.o.v. this would be preferable, make artifacts > > more maven-like. OTOH, I checked that no artifacts from > > the Eclipse Project strictly require "2.12.0" (Neon.2). > > > > Ergo: I believe it would be more consistent if we all use > > 3-part release versions for maven artifacts, but my current > > effort doesn't seem to depend on any change in EMF. > > > > thanks, > > Stephan > > > > [1] > https://wiki.eclipse.org/CBI/aggregator/manual#Creating_a_Maven-conformant_p2_repo > > > > On 12/16/2016 09:28 AM, Martin Taal wrote: > > > Hi, > > > Indeed as Dennis mentions I publish EMF artifacts on request. > I use a partial automated script for this. I am happy to > > continue > > > doing this and normally I should be able to do it within a > couple of days of someone asking it. > > > > > > I can imagine that it can make sense to make this part of an > automated build step at some point. Until then no problem for > > me to > > > continue with it. > > > > > > I will publish the EMF artifacts for neon.2 the upcoming days > (this weekend) to get you going. > > > > > > Let me know ofcourse if anyone has any comments on this. > > > > > > gr. Martin > > > > > > > > > On Fri, Dec 16, 2016 at 9:17 AM Dennis Hübner < > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto: > [email protected]>>> wrote: > > > > > > > > > > Am 15.12.2016 um 21:41 schrieb Stephan Herrmann < > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto: > [email protected]>>>: > > > > > > > > Hi EMF :) > > > > > > > > > > Hello Stephan, > > > > > > I’m not EMF, but I will try to answer :) > > > > > > > In https://bugs.eclipse.org/408760 I'm working on > publishing all > > > > artifacts of the Eclipse Project to Maven Central. > > > > > > > > Initially, I naively thought, that this would comprise > *everything* > > > > in the release repo of the Eclipse Project. > > > > > > > > Only later it dawned on me that artifacts from other > projects > > > > are involved, too, notably: EMF :) > > > > > > > > Since we can only publish stuff where all dependencies > already > > > > exist on Maven Central, and given that we are targeting > to publish > > > > Neon.2 for which naturally no EMF artifacts are yet > available > > > > on Maven Central here my questions: > > > > > > > > Does EMF routinely publish all artifacts to Central? > > > > > > No. We never had a target to feed the maven repository > with our excellent framework. But > > > this may change in the future. The only guy behind > existing EMF maven artifacts is Martin Taal. > > > > > > > > > > > When may we expect Neon.2 artifacts to be available? > > > If one asks Martin and he has time. > > > > > > > > > > > Is org.eclipse.emf the correct groupId for referring to > EMF artifacts? > > > Yes. > > > > > > > > > > > > > > Strangely, I see the latest EMF artifacts only in > groupId org.eclipse.birt.runtime ?!? > > > They have there own artifacts. > > > > > > > > > > > thanks, > > > > Stephan > > > > _______________________________________________ > > > > emf-dev mailing list > > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > > To change your delivery options, retrieve your password, > or unsubscribe from this list, visit > > > > https://dev.eclipse.org/mailman/listinfo/emf-dev > > > > > > Viele Grüße, > > > Dennis Hübner > > > > > > -- > > > With Regards, Martin Taal > > > > > > Springsite > > > Nassaulaan 7 > > > 3941 EC Doorn > > > The Netherlands > > > > > > C: +31 (0) 6 288 48 943 > > > M: [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>> - > > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > S: martintaal > > > > > > > > > _______________________________________________ > > > emf-dev mailing list > > > [email protected] <mailto:[email protected]> > > > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > > > https://dev.eclipse.org/mailman/listinfo/emf-dev > > > > > > > _______________________________________________ > > emf-dev mailing list > > [email protected] <mailto:[email protected]> > > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > > https://dev.eclipse.org/mailman/listinfo/emf-dev > > > > -- > > With Regards, Martin Taal > > > > Springsite > > Nassaulaan 7 > > 3941 EC Doorn > > The Netherlands > > > > C: +31 (0) 6 288 48 943 > > M: [email protected] <mailto:[email protected]> - > [email protected] <mailto:[email protected]> > > S: martintaal > > > > -- > > With Regards, Martin Taal > > > > Springsite > > Nassaulaan 7 > > 3941 EC Doorn > > The Netherlands > > > > C: +31 (0) 6 288 48 943 > > M: [email protected] <mailto:[email protected]> - [email protected] > <mailto:[email protected]> > > S: martintaal > > > > > > _______________________________________________ > > emf-dev mailing list > > [email protected] > > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > > https://dev.eclipse.org/mailman/listinfo/emf-dev > > > > _______________________________________________ > emf-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/emf-dev > -- With Regards, Martin Taal Springsite Nassaulaan 7 3941 EC Doorn The Netherlands C: +31 (0) 6 288 48 943 M: [email protected] - [email protected] S: martintaal
_______________________________________________ emf-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/emf-dev
