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 16:03] jbispo |
ideas:lara:api_in_folder [2022/01/17 16:55] (current) jbispo |
||
---|---|---|---|
Line 13: | Line 13: | ||
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/ | 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 são extraídas. | ||
+ | |||
+ | * Em relação ao quando/ | ||
+ | * 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 uma solução em que as APIs se mantém como resources, já que permite ao próprio weaver fazer este management da pasta de APIs. Se não estiverem como resources, será preciso algum externo (e.g. build system) para gerir isto (ficheiros estarem como resources permite à aplicação Java gerir esses resources). | ||
+ | |||
===== Ambiente de Desenvolvimento ===== | ===== Ambiente de Desenvolvimento ===== | ||
Line 24: | Line 32: | ||
Pode ser criada uma interface que resolve para uma ou mais pastas (e.g. FolderProvider/ | 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), | + | No entanto, parece haver dois sets diferentes de pastas que queremos usar como fonte de APIs: as pastas durante o desenvolvimento da ferramenta (developer), |
- | + | ||
- | Uma forma de distinguir entre estes dois modos poderia | + | |
- | + | ||
- | + | ||
+ | - Implicitamente: | ||
+ | - Explicitamente: | ||
- | ===== Abordagens ===== | + | Independemente de como os sets são ativados, devem ser definidos em conjunto? Ou seja, uma instância de uma pasta, deve indicar à partida a configuração dev e user? Ou são sets à parte, definidos de forma independente? |
- | ==== Manter | + | 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). |
- | Durante a instalação ou execução as APIs são extraídas para uma subpasta predefinida onde o JAR está localizado. À partida este é o método que implica menos mudanças, a questão é quando/como extrair, e que mecanismo usar para manter uma espécie de cache, para minimizar as vezes que as resources são extraídas. | ||
- | * Unordered List ItemEm relação ao quando/ | + | ===== Considerações Práticas ===== |
- | * Um método mais robusto será durante a execução do weaver | + | |
+ | * 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? | ||
- | ==== APIs como Pastas ==== | ||
- | * Ser uma n´v | + | ===== Conclusão/ |
- | * Desenvolvimento facilitado | ||
- | Transformar LARA API resources em ficheiros que vão bundled no zip, e que são indicados ao graalVM como uma pasta de includes (para o import funcionar), e adicionado automaticamente à pasta de includes | + | * APIs Lara continuam a ser managed pela Lara framework. |
+ | * Cria-se a pasta quando corremos a partir de um JAR, essa pasta serve apenas | ||
+ | * 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?) | ||