This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
ideas:lara:api_in_folder [2022/01/17 15:16] jbispo created |
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 ===== |
- | * Implica mudanças | + | |
+ | 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 | ||
+ | |||
+ | Ao passarem para uma pasta, sempre que uma execução | ||
+ | |||
+ | 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 | ||
+ | |||
+ | - Implicitamente: | ||
+ | - Explicitamente: | ||
+ | |||
+ | Independemente | ||
+ | |||
+ | 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 | ||
+ | |||
+ | |||
+ | ===== 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 de includes especificadas na configuração devem ser dadas ao GraalVM, e ficheiros nessas pastas podem ser importados através do import JS. | ||