Community
Participate
Working Groups
Follow-up from bug 408760 comment 7 (and thus of bug 484004): Let's use this bug to coordinate: - Publishing Eclipse SDK artifacts to Maven Central requires a few artifacts from ECF. - Other ECF artifacts have dependencies on some Eclipse Platform artifacts From this I see the following topics for coordination: (A) Sequencing of uploads, each upload can depend only on artifacts already available on Maven Central. (B) Format and content of artifacts (C) Mechanics of using OSSRH as our gateway to Maven Central
(A.1) The minimal slice of ECF required for the Platform can be seen in this preview: http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612161800/org/eclipse/ecf/ I.e., only three ECF artifacts seem to be used by Platform artifacts scheduled for publishing. (A.2) I also created a preview of a full upload driven by these features: - org.eclipse.ecf.remoteservice.sdk.feature - org.eclipse.ecf.remoteservice.sdk.source.feature - org.eclipse.ecf.core - org.eclipse.ecf.core.source available for inspection at http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612170730/org/eclipse/ecf/ ---- These repos intentionally omit: tests, features, artifacts without a jar, assuming that all these are irrelevant for regular maven consumption. The repo for (A.2) pulls in a few more 3rd party dependencies, which are not yet tackled via bug 484004: - ch/ethz/iks/ch.ethz.iks.r_osgi.remote/1.0.8 - org/apache/hadoop/org.apache.hadoop.zookeeper/3.3.3 - org/jdom/org.jdom/1.1.1 - org/jivesoftware/smack/org.jivesoftware.smack/3.3.100 - org/xbill/dns/org.xbill.dns/2.0.8 For these we need to identify the correct coordinates in Maven Central, so they are referenced using the correct groupId/artifactId.
Re (B) Format and content of artifacts: Characteristics of the referenced preview-repos: - 3-part versions - -sources.jar correctly co-located - pom files enriched with some necessary information, see, e.g., http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612170730/org/eclipse/ecf/org.eclipse.ecf/3.8.0/org.eclipse.ecf-3.8.0.pom We may have to add some more details to poms as soon as we get feedback from OSSRH's validator. Also, OSSRH requires -javadoc.jar. They mention that minimally a jar containing only a README would be tolerated. For the Eclipse Project I'm planning a first version where this README would point to the existing artifact containing the desired javadoc. Would org.eclipse.ecf.doc play this role for ECF?
Re (C) Mechanics of using OSSRH as our gateway to Maven Central I'm Cc'ing Fred to request one OSSRH account for org.eclipse.ecf, as well. This one should be associated to ECF's HIPP, I assume. TIA.
(In reply to Stephan Herrmann from comment #2) > Re (B) Format and content of artifacts: > > Characteristics of the referenced preview-repos: > - 3-part versions > - -sources.jar correctly co-located > - pom files enriched with some necessary information, see, e.g., > > http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612170730/org/ > eclipse/ecf/org.eclipse.ecf/3.8.0/org.eclipse.ecf-3.8.0.pom > > We may have to add some more details to poms as soon as we get feedback from > OSSRH's validator. > > Also, OSSRH requires -javadoc.jar. They mention that minimally a jar > containing only a README would be tolerated. For the Eclipse Project I'm > planning a first version where this README would point to the existing > artifact containing the desired javadoc. > Would org.eclipse.ecf.doc play this role for ECF? No, the doc plugin isn't right for that. However, we do consistently generate API javadoc for our releases...e.g.: http://download.eclipse.org/rt/ecf/3.13.3/javadoc
<stuff deleted> > (A.2) > I also created a preview of a full upload driven by these features: > - org.eclipse.ecf.remoteservice.sdk.feature > - org.eclipse.ecf.remoteservice.sdk.source.feature > - org.eclipse.ecf.core > - org.eclipse.ecf.core.source This is right. These two features include all of the other necessary features. > > available for inspection at > http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612170730/org/ > eclipse/ecf/ > > ---- > > These repos intentionally omit: tests, features, artifacts without a jar, > assuming that all these are irrelevant for regular maven consumption. yes, that's right. > > The repo for (A.2) pulls in a few more 3rd party dependencies, which are not > yet tackled via bug 484004: > > - ch/ethz/iks/ch.ethz.iks.r_osgi.remote/1.0.8 This is an implementation of R-osgi that has been donated to the ECF project. We now maintain it. Would it be possible to publish to Maven central under ECF's group id? > - org/apache/hadoop/org.apache.hadoop.zookeeper/3.3.3 This is from Orbit. It looks as though this version is already in Maven Central http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.zookeeper%22%20AND%20a%3A%22zookeeper%22 but I'm not sure whether it matches the Orbit version exactly, as we do not maintain that. What it the approach with Orbit bundles? Can they be published under ECF's group id too? > - org/jdom/org.jdom/1.1.1 We get this from Orbit as well. It does not look as if the 1.1.1 version is in Maven Central right now: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.jdom%22 Same question for this one about Orbit bundles in Maven Central. > - org/jivesoftware/smack/org.jivesoftware.smack/3.3.100 This contribution is part of the ECF repo...not in Orbit...and modified slight so that it can be built by us as a bundle. 3.3.100 is rather old, now, and it seems that only the 4.x stream is in Maven Central now and I doubt that that is OSGi bundles. We may have to see what we can do WRT the move to 4.x version of Smack. > - org/xbill/dns/org.xbill.dns/2.0.8 This we also get from Orbit. > > For these we need to identify the correct coordinates in Maven Central, so > they are referenced using the correct groupId/artifactId. Right. For bundles from Orbit...what is the general policy? Are these to have their own group id? (e.g. org.eclipse.orbit?). For the ones maintained by ECF (rosgi, smack 3.3) I would hope that we could make those available under org.eclipse.ecf group id, as we have been distributing them ourselves over many years, but perhaps something more/else is needed.
(In reply to Stephan Herrmann from comment #2) > Re (B) Format and content of artifacts: > > Characteristics of the referenced preview-repos: > - 3-part versions > - -sources.jar correctly co-located > - pom files enriched with some necessary information, see, e.g., > > http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612170730/org/ > eclipse/ecf/org.eclipse.ecf/3.8.0/org.eclipse.ecf-3.8.0.pom Why is this listed as version 3.8? Our current release version is 3.13.3...shouldn't this be the same?
(In reply to Scott Lewis from comment #5) > <stuff deleted> > > The repo for (A.2) pulls in a few more 3rd party dependencies, which are not > > yet tackled via bug 484004: > > > > - ch/ethz/iks/ch.ethz.iks.r_osgi.remote/1.0.8 > > This is an implementation of R-osgi that has been donated to the ECF > project. We now maintain it. Would it be possible to publish to Maven > central under ECF's group id? > > > - org/apache/hadoop/org.apache.hadoop.zookeeper/3.3.3 > > This is from Orbit. It looks as though this version is already in Maven > Central > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.zookeeper%22%20AND%20a%3A%22zookeeper%22 > > > but I'm not sure whether it matches the Orbit version exactly, as we do not > maintain that. What it the approach with Orbit bundles? Can they be > published under ECF's group id too? I'd think that the same version from Orbit and Maven Central _should_ be compatible. I will update my maven mappings to point to the existing G/A/V for this one. > > - org/jdom/org.jdom/1.1.1 > > We get this from Orbit as well. It does not look as if the 1.1.1 version > is in Maven Central right now: > > http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.jdom%22 They have 1.1 and 1.1.2: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.jdom%22%20AND%20a%3A%22jdom%22 Mhh... If your dependency is s.t. like [1.1.1,1.2,0) then we could indeed point to this stream, right? > Same question for this one about Orbit bundles in Maven Central. > > > - org/jivesoftware/smack/org.jivesoftware.smack/3.3.100 > > This contribution is part of the ECF repo...not in Orbit...and modified > slight so that it can be built by us as a bundle. 3.3.100 is rather old, > now, and it seems that only the 4.x stream is in Maven Central now and I > doubt that that is OSGi bundles. > > We may have to see what we can do WRT the move to 4.x version of Smack. Closest I can see is 3.1.0 ( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22jivesoftware%22%20AND%20a%3A%22smack%22 ) > > > - org/xbill/dns/org.xbill.dns/2.0.8 > > This we also get from Orbit. > > > > > > For these we need to identify the correct coordinates in Maven Central, so > > they are referenced using the correct groupId/artifactId. > > Right. For bundles from Orbit...what is the general policy? Are these to > have their own group id? (e.g. org.eclipse.orbit?). For the ones > maintained by ECF (rosgi, smack 3.3) I would hope that we could make those > available under org.eclipse.ecf group id, as we have been distributing them > ourselves over many years, but perhaps something more/else is needed. I don't think Orbit has a general policy for this. I see that some projects already published 3rd party libs under their own groupId, e.g., https://repo1.maven.org/maven2/org/eclipse/birt/runtime/org.w3c.css.sac/1.3.1.v200903091627/org.w3c.css.sac-1.3.1.v200903091627.pom OTOH, many (most?) Orbit bundles correspond to libraries that have been in use outside Eclipse for some time, and chances are that they are typically consumed using maven already. In fact one of the motivations for the current effort is to avoid duplication of existing maven artifacts in a different group (notably in group "p2.osgi.bundle"). PS: I noticed some quirks in the search on http://search.maven.org, so failure to find a particular artifact may not be definite. E.g., version 1.1.1 of jdom can be found via: http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.jdom.CDATA%22 (by searching for a contained class). Some of those finds my be similar to what you are proposing: someone needing the artifact published it in their own groupId. It's kind of: if you consider the group reliable, we may reference it from their, otherwise including it in your group may be the best we can do for now.
(In reply to Scott Lewis from comment #6) > (In reply to Stephan Herrmann from comment #2) > > Re (B) Format and content of artifacts: > > > > Characteristics of the referenced preview-repos: > > - 3-part versions > > - -sources.jar correctly co-located > > - pom files enriched with some necessary information, see, e.g., > > > > http://build.eclipse.org/tools/objectteams/sdk_aggr/repo-201612170730/org/ > > eclipse/ecf/org.eclipse.ecf/3.8.0/org.eclipse.ecf-3.8.0.pom > > Why is this listed as version 3.8? Our current release version is > 3.13.3...shouldn't this be the same? This I should better ask you :) I just pick up what's available from http://download.eclipse.org/eclipse/updates/4.6/R-4.6.2-201611241400/plugins/?d and from http://download.eclipse.org/rt/ecf/3.13.2/site.p2/plugins/?d Note, that the above reference is for a plug-in, not a feature. Apparently, plug-ins have their individual history / version, independent from the general version of "ECF", which sounds good to me.
<stuff deleted> > > > > > - org/jdom/org.jdom/1.1.1 > > > > We get this from Orbit as well. It does not look as if the 1.1.1 version > > is in Maven Central right now: > > > > http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.jdom%22 > > They have 1.1 and 1.1.2: > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org. > jdom%22%20AND%20a%3A%22jdom%22 > > Mhh... > > If your dependency is s.t. like [1.1.1,1.2,0) then we could indeed point to > this stream, right? Yes. I'll check this out. <stuff deleted> > > This contribution is part of the ECF repo...not in Orbit...and modified > > slight so that it can be built by us as a bundle. 3.3.100 is rather old, > > now, and it seems that only the 4.x stream is in Maven Central now and I > > doubt that that is OSGi bundles. > > > > We may have to see what we can do WRT the move to 4.x version of Smack. > > Closest I can see is 3.1.0 ( > http://search.maven.org/ > #search%7Cgav%7C1%7Cg%3A%22jivesoftware%22%20AND%20a%3A%22smack%22 ) Unfortunately we can't go back to 3.1. > > > > > > - org/xbill/dns/org.xbill.dns/2.0.8 > > > > This we also get from Orbit. > > > > > > > > > > For these we need to identify the correct coordinates in Maven Central, so > > > they are referenced using the correct groupId/artifactId. > > > > Right. For bundles from Orbit...what is the general policy? Are these to > > have their own group id? (e.g. org.eclipse.orbit?). For the ones > > maintained by ECF (rosgi, smack 3.3) I would hope that we could make those > > available under org.eclipse.ecf group id, as we have been distributing them > > ourselves over many years, but perhaps something more/else is needed. > > I don't think Orbit has a general policy for this. I see that some projects > already published 3rd party libs under their own groupId, e.g., > https://repo1.maven.org/maven2/org/eclipse/birt/runtime/org.w3c.css.sac/1.3. > 1.v200903091627/org.w3c.css.sac-1.3.1.v200903091627.pom > > OTOH, many (most?) Orbit bundles correspond to libraries that have been in > use outside Eclipse for some time, and chances are that they are typically > consumed using maven already. > > In fact one of the motivations for the current effort is to avoid > duplication of existing maven artifacts in a different group (notably in > group "p2.osgi.bundle"). Yeah, I would prefer it if Orbit bundles were just made available in Orbit under whatever group id made sense. But we don't have any direct control over that and are just Orbit consumers. > > > PS: I noticed some quirks in the search on http://search.maven.org, so > failure to find a particular artifact may not be definite. E.g., version > 1.1.1 of jdom can be found via: > http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.jdom.CDATA%22 (by > searching for a contained class). Some of those finds my be similar to what > you are proposing: someone needing the artifact published it in their own > groupId. Ok. thanks. > > It's kind of: if you consider the group reliable, we may reference it from > their, otherwise including it in your group may be the best we can do for > now. Either is fine with me/us. I share your desire to minimize the duplication for Orbit dependencies, but we can't really control any of that. Have you interacted with the Orbit project folks about that?
(In reply to Scott Lewis from comment #9) > Either is fine with me/us. I share your desire to minimize the duplication > for Orbit dependencies, but we can't really control any of that. Have you > interacted with the Orbit project folks about that? I think requesting action from Orbit should only be the last resort. They are only repackaging, not authoring any of this. The upstream projects should ideally (and in most cases already do) publish their artifacts to maven. For the Eclipse Project we're lucky: all Orbit prereqs could be suitably identified in Maven Central. IOW, this topic is solved for phase 1 & 2 out of 3: 1. publish minimal ECF 2. publish Eclipse SDK 3. publish full ECF I think I forgot to comment on R-osgi: should I remap this to s.t. like org.eclipse.ecf:ch.ethz.iks.r_osgi.remote ? If it has been donated to you, I'm surprised it is not in your (OSGi) namespace, but then this is none of my business :)
(In reply to Stephan Herrmann from comment #10) <stuff deleted> > I think requesting action from Orbit should only be the last resort. They > are only repackaging, not authoring any of this. The upstream projects > should ideally (and in most cases already do) publish their artifacts to > maven. I agree that the upstream project should ideally publish their artifacts to maven central. However, the use of Orbit project bundles is a) mandated by the simultaneous release requirements b) *technically required* when the upstream library doesn't already contain OSGi metadata. I'm not sure how many of the ones we currently depend upon now publish their libs with OSGi metadata, but when we started consuming them from Orbit none of them did. So we had to consume them from Orbit because of both a (mandate) and b (technical requirement). > > For the Eclipse Project we're lucky: all Orbit prereqs could be suitably > identified in Maven Central. IOW, this topic is solved for phase 1 & 2 out > of 3: > 1. publish minimal ECF What is meant by minimal? Just the ECF filetransfer components depended upon by Eclipse SDK? I would say that ECF minimal (for ECF's consumers) includes the ECF Remote Services SDK (3a below). > 2. publish Eclipse SDK > 3. publish full ECF I think you should break 3 into two parts: a) the ECF Remote Services SDK and 3b) the ECF SDK for Eclipse. This is reflected in the two features that I listed. The reason I think this should be done is that many of our consumers are using ECF Remote Services on Karaf...which uses maven for feature install. So 3a is particularly important to us and our consumers/community to make available on maven central. 3b would be valuable, but less valuable to our consumers than 3a. > > I think I forgot to comment on R-osgi: should I remap this to s.t. like > org.eclipse.ecf:ch.ethz.iks.r_osgi.remote > ? Yes please. > > If it has been donated to you, I'm surprised it is not in your (OSGi) > namespace, but then this is none of my business :) It's been donated to the ECF project quite a few years ago by one of the former committers. FWIW here's the CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2063
(In reply to Scott Lewis from comment #11) > I agree that the upstream project should ideally publish their artifacts to > maven central. However, the use of Orbit project bundles is > > a) mandated by the simultaneous release requirements > > b) *technically required* when the upstream library doesn't already contain > OSGi metadata. > > I'm not sure how many of the ones we currently depend upon now publish their > libs with OSGi metadata, but when we started consuming them from Orbit none > of them did. So we had to consume them from Orbit because of both a > (mandate) and b (technical requirement). Frankly, when targeting Maven Central I'm not much concerned about OSGi metadata, since the primary usage scenario I am thinking of are plain maven projects that use Eclipse artifacts with no OSGi context (that's why I am content with *any* upstream artifacts on Maven Central). Builds using tycho can directly consume our p2 repositories, those don't need Maven Central. Apparently, you have other scenarii in mind, which use OSGi with maven but not tycho? If so, that would indeed motivate publishing some artifacts in the org.eclipse.orbit groupId. If needed, and once the Eclipse SDK ball is rolling, letting Orbit follow suite should not be too hard, hopefully, but I'm not involved in Orbit.
(In reply to Scott Lewis from comment #11) > (In reply to Stephan Herrmann from comment #10) > <stuff deleted> > > > I think requesting action from Orbit should only be the last resort. They > > are only repackaging, not authoring any of this. The upstream projects > > should ideally (and in most cases already do) publish their artifacts to > > maven. > > I agree that the upstream project should ideally publish their artifacts to > maven central. However, the use of Orbit project bundles is > > a) mandated by the simultaneous release requirements > > b) *technically required* when the upstream library doesn't already contain > OSGi metadata. > > I'm not sure how many of the ones we currently depend upon now publish their > libs with OSGi metadata, but when we started consuming them from Orbit none > of them did. So we had to consume them from Orbit because of both a > (mandate) and b (technical requirement). > > > > > For the Eclipse Project we're lucky: all Orbit prereqs could be suitably > > identified in Maven Central. IOW, this topic is solved for phase 1 & 2 out > > of 3: > > 1. publish minimal ECF > > What is meant by minimal? Just the ECF filetransfer components depended > upon by Eclipse SDK? I would say that ECF minimal (for ECF's consumers) > includes the ECF Remote Services SDK (3a below). > > > 2. publish Eclipse SDK > > 3. publish full ECF > > I think you should break 3 into two parts: a) the ECF Remote Services SDK > and 3b) the ECF SDK for Eclipse. This is reflected in the two features that > I listed. The reason I think this should be done is that many of our > consumers are using ECF Remote Services on Karaf...which uses maven for > feature install. So 3a is particularly important to us and our > consumers/community to make available on maven central. 3b would be > valuable, but less valuable to our consumers than 3a. Can you easily say which of the 3rd party dependencies are needed for 3a? If 3a can be served from already-identified artifacts on Maven Central, then I see no objections. Otherwise I'd prefer "minimal" in the strict sense of "enabling step (2)". As you mention "feature install", would that require features to be available via maven?
> > Frankly, when targeting Maven Central I'm not much concerned about OSGi > metadata, since the primary usage scenario I am thinking of are plain maven > projects that use Eclipse artifacts with no OSGi context (that's why I am > content with *any* upstream artifacts on Maven Central). > > Builds using tycho can directly consume our p2 repositories, those don't > need Maven Central. > > Apparently, you have other scenarii in mind, which use OSGi with maven but > not tycho? Yes, specifically Karaf: http://karaf.apache.org/ This is an OSGi-based server (so requires OSGi metadata), and it uses maven for install/update. A number of Karaf users use ECF's impl of OSGi Remote Services/RSA. > > If so, that would indeed motivate publishing some artifacts in the > org.eclipse.orbit groupId. If needed, and once the Eclipse SDK ball is > rolling, letting Orbit follow suite should not be too hard, hopefully, but > I'm not involved in Orbit. Right...neither are we (as committers...obviously we are consumers).
(In reply to Stephan Herrmann from comment #13) > > Can you easily say which of the 3rd party dependencies are needed for 3a? Yeah. I'll work on a list today. It won't be that many...on the order of 5. > 3a can be served from already-identified artifacts on Maven Central, then I > see no objections. Well, this is where I'm not sure...if the upstream has produced matching OSGi meta-data this will be fine, but if not...then we need to consume the Orbit version. >Otherwise I'd prefer "minimal" in the strict sense of > "enabling step (2)". > > > As you mention "feature install", would that require features to be > available via maven? When I say 'feature install' wrt karaf...yes I do mean available via maven. For example, here's the karaf feature meta-data for maven-based install that uses our 3.13.2 metadata (which is here: http://build.ecf-project.org/maven/3.13.2/): http://download.eclipse.org/rt/ecf/3.13.2/site.p2/karaf4-features-maven.xml It's definitely a pain for our users to add a separate repository (i.e. the one at build.ecf-project.org, and that's why it would be really nice for them if the remote services sdk in particular was available via maven central.
(In reply to Scott Lewis from comment #15) > > Can you easily say which of the 3rd party dependencies are needed for 3a? > > Yeah. I'll work on a list today. It won't be that many...on the order of 5. All of these are from Orbit and available here (this is where our build gets them) http://download.eclipse.org/tools/orbit/downloads/drops/R20160520211859/ 1) org.xbil.dnssd v 2.0.8. 2) ch.ethz.iks.rosgi and ch.ethz.iks.slp (this was part of the contribution for osgi and so the source is in our repo and we build it). It should be in the org.eclipse.ecf gropuid as discussed. It is not in Orbit. 3) org.apache.log4j From Orbit. This is also distributed with Eclipse) 4) org.apache.hadoop.zookeeper 3.3.3. Available via Orbit. this would be sufficient for us wrt the remote services sdk. > > > 3a can be served from already-identified artifacts on Maven Central, then I > > see no objections. > > Well, this is where I'm not sure...if the upstream has produced matching > OSGi meta-data this will be fine, but if not...then we need to consume the > Orbit version. > > >Otherwise I'd prefer "minimal" in the strict sense of > > "enabling step (2)". > > > > > > As you mention "feature install", would that require features to be > > available via maven? > > When I say 'feature install' wrt karaf...yes I do mean available via maven. > For example, here's the karaf feature meta-data for maven-based install that > uses our 3.13.2 metadata (which is here: > http://build.ecf-project.org/maven/3.13.2/): > > http://download.eclipse.org/rt/ecf/3.13.2/site.p2/karaf4-features-maven.xml > > It's definitely a pain for our users to add a separate repository (i.e. the > one at build.ecf-project.org, and that's why it would be really nice for > them if the remote services sdk in particular was available via maven > central.
(In reply to Scott Lewis from comment #16) > > 4) org.apache.hadoop.zookeeper 3.3.3. Available via Orbit. > > this would be sufficient for us wrt the remote services sdk. Forgot some more 5) org.objectweb.asm v5.0.1 (From Orbit...this is also used/required by Eclipse) 6) com.jcraft.jsh 0.1.53 (From Orbit...this is also uses/required by Eclipse)
One thing we should probably carefully avoid: if ECF and Eclipse have a shared dependency (like asm / jsch), when Eclipse maps this to an existing maven artifact, and when that artifact lacks OSGi metadata, then you'll be out of luck. Do you want to check those two artifacts on Maven Central if they are good for you? I'm referencing them as org.ow2.asm:asm:5.0.1 (plus asm-tree) com.jcraft:jsch:0.1.53 ("out-of-luck" meaning: consumers may have to explicitly exclude one variant and include the other). For the others we are still free to decide either way, and when Maven-Central-variants lack OSGi data, you could e.g., include them in org.eclipse.ecf for now and in a future version map it to s.t. sharable published under org.eclipse.orbit etc.
(In reply to Stephan Herrmann from comment #18) > One thing we should probably carefully avoid: if ECF and Eclipse have a > shared dependency (like asm / jsch), when Eclipse maps this to an existing > maven artifact, and when that artifact lacks OSGi metadata, then you'll be > out of luck. >Do you want to check those two artifacts on Maven Central if > they are good for you? I'm referencing them as > org.ow2.asm:asm:5.0.1 (plus asm-tree) > com.jcraft:jsch:0.1.53 > > ("out-of-luck" meaning: consumers may have to explicitly exclude one variant > and include the other). I did check these. It seems that they have not been 'bundleized' in the maven central upstream distribution. I think for the time being, what should be done is to distribute the Orbit instance of these specific versions in the org.eclipse.ecf namespace. > > For the others we are still free to decide either way, and when > Maven-Central-variants lack OSGi data, you could e.g., include them in > org.eclipse.ecf for now and in a future version map it to s.t. sharable > published under org.eclipse.orbit etc. I think for the immediate we should just use the Orbit versions (in ECF repo) and include them in the org.eclipse.ecf groupid. It's going to take some time for use to verify not only that the upstream projects are including OSGi meta-data, but also that the most recent versions haven't broken anything. Thanks.
(In reply to Stephan Herrmann from comment #3) > Re (C) Mechanics of using OSSRH as our gateway to Maven Central > > I'm Cc'ing Fred to request one OSSRH account for org.eclipse.ecf, as well. > This one should be associated to ECF's HIPP, I assume. TIA. I've created OSSRH ticket https://issues.sonatype.org/browse/OSSRH-27022 and will set up GPG signing now.
I've created and configured the signing key on the ECF HIPP. Your public key is https://pgp.mit.edu/pks/lookup?op=get&search=0x021B6E5B2F3B218C. It is signed by the webmaster's key. As a committer, you should sign it too. You have to use a dedicated Maven settings file which is located here: /opt/public/hipp/homes/genie.ecf/.m2/settings-deploy-ossrh.xml. These settings have to be selected in the Maven build step in your jobs (under Advanced). The settings contain a server definition named 'ossrh' to let you upload things to Sonatype's server. This server id should be used in a distributionManagement repository somewhere specifying the URL. See http://central.sonatype.org/pages/ossrh-guide.html#releasing-to-central and http://central.sonatype.org/pages/ossrh-guide.html#ossrh-usage-notes for details. The GPG passphrase is also configured (encrypted) in the settings (as described at https://maven.apache.org/plugins/maven-gpg-plugin/usage.html#Configure_passphrase_in_settings.xml). You can now use the maven-gpg-plugin, it should work as is without further configuration if you properly selected the 'Deploy to OSSRH' setting. Please wait for the mentioned OSSRH ticket to be resolved before testing.
https://issues.sonatype.org/browse/OSSRH-27022 is now resolved. Let me know when you promoted your first release so I can comment on https://issues.sonatype.org/browse/OSSRH-27022. Or you can do this yourself.
Scott, in case you aren't following progress in bug 484004: - I got org.eclipse.platform and org.eclipse.jdt artifacts successfully validated in OSSRH, basically ready to push the release button (only PDE still missing for some dubious permission problems) - This implies that platform can be released independently from ecf, though both should be done "in a coordinated fashion". - I documented all my steps in https://wiki.eclipse.org/Platform-releng/Publish_To_Maven_Central - I recommend you read this as a starting point, though I'm not sure whether all these steps are required for the ECF case. In particular I understand you don't want to remove features. (lmk if anything is unclear / bogus). - All the required scripts & models should be linked, lmk if some content is not visible without, e.g., a login to the releng HIPP. - If you set up build jobs similar to those I have on releng HIPP I can help with any details. I don't yet know when my scripts / tools will be adopted by Platform/Releng, and whether they will be suitable for direct re-use. For now I'd suggest you just copy the parts you need into your own git repo.
Has there been any progress on publishing ECF artifacts to Maven Central? I have a Gradle project that depends on org.eclipse.platform:org.eclipse.equinox.p2.transport.ecf:1.2.400. It has 3 ECF dependencies: org.eclipse.ecf is currently being published to Maven Central, but org.eclipse.ecf.filetransfer and org.eclipse.ecf.provider.filetransfer are not in Maven Central.
I'm assigning to Mat Booth as he has been doing the artifact publication to maven central. This should just be a matter of adding org.eclipse.ecf.filetransfer and org.eclipse.ecf.provider.filetransfer as part of next release.
Thanks! I might also need these artifacts too if it's possible: org.eclipse.ecf.provider.filetransfer.httpclient4 org.eclipse.ecf.provider.filetransfer.httpclient4.ssl org.eclipse.ecf.provider.filetransfer.ssl org.eclipse.ecf.ssl
(In reply to Tyler King from comment #26) > Thanks! I might also need these artifacts too if it's possible: > > org.eclipse.ecf.provider.filetransfer.httpclient4 > org.eclipse.ecf.provider.filetransfer.httpclient4.ssl > org.eclipse.ecf.provider.filetransfer.ssl > org.eclipse.ecf.ssl Hi, ECF artifacts are pushed to maven central under the "org.eclipse.ecf" namespace: https://search.maven.org/search?q=g:org.eclipse.ecf But yeah filetransfer is missing. It looks like we have only been pushing stuff mentioned in the karaf features file: https://download.eclipse.org/rt/ecf/3.14.7/karaf-features.xml I will make sure filetransfer artifacts are pushed to maven central in the next release, sorry for the inconvenience
