Thanks for the overview. From the user's perspective, this solution is a step in the right direction.
its missing some syntax highlighting (show 'hidden' lines in a 'disabled' color and also make correct syntactic analysis, IE, not to show syntax errors for: //#ifdef FOO class Bar extends Baz #elseif class Bar extends Zab #endif but I am sure you are aware of this issue. BTW: I think this functionality might be added via the mechanism that allow eclipse to support multiple variants of the Java (1.3 vs 1.4 vs 1.5 etc), although I am not sure how simple/hard it will be because those probably comes with AST of the java structure, and not lines-based (like a preprocessor). from the technical point of view, I like it better than the multiple projects, because its transparent to the user - although its a hack that might blow up under some conditions (can't think of anything specific atm). hopefully eclipse will introduce real support for preprocessing some time soon and we will be able to dump this :). The advantage of the in-place code rewrite is that its gives better user experience in the two aspects I mentioned before (syntax highlighting and analysis), but once you got those two covered your solution will be superior - so I am glad you are pushing in that direction. Craig Setera wrote: > Omry, > > I should probably write this up more formally, but right now I don't > have the time to do that. Here is a quick high-level on what is going > on... The primary goals of the EclipseME implementation are to 1) Make > things work as "Eclipse-like" as possible and 2) Not rewrite (in place) > the user's source code. My first pass at handling this used a > secondary EclipseME project into which the source was processed and then > compiled back into the primary project. Ugly, but semi-effective. > > The new implementation takes advantage of the Eclipse OSGi framework > hooks feature (see http://wiki.eclipse.org/index.php/Adaptor_Hooks for > full details). The basic idea is to use the hooks to rewrite the JDT > SourceFile class to look for preprocessed sources rather than the user's > original sources. This is my way of handling my needs as documented in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=116143 The flow goes > something like this: > > * During Eclipse startup, the eclipseme.core.hooks bundle is started as > a framework hook configurator. It installs three hooks: > ** A classloader hook that rewrites the bytecode of the JDT Sourcefile > class to look for SourceMapper registrations. > ** A classloader hook that rewrites the bytecode of EclipseME's > SourceMapperAccess class to make it clear to callers that the hooks have > been correctly installed. > ** A class loader creation hook that adds a new "wire" from the JDT > bundle to the eclipseme.core.hooks bundle, so that the rewritten JDT > Sourcefile class can find the classes in the rewritten code. > > * When the user makes a source change in the project: > ** The preprocessor runs and writes out a processed source file to the > processed subdirectory in the project > ** The JDT compiler runs and requests the resource to be compiled via > the JDT Sourcefile class > ** The (rewritten) JDT Sourcefile class checks with the registered > SourceMapper (if any) to get the mapped resource or returns the user's > source. > ** The source file is compiled and then the preverifier runs against the > compiled class. > > In a nutshell, that is what is going on. Obviously, this whole thing is > somewhat tricky. On the other hand, as long as the JDT Sourcefile class > continues to implement the #getResource method as it does now, this > implementation will continue to work and provides a nice user workflow > once the initial installation is completed. > > Craig > > Omry Yadan wrote: > >> Hi Craig, >> >> can you please describe what you are currently doing on the technical >> level with the new preprocessor support? >> >> I saw that you use a preprocessor builder, and I also saw that you >> magically patch the eclipse platform at runtime for some reason. >> >> I saw the SourceMapper in your hooks project, but no one seems to call >> SourceMapperAccess.getMappedSourceFile from anywhere (that I saw). >> Can you explain whats happening there at the moment? >> >> thanks. >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Eclipseme-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/eclipseme-users >> >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Eclipseme-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/eclipseme-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Eclipseme-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/eclipseme-users
