Re: Localize taskdef shouldn't compile

Jake, I thought the same thing but a quick search in Localize.java shows 
that the destdir is being used for something else in addition to the 
javac target. I think it was some sort of out-of-date check?

Anyways, since I wasn't completely sure how it was used for what the 
ramifications were I just left it in. Christian: do you have any more 
insight on this?

Thanks,
-shawn

Jacob Kjome wrote:

> 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
> 
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda