Re: Localize taskdef shouldn't compile

Jake,

 > Yes, I'd definitely like to hear Christian's opinion on this.  Also, you
 > didn't address my comment about removing compilation from the events
 > taskdef.  That would bring it in-line with the changes to the localize
 > taskdef.  What do you think about that?

Sorry about missing the second part of your email, I think I just 
completely read over it :). Anyways, you are right that the compilation 
should probably be taken out of the events taskdef as well. I will work 
on getting that change implemented today.

Thanks,
-shawn

Jacob Kjome wrote:

> At 03:11 PM 9/8/2003 -0600, you wrote:
> 
>> 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?
> 
> 
> Yes, I'd definitely like to hear Christian's opinion on this.  Also, you 
> didn't address my comment about removing compilation from the events 
> taskdef.  That would bring it in-line with the changes to the localize 
> taskdef.  What do you think about that?
> 
> Jake
> 
>> 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
>>
>>
>> _______________________________________________
>> Barracuda mailing list
>> [email protected]
>> http://barracudamvc.org/lists/listinfo/barracuda
> 
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda