On Wed, Nov 26, 2008 at 7:51 AM, Andrew Moore
<[EMAIL PROTECTED]> wrote:
>
> That would be great... from an engineering perspective I agree. It would be
> very
> simple to filter a property file.
>
> But in business everything doesn't always make engineering sense.
>
> Our business has political reasons (that are out of my control as an
> engineer)
> for having this information substituted into and compiled from a source
> file.
>
> The best solution I've come up with so far is create a temporary copy of the
> original
> source file, filter that copy, copy the filtered version over the location
> of the
> original source, and finally restore the original after the compilation is
> complete.
Try this instead. Decide on a directory to store post-processed
sources: source code with the modification, and create a task that
will copy the files over, in doing so change the file that needs
changing. Use a Filter for that, it will help in only copying files
that changed.
You can then tell the compile task to use that source directory
instead of the original sources. Because the compile task has a
dependency on the new directory, it will run that task -- creating the
new source code -- before compiling.
>
>
>
> In trying this approach, I am running into an issue.
>
> I need to perform my filter before I build my sub-project, but restore it
> right after
> the build task is done.
>
> From the documentation it looks like I can set a variable to a task and call
> build on the
> variable to run the task before the build task. To run code after the build
> I simply
> define a build block... so I essentially have this:
>
>
> define 'root' do
>
> define 'othersubproject1' do
> end
>
>
> define 'subproject' do
>
> pre_build_task = task do
> puts "this should print BEFORE compiling"
> # filtering of source file happens here
> end
>
> # this should run pre-build
> build pre_build_task
>
> # this should run post-build
> build do
> puts "this should print AFTER compiling"
> # restoration of source file happens here
> end
>
> end
>
>
> define 'othersubproject2' do
> end
>
> end
>
>
>
> I don't know if this is a buildr bug or not, but if I run the following in
> my subproject:
>
> $ cd root/subproject
> $ buildr clean build package
>
> the output and order of things is like this:
>
> Cleaning root:subproject
> Building root:subproject
> this should print BEFORE compiling
> Compiling root:subproject into
> <dir-to-project>/root/subproject/target/classes
> Compiling root:subproject into
> <dir-to-project>/root/subproject/target/test/classes
> Skipping tests for root:subproject
> this should print AFTER compiling
> Packaging root:subproject
>
>
> And it works that way! I can see the source file get filtered, compiled,
> then reverted.
> However... when I run from the root of my project:
>
> $ cd root/
> $ buildr clean build package
>
> the output and order of things is like the following:
>
> Cleaning root
> Building root
> Compiling root:othersubproject1 into
> <dir-to-project>/root/othersubproject1/target/classes
> Skipping tests for root:othersubproject1
> Compiling root:subproject into
> <dir-to-project>/root/subproject/target/classes
> this should print BEFORE compiling
> Compiling root:subproject:test
> <dir-to-project>/root/subproject/target/test/classes
> Skipping tests for root:subproject
> this should print AFTER compiling
> Compiling root:othersubproject2 into
> <dir-to-project>/root/othersubproject2/target/classes
> Skipping tests for root:othersubproject2
> Skipping tests for root
> Packaging root
>
>
> When building the root project (or from the root project) the task I'm
> wanting to have happen before
> the root:subproject gets compiled doesn't happen... it happens after
> compiling instead.
>
> Is this a bug? Am I doing something wrong here?
As you can see if happens during the build, but in your case you want
to be more specific around the compile task:
compile.enhance [pre_build_task] do
puts "this should print AFTER compiling"
# restoration of source file happens here
end
Assaf
>
> Thanks for your help!
>
> ~ Andrew Moore
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Nov 25, 2008, at 5:30 PM, Alexis Midon wrote:
>
>> First, why about externalizing these values in a property file and making
>> your java class reads this file. So you don't have to worry about
>> overwriting the java class.
>>
>> Then in the buildfile you create a rake task that dumps the property file
>> every time you package for instance.
>>
>> something like:
>>
>> desc "my killer app"
>> define "app" do
>> package(:jar).enhance do |task|
>> File.open(path_to(:target,:classes,"build.properties"), 'w') do |io|
>> io.puts "build.version=#{project.version}"
>> end
>> end
>> end
>>
>>
>> Alexis
>>
>>
>> On Tue, Nov 25, 2008 at 1:05 PM, rp.andrew.moore
>> <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> We want to compile our version, build, time of compilation, location of
>>> compilation, and other information into a java class that our web app
>>> references (this way we can check the info online while it's running, and
>>> know that it can't be inadvertantly changed in properties, xml or
>>> manifest
>>> file)
>>>
>>> How do I do that before building it?
>>>
>>> For example, our java file has pretty simple variables where the filter
>>> needs to be applied:
>>>
>>> from the myproject/src/main/java/com/example/info/Info.java file:
>>>
>>> private static final String APPLICATION_VERSION = "${APP_VERSION}"; //
>>> Substituted by the build
>>> private static final String BUILD_NUMBER = "${BUILD_NUMBER}"; //
>>> Substituted by the build
>>> private static final String BUILD_TIMESTAMP = "${BUILD_TIMESTAMP}"; //
>>> Substituted by the build
>>>
>>>
>>> How do I apply a filter so that when I build "myproject", the values are
>>> updated prior to compilation, yet the original java file isn't written
>>> over
>>> so that I can repeat it over and over again?
>>>
>>> Thanks!
>>>
>>> ~ Andrew
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>>> http://n2.nabble.com/How-do-I-repeatably-filter-a-java-file-before-it-is-compiled--tp1578216p1578216.html
>>> Sent from the Apache Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>
>
