Ok.  approach makes sense.  This may also be a good candidate for "advice" 
to the generator.  The info is in effect advice but we need ways of 
letting users give such input more easily.  That is essentially why I was 
pushing on moving this stuff out of the generator.  Things like the names 
and locations of the executables should come from outside.

Jeff




John Arthorne/Ottawa/[EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
10/23/2007 07:53 PM
Please respond to
Equinox development mailing list <equinox-dev@eclipse.org>


To
Equinox development mailing list <equinox-dev@eclipse.org>
cc

Subject
Re: [equinox-dev] [prov] generator changes







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

_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to