Community
Participate
Working Groups
Hi, customizing the names of zip file that come out of a product build should be possible. The attached patch adds support for this feature by introducing String "zipFileName" and boolean "includeVersion" as configuration properties for the director bundle. Btw. this has also been requested on the mailinglist before.
Created attachment 203251 [details] Adds zip file naming support
FWIW this patch can also be found on my Tycho Github fork: https://github.com/lemmy/sonatype-tycho/commit/f760594f60d91d75ea597fa6175955c21fbfbc6d
Any decision yet if this is going to be merged upstream?
I haven't done a full review yet, but just one quick question ahead: Does the code prevent that the zips for different environments overwrite each other?
FWIW: I've update the code to master and filed a pull request at github [0]. [0] https://github.com/eclipse/tycho/pull/1
Hi Tobias, the zip will still be prepended with the environment, e.g. "-linux.gtk.x86". Btw. we successfully use this feature in our own build [0]. [0] https://tla.msr-inria.inria.fr/tlatoolbox/ci/products/
Hi Tobias, anything I can do to help get this into master? Thanks Markus
Sorry, this somehow dropped from my list. I'm wondering if we really need three new parameters. IMHO, just one "archiveName" parameter should be enough (see also comments in github). In order to contribute this, you'd need to answer some legal-related questions. [1] has the details. [1] http://wiki.eclipse.org/Tycho/Contributor_Guide#Contributing_the_Patch
Did you author 100% of the content you are contributing? Yes Who owns the copyright of the contributed content? (This is typically your employer.) Me (individual) Is the contributed code licensed under the EPL? (You should answer this question by putting a copyright and license header into every new java file.) Yes, EPL. Do you have the right to contribute the content to Eclipse? (You need to confirm this with the copyright owner.) Yes
I'm fine with the name change (do you want me to refactor it?) Not sure about the version though. How would it handle versions which are invalid for ${project.version}? E.g. marketing versions like "MyRCP-2012NTYaddaYadda"
(In reply to comment #10) > Not sure about the version though. How would it handle versions which are > invalid for ${project.version}? E.g. marketing versions like > "MyRCP-2012NTYaddaYadda" Coun't you just specify <archiveName>MyRCP-2012NTYaddaYadda</archiveName> in this case? You don't need to use the variable ${project.name} if you don't want the technical version in the name. Please don't get me wrong: I appreciate your contribution. But I also want to make sure that we introduce the right parameters (which are API) for the use case.
The actual value for version is taken from the .product file if includeVersion is set to true. How would I do this with ${...} substitution? Btw. the code has been refactored to "archiveFileName".
(In reply to comment #12) > The actual value for version is taken from the .product file if includeVersion > is set to true. How would I do this with ${...} substitution? Good question! Today, these versions can be different, but we anyway plan to introduce a new packaging type eclipse-product (bug 348586) which will only allow one product per module and that will make sure that the POM and product versions match. Therefore I am unsure if we really need the proposed version-related switches. Still, I would say we could take them now, but remove them again in eclipse-product (which will be incompatible anyway). Either way would be fine with me. For the contribution, we will also need an exact link to the patch as described in [1]. [1] http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions
(In reply to comment #13) > (In reply to comment #12) > > The actual value for version is taken from the .product file if includeVersion > > is set to true. How would I do this with ${...} substitution? > Good question! Today, these versions can be different, but we anyway plan to > introduce a new packaging type eclipse-product (bug 348586) which will only > allow one product per module and that will make sure that the POM and product > versions match. Therefore I am unsure if we really need the proposed > version-related switches. Still, I would say we could take them now, but remove > them again in eclipse-product (which will be incompatible anyway). Either way > would be fine with me. +1 > For the contribution, we will also need an exact link to the patch as described > in [1]. > > [1] http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions Don't you create the commit to reference to by accepting my Github pull request? Otherwise, won't https://github.com/eclipse/tycho/pull/1/files#diff-0 do as I don't see how I can squash my 5 commits that span across multiple others (due to merge).
hello, I have applied your commits to my local tycho git repo, and installed it on my desktop. It worked , thank you Markus ! As a n00b, it took me a while to find out what was needed in my pom to benefit from this addition, so here are my 2 cents : <build> <plugins> [...] <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-p2-director-plugin</artifactId> <version>${tycho-version}</version> <executions> <execution> <id>materialize-products</id> <goals> <goal>materialize-products</goal> </goals> </execution> <execution> <id>archive-products</id> <goals> <goal>archive-products</goal> </goals> </execution> </executions> <configuration> <products> <product> <id>THE_UID_FOUND_IN_MY_PRODUCT</id> <includeVersion>true</includeVersion> <version>${project.version}</version> <!--archiveFileName>optional, will replace the product UID in the file name</archiveFileName--> </product> </products> </configuration> </plugin> </plugins> </build>
(In reply to comment #15) > <product> > <id>THE_UID_FOUND_IN_MY_PRODUCT</id> > <includeVersion>true</includeVersion> > <version>${project.version}</version> > <!--archiveFileName>optional, will replace the product > UID in the file name</archiveFileName--> > </product> Just another note about the version : if you use <version>${project.version}</version> and your pom.xml version is 1.0.0-SNAPSHOT, then even if you set the build qualifier, via -Dbuild.qualifier , the -SNAPSHOT will never get replaced. So imagine I want to release M01, and I want the product zip to be named 1.0.0-M01, then I have to use <version>${buildQualifier}</version> and launch the build with mvn clean install -Dbuild.qualifier='M01'
Are we in a deadlock state here? Thanks Markus
Tobias is currently out of office and will not be back before we release 0.14.0. I haven't looked into the details yet but judging from the comments on this bug so far I will try to get this into 0.14.0.
(In reply to comment #18) > Tobias is currently out of office and will not be back before we release > 0.14.0. > > I haven't looked into the details yet but judging from the comments on this bug > so far I will try to get this into 0.14.0. Terrific, just let me know what I can do to make it go into 0.14.
Markus, I took your commits from [1], squashed them into one, added an integration test and reworked it to remove the version handling, see [2]. We now have one additional product configuration parameter "archiveFileName" <products> <product> <id>PRODUCT_UID</id> <archiveFileName>YOUR_ARCHIVE_PREFIX</archiveFileName> </product> </products> This is a prefix, i.e. the suffix <os>.<ws>.<arch>.<archiveExtension> will still be appended to the archive file name to avoid name collision for different os/ws/arch's. This should be enough to cover all use cases. In particular, if you want to include the version used by tycho including qualifier in the archive name, you can use e.g. <archiveFileName>CUSTOM_PREFIX-${unqualifiedVersion}.${buildQualifier}</archiveFileName> [1] https://github.com/eclipse/tycho/pull/1/ [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=066a12dc3686f14c637f901fc413d6959830f682
(In reply to comment #20) > Markus, > I took your commits from [1], squashed them into one, added an integration test > and reworked it to remove the version handling, see [2]. Why did you remove the version handling? Without it, the patch doesn't solve my use case of reusing the product file version by setting includeVersion=true any longer.
(In reply to comment #21) > (In reply to comment #20) > > Markus, > > I took your commits from [1], squashed them into one, added an integration test > > and reworked it to remove the version handling, see [2]. > > Why did you remove the version handling? Without it, the patch doesn't solve my > use case of reusing the product file version by setting includeVersion=true any > longer. version handling and configuring the archive name should not be mixed up IMHO. In case of the version ending with ".qualifier", the qualifier was simply stripped. The current patch allows to configure the product archive name. If you are not happy with it and think you need more convenience for including a version in the archive name, open a new bug.
(In reply to comment #22) > version handling and configuring the archive name should not be mixed up IMHO. > In case of the version ending with ".qualifier", the qualifier was simply > stripped. > The current patch allows to configure the product archive name. > If you are not happy with it and think you need more convenience for including > a version in the archive name, open a new bug. Well thanks, but I rather keep my own Tycho fork instead for now. The Tycho turnaround time wrt contributions just doesn't cut it for me and the fact that you have just removed the very same functionality doesn't make it look likely that it is going to be included any time soon.
(In reply to comment #20) > This is a prefix, i.e. the suffix <os>.<ws>.<arch>.<archiveExtension> will > still be appended to the archive file name to avoid name collision for > different os/ws/arch's. Anybody knows if it's possible to customize the complete name for a specific configuration? I'm producing a server build and only for 64bit. Thus, I don't need the <ws> part in the file name. I'd also like to replace <arch> and <os> with a complete custom file name. Is that possible with Tycho 0.18 or should I open a new enhancement request?
only the prefix can be configured. you will have to use maven antrun plugin or post-build steps if you want to rename the file.
