Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] Publishing to Maven Central 
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 <mtaal@xxxxxxxxx <mailto:mtaal@xxxxxxxxx>> 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 <stephan.herrmann@xxxxxxxxx <mailto: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
             <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.huebner@xxxxxxxxx <mailto:dennis.huebner@xxxxxxxxx>
        <mailto: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>
        <mailto: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?
        >     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@xxxxxxxxxxx <mailto:emf-dev@xxxxxxxxxxx> <mailto: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
        >
        > Springsite
        > Nassaulaan 7
        > 3941 EC Doorn
        > The Netherlands
        >
        > C: +31 (0) 6 288 48 943
        > M: mtaal@xxxxxxxxxxxxxx <mailto:mtaal@xxxxxxxxxxxxxx> <mailto:mtaal@xxxxxxxxxxxxxx <mailto:mtaal@xxxxxxxxxxxxxx>> -
        mtaal@xxxxxxxxx <mailto:mtaal@xxxxxxxxx> <mailto:mtaal@xxxxxxxxx <mailto:mtaal@xxxxxxxxx>>
        > S: martintaal
        >
        >
        > _______________________________________________
        > 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
        >

        _______________________________________________
        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

    --
    With Regards, Martin Taal

    Springsite
    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

--
With Regards, Martin Taal

Springsite
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
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

Back to the top