Re: [rt-pmc] Vert.x 2.1.0 release

[Wayne Beaton <wayne@xxxxxxxxxxx>]

I was using the word "artefact" in a generic sense. That spelling of the word is correct English.

I am in no way suggesting that any Maven artifact published to Maven central should reference Maven artifacts in an Eclipse repository. I don't know what the exact impact on this is, but I assume that pom files that reference Eclipse Foundation Maven server artifacts would have to be changed before being pushed to Maven Central.

We can push original artifacts into the Eclipse Maven repository. There's no specific requirement that says only OSGi-ified bundles can go there. In fact, I've suggested that we use the Eclipse-based Maven repository as a place to put "raw" JAR files for consumption by Orbit. At some point in the future, we need to put some energy into changing how Orbit works, and having it work from and push to an Eclipse Foundation-run Maven repository seems to make sense.

We do want to play well with the rest of the world. Again, I look to the RT PMC for guidance; how can we be confident that the artifacts pulled from Maven Central exactly match the JAR files that have been approved by the IP Team?

Wayne

On 03/12/2014 12:49 PM, Joakim Erdfelt wrote:

On Wed, Mar 12, 2014 at 8:38 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

On 03/12/2014 11:22 AM, Tim Fox wrote:

AIUI Vert.x is an Eclipse project and we consume artifacts from Maven Central as part of our build. Is this wrong? All the dependencies have been IP checked so I don't see why this is an issue.

Strictly speaking... yes, it's wrong, and I think that I explained why. If you don't agree with my reasoning, we can use that as a basis for discussion.

I don't want this to be show-stopper. If the artefacts that get consumed in a build are *exactly* the same as what has been IP checked and approved, and you are absolutely certain that there is no risk of any unapproved artefacts sneaking into the build, then we can consider this an invalid intermediate state for the time being. As we move forward, we need to either get Vert.x building against the Eclipse Foundation-hosted Maven instance, or put the necessary energy into convincing the IP Team that building against Maven is acceptable (I'll need the PMC's assistance with the latter option).

FWIW, Thanh Ha can help you with the build (e.g. if there are required artefacts missing from our Maven instance. or POMs need to be updated).

Some things that have been brought up before in this mailing list and bugzilla...

If you want to release your own Eclipse Artifacts (don't know what an "artefact" is, but is not a maven term) to Maven Central then all other dependencies that you use *must* be accessible *only* through Maven Central.  This is a requirement for participating in the global Maven Central repository system.

3rd party maven repositories are not allowed.

You are not even allowed to reference 3rd party maven repositories in your own released POMs.  (this results in a rejection of your artifact deployment to maven central)

In order for Eclipse projects to participate in the global mindshare of developers that use Maven Central, then all of the Eclipse artifacts that are on the Eclipse Maven Repository must also be deployed to Maven Central.  This also means that the Eclipse Maven Repository has 2 rolls, 1 for Eclipse Maven Artifacts in a unreleased / staging / snapshot form.  and 1 being a place for released Eclipse Maven Artifacts that are automatically synched to Maven Central).

The biggest crutch to this is that we modify the artifact contents for Orbit and that results in a different coordinate space for that artifact, a highly discouraged process in Maven terms (as it prevents duplicate artifact detection / proper dependency resolution).

- Joakim

Eclipse Jetty Project

_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects