Once someone provides/advertises a ?CBI? wiki page that explains
exactly how to follow the "just one step", I will endeavour to
follow it for my projects. However migration from Buckminster to
Tycho is still on my to-do list.
If a standard account at OSSRH is required, then I could argue
that EF IT should create it, since EF IT should be able to step in
and maintain it in extremis. EF IT could create corresponding
releng accounts, perhaps requiring a first time password
definition by the true user.
Hi Ed,
from my understanding there is just one step that must be
handled by each "project":
create and use an account (matching a maven groupId) at
OSSRH.
(Granularity can be decided within each top-level project,
even one huge group org.eclipse.modelling would be possible)
Other than that I agree, I just want to conquer one level at
the time, s.t. like:
1. Get Eclipse SDK Neon.2 published soon
2. Get this automated as much as possible
3. "Invite" others to join (opt-in/opt-out is not for me to
decide).
Still a few yards towards (1), but getting closer.
Good to know there will be allies for the subsequent levels..
cheers,
Stephan
----- ursprüngliche Nachricht ---------
Subject: Re: [emf-dev] Publishing to Maven Central
Date: Fr 16 Dez 2016 10:58:32 CET
From: Ed Willink
<ed@xxxxxxxxxxxxx>
To: Eclipse Modelling Framework
<emf-dev@xxxxxxxxxxx>
Hi
I disagree. EMF is just the first on a slippery slope of all
modeling artefacts.
IMHO, there should be a standard EF facility closely related
to the SimRel aggregator that automatically publishes all
SimRel contributions, other than those that opt out, either
because they have traditional practices that they wish to
continue using, or because they really should not be
published.
Regards
Ed Willink
On 16/12/2016 08:33, LE FEVRE
FRANCOIS wrote:
Hello
Thanks for the publication of EMF artifacts
to Eclipse Nexus.
I have two remarks:
1.
Automatic
a.
I think it is preferable to have a
continuous integration and a job dedicated to publish
EMF artifacts in a snapshot and release nexus
repositories.
2.
One repo for Eclipse train
a.
Do you think it could be possible at term
that Eclipse plugins that are part of the release train
could publish all artifacts in a shared nexus repository
avoiding to reference multiple nexus repositories?
Point 1 is the more critic for me.
Perhaps we could create a vote/bugzilla on
it?
+1, for me
Francois
De : emf-dev-bounces@xxxxxxxxxxx
[mailto:emf-dev-bounces@xxxxxxxxxxx]
De la part de Martin Taal
Envoyé : vendredi 16 décembre 2016 09:28
À : Dennis Hübner <dennis.huebner@xxxxxxxxx>;
Eclipse Modelling Framework <emf-dev@xxxxxxxxxxx>
Objet : Re: [emf-dev] Publishing to Maven Central
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.
> Am 15.12.2016 um 21:41 schrieb Stephan Herrmann
<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
> 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
_______________________________________________
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
|
This email has been checked for
viruses by Avast antivirus software.
www.avast.com
|
---- ursprüngliche Nachricht Ende ----
_______________________________________________
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