Community
Participate
Working Groups
Please add support for building with license features, based on the support that was introduced in PDE and p2 in Indigo M4. This would be especially useful given that we need to make (many) changes to incorporate the latest Eclipse SLA. See http://relengofthenerds.blogspot.com/2011/01/implementing-shared-licenses-with-37m5.html (for example) for more information.
Hi Bucky Team, Any plan to deal with this ? Best Regards, Adolfo.
Indeed. It is already partially supported in 3.7 in that the declaration is recognized as a dependency. More to follow...
Full build support has been added and released to trunk, rev 11755.
Thomas, I've not migrated my Eclipse MDT/OCL hudson job to use buckminster 3.7 yet. With this enhancement it's definitely a good reason to do it. Could you touch me as soon as this buckminster version is available in Eclipse Hudson server ?. I'm not sure if there is a formal way to do such updates in Eclipse Hudson server... and of course a wayto be informed about them. Cheers, Adolfo.
Thanks, Thomas. Unfortunately, without support for rootfiles being shared via the common license feature, this is only a partial solution (since every feature's copy of notice.html would need to be updated each time the SUA changes). Could you please add support for sharing rootfiles via the common license feature? The idea would be for the 'rootfiles' folder and reference to it (i.e., "root=rootfiles" in the build.properties file) to be located in the license feature and for these to be merged with the destination feature along with the license properties and files (as already implemented).
I'm trying to make sense of the concept of every feature having similar "rootfiles". What happens when you install those features? Which features rootfiles will take precedence? Seems to me like the whole concept of having every feature containing roots with the same name is a certain recipe for conflicts. What happens the day a third party feature uses the same concept? Wouldn't that simply overwrite your root files (or vice versa depending on installation order)? I've learned to use rootfiles for products or for features that make very special contributions (like the Eclipse launcher). Consequently we have rootfiles in our headless product. But we don't have them in any other place. This doesn't mean that our other features lack license information. Each feature is expanded into a 'features' subfolder and the license, copyright, etc. is right there.
(In reply to comment #6) > I'm trying to make sense of the concept of every feature having similar > "rootfiles". What happens when you install those features? Which features > rootfiles will take precedence? I'm not suggesting that every feature necessarily have rootfiles that are similar or the same. Rather, I'd like to rootfiles contributed by the license feature be copied over. Perhaps it makes more sense to retain the root=rootfiles declaration in each of the individual features and simple copy the license files over. > Seems to me like the whole concept of having every feature containing roots > with the same name is a certain recipe for conflicts. What happens the day a > third party feature uses the same concept? Wouldn't that simply overwrite your > root files (or vice versa depending on installation order)? I agree. I'd like to view the rootfiles in the license feature as a _contribution_ to the root files for a given feature, not its complete definition. > I've learned to use rootfiles for products or for features that make very > special contributions (like the Eclipse launcher). Consequently we have > rootfiles in our headless product. But we don't have them in any other place. > This doesn't mean that our other features lack license information. Each > feature is expanded into a 'features' subfolder and the license, copyright, > etc. is right there. Every download at Eclipse is required to have license artifacts at its root location, and this is what the rootfiles I refer to above are used for in my case(in the EMF build). If you can suggest another way of adhering to this requirement (other than not shipping downloads), please do.
(In reply to comment #7) > (In reply to comment #6) > > I'm trying to make sense of the concept of every feature having similar > > "rootfiles". What happens when you install those features? Which features > > rootfiles will take precedence? > > I'm not suggesting that every feature necessarily have rootfiles that are > similar or the same. Rather, I'd like to rootfiles contributed by the license > feature be copied over. The license feature is just a template extending the features that use it so the end result is the same. > > Seems to me like the whole concept of having every feature containing roots > > with the same name is a certain recipe for conflicts. What happens the day a > > third party feature uses the same concept? Wouldn't that simply overwrite your > > root files (or vice versa depending on installation order)? > > I agree. I'd like to view the rootfiles in the license feature as a > _contribution_ to the root files for a given feature, not its complete > definition. > I don't see how that changes anything. You still end up with lots of features that has the same rootfiles and thus, overwrite each others contribution when they are installed. > > I've learned to use rootfiles for products or for features that make very > > special contributions (like the Eclipse launcher). Consequently we have > > rootfiles in our headless product. But we don't have them in any other place. > > This doesn't mean that our other features lack license information. Each > > feature is expanded into a 'features' subfolder and the license, copyright, > > etc. is right there. > > Every download at Eclipse is required to have license artifacts at its root > location, and this is what the rootfiles I refer to above are used for in my > case(in the EMF build). If you can suggest another way of adhering to this > requirement (other than not shipping downloads), please do. Several files can be shipped. So let's take them one by one: 1. All feature jars has the license at the root, as contributed by bin.includes, so AFAICT they are in the clear. 2. A product that has been installed and then zipped up will also have the license at its root (contributed by root files in product feature or branding plug-in) so that's in the clear too. 3. A zipped repository containing the feature will yield either #1 or #2 when things are installed from it. The zip doesn't have licenses at the root but the p2 publisher doesn't place root files at the root of a repository anyway so what's suggested here won't help. What is missing? I hope you don't suggest that every feature should be delivered in a zip form to be sprayed over an existing installation using unzip? That's an absolute no-no nowadays (and has been since p2 entered the scene). Pascal and Ian Bull list it as one of the top ten pitfalls: http://eclipsesource.com/blogs/2011/03/23/p2-10-common-pitfalls-and-how-to-avoid-them/ The paragraph to pay attention to here is on slide 5 and reads: "Do you instruct your users to unzip over eclipse? We don't like you! (And we will sabotage your wiki page :-) )" You may still want to encourage your users to do that, but I have a moral problem providing support for it ;-). Please continue to slide 6...
(In reply to comment #8) The more I learn about it, the more I think that use of rootfiles isn't an ideal approach for getting license files into the root of download archives (i.e., for case #2). I'm not suggesting that every feature be delivered in a ZIP... Instead of adding support for rootfiles in license features, I'll pursue the avenue of changing the way ZIP files are produced by the EMF build so that it pulls root files from the license features directly.
One thing that would be interesting is making the publisher aware of the shared license so that it could pull the license files and put them adjacent to the content.jar/artifacts.jar when a repository is produced. That way, a zipped repository would contain the license files at the root of the zip as well as inside the meta-data and inside each artifact. Personally I recent the redundancy but what more could a lawyer want?
