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 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 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+===== Intro ===== 
 + 
 +A ideia é adicionar nova forma de distribuir APIs.  
 + 
 +Atualmente APIs são resources dentro do JAR. Isto tem várias vantagens, como uma desenvolvimento  e distribuição mais simples. No entanto, os ficheiros das APIs, que muitos serão JS, não estão facilmente disponíveis pelos IDEs. Como disponibilizar estes ficheiros numa pasta de forma a estarem disponíveis pelos IDEs? 
 + 
 +Dois caminhos possíveis: 
 + 
 +  - Manter as APIs como resources, e extraí-las para uma pasta predefinida algures no tempo (e.g. durante a instalação ou execução) 
 +  - 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/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 ===== 
 + 
 +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, nem é preciso reiniciar a aplicação Java para ver refletidas as mudanças. 
 + 
 +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, e não os originais que estão no repositório git. 
 + 
 +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/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). Como distingui-los? Pode ser  implicitamente, ou explicitamente: 
 + 
 +  - 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. 
 + 
 +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.  
 + 
 +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/Solução Prática ===== 
 + 
 + 
 +  * 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.1642432595.txt.gz · Last modified: 2022/01/17 15:16 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