Re: Localize taskdef shouldn't compile

Hi Shawn,

Does it make sense to continue to have the "destdir" attribute on 
<localize> if it isn't going to be used since the compilation step isn't 
happening?  Locally, I removed it and it didn't seem to bother the build.

Also, the events taskdef has the same issue.  It invokes the compiler where 
all it should do, if it is to be consistent with the localize taskdef, is 
generate the source and let the javac taskdef do the work of 
compilation.  Want to make that change as well?

Also, not need to define a separate <javac> after the <localize>.  Here is 
an example of what I did locally to the <javac> task in Diez' contrib 
build.xml...

         <javac
             srcdir="${src.home}:${src.generated.home}/src_xmlc"
             destdir="${build.home}/WEB-INF/classes"
             includes="**/*.java"
             excludes="**/old**/**"
             debug="${build.debug}"
             deprecation="${build.deprecation}"
             optimize="${build.optimize}"
             verbose="${build.verbose}">
             <classpath refid="build.classpath" />
         </javac>

Notice that I just used colon-separated paths in the "srcdir" attribute to 
allow for compilation of multiple source directories.  You can also use 
separate nested <src> (or is it <srcdir>?) tags.

I also moved the fileset for copying of .xmlc files to the <copy> task that 
was already in the compile target....

             <!-- copy the xmlc files -->
             <fileset dir="${src.generated.home}/src_xmlc">
                 <include name="**/*.xmlc"/>
             </fileset>


Actually, I just checked these changes in only on Diez' build so you can 
take a look at it.  I think it is a bit more succinct.  When the events 
taskdef is modified to not compile, the same thing as above can be done for 
compiling event classes.

Jake

At 01:20 PM 9/8/2003 -0600, you wrote:
>Okay I have committed my changes and modified all affected build.xml files 
>accordingly. The changes to build.xml simply involved adding a <javac> 
>call right after <localize> and removing the "classpathref" attribute from 
><localize> calls.
>
> > Wouldn't it be even better to introduce a "nocompile" (default false)
> > option to the Localize taskdef? If set to true, it skips the javac call.
> > This way we would not break any existing code and keep backward
> > compatibility.
>
>Sorry Stefan I didn't see your email until after I had already committed 
>changes. Of course, if you think this is a sticking point I could go ahead 
>and introduce a "nocompile" option. However, the Xmlc taskdef that 
>Localize extends from already provides a do/don't compile switch, which 
>would have different meaning than this one would. Basically, I don't think 
>the compiling should have ever been in Localize so my gut feeling is to 
>just remove it all-together.
>
>-shawn
>
>Stefan Armbruster wrote:
>>In prinicple +1.
>>Wouldn't it be even better to introduce a "nocompile" (default false)
>>option to the Localize taskdef? If set to true, it skips the javac call.
>>This way we would not break any existing code and keep backward
>>compatibility.
>>Stefan
>>Am Mon, 2003-09-08 um 19.04 schrieb Shawn Wilson:
>>
>>>I would like to make a change to the Barracuda Localize taskdef 
>>>(org.enhydra.barracuda.taskdefs.Localize) that could affect any users 
>>>who might be using it in their build.xml files.
>>>
>>>Basically I'd like to remove the lines that invoke the Javac compiler, 
>>>for a few reasons:
>>>
>>>    1. Localize extends Xmlc taskdef which already provides an option to 
>>> compile classes (though it is noted it should normally not be used).
>>>    2. There is no way to tell Localize NOT to compile classes.
>>>    3. There is no way to pass options to the compiler that Localize 
>>> uses (or to use a different compiler).
>>>    4. There already exists the fully-functional <javac> taskdef as part 
>>> of the core Ant distribution that alleviates problems 2 and 3 above.
>>>
>>>Rather than Localize trying to do everything I think we should limit it 
>>>to just taking care of localization and XMLC processing and leave the 
>>>compiling to a separate <javac> task in the build.xml.
>>>
>>>As long as everyone is okay with this, I can make the necessary changes 
>>>to Localize.java and the Barracuda and BarracudaDiscRack build.xml files.
>>>
>>>Thanks,
>>>-shawn
>>>
>>>_______________________________________________
>>>Barracuda mailing list
>>>[email protected]
>>>http://barracudamvc.org/lists/listinfo/barracuda
>>
>>_______________________________________________
>>Barracuda mailing list
>>[email protected]
>>http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda