Open ruspl-afed opened 6 months ago
This was fully automated via https://github.com/eclipse-mylyn/org.eclipse.mylyn.docs/blob/master/Jenkinsfile-release so running some job using this jenkinsfile should be a good starting point.
How can this work?
We now have version 3.0.48.202308291007 as a dependency. But build the version 4.3 and include this version in the updatesite!
Maven Central and Eclipse Update Site are totally different things. Update site is easy to produce and committer rights are sufficient to upload. While uploading to Maven Central is quite a quest.
Maven Central and Eclipse Update Site are totally different things. Update site is easy to produce and committer rights are sufficient to upload. While uploading to Maven Central is quite a quest.
That is not the point.
We use mvn clean verify
for the Mylyn build, but Mylyn.docs needs mvn clean deploy
to push the build result into the remote repository.
Why do you fix set the version to the old version (3.0.48.202308291007) for org.eclipse.mylyn.wikitext and org.eclipse.mylyn.wikitext.textile in the pom of org.eclipse.mylyn.wikitext.maven?
How are newer version of the projects org.eclipse.mylyn.wikitext and org.eclipse.mylyn.wikitext.textile build and come into the maven repository?
Perhaps I miss something important: do you mean that you have a solution how to restore Mylyn Docs publishing? If so, please provide a PR.
@BeckerFrank I created a PR #487 to revert versions back to available in reactor
Perhaps I miss something important: do you mean that you have a solution how to restore Mylyn Docs publishing? If so, please provide a PR.
We have the following calls to maven for builder Mylyn
mvn \
clean \
verify \
-B \
$MAVEN_PROFILES \
-Dmaven.repo.local=$WORKSPACE/.m2/repository \
-Dmaven.test.failure.ignore=true \
-Dmaven.test.error.ignore=true \
-Ddash.fail=false \
-Dorg.eclipse.justj.p2.manager.build.url=$JOB_URL \
-Dbuild.type=$BUILD_TYPE \
-Dgit.commit=$GIT_COMMIT
and Mylyn.Docs
mvn clean deploy -U -B -V -e -s /home/jenkins/.m2/settings-deploy-ossrh-docs.xml -Psign -Possrh -Dmaven.repo.local=$WORKSPACE/.m2/repository -Dtycho.buildqualifier.format=yyyyMMddHHmm -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true -Ddash.fail=false -Dgpg.passphrase="${KEYRING_PASSPHRASE}" -Dnexus.autoReleaseAfterClose="${PERFORM_RELEASE}"
verify \
with deploy \
-U -V -e -s /home/jenkins/.m2/settings-deploy-ossrh-docs.xml \
-Possrh -Dgpg.passphrase="${KEYRING_PASSPHRASE}" \
-Dnexus.autoReleaseAfterClose="${PERFORM_RELEASE}"
-f mylyn.docs/pom.xml
But how can we make sure that with our test we did not create problems in maven central?
Thougths?
Could you publish snapshots to repo.eclipse.org first. What's published to staging needs to be closed and release before it's final. Can the not-yet-closed thing be tested before closing and releasing?
Maven publishing is most likely not working after moving Mylyn Docs inside Maven and further releng work. Perhaps, we need to restore it.
@akurtakov how do you recommend to approach this? Should we have a separate Jenkins config that launches
mvn
from the specific entry point (special pom.xml with enumerated modules to publish) and with special set of options? An outline of the steps to implement would be very helpful, because I'm not an experienced maven publisher.