Community
Participate
Working Groups
With the maven-release-plugin you can go through a very complex workflow for artifacts. With tycho I must do all steps by hand: - checkout the plugins - patching the manifests and poms (partially supported with the tycho-setversion-plugin) - patching the .product-files, feature.xml and so on with the new version-numbers - build & deploy - SVN-commit - set the new SNAPSHOT-version (same steps like above) Especially the patching of manifests, pom's, feature.xml and product-files is very critical.
we have several patches by Beat Strasser pending for this story. See https://issues.sonatype.org/browse/TYCHO-426 https://issues.sonatype.org/browse/TYCHO-440 https://issues.sonatype.org/browse/TYCHO-573 https://issues.sonatype.org/browse/TYCHO-574 To set the expectations right, in my opinion there should not be a single magic black-box "tycho-release" mojo which does everything in one swoop. My personal experience with the maven-release-plugin is that it's not modular/configurable enough. The notion of "release process" depends too much on your concrete environment and taste. SCM checkout/checkin are out of scope for tycho. However tycho should provide the modular pieces needed to create such a workflow. That is mostly the steps "patching the manifests and poms, patching the .product-files, feature.xml and so on with the new version-numbers"
We should review & apply Beat's patches once the Tycho sources are in parallel IP at Eclipse.
FYI: Two of Beat's patches are in review: - bug 344210 (aka https://issues.sonatype.org/browse/TYCHO-426), and - bug 341745 (aka https://issues.sonatype.org/browse/TYCHO-558).
I've abandoned my efforts in the release/version plugin of tycho. I'm now concentrating my work on the version tiger which lets the developer set versions of tycho modules individually, and with Eclipse ide ui support. https://github.com/inventage/version-tiger/wiki
Is there any further progress on this issue? Or is there a solution already? Which would be super great...
(In reply to Jan Sievers from comment #1) > However tycho should provide the modular pieces needed to create such a > workflow. > That is mostly the steps > > "patching the manifests and poms, patching the .product-files, feature.xml > and so on with the new version-numbers" Totally agree, it would be great to configure maven-release-plugin to invoke tycho-versions plugin for versions changes before and right after the release build. Is there a way to do so? What about "property" conversions -DdevelopmentVersion -> -DnewVersion and additional pre-configured properties such as -Dtycho.mode=maven ?
The most crucial problem when trying to use tycho in conjunction with maven-release-plugin seems to be handle versions update. I have very simple solution for this, which doesn't require writing of entire release framework for tycho builds. maven-release-plugin can be used to generate release poms and after versions transformation we can add custom-tailored tycho goal which could sync OSGi metadata with maven poms. It shouldn't be that hard I believe.
(In reply to comment #7) > maven-release-plugin can be used to generate release poms and > after versions transformation we can add custom-tailored tycho goal which could > sync OSGi metadata with maven poms. It shouldn't be that hard I believe. Like the update-pom goal [1] but the other way (POM -> manifest)? This definitely shouldn't be hard. (In reply to comment #6) > Totally agree, it would be great to configure maven-release-plugin to invoke > tycho-versions plugin for versions changes before and right after the release > build. Is there a way to do so? Apparently, something like this is at least almost possible with the maven-release-plugin's preparationGoals parameter: There has been a mailing list post [2] attempting this. > What about "property" conversions -DdevelopmentVersion > -> -DnewVersion and additional pre-configured properties such as > -Dtycho.mode=maven ? Is the maven-versions-plugin setting -DdevelompentVersion when it calls the preparationGoals? If yes, it would be trivial to add developmentVersion as alias for newVersion on the Tycho side. Can anyone who knows the maven-release-plugin try this out? [1] https://www.eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/update-pom-mojo.html [2] https://dev.eclipse.org/mhonarc/lists/tycho-user/msg05790.html
What is the recommended approach for qualifier support in such a scenario? - Is the qualifier dropped during release build? - Is it set as usual but Tycho forced to ignore qualifier/snapshot mismatch?
(In reply to Gunnar Wagenknecht from comment #9) > What is the recommended approach for qualifier support in such a scenario? > > - Is the qualifier dropped during release build? > - Is it set as usual but Tycho forced to ignore qualifier/snapshot mismatch? Everything depends on release policy of your company. Previously when we were using releng builder we preferred to add timestamp for qualifier replacement which shows the date & time of our release. Now we can do exactly the same thing with tycho-versions plug-in and additional shell script which generates this timestamp replacement. Of course it would be very nice if release plug-in does this automatically but this can also be achieved very easy without so many extra-complications.
(In reply to Tobias Oberlies from comment #8) > (In reply to comment #7) > > maven-release-plugin can be used to generate release poms and > > after versions transformation we can add custom-tailored tycho goal which could > > sync OSGi metadata with maven poms. It shouldn't be that hard I believe. > Like the update-pom goal [1] but the other way (POM -> manifest)? This > definitely shouldn't be hard. bug 514163 has a proposed patch for this
New Gerrit change created: https://git.eclipse.org/r/94536
any reviewer can say if I must change something ? or if it's ok ;o)
(In reply to guillaume dufour from comment #13) > any reviewer can say if I must change something ? or if it's ok ;o) will review until end of this week. BTW it's best if you reply to individual comments in gerrit with 'done' or other so it's easy to see whether the particular concern is adressed with a new patchset.
Gerrit change https://git.eclipse.org/r/94536 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=9e72e1394c5d80139be3378e5231668b2b429a8b
(In reply to Eclipse Genie from comment #15) > Gerrit change https://git.eclipse.org/r/94536 was merged to [master]. > Commit: > http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/ > ?id=9e72e1394c5d80139be3378e5231668b2b429a8b this provides a new goal mvn org.eclipse.tycho:tycho-versions-plugin:update-eclipse-metadata which will update MANIFEST/feature.xml/product versions to match its respective pom versions (inverse operation of https://eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/update-pom-mojo.html ). I have no experience with maven-release-plugin myself but as far as I understood this was the missing piece to be able to use maven-release-plugin on a Tycho project. So if someone could write up a how-to in the wiki [1] with a full example release workflow with maven-release-plugin and the new update-eclipse-metadata goal that would be great. @Guillaume thanks for your patch! Feel free to review/extend on the respective section of the release notes [2] [1] https://wiki.eclipse.org/Tycho/Release_Workflow [2] https://wiki.eclipse.org/Tycho/Release_Notes/1.1
New Gerrit change created: https://git.eclipse.org/r/96130
I sucessfully tested the new feature in combination with the maven-release-plugin and will write up a how-to.
Small tutorial is online: https://wiki.eclipse.org/Tycho/Release_Workflow
(In reply to Martin Schreiber from comment #19) > Small tutorial is online: https://wiki.eclipse.org/Tycho/Release_Workflow thanks a lot Martin for taking the time to write this detailed tutorial! looking at the original requirements from comment #1 I consider this fixed now
