This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
ideas:lara:api_in_folder [2022/01/17 15:16] jbispo |
ideas:lara:api_in_folder [2022/01/17 16:55] (current) jbispo |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== LARA: APIs in Folder ====== | ====== LARA: APIs in Folder ====== | ||
- | Transformar LARA API resources | + | ===== Intro ===== |
+ | |||
+ | A ideia é adicionar nova forma de distribuir APIs. | ||
+ | |||
+ | Atualmente APIs são resources | ||
+ | |||
+ | Dois caminhos possíveis: | ||
+ | |||
+ | - Manter as APIs como resources, e extraí-las para uma pasta predefinida algures | ||
+ | - Mecanismo adicional não baseado em resources mas em pastas | ||
+ | |||
+ | Em qualquer dos casos, é preciso manter suporte para APIs como resources. Mesmo que se mude o Clava para usar pastas, outros weavers estão a usar APIs como resources para distribuir/ | ||
+ | |||
+ | Durante a instalação ou execução as APIs são extraídas para uma subpasta predefinida onde o JAR está localizado. A questão é quando/como extrair, e que mecanismo usar para manter uma espécie de cache, para minimizar as vezes que as resources | ||
+ | |||
+ | * Em relação | ||
+ | * Um método mais robusto será durante a execução do weaver criar esta pasta caso ela não exista. Assume-se que o JAR existe, e que tem um build number que nos permite saber se é preciso apagar a pasta e extrair de novo. | ||
+ | |||
+ | Considerando o segundo método, isto implica que será mais simples | ||
+ | |||
+ | |||
+ | ===== Ambiente de Desenvolvimento ===== | ||
+ | |||
+ | Qualquer uma das abordagens introduz problemas relacionados com o ambiente de desenvolvimento de weavers. Neste momento, quando de desenvolve um weaver, pode-se mudar diretamente os ficheiros .lara/.js, sendo resources são atualizados automaticamente, | ||
+ | |||
+ | Ao passarem para uma pasta, sempre que uma execução de teste é feita, é preciso copiar estas APIs para uma pasta, para se manterem atualizadas. Além disso, se alterarmos as APIs na pasta onde estão a ser lidas, essa pasta poderá não corresponder à pasta original, então vamos estar a modificar ficheiros temporários, | ||
+ | |||
+ | Uma solução é adicionar suporte aos weavers de especificarem um conjunto de pastas, onde estão os ficheiros originais. Estas pastas podem estar distribuídas por vários projectos, como já acontece com as APIs como resources. | ||
+ | |||
+ | Pode ser criada uma interface que resolve para uma ou mais pastas (e.g. FolderProvider/ | ||
+ | |||
+ | No entanto, parece haver dois sets diferentes de pastas que queremos usar como fonte de APIs: as pastas durante o desenvolvimento da ferramenta (developer), | ||
+ | |||
+ | - Implicitamente: | ||
+ | - Explicitamente: | ||
+ | |||
+ | Independemente de como os sets são ativados, devem ser definidos em conjunto? Ou seja, uma instância de uma pasta, deve indicar | ||
+ | |||
+ | Tendo uma interface que nos devolve as pastas onde estão as APIs, é uma questão de adicioná-las aos includes do weaver. A partir do momento em que se tem a divisão de pastas dev/user, as abordagens podem-se preocupar apenas com a parte user (durante o modo dev, são usadas diretamente as pastas source). | ||
+ | |||
+ | |||
+ | ===== Considerações Práticas ===== | ||
+ | |||
+ | * Estando as APIs como resources, em modo user só tem que copiar a lista de resources que já existe atualmente para uma subpasta do JAR, não é preciso fornecer mais informação além da que o weaver já tem disponível. | ||
+ | * Ao deixar o GraalVM tratar dos imports, o sistema de imports LARA deverá deixar de importar .js, para não acontecer problemas estilo carregar duas vezes o mesmo ficheiro? No entanto, como é que isto interage com o sistema de imports Lara? Se um import Lara tiver um ficheiro .js, ele precisa de ser importando pelo sistema Lara, de outra forma precisaria de um import JS. Isto significa que o conjunto de ficheiros importados pelo sistema Lara e pelo sistema JS (i.e. GraalVM) têm que ser mutuamente exclusivos? | ||
+ | |||
+ | |||
+ | ===== Conclusão/ | ||
+ | |||
+ | |||
+ | * APIs Lara continuam a ser managed pela Lara framework. | ||
+ | * Cria-se a pasta quando corremos a partir de um JAR, essa pasta serve apenas de referência para IDEs, os resources do JAR continuam a ser os ficheiros importados na VM. | ||
+ | * Durante a criação dessa pasta pode-se gerar os ficheiros .d.ts. | ||
+ | * Pastas | ||
- | * Implica mudanças a nível da lara framework, será necessário suportar tanto resources como pastas, para não ter que mudar todos os weavers (mudar isto para a página de LARA?) | ||