SPeCS Research Group

User Tools

Site Tools

Trace:
ideas:lara:api_in_folder

Warning: Undefined array key -1 in /home/feupptspecs/public_html/wiki/inc/html.php on line 1458

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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/usar as APIs. 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/usar as APIs.
 +
 +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/como, a resposta óbvia para ser durante a execução do clava-update, mas nem todas as instalações usam este script, e há weavers que não têm sequer script de instalaçã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 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/ApiProvider), com várias implementações. Uma implementação pode ser baseada em projectos Eclipse (e.g. nome do projecto, pastas dentro do projecto, opcionalmente um repo git caso uma pasta local não tenha sido dada). Pode ser criada uma interface que resolve para uma ou mais pastas (e.g. FolderProvider/ApiProvider), com várias implementações. Uma implementação pode ser baseada em projectos Eclipse (e.g. nome do projecto, pastas dentro do projecto, opcionalmente um repo git caso uma pasta local não tenha sido dada).
  
-No entanto, parece haver dois sets diferentes de pastas que queremos usar como fonte de APIs: as pastas durante o desenvolvimento da ferramenta (developer), e as pastas após instalação (user). +No entanto, parece haver dois sets diferentes de pastas que queremos usar como fonte de APIs: as pastas durante o desenvolvimento da ferramenta (developer), e as pastas após instalação (user). Como distingui-los? Pode ser  implicitamente, ou explicitamente:
- +
-Uma forma de distinguir entre estes dois modos poderia ser verificando a existência do JAR. Durante o desenvolvimento, não existe JAR, mas durante a utilização estilo user, o JAR existe (no entanto, ficam corner cases por resolver. Se um weaver estiver a ser usado como biblioteca por outra aplicação, o que acontece? Consegue detectar o JAR, ou nem por isso?) +
- +
- +
  
 +  - Implicitamente: uma forma implícita de distinguir entre estes dois modos poderia ser verificando a existência do JAR. Durante o desenvolvimento, não existe JAR, mas durante a utilização estilo user, o JAR existe. No entanto, ficam corner cases por resolver. Se um weaver estiver a ser usado como biblioteca por outra aplicação, o que acontece? Consegue detectar o JAR, ou nem por isso?
 +  - Explicitamente: o utilizador indica, com algum mecanismo (e.g. flag, ficheiro properties), que é para usar o modo dev, em que assume-se que os sources estão disponíveis. Pode suportar parametros, como a pasta root onde os projetos estão, e serem transmitidos através do DataStore do weaver.
  
-===== 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? Talvez a primeira opção seja mais robusta. 
  
-==== Manter APIs como Resources ====+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/como, a resposta óbvia para ser durante a execução do clava-update, mas nem todas as instalações usam este script, e há weavers que não têm sequer script de instalação.  +===== 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/Solução Prática =====
  
-  * 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 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.
  
-    * 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?) 
  
ideas/lara/api_in_folder.1642435427.txt.gz · Last modified: 2022/01/17 16:03 by jbispo

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki