|Re: [emf-dev] Publishing to Maven Central|
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. MartinOn Sat, Dec 17, 2016 at 12:57 PM Stephan Herrmann <stephan.herrmann@xxxxxxxxx> 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
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" .
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.
On 12/16/2016 09:28 AM, Martin Taal wrote:
> 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.huebner@xxxxxxxxx <mailto:dennis.huebner@xxxxxxxxx>> wrote:
> > Am 15.12.2016 um 21:41 schrieb Stephan Herrmann <stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>>:
> > 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?
> > 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@xxxxxxxxxxx <mailto:emf-dev@xxxxxxxxxxx>
> > 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
> Nassaulaan 7
> 3941 EC Doorn
> The Netherlands
> C: +31 (0) 6 288 48 943
> M: mtaal@xxxxxxxxxxxxxx <mailto:mtaal@xxxxxxxxxxxxxx> - mtaal@xxxxxxxxx <mailto:mtaal@xxxxxxxxx>
> S: martintaal
> emf-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
emf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
--With Regards, Martin TaalSpringsiteNassaulaan 73941 EC DoornThe NetherlandsC: +31 (0) 6 288 48 943
Back to the top