The use case I added support for was generating IUs for all platform launchers when generating against an Eclipse install that contains the delta pack. It does consult IGeneratorInfo to get the location of the org.eclipse.equinox.executable feature where the launchers live, but from that point it makes assumptions about the shape of the executable feature. It does this to figure out the os/ws/arch values and to figure out the native touchpoint instructions (zip and chmod) so that the resulting install will have the right shape.
Overall, it feels quite brittle to be reverse-engineering the launcher configuration units based on the delta pack structure produced by PDE build. There are subtle details such as which files need the execute bit set, etc. I was thinking this will be a good candidate for hand-crafting metadata once we have a stable metadata file format. The launcher metadata could be authored at develop time, and checked into CVS alongside the actual launcher files. Jeff McAffer/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 02:44 PM Please respond to Equinox development mailing list <equinox-dev@eclipse.org> To equinox-dev@eclipse.org cc Subject [equinox-dev] [prov] generator changes I noticed a few changes around the generator that seem to embed knowledge of the launcher etc in the generator itself. would it be reasonable to separate these out and put that stuff into the GeneratorInfo? The idea of the design is that the generator itself is reasonably generic and the infos fill in the details for particular scenarios. Currently we only have on info class but thta is more of a current state than anything. Thoughts? Jeff _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
