[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?