-
Notifications
You must be signed in to change notification settings - Fork 81
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
Deploy PDE artifacts to maven #936
base: master
Are you sure you want to change the base?
Conversation
I fully support deploying to maven. |
You can have a p2 repo on maven as well, see https://github.com/eclipse-tycho/tycho/tree/master/demo/p2-maven-site Beside that I think Eclipse/IBuild/SDK/Simrel/... will still include PDE anyways one way or another. |
e20b1de
to
0f5bcf2
Compare
So if SDK/I-builds want to include PDE without building it, you propose adding it as maven dependency. Can we say "latest" in maven deps somehow as I don't envision editing target file to pick latest PDE? |
Yes
Yes but it is deprecated.
In the end PDE becomes a third party dep and we do updates for these as well, at best there the just one feature mentioned and one might even use a version range there, that especially the things we need to explore here how it works out and where we need better support or additional features to support such use-cases, but I strongly believe that platform should be leading here even though I know others are already using such setups. |
by the way I created https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3993 as it seems PDE is suffering build executors... |
b216b17
to
d34b33e
Compare
I fully support this approach, moving to a pure Maven build is also what a lot of my clients desire and if we use this approach it will help to stabilise the process. P2 update sites are often considered as "extra" or "Eclipse only" technologies by my clients which normally also have a lot of "regular" Maven projects and Maven knowledge. |
d34b33e
to
b37b3c9
Compare
It seems some plugins use an older deploy plugin I have no clue why... will try to move this up otherwhise have to wait until master opens and maybe define it in the parent... |
b37b3c9
to
fe9b814
Compare
Please put it in the parent now. It's better to push such change now rather than multiplying it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fully support deploy PDE to a Maven-repo or maven central in a more direct and simple way and I'm happy to use it as a play ground to enhance that method further.
Nevertheless I also think that PDE should still also be provided through a p2 repo.
While I understand that some may like to get it through Maven I also assume that there is also a large user base that would like to obtain it through p2 as it is now.
But luckily we can do both so there is no need to choose. :)
It is to be discussed if PDE then gets its own p2-repo or will just continue to be provided through the existing eclipse/updates p2-repo.
And although it is actually not directly related to this PR and should be more discussed as part of eclipse-platform/eclipse.platform.releng.aggregator#1472: Even if PDE gets it own build there should be frequent builds of PDE against the latest versions of the other parts of the SDK, just like it is done at the moment with the I-builds. If PDE is still build as part of the nightly builds or a master build is triggered after a I-build, doesn't really matter. But I think it is important to have that since PDE usues many parts of other SDK areas that are not public API and may change at any time and we will only notice required actions quickly if we have frequent builds.
<pluginManagement> | ||
<plugins> | ||
</plugins> | ||
</pluginManagement> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks unnecessary.
<pluginManagement> | |
<plugins> | |
</plugins> | |
</pluginManagement> |
stages { | ||
stage('Build') { | ||
steps { | ||
wrap([$class: 'Xvnc', useXauthority: true]) { | ||
sh ''' | ||
mvn clean verify --batch-mode -Dmaven.repo.local=$WORKSPACE/.m2/repository \ | ||
mvn clean ${MVN_GOALS} --batch-mode -Dmaven.repo.local=$WORKSPACE/.m2/repository \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you convert this text-block to a GString block (i.e. by replacing leading and trailing '''
by """
) you can probably inline the function call and save the indirection through the environment variable.
mvn clean ${MVN_GOALS} --batch-mode -Dmaven.repo.local=$WORKSPACE/.m2/repository \ | |
mvn clean ${getMavenGoals()} --batch-mode -Dmaven.repo.local=$WORKSPACE/.m2/repository \ |
<plugin> | ||
<groupId>org.apache.maven.plugins</groupId> | ||
<artifactId>maven-deploy-plugin</artifactId> | ||
<version>3.1.1</version> | ||
</plugin> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this unnecessary with eclipse-platform/eclipse.platform.releng.aggregator#1582?
<plugin> | |
<groupId>org.apache.maven.plugins</groupId> | |
<artifactId>maven-deploy-plugin</artifactId> | |
<version>3.1.1</version> | |
</plugin> |
I also fully support deploying to Maven. |
Actually, if the p2.inf is included in the artifact and is honored later by the PDE target resolution, and by Tycho target resolution and by p2-maven-site, there seems to be no need to store them in Maven repo as they can be inferred later. |
fe9b814
to
0ddb87f
Compare
p2 metadata is attached to the project and would then be published along with the artifact
p2.inf is only considered at build time but not later on, but p2-maven-site will contain it as it is a regular p2 site just deployed at maven repository instead of http/ftp/.... |
IIRC, if the p2.inf is embedded at the right place in the artifact, the p2 publisher would always process it. So if client use the publisher, sharing the p2.inf is enough as every client should then regenerate the same p2 metadata. |
That's possible at least Tycho do not do any special processing if used as maven artifact in a target everything is delegated to P2 publisher. But p2.inf is not the only source in a Tycho build for p2 metadata.
This is one thing we should/can check then as well if Tycho also would download such data and use it later on. |
Maybe we could we also directly publish to repo.eclipse.org? |
As an alternative to
I think we maybe better should go the path of deploy PDE directly to the maven where we can consume than with maven target locations instead of create a new update site.
This has the following benefits:
If this is in place, we can start to iron out the produced poms and start trying to strip PDE form the aggregator and instead consume it from the target.
FYI @HannesWell @akurtakov @mickaelistria @vogella