Community
Participate
Working Groups
The new development in Bug 431116 changed the way Tycho generates Mac OS X layout with Eclipse 4.5. However it looks like headless PDE build was not updated accordingly and now doesn't generate the Mac OS X package correctly. In particular PDE build produces OS X packages without the executable launcher. I don't get anything related to .app folder which was the case in Eclipse 4.4 and earlier. Here's the top level contents of the tar.gz file as it is produces now: configuration/ dropins/ features/ jre/ p2/ plugins/ .eclipseproduct about.html artifacts.xml WireframeSketcher.ini
(In reply to Peter Severin from comment #0) > The new development in Bug 431116 changed the way Tycho generates Mac OS X > layout with Eclipse 4.5. However it looks like headless PDE build was not > updated accordingly and now doesn't generate the Mac OS X package correctly. > In particular PDE build produces OS X packages without the executable > launcher. I don't get anything related to .app folder which was the case in > Eclipse 4.4 and earlier. Here's the top level contents of the tar.gz file as > it is produces now: > > configuration/ > dropins/ > features/ > jre/ > p2/ > plugins/ > .eclipseproduct > about.html > artifacts.xml > WireframeSketcher.ini I've the same problem with a regular PDE built for a complex RCP product. No executable launcher is exported on MacOSX Yosemite. A functional PDE built would be great for 4.5.
Peter, Marcel, do you use the delta pack when you are performing the export?
Peter, Marcel, when you do the export, if you specify <appName>.app as the export folder, does it help?
Another question, are you sure that your target platform is pointing to Mars RC2?
Created attachment 253721 [details] Delta pack fetch script
Pascal, yes I am using a delta pack. Since there is no delta pack supplied as of 4.5 I'm creating one myself from the p2 repository using the attached shell script. I don't think there is a way to specify <appName>.app output directory with the headless PDE build. I just launch the productBuild.xml via the antRunner with various settings supplied via properties and ant files and get the output for all configured platforms. The produced result is fine for Linux and Windows, but is incomplete for Mac OS X platform. I am not using the target platform settings, however I am sure I am using Mars RC2. My build is almost unchanged since Eclipse 3.6 and it was working correctly up to Eclipse Luna 4.4.
(In reply to Pascal Rapicault from comment #4) > Another question, are you sure that your target platform is pointing to Mars > RC2? I updated 4.5M7 to the latest updates which should be 4.5RC2. I don't use the delta pack. I have no target platform defined (regular PDE export). If I export my RCP product with the export folder defined 'My.app' then it doesn't create the 'Contents' folder in the 'My.app'. However if I define as an export folder 'My.app/Contents' (Root directory: 'My') then it creates a regular executable app application. Now if I try to execute 'My.app' a message with the warning 'The My.app executable launcher was unable to locate its companion shared library'
(In reply to Pascal Rapicault from comment #4) > Another question, are you sure that your target platform is pointing to Mars > RC2? Hello Pascal, I made some several attempts to export the application and finally was able to produce a decent running app. Instead of exporting the *.app under the name of 'My.app' I thought this could be a naming problem because all other settings were exactly like in the eclipse.app. So I exported 'My.app' under the name 'Eclipse.app' Export folder has to be: 'Eclipse.app/Contents' (Eclipse.app can be renamed later!) Root directory: 'Eclipse' So it seems to be that the launcher expects Eclipse as the application name and path?
I've had some progress by changing the build.properties file for headless PDE build in this way: # The prefix that will be used in the generated archive. archivePrefix=WireframeSketcher.app # The location underwhich all of the build output will be collected. collectingFolder=${archivePrefix} With this change the Mac OS X package is generated correctly. The downside is that all other configurations (gtk, win32) are also using .app folder at the top level. Perhaps there should be some dedicated configuration property for Mac OS X environment to fix this issue.
(In reply to Pascal Rapicault from comment #4) > Another question, are you sure that your target platform is pointing to Mars > RC2? Just one note. I wasn't able to use my bundled jre. Specified in the *.ini file the launcher requires a Java 6 runtime. Very strange. If I don't specify a JRE in the *.ini my app launches. However I need to use a bundled JRE. Any information how to use a bundled JRE is welcome.
OK. I found another Bug report for the bundled JRE problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=444201#c0
Peter/Marcel Can you give me detailed steps to recreate this one. If there is a non-headless way of recreating this (comment#8), can you attach a sample project that exhibits this behavior?
Created attachment 253838 [details] RCP project with headless build
I attached a sample project with headless build. You'll need to configure a target platform with delta pack before running the launch script. The result is linux/windows/macosx zips, all with acme.app folder at top level. There needs to be a way to use .app folder suffix for Mac OS X package only.
(In reply to Peter Severin from comment #14) > I attached a sample project with headless build. You'll need to configure a > target platform with delta pack before running the launch script. Can you provide the exact steps for that please.
http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Ftasks%2Fpde_product_build.htm&cp=47_2_0_0
Create a delta pack first using the attached script like so: ./fetch-delta-pack.sh http://download.eclipse.org/eclipse/updates/4.5milestones/S-4.5RC2a-201505222000 Or you can get my delta pack here: https://dl.dropboxusercontent.com/u/25239782/eclipse-4.5RC2a-delta-pack.zip Then extract this delta pack somewhere, say /tmp/delta-pack and then follow the steps described here to configure it: http://ugosan.org/eclipse-rcp-delta-pack/
Note that the build still produces a delta-pack, although it's not linked from the download page any more: http://download.eclipse.org/eclipse/downloads/drops4/S-4.5RC2a-201505222000/eclipse-4.5RC2a-delta-pack.zip
(In reply to Vikas Chandra from comment #12) > Peter/Marcel > > Can you give me detailed steps to recreate this one. > > > If there is a non-headless way of recreating this (comment#8), can you > attach a sample project that exhibits this behavior? Dear Vikas, I have no headless built just a regular PDE built from a RCP product export. As I already noted the export works fine if I define as an export folder in the PDE GUI 'My.app/Contents' (Root directory: 'Eclipse' - it is important not to change the name here!) then it creates a regular executable *.app application. It should be reproducable with the RCP Mail example. I'm now also able to bundle a JRE by setting the -vm switch in the *.ini file to -vm jre/lib/jli/libjli.dylib Location of the JVM in the app bundle: My.app/Contents/MacOS/jre I also tried some other locations which only worked if I copied a whole JDK folder structure. So this is by now the best recipe.
Created attachment 253933 [details] Comparison Now with the attached project export, I get with 4.5 RC2 macosx.cocoa.x86_64\Info.plist macosx.cocoa.x86_64\MacOS macosx.cocoa.x86_64\Resources macosx.cocoa.x86_64\MacOS\eclipse macosx.cocoa.x86_64\MacOS\workspace and dont get \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents\Info.plist \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents\MacOS \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents\Resources \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents\MacOS\eclipse \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents\MacOS\eclipse.ini \macosx.cocoa.x86_64\eclipse\Eclipse.app\Contents\MacOS\workspace
Come to think of it, this looks somewhat similar to testcase testBug192127 tracked by bug 462642
We will have to further investigate this for 4.5.1.
just one question guys, is there no way that i can create a macosx bundle with P2 with eclipse 4.5 (with the generated deltapack?) Can i patch something myself? Maybe some build files or property files? Or even patch some java code? Or is there already a build (where 4.5.1 will come from) that fixes these issues? Else we just need to go back and stay for quite a while on 4.4.2 in our release (and then it could take a while for use to really make the jump because we are doing a major release soon) Going to tycho is for use currently way to much work, the p2 is tiddly integrated into a large build that spits out all kinds of stuff.
This issue is happening because in BrandingIron::brandMac(ExecutablesDescriptor descriptor) File target = new File(root, applicationName + ".app/Contents"); //$NON-NLS-1$ is changed to File target = root; If the root doesnt have app/launcher.app folder then the app folder should be added. ( my guess) If I change the target to original value and disable ChmodAction ( ChmodAction is failing because of path mismatch), I am getting the expected result. Pascal, can you give a suggestion here. To recreate this 1) Take acme.zip ( RCP project with headless build ) 2) Set up delta pack in target 3) Open acme.product 4) Click "Eclipse Product export wizards" 5) Select option for "Select Export for Multiple Platforms" 6) Select MacOSX 7) Select Finish. The function brandMac is responsible for packaging the folders.
thx Vicas I patched the BrandingIron class (and also the 2 ChmodAction classes to not fail on a file that is not there) That does result in a tmp folder like this: tmp\servoy tmp\servoy.app (servoy is the launcher name and has the plugins) the servoy.app is has the Contents dir and there the MacOS and Resources dir so that looks good. Problem is i still have this: C:\Users\Administrator\dev_trunk\eclipse_build\build\forEclipse\package.org.eclipse.pde.build.container.feature.macosx.cocoa.x86_64.xml:92: The following error occurred while executing this line: C:\Users\Administrator\dev_trunk\eclipse_build\build\forEclipse\package.org.eclipse.pde.build.container.feature.macosx.cocoa.x86_64.xml:1741: C:\Users\Administrator\dev_trunk\eclipse_build\build\forEclipse\tmp\servoy\Contents\MacOS does not exist. because this generated package build file: <target name="assemble.archive" unless="skipDirector"> <antcall target="customAssembly"> <param name="rootFolder" value="${eclipse.base}/macosx.cocoa.x86_64/${collectingFolder}"/> <param name="customTarget" value="pre.archive"/> </antcall> <zip destfile="${archiveFullPath}" filesonly="false" whenempty="skip" update="true"> <zipfileset dir="${eclipse.base}" includes="**/**" excludes="launcher.exe,${launcherName},${launcherName},launcher.exe,${launcherName},Contents/MacOS/${launcherName}" prefix="${archivePrefix}" /> <zipfileset file="${eclipse.base}/${launcherName}" fullpath="${archivePrefix}/${launcherName}" filemode="755" /> <zipfileset file="${eclipse.base}/Contents/MacOS/${launcherName}" fullpath="${archivePrefix}/Contents/MacOS/${launcherName}" filemode="755" /> </zip> </target> Wants to still have 2 files i guess and put that also in I think it even wants to do the tmp/servoy as a file (which is a dir) I guess i need to track down where those ant files are really generated to get this working.
ok i patched BrandingIron even more, what i did was also making a copy of the servoy.app to just servoy so the Contents dir is now also inside the servoy dir where the plugins/features are, this way the package build script could find it. Problem is this generates something that doesn't start, and it really doesn't look like what a eclipse download looks like for the mac.
Hi Johan, The explanation in comment#24 is not a proposal for solution. We are awaiting a suggestion from Pascal.
we did get it now fully working With patches to BrandingIron to make sure all the files are in the correct places (for the build files, so also just copies to a "incorrect" place but the build file expects it to be there) And then having a script after that that completely reconstructs the directory structure that is generated (and setting the executable flag) Then it seems to work. By the way this is not just about the headless build. because also export product right from eclipse results for the mac in something which does not run.
Moving to 4.5.2
Moving to 4.6
The discussion on this bug has gone stale over the past six months. What is the likelihood that I will be able to build a functional Mac app bundle in Eclipse 4.6 this June? If the likelihood is low, what needs to be done to hit the 4.6 milestone? We use Eclipse the build four production RCP apps for Windows and Mac. I do not wish to appear off-putting, but, as you can imagine, fixing this regression is important to us.
it seems that pde build (that is also used through the UI of eclipse, like all the export commands you have there) is not a high prio anymore, many things don't work or don't work out of the box For example feature export of egit/jgit projects is also not working (cycle detected) or if i disabled some plugins then that works but then the problem about the eclipse.license feature is popping up (that i think can be solved by adding something to the target) You have to build through command line (maven). I see it more and more, i guess the best thing to do now is to just remove all the export commands from the IDE itself because they are not really maintained (by eclipse or by the plugin developers itself) anymore. I do find that weird, eclipse is a IDE (Integrated Development Environment) but suddenly we have to do all kinds of command line stuff with 3th party tools to build anything..
Pascal , can you look at comment#24 Can this change be done in equinox? >If the root doesnt have app/launcher.app folder then the app folder should be >added. ( my guess)
Is there any chance that a workaround could be found and described for the less technical of us? I have made ~100 users wait since last year for this fix, and the amount of disruption this delay creates is very large. I assume others may be in the situation of not being able to support Mac users and not having the resources to switch to another build process.
I thought that it will solved on Eclipse Mars 4.5.2, but not. Do you expect to solve it on Neon release?
On Windows, I am getting what I understand to be the equivalent problem with the PDE build with Eclipse Mars 4.5.2. It is not generating the exe and there are no errors in the logfile. Should this work on Windows (Windows 7 64-bit)?
(In reply to Johan Compagner from comment #28) > we did get it now fully working > With patches to BrandingIron to make sure all the files are in the correct > places (for the build files, so also just copies to a "incorrect" place but > the build file expects it to be there) > > And then having a script after that that completely reconstructs the > directory structure that is generated (and setting the executable flag) > > Then it seems to work. > > By the way this is not just about the headless build. because also export > product right from eclipse results for the mac in something which does not > run. Hi Johan, Would you be so kind as to attach your "working" solution to this issue to have at least some sort of workaround for this annoying issue? Thanks in advance
The following 4 bugzillas seem to relate to the same underlying problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=465602 p2 fails to resolve a target platform with Eclipse Mars artifacts on Mac OS X https://bugs.eclipse.org/bugs/show_bug.cgi?id=474494 Wrong directory structure for MacOS executables created https://bugs.eclipse.org/bugs/show_bug.cgi?id=483101 [macosx] Rcp product build fails with 4.5 https://bugs.eclipse.org/bugs/show_bug.cgi?id=468131 PDE headless build does not generate the Mac OS X package correctly
Moving to 4.7
It is frustrating to see that this issue, which was raised in May 2015, is being kicked down the road again into 2017--especially as it blocks the creation of a functional application bundle. If the PDE group is going to abandon this export/headless build feature, it would only be fair that the feature go through a formal deprecation process and official documentation on how to implement this part of the build process is provided. I am very grateful for the work and tools provided by the PDE group as well as the entire Eclipse team and community. Also, I do not want to denigrate your efforts. I honestly do not understand the current course of action because the expectations of the PDE group are not being communicated to the community.
I'm also still waiting on a clear resolution of this issue. WireframeSketcher is still based on Eclipse 4.4 and it looks like we'll have to wait for at least another year which is frustrating. I've experimented with Maven and Tycho and there are just too many issues with customizing the build. Tycho is just not very flexible as compared to PDE Build. It might be working well for producing Eclipse builds, but it doesn't seem to be suited for use cases where various custom build steps are required.
The reality is that this issue should be closed as wontfix. Basically PDE build has been dead for a number of years. Last year the change to the Mac layout got attempted, but the code was such (remember that PDE build is a generator of scripts for a complex fwk of existing ant scripts) that we could not get it to work w/o breaking other scenarios, and going over the monetary budget that was allotted to this. The way forward is Tycho. I was the maintainer of PDE build a long time ago, and I was the first to adopt Tycho on an official Eclipse project, and to promote the technology. I decided to promote tycho because it is technologically superior to PDE build. One of the main advantage is the ability to tap into the vast Maven ecosystem which greatly simplifies the integration with third party tools such as code coverage, quality analysis, etc.
(In reply to Pascal Rapicault from comment #42) > The reality is that this issue should be closed as wontfix. > Basically PDE build has been dead for a number of years. Last year the > change to the Mac layout got attempted, but the code was such (remember that > PDE build is a generator of scripts for a complex fwk of existing ant > scripts) that we could not get it to work w/o breaking other scenarios, and > going over the monetary budget that was allotted to this. > > The way forward is Tycho. I was the maintainer of PDE build a long time ago, > and I was the first to adopt Tycho on an official Eclipse project, and to > promote the technology. I decided to promote tycho because it is > technologically superior to PDE build. One of the main advantage is the > ability to tap into the vast Maven ecosystem which greatly simplifies the > integration with third party tools such as code coverage, quality analysis, > etc. And why not have all the possibilities to perform the builds? Sometimes is better to offer multiple ways to do them. I think that the Eclipse Framework is so extended in the community that you need to think about that.
(In reply to Marc Gil from comment #43) > (In reply to Pascal Rapicault from comment #42) > > The reality is that this issue should be closed as wontfix. > > Basically PDE build has been dead for a number of years. Last year the > > change to the Mac layout got attempted, but the code was such (remember that > > PDE build is a generator of scripts for a complex fwk of existing ant > > scripts) that we could not get it to work w/o breaking other scenarios, and > > going over the monetary budget that was allotted to this. > > > > The way forward is Tycho. I was the maintainer of PDE build a long time ago, > > and I was the first to adopt Tycho on an official Eclipse project, and to > > promote the technology. I decided to promote tycho because it is > > technologically superior to PDE build. One of the main advantage is the > > ability to tap into the vast Maven ecosystem which greatly simplifies the > > integration with third party tools such as code coverage, quality analysis, > > etc. > > And why not have all the possibilities to perform the builds? Sometimes is > better to offer multiple ways to do them. I think that the Eclipse Framework > is so extended in the community that you need to think about that. Eclipse (and other OSS projects) does not evolve like corporate-backed software trying to make a consistent offering. Sure Eclipse does try to offer something great, usable, etc. but it is important to recognize that Eclipse is the result of a number of contributors and companies with different agendas. For the case of PDE Build, the individuals and corporations moved on because it was good enough for their needs and nobody stepped up to improve it further. Meanwhile Tycho was developed by a completely different set of individual and corporations because they felt pain in PDE build that could never be addressed there. So of course it would be great if multiple possibilities were kept, but in the end it comes down to incentive, time and money.
(In reply to Pascal Rapicault from comment #44) > (In reply to Marc Gil from comment #43) > > (In reply to Pascal Rapicault from comment #42) > > > The reality is that this issue should be closed as wontfix. > > > Basically PDE build has been dead for a number of years. Last year the > > > change to the Mac layout got attempted, but the code was such (remember that > > > PDE build is a generator of scripts for a complex fwk of existing ant > > > scripts) that we could not get it to work w/o breaking other scenarios, and > > > going over the monetary budget that was allotted to this. > > > > > > The way forward is Tycho. I was the maintainer of PDE build a long time ago, > > > and I was the first to adopt Tycho on an official Eclipse project, and to > > > promote the technology. I decided to promote tycho because it is > > > technologically superior to PDE build. One of the main advantage is the > > > ability to tap into the vast Maven ecosystem which greatly simplifies the > > > integration with third party tools such as code coverage, quality analysis, > > > etc. > > > > And why not have all the possibilities to perform the builds? Sometimes is > > better to offer multiple ways to do them. I think that the Eclipse Framework > > is so extended in the community that you need to think about that. > > Eclipse (and other OSS projects) does not evolve like corporate-backed > software trying to make a consistent offering. Sure Eclipse does try to > offer something great, usable, etc. but it is important to recognize that > Eclipse is the result of a number of contributors and companies with > different agendas. > > For the case of PDE Build, the individuals and corporations moved on because > it was good enough for their needs and nobody stepped up to improve it > further. Meanwhile Tycho was developed by a completely different set of > individual and corporations because they felt pain in PDE build that could > never be addressed there. > > So of course it would be great if multiple possibilities were kept, but in > the end it comes down to incentive, time and money. I agree with you, Pascal.
We use Buckminster as our build system - as do quite a number of Eclipse projects (though not as many as use Tycho). Using Buckminster we cannot (in Eclipse 4.5) create our MacOS product, for the reason described in this bugzilla. I presume that is because, although we are using Buckminster, underneath it is using something from PDE build, which is currently broken. I understand the lack of interest in maintaining multiple build systems, but I think it needs to be pointed out that this problem in PDE Build affects more than just a few people using an obsolete tool (PDE Build); it affects people using Buckminster also. If this problem is not going to be fixed, then I think that needs to be made clear, so that those who need the ability to generate MacOS packages can migrate to whatever (presumably Tycho). Changing build systems takes time, since are typically a lot of bespoke scripts and workflow practices to change.
+1 on Matthews comment, we in the Java Mission Control team also (still) use Buckminster.
Created attachment 262823 [details] image showing the failure in 'the target editor' view
Created attachment 262824 [details] trivial test case (target file)
The issue is easily re-created also via the target editor. To re-produce (on a Mac - in my case El Capitan 10.11.5) follow these steps: NB: I am using Mars 4.5.2 to perform these steps. 1. download attached target. 2. open target in eclipse environment (assuming that you have plugin development tools). 3. See that eclipse attempts to resolve the target, but fails with the given error message. It is not possible to create a target that references 4.5.2 or 4.6.x platforms on MacOSZ at the moment - AT ALL. There have been conversations about PDE vs buckminster vs Tycho etc in various threads but they all seem to have missed the fundamental underlying issue. IT IS NOT POSSIBLE (unless someone can prove to me otherwise) to create a target for these platforms on a MAC - let alone get to a point where a build tool is involved. Can someone please look at this, reproduce and apply a fix somewhere. I have OSX users that can use software because their OS is too 'new', and need to update eclipse that i base our developed 'product' on to at least 4.6 to take advantage of the SWT fixes. ....... ..... totally stuck - someone please own this and drive through a fix asap !
(In reply to Peter Severin from comment #9) > I've had some progress by changing the build.properties file for headless > PDE build in this way: > > # The prefix that will be used in the generated archive. > archivePrefix=WireframeSketcher.app > > # The location underwhich all of the build output will be collected. > collectingFolder=${archivePrefix} > > With this change the Mac OS X package is generated correctly. The downside > is that all other configurations (gtk, win32) are also using .app folder at > the top level. Perhaps there should be some dedicated configuration property > for Mac OS X environment to fix this issue. hi Peter, Is this working for you. Can you please share your comments we are also having the same issue in MAC. Regards, Kavitha
Kavitha, I'm still using Eclipse 4.4 and have postponed the migration. It looks like Tycho build is the only way forward, but the migration effort is quite big in our case. The described solution was only a test and it doesn't resolve the issue.
This issue still exists in 4.7 Oxygen-Release. :-/ The folders still seems incorrect as described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=468131#c20
This issue still exists... Has someone an idea how two workaround this issue?
i think no body is really working on this anymore (the p2 stuff) So you need to use tycho.. Weird thing is that the eclipse ui still gives you options to export from the ui. And that is just broken, i think they should then just also remove it fully from the ui...
But we can not easyly switch to another build-process because our current software rollout still uses p2. According to the comments on this issue this seems to be a small change.
With this customAssembly.xml you can successfully run the p2 build with new eclipse-version https://github.com/ankane/carrot2-fork/blob/master/workbench/build-conf/customAssembly.xml This file must be copied into your builder dir. Not nice but seems to work...
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. If you have further information on the current state of the bug, please add it. 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.
>...that you still want the feature ... Yes, we still want the bug fixed. We've been working around it after the PDE build finishes by modifying the resulting broken application bundle.
Indeed - it would be really nice to have a working pde-build Since my link to the customAssembly.xml is broken here is my last version. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <project name="customAssembly.template" default="noDefault" xmlns:if="ant:if"> <!-- ===================================================================== The Following Properties are available in all targets: - eclipse.base : the base folder everything will be collected into - eclipse.plugins : the plugins folder - eclipse.features: the features folder - archiveFullPath : the full path of the final archive once it is created ===================================================================== --> <!-- ===================================================================== --> <!-- Called after each invocation of the gather.bin.parts target on the --> <!-- individual plugins and features. --> <!-- Available properties are: --> <!-- projectLocation: location of the project being gathered --> <!-- projectName: symbolic name with version (org.eclipse.foo_1.0.0.v123) --> <!-- target.folder: the destination, eclipse/plugins or eclipse/features --> <!-- --> <!-- The generated pattern is that plugins/features are gathered into the --> <!-- folder ${target.folder}/${projectName} --> <!-- ===================================================================== --> <target name="gather.bin.parts"> </target> <!-- ===================================================================== --> <!-- Called after invoking the gather.bin.parts targets for all plugins --> <!-- and features. Results exist as folders and have not yet been jarred. --> <!-- ===================================================================== --> <target name="post.gather.bin.parts"> </target> <!-- ===================================================================== --> <!-- Called just prior to signing a jar --> <!-- In addititon to the properties listed above: --> <!-- - source : plugins or features directory --> <!-- - elementName: element being signed without .jar --> <!-- (eg "org.eclipse.foo_1.0.0" --> <!-- ===================================================================== --> <target name="pre.jarSigning"> </target> <!-- ===================================================================== --> <!-- Called after all plugins and features have been jarred --> <!-- (and potentially signed) --> <!-- ===================================================================== --> <target name="post.jarUp"> </target> <!-- ===================================================================== --> <!-- Called just before the archive file is built --> <!-- In addititon to the properties listed above: --> <!-- - rootFolder : the folder containing the root files --> <!-- ===================================================================== --> <target name="pre.archive"> <!-- hotfix PDE Build problems --> <antcall target="fix.mac.client"/> </target> <target name="test.if.is.mac.client"> <condition property="is.mac.client"> <available file="${rootFolder}/MacOS" type="dir" /> </condition> </target> <target name="fix.mac.client" depends="test.if.is.mac.client" if="${is.mac.client}"> <echo message="fixing pde-build problems for macos..."/> <!-- zipfileset references this path and fails the build if not present. --> <mkdir dir="${rootFolder}/Contents/MacOS" /> <!-- Move broken paths around. --> <move todir="${rootFolder}/${launcherName}.app/Contents"> <fileset dir="${rootFolder}"> <include name="MacOS/**" /> <include name="Resources/**" /> <include name="Info.plist" /> </fileset> </move> </target> <!-- ===================================================================== --> <!-- Default target --> <!-- ===================================================================== --> <target name="noDefault"> <echo message="You must specify a target when invoking this file" /> </target> </project>
Anyone on Mac OS can try to fix and give a patch.
