Community
Participate
Working Groups
I want like to build a targetplatform with Tycho containing all jar and its depdendencies. Therefore I am using the tycho-p2-repository-plugin: <plugin> <groupId>org.sonatype.tycho</groupId> <artifactId>tycho-p2-repository-plugin</artifactId> <version>${tycho-version}</version> <configuration> <includeAllDependencies>true</includeAllDependencies> <createArtifactRepository>true</createArtifactRepository> <compress>true</compress> </configuration> </plugin> The result is a zipfile with a p2 repository, that is named like the project/artifact itself for example org.example.build.updatesite.zip. I would like the name to include the timestamp and version of the build and therefore need a configuration-option like <outputfilename>.
Actually, you don't need a new parameter for this. The file name in the target folder doesn't matter at all, so we could just change it to include the qualified version of the module. Would this help?
Not just yet. I would like to have the possibility to give the zip file a name like myproduct-1.2.3-20110614.zip instead of org.example.build.updatesite.zip.
Adding the qualified version to the file name would improve the current situation, but its not the final solution. The background is, we are providing targetplatforms to our customers as a download. So we need to give them a name with a version, build-id, environment etc. Would be great to see this fixed, so we can finally move from pde-build to tycho.
(In reply to comment #1) > Actually, you don't need a new parameter for this. The file name in the target > folder doesn't matter at all, so we could just change it to include the > qualified version of the module. Would this help? Hi Tobias, What would the qualified version exactly look like…Current the target platform for Riena that we build is called Riena-target-201109020507-win32.zip (for the Target platform) (that includes Riena and Equinox and RCP and all this) or its called Riena-p2repo-201109020507-win32.zip (which is only Riena as p2 repo). If we use Tycho we get something like this org.eclipse.riena.build.updatesite.zip. So what would we get with the qualified version that you are proposing ? thanks christian p.s.s Riena build is all on Eclipse.org. So if you care to look at the pom.xml I could give you a pointer,
My idea was to use <artifactId>-<version>.zip
(In reply to comment #5) > My idea was to use <artifactId>-<version>.zip Well you run a nightly build that is untagged for a product. So the version in the product is 4.0.0.qualifier. Say the artifact (is that the artifact of the product) would be org.eclipse.riena.build.product ? So I wanna build something for today 12:00 am…… So obviously org.eclipse.riena.build.product-4.0.0.qualifier.zip is really not enough. That seems to be a quite common thing that you do nightly builds and need something like a build id which currently is often a timestamp. So we need something like that for the zip of the p2 update site so that we can distinguish them and upload them to a web upload directory.
So, <artifactId>-<qualifiedVersion>.zip would be good enough?
(In reply to comment #7) > So, <artifactId>-<qualifiedVersion>.zip would be good enough? I said "So obviously org.eclipse.riena.build.product-4.0.0.qualifier.zip is really not enough." (NOT :-) ) But maybe I am mistaken how the concrete filename would look like. What would the concrete .zip file look like based on the example I defined in comment 4 ?
(In reply to comment #8) > What would the concrete .zip file look like based on the example I defined in > comment 4 ? If your artifactId is org.eclipse.riena.repo and the unqualified version is 1.2.3.qualifier, and you use the default qualifier, the file would be called org.eclipse.riena.repo-1.2.3.201109021742.zip
(In reply to comment #9) > (In reply to comment #8) > > What would the concrete .zip file look like based on the example I defined in > > comment 4 ? > If your artifactId is org.eclipse.riena.repo and the unqualified version is > 1.2.3.qualifier, and you use the default qualifier, the file would be called > org.eclipse.riena.repo-1.2.3.201109021742.zip That would be certainly better than a static filename. But not really the common practice at eclipse.org. Look at the download page of Eclipse http://download.eclipse.org/eclipse/downloads/drops4/M20110831-2000/index.php. These are milestone downloads. The download zip is i.e. eclipse-SDK-M20110831-2000-win32.zip. We like to do the same thing. How could you create such a filename with Tycho ?
For this, it would be necessary to have a parameter in the tycho-p2-director-plugin which maps ws/os/arch triples to archive names in the target directory. In order to avoid name clashes, the archives should be each placed into a separate folder with ws/os/arch in the name. Would this be okay?
Why not just add the configuration parameter <finalName> known from the tycho-packaging-plugin? We are now mitigating this problem using the maven-assembly-plugin and just zip-up the entire ./target/repositoy again into another file named ${project.name}-${project.version}.zip
Created attachment 214007 [details] New parameter 'finalName' for the repo archive file name [PATCH] 347416 New parameter 'finalName' for the repo archive file name - Add the parameter finalName to the Mojo - Use finalName as file name for the repository archive - Tycho491PublishFeaturesAndCategoriesTest now expects the project version being part of the repository archive file name. - Added test case bug347416_testFinalNameForRepositoryArchiveFile with a custom finalName and asserts that check for the zip file being created having that name
And the legal stuff about the patch: - Did you author 100% of the content you are contributing? YES - Who owns the copyright of the contributed content? Me - Is the contributed code licensed under the EPL? YES - Do you have the right to contribute the content to Eclipse? YES
thanks for the patch and nice test case. Will apply soon.
stripped down test case https://git.eclipse.org/r/#/c/5593/
http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=320e624dfc14baad5e313e9194cfb5f274f42a30
Thanks for merging my patch!
