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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

Eclipse IP has expressed concern historically about the integrity of the maven central repository.  Until they are comfortable with that then I don't see the point of going much further.  Once they are comfortable that things in maven central do not change once placed there (which is the policy of maven central, lord knows I have enough boo boo's out there), then there needs to be comfort that the binary bits in maven central are equivalent to those approved through the CQ process.  I am comfortable with the ones we use because we opened the CQ's using the binary and source from maven central itself.  How someone else can have the same level of comfort is hard to say....it is not like you can do a simple md5 check against the binary files since eclipse insisted on signing them and tweaking their metadata files so they follow 'The Eclipse Way'.  I have gone through and done source diffs in the past to feel comfortable about it.

We have discussed it many times in the past on the RT calls...and the ultimate decision has been to just do things as we can following eclipse policy in the creation of P2 repositories as they are the true 'Eclipse Release' output....and let the LTS efforts flesh out the actual nuts and bolts of putting requirements in place to bring sanity to the Orbit project since they have the resources and mandate to affect change.  There are big nasty hairy dragons there....if it was a map there would be monsters drawn all over it.

cheers,

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx

On Wed, Mar 12, 2014 at 12:31 PM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

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

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