[Laszlo-dev] how does autoinclude work now?

[P T Withington]

I didn't mean to cast aspersions.

In the 1-3 era, there was a much larger team devoted to maintaining  
the components, including an 'editor' who could make judicious  
decisions about what should be auto-included.  The tool that Henry  
wrote was in response to many bug reports about components that were  
not auto-included, the diminished team (who were not able to explain  
the editorial choices), the addition of components by people who did  
not know of the existence of the auto-include mechanism, and, the lack  
of an editor to ask for guidance.

The tool can at least give a list of what you _might_ want to auto- 
include.  There still needs to be a human in the loop to make  
editorial decisions as to what _should_ actually be included.

We would be happy to accept input from the community on this task,  
especially yours.

On 2009-04-05, at 22:33EDT, Sarah Allen wrote:

> This file used to be maintained carefully by hand, with editorial  
> choices about what was auto-included (at least in the LPS v1.x-3  
> era).  Now it appears (based on Henry's synopsis) that there are  
> components included without much intention.
>
> I guess if I have new components, I run the tool, examine the diffs,  
> edit out anything I don't want and check it in?
>
> On Apr 5, 2009, at 12:04 PM, P T Withington wrote:
>
>> Executive summary:
>>
>> This file used to be maintained haphazardly by hand.
>>
>> We now have a tool that gives you a comprehensive list of candidate  
>> tags -> include mappings for you to examine.
>>
>> But you still have to maintain it by hand.  Please don't just check  
>> in the output of the tool.  The tool output is for your guidance  
>> only.  If it makes additions or deletions you cannot understand,  
>> please don't check them in.
>>
>> On 2009-04-05, at 14:12EDT, Henry Minsky wrote:
>>
>>> There's a script in build-tools/build-autoincludes.sh, that gets  
>>> called by
>>> the ant taskin lps/components, "ant autoincludes".
>>>
>>> It scans a list of every file in the lps/components directory,  
>>> except for a
>>> specific list of
>>> directories not to include
>>>
>>>
>>> (cd ${LPS_HOME}/lps/components; find . -name '*.lzx' -not -path
>>> '*/incubator/*' \
>>>                                    -not -path '*/queens-charts/*' \
>>>                                    -not -path '*/utils/performance/ 
>>> *' \
>>>                                    -not -path
>>> '*/utils/diagnostic/inspector/*' \
>>>                                    -not -path '*/debugger/*' \
>>>                                    -not -path '*/extensions/views/ 
>>> *' \
>>>                                    -not -path
>>> '*/extensions/av/videoslider.lzx' \
>>>                                    -not -path '*/rpc/ajax.lzx' \
>>>                                    -not -path '*/debugger/*' \
>>>                                    -not -path '*/lzunit/*' \
>>>                                    -print | \
>>> "${JAVA_HOME}/bin/java" ${JAVA_OPTS} -DLPS_HOME="${LPS_HOME}" -cp  
>>> "$LZCP"
>>> org.openlaszlo.utils.BuildAutoincludes "$@"
>>> )
>>>
>>> The tool itself scans a single .lzx file, looking for <class> and
>>> <interface> declarations, and adding anything
>>> that is declared.
>>>
>>> I think I need to  modify this tool to only scan files which are  
>>> <library>
>>> definitions, because there are
>>> a couple of <canvas> files in there getting scanned I think.
>>>
>>> Further, I think it is catching too much stuff this way, it might  
>>> be that we
>>> want to only have classes picked up which are preceded by some  
>>> special
>>> comment like <!-- autoincludes=true --> or something, to have more  
>>> control.
>>> For example, I think it may be a mistake to include all the  
>>> "base*" classes,
>>> since those would only be used by people who are building their own
>>> components, and thus would be expected to
>>> know which files need to be explicitly included to build their app/ 
>>> library.
>>>
>>> Currently, the build tool actually ignores any classes which start  
>>> with "_",
>>> assuming they are
>>> internal classes that don't want to be exposed, but I think we  
>>> really ought
>>> to be more explicit about
>>> what goes into the autoincludes file.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Apr 5, 2009 at 12:53 PM, Sarah Allen  
>>> <sarah at ultrasaurus.com> wrote:
>>>
>>>> Henry, or whoever knows,
>>>>
>>>> How does the auto-include mechanism work now?  (apologies if this  
>>>> is
>>>> documented somewhere, if so, just point me there).  For context,  
>>>> I'm working
>>>> to make the videoplayer more skinnable (using the scrollbar  
>>>> methodology
>>>> where there are some more granular classes you can put together  
>>>> differently
>>>> if you want).  Do I need to add these to a list somewhere?  and  
>>>> what part of
>>>> the build process re-generates the lzx-autoincludes.properties  
>>>> file?
>>>>
>>>> Thanks,
>>>> Sarah
>>>>
>>>
>>>
>>>
>>> -- 
>>> Henry Minsky
>>> Software Architect
>>> hminsky at laszlosystems.com
>>
>