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 < stephan.herrm...@berlin.de> 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 <dennis.hueb...@gmail.com > <mailto:dennis.hueb...@gmail.com>> wrote: > > > > > > > Am 15.12.2016 um 21:41 schrieb Stephan Herrmann < > stephan.herrm...@berlin.de <mailto:stephan.herrm...@berlin.de>>: > > > > > > 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 > > > emf-dev@eclipse.org <mailto:emf-dev@eclipse.org> > > > 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: mt...@springsite.com <mailto:mt...@springsite.com> - mt...@elver.org > <mailto:mt...@elver.org> > > S: martintaal > > > > > > _______________________________________________ > > emf-dev mailing list > > emf-dev@eclipse.org > > 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 > emf-dev@eclipse.org > 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: mt...@springsite.com - mt...@elver.org S: martintaal
_______________________________________________ emf-dev mailing list emf-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/emf-dev
