Fixing path name of realistics scenarios and deleting files with dependencies#80
Fixing path name of realistics scenarios and deleting files with dependencies#80galilasmb wants to merge 7 commits into
Conversation
|
Os caminhos para os três cenários realistas estavam com (), gerando erro ao localizar o pacote com o padrão: org.pasta().main.method() Removi os parênteses de pasta(). @barbosamaatheus isso influencia em algo no seu estudo? Se sim, deixa em uma branch separada, exclusivo para sdg. |
Acredito que não @galilasmb |
@barbosamaatheus se certificasse que continua tudo ok? @galilasmb isso pode afetar os experimentos de testes também? não entendi a causa dos renamings dos arquivos |
|
Não faz sentido ter um nome de pasta com (), isso representa método, e o SDG tenta fazer esse padrão no input, pra não ter que ajustar nada no SDG, apenas renomear a pasta para um padrão correto que todos os outros cenários seguem. |
galilasmb
changed the title
|
Isso foi somente em três arquivos de realistic |
|
@HACardoso podes verificar se há impacto no experimento de testes? |
There was a problem hiding this comment.
Eu não faço ideia, mas em uma das execuções, estava pegando esse arquivo e tinha dependência.
There was a problem hiding this comment.
Não! segundo o readme do projeto: Tachyon comes in two parts: the server to serve images and the plugin to use it.
There was a problem hiding this comment.
certo. então o código do sistema que estamos analisando usa tachyon como um servidor? se for isso, não é bem uma dependência externa no sentido que a gente estava falando, mas é algo a não ser considerado pelas análises mesmo
There was a problem hiding this comment.
@galilasmb aqui fiquei na dúvida, já que o jar sendo removido é também do dropwizard. não parece uma dependência externa. podes verificar o que tem nesse jar?
There was a problem hiding this comment.
@barbosamaatheus fez essa avaliação dos .jars
There was a problem hiding this comment.
Esse é o conteúdo do .jar
O que interessa para nossa analise seria apenas o pacote io
There was a problem hiding this comment.
@barbosamaatheus estritamente, a análise deveria ser executada com todo o código do sistema que a gente está analisando, nesse caso dropwizard, não apenas com o pacote onde está a classe a ser analisada. pacotes como antlr e javax certamente são dependências externas e não deveriam ser considerados, mas precisamos saber se algum dos outros pacotes também faz parte do sistema dropwizard, ao invés de ser uma dependência externa, entendeu?
There was a problem hiding this comment.
Esse é o exemplo que o Matheus analisou que o .jar estava com dependência.
There was a problem hiding this comment.
idem meu último comentário acima
There was a problem hiding this comment.
Está sendo produzido vários arquivos duplicados, uns com dependências e outros sem. O arquivo correto do cenário de dropwizard não é esse, é o dropwizard-core-0.7.1-SNAPSHOT. E ao executar, está pegando o arquivo de outro módulo, example, quando o correto é o core.
There was a problem hiding this comment.
@galilasmb aqui fiquei na dúvida, já que o jar sendo removido é também do druid. não parece uma dependência externa. podes verificar o que tem nesse jar?
There was a problem hiding this comment.
Novamente nesse caso. a classe que queremos analisar está no pacote "com"
There was a problem hiding this comment.
@barbosamaatheus estritamente, a análise deveria ser executada com todo o código do sistema que a gente está analisando, nesse caso druid, não apenas com o pacote onde está a classe a ser analisada. pacotes como scala e kafka certamente são dependências externas e não deveriam ser considerados, mas precisamos saber se algum dos outros pacotes também faz parte do sistema druid, ao invés de ser uma dependência externa, entendeu?
There was a problem hiding this comment.
Como posso saber isso professor? o .jar que consideramos certo nesse exemplo é assim (druid-server-0.2.8-SNAPSHOT.jar):
There was a problem hiding this comment.
pelo nome do pacote, vendo se tem o mesmo padrão/nome da organização
There was a problem hiding this comment.
@galilasmb aqui fiquei na dúvida, já que o jar sendo removido é também do druid. não parece uma dependência externa. podes verificar o que tem nesse jar?
There was a problem hiding this comment.
Aqui o mesmo se aplica, esse não é o arquivo correto, está pegando o módulo services, mas o correto é server, conforme o jar correto: druid-server-0.2.8-SNAPSHOT.jar
barbosamaatheus
left a comment
barbosamaatheus
left a comment
There was a problem hiding this comment.
@galilasmb no lugar de apagar, não seria ideal guardar esses .jars em um local diferente para caso seja necessário no futuro?
There was a problem hiding this comment.
Não! segundo o readme do projeto: Tachyon comes in two parts: the server to serve images and the plugin to use it.
There was a problem hiding this comment.
Esse é o conteúdo do .jar
O que interessa para nossa analise seria apenas o pacote io
There was a problem hiding this comment.
Novamente nesse caso. a classe que queremos analisar está no pacote "com"
@pauloborba não detectei nenhum impacto nos respectivos experimentos com testes |
barbosamaatheus
left a comment
barbosamaatheus
left a comment
There was a problem hiding this comment.
Aprovando, pois acredito que esse PR não causa nenhum prejuízo para as análises ou mergedetaset. Os jar apenas foram movidos e a remoção dos () também não chega a influenciar negativamente.
Entendo que ainda existe um ponto em discussão para os casos de .jar com/sem dependências
|
Falta algo mais para que esse PR seja integrado? @pauloborba @barbosamaatheus |
vê as pendências que marquei acima @galilasmb |
4 participants
No description provided.