Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 412709

Summary: remove or improve cp-content.xsl from "repository building"
Product: [Eclipse Project] Platform Reporter: David Williams <david_williams>
Component: RelengAssignee: Platform-Releng-Inbox <platform-releng-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P2 CC: akurtakov, Lars.Vogel, pwebster
Version: 4.3   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard: stalebug
Bug Depends on:    
Bug Blocks: 485646    

Description David Williams CLA 2013-07-10 16:36:48 EDT
Currently there is a cp-content.xsl in 
eclipse.platform.releng.aggregator/eclipse.platform.repository/
and invoked in the pom.xml there. This was to "massage" "executables metadata" if I recall. 

But I think that was just a "first attempt" and that the final solution to this issue was put in 

/rt.equinox.framework/features/org.eclipse.equinox.executable.feature/cp-content.xsl

As far as I know, we don't need both?
Comment 1 David Williams CLA 2013-07-10 16:38:39 EDT
Paul, you may know answer off the top of your head. 

If I get bored, I might experiment in a test branch ... but if you read this before I get bored, please comment if both really (still) needed. 

Thanks,
Comment 2 Paul Webster CLA 2013-07-16 11:01:22 EDT
AFAIK we need the one in eclipse.platform.repository.

The one in rt.equinox.framework/features/org.eclipse.equinox.executable.feature fixes the target/p2-artifacts.xml and p2-content.xml files.  Ideally that should be enough, but even though the changes were done early they weren't picked up by the eclipse-repository pom.

We could in theory remove the org.eclipse.equinox.executable.feature  one (and the pom.xml file entry)  we just need to remember that the feature isn't quite right and the full fix is in the repository.

PW
Comment 3 David Williams CLA 2016-04-17 00:12:20 EDT
Added 'improve' to the title just to reflect that I am not sure it can completely be removed. But, A) doesn't seem we should have to do it twice (perhaps the low-level one just needs an "attach metadata" as we do for source features?) and/or B) perhaps it should be it's own "build step". The problem with the current method, in 'eclipse.platform.repository' is that we are "hacking into" Tycho's normal build steps and phases and changing content that Tycho thinks is "done". If we had created it earlier, in its own build step, it would be closer to the normal flow of a Tycho/Maven build. 

Our workaround "bit us" when moving to Tycho 0.25.0, because as part of our "special processing" we remove the content.jar that Tycho created, massage the content.xml file with XSL, and then later jar it back up. But in 0.25.0 Tycho added the automatic creation of "content.xml.xz" as well as the jar, plus even adds a p2.index file. As a result, the "custom" equinox.executable was not in the "final repository" because it was not in the "content.xml.xz" file, so overall that repository creation failed. (We do a lot, in that one step!) 

Luckily, removing the content.xml.xz file, as well as the content.jar, allows us to continue to use the workaround.
Comment 4 David Williams CLA 2016-04-17 02:40:35 EDT
See also bug 406368 for more information about these two nearly identical (but not identical) features.
Comment 5 Eclipse Genie CLA 2020-04-27 16:30:20 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.