[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.jdt] Re: Changing Java source in a builder; which mechanism?

"Brad Jarvinen" <Brad.Jarvinen@xxxxxxxxxxxxx> wrote in message 
news:fcu8gl$qet$2@xxxxxxxxxxxxxxxxxxxx
>I have a builder, MyBuilder, that is meant to add a method to Java source 
>files automatically.

Perhaps I'm misunderstanding the use case you have in mind.  But I really 
want to discourage you from doing anything that modifies your source code 
during a build - I think you will find that you will put a lot of work into 
it, only to be disappointed in the end results.  I think you will probably 
be a lot happier if you implement your operation as a wizard, a refactoring 
operation, a quick fix, etc. rather than as a Builder.

The idea of a Builder is that it starts with some source code and produces 
some output.  Builders that modify the same resources they're trying to 
build are ugly.  I'm not saying you'll never get it to work, but I suspect 
it'll always be fragile.  For example, it's going to be a problem when the 
source code being modified is under version control.

And anyway, since obviously if you're modifying the source code you have to 
have a sort of "only do this the first time" logic in order to avoid an 
endless loop of rebuilding, then why not make it a user-initiated action 
anyway?  I can sure tell you that, as a Java developer, if I did a build and 
it caused my source code to change, I'd be very upset.  Life is hard enough 
without something else trying to edit my source code from under me.

You could in principle use a Builder to modify the source code and place it 
into an intermediate location, from which the Java Builder would then 
compile it.  But that would make the debugger's life rather more difficult. 
Perhaps you don't recall what it was like to work with the early C++ 
preprocessors that worked essentially that way; I do, and it was ugly.

If all the above is missing the point, can you comment more on your use 
case?