-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish Eclipse features also to Maven central #1421
Comments
No, I doubt that is a simple task at all. In addition, I don't see significant value in this that would justify the time investment from my personal perspective. To my thinking, features are really only useful for installing a set of bundles into an Equinox runtime. So I have no plans to invest time into such an effort. |
Can you remind me how we publish currently to Maven central?
Ed Merks ***@***.***> schrieb am Do., 5. Okt. 2023, 13:43:
… No, I doubt that is a simple task at all. In addition, I don't see
significant value in this that would justify the time investment from my
personal perspective. To my thinking, features are really only useful for
installing a set of bundles into an Equinox runtime. So I have no plans to
invest time into such an effort.
—
Reply to this email directly, view it on GitHub
<#1421 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABCFBQDNBLQBEENKWM46STX52MODAVCNFSM6AAAAAA5UDBBPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBYG4YTSOJTGI>
.
You are receiving this because you authored the thread.Message ID:
<eclipse-platform/eclipse.platform.releng.
***@***.***>
|
There's a bunch of stuff here: And this set of jobs do the work: |
Keep in mind that nexus as a bunch of rules for what can be published; rules that are more difficult than those for publishing to repo.eclipse.org which lets you dump pretty much anything... |
@merks I think deploy the plain feature file is not what one really wants alone but the generated pom should simply list all requirements (like its already done for a bundle) and then it will be pulled from maven central as well. Nerveless the only requirements are source+javadoc where we already have feature source jars and for bundles we already deploy a dummy javadoc so I won't expect anything different compared to deploy a jar if it contains a "bundle" or "feature". |
Thanks @merks looks at if features are currently explicitly excluded. #==== remove features: ====. Others are already publishing their feature, for example https://repo.eclipse.org/content/groups/jgit/org/eclipse/jgit/feature/org.eclipse.jgit/3.0.0.201305281830-rc2/ |
What's actually published to Maven central appears to be much reduced: https://repo1.maven.org/maven2/org/eclipse/jgit/ I have no plans to publish EMF's features to a Maven repository. |
Feature can be used in a target platform to retrieve the plug-ins listed in them, see eclipse-m2e/m2e-core#636 Publishing these features would allow a user to use these features to define their set of available platform plug-ins based on pure Maven targets. Fixes #1421
Feature can be used in a target platform to retrieve the plug-ins listed in them, see eclipse-m2e/m2e-core#636 Publishing these features would allow a user to use these features to define their set of available platform plug-ins based on pure Maven targets. Fixes #1421
@merks @laeubi Do you know how we publish to https://repo1.maven.org/maven2/? I see that our features are also missing their. |
We only publish there after a release. |
Looks like https://ci.eclipse.org/releng/view/Publish%20to%20Maven/job/PublishPlatformToMaven/ runs regulary, I see it running at the moment |
It's almost as if you are not reading what I am writing. That makes this time consuming. Please read what the job description says and please reread #1421 (comment) |
Feature can be used in a target platform to retrieve the plug-ins listed in them, see eclipse-m2e/m2e-core#636 Publishing these features would allow a user to use these features to define their set of available platform plug-ins based on pure Maven targets. Fixes #1421
I continue to get the sense that you have not read what I have written. Moreover, you appear to be under the impression that correctly publishing features to a Maven repository is simply a matter of editing one simple shell script. In addition to that, you seem to believe that the best time to test this and to iron out inevitable problems is when the final publishing is actually being done. Publishing correct final results is a vital final step in our release process, one for which we cannot risk mistakes because cannot un-publish mistakes. I really must strongly advise you to please take a step back and consider carefully the tasks involved in making this happen. To start with, have you ever opened these resources to understand what this means and what it does? Someone will need to edit this file: That someone will need to understand in detail what this file means and that someone will be best off to understand the purpose of this file: and how its associated editor can be used to verify and analyze the aggregation definition. Assuming we enhanced the aggregator to map features properly, assuming we configure all the mapping rules correctly for all the features, assuming we know how to massage feature artifacts into proper maven artifacts acceptable to Nexus, then we still have the problem that the Platform's features depends on features from EMF and ECF that are not published, so maybe we must assume too that only a subset of the "pure platform" features are to be published. You see there are a significant number assumptions involved here and a significant number of prerequisite TODOs that will require a significant depth of understanding and a significant investment of time. Are you prepared to make this significant investment? Such an investment must take place at the start of a release cycle, not at the end... |
In my experience things in Eclipse world are only requiring a significant investment because we continue to use our non customized technology. I plan to learn more about publishing to Maven central and return to this issue.
I tend to agree here, but as you said, it cannot be tested before the release cycle..... One option here might be to publish the features under a different namespace, e.g. vogellacompany (effectively a fork which would not affect the Eclipse standard) and if this works apply the learning to Eclipse. Thanks again for you kind response, @merks. I understand your concerns and of course respect them. |
One can deploy to a file based repository
also sonatype has staging repositories that can act as a playground. |
Discussion for PDE eclipse-pde/eclipse.pde#936 |
IIRC Lars gave up on this one in another issue. |
AFAICS we currently do not publish our features to Maven central. https://central.sonatype.com/search?q=org.eclipse.e4.rcp
A target platform can include features from Maven, see eclipse-m2e/m2e-core#636 therefore it would be nice if we publish also our features to Maven so that a target platform can avoid using p2 update sites.
@merks IIRC you are handling the release to Maven? I hope that publishing the feature to Maven is a simple task, e.g., by just adding the artifacts to the publishing script.
The text was updated successfully, but these errors were encountered: