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
