Community
Participate
Working Groups
In order to support builds which can be used on multiple architectures, P2 needs to use a different profile name per architecture. Currently the Tycho director plugin uses the same profile name (DefaultProfile or as specified in the configuration) for all architectures. Being able to use different profile names - either by appending the architecture name (e.g. DefaultProfile-win32.win32.x86-64) or by allowing these to be configured on a per-architecture basis allows a single build to be created for multiple architectures, as per http://alblue.bandlem.com/2011/04/adventures-in-multi-architecture.html
This is an interesting suggestion, and I would like to have support for this in Tycho. However I wouldn't implement this around p2, but rather change/improve p2 where this is the right thing to do. For example I don't think that Tycho should rename the executables after the installation (step 3 in your blog), but instead the p2 publisher should already append the platform to the executable name. If you are willing to provide patches (preferably in TDD quality), I will review and apply them to Tycho and p2.
Fixing p2 director by allowing wildcards (ie not limited to single arch) would be a better fix since then you don't need to muck about with products, which are a hack on p2's inability to handle it. However I don't believe p2 is in a window where this is likely to happen any time soon.
p2 is an open source project, so anyone is free to contribute. If you provided a good patch for p2, I could apply it. However if you would wait for someone else to do it, I'd agree that this could take some time. Is there already an p2 bug for wilcard architectures?
I wonder if patch for bug 348428 solves this issue. If so, do we just need to consume p2 Juno M1 in tycho or is there more to be done?
(In reply to comment #4) > I wonder if patch for bug 348428 solves this issue. > If so, do we just need to consume p2 Juno M1 in tycho or is there more to be > done? I think this is only for products without environment-spcific bundles/fragments. These can be started on any platform, but certain configuration (like start levels etc.) would be disabled in all but one environment. The patch fixes this, but Tycho needs to be adapted so that it is possible to pass in the "ANY" parameter to the product publisher.
See /home/data/httpd/download.eclipse.org/webtools/incubator/repository/sieditor/snapshots/content.jar (Permission denied) And mistria@dev2:/home/data/httpd/download.eclipse.org/webtools/incubator/repository/sieditor/snapshots> ls -alld . drwxrwsr-x 2 dacarver webtools.incubator 4096 2011-08-10 10:21 . Than means that since the hudson user is not dacarver and not part of the webtools.incubator group, he cannot write into this folder. You have to give more permissions on this folder, by allowing anyone to write in it: chmod o+w /home/data/httpd/download.eclipse.org/webtools/incubator/repository/sieditor/snapshots
Please ignore my last comment, my mistake.
I really would like to see this happening. Today we have to manually copy the Deltapack into our products to have a multi-platform product. And I know other projects that do the same. I would also suggest as for an architecture keyword the "ALL" instead of the "ANY". Any to me means any architecture, or specifically no architecture at all, a complete platform independente set of artifacts. Whereas "ALL" means all the architectures.
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
