Materialdrawer: [Solicitação de recurso] Kotlin DSL

@AllanWang oh, isso é algo em que estávamos pensando, mas não tivemos tempo ainda.

Eu gosto da ideia de trabalhar junto com @ zsmb13 já que este projeto agora é totalmente kotlin, então integrar o dsl faria absolutamente sentido.

@ zsmb13 por favor me diga se seria bom integrar seu ótimo DSL.

Esta é uma proposição interessante com certeza.

Ainda estou mantendo ativamente a biblioteca DSL. Não havia muito a fazer em termos de manter-se atualizado com a biblioteca base por um tempo agora, mas eu já comecei a procurar atualizações para a versão 7.0.0.

Eu, é claro, ficaria emocionado se minha biblioteca se tornasse "oficial" de alguma maneira (se houvesse uma organização para essas bibliotecas, ela poderia ser movida para lá, mas não existe) e veria mais usuários, bem como possivelmente colaboradores .

Não tenho certeza se ele deve ser empacotado com a biblioteca base, mesmo que tenha sido refatorado para Kotlin. Ele fornece uma interface totalmente nova para usar a biblioteca. Ele também não _tem que_ ser agrupado para funcionar, pois depende apenas de extensões. Acho que faria muito sentido ainda ter isso como um artefato separado que é opcional para os usuários, especialmente se alguém estiver usando a biblioteca base de um código Java. Eles não gostariam de incluir toda aquela funcionalidade extra que nunca usarão.

Então, é claro, há a questão da nomenclatura. MaterialDrawerKt não faz mais muito sentido se a biblioteca base for Kotlin também (se eu previsse que isso aconteceria, mas tudo bem), deveria ser MaterialDrawer-DSL ou algo parecido. Renomear é um esforço significativo que eu não levaria a sério. Especialmente se o artefato for renomeado, temo que muitas pessoas não tenham acesso às atualizações que, de outra forma, estariam recebendo - não há uma boa maneira de notificar todos os usuários sobre as mudanças.

TL; DR:

• Acho que o DSL ainda deve ser empacotado separadamente, porque a biblioteca central não precisa incluir essa API totalmente diferente. Especialmente os usuários Java não devem precisar puxar todo esse código.
• O nome da biblioteca DSL não faz mais sentido, o que é triste, mas também parece muito difícil de corrigir.

Estou aberto a todo e qualquer pensamento e opinião sobre isso, deve ser uma discussão empolgante!

@ zsmb13 é muito bom ver que você ainda está mantendo a biblioteca.

• Com base nos detalhes atuais, pensei em adicionar o DSL como um novo módulo ao projeto. e sendo um novo artefato ao lado da biblioteca principal que fornece o DSL.
• Seu código-fonte viveria diretamente ao lado do núcleo neste repositório, dando-lhe visibilidade total para as pessoas que usam o MaterialDrawer.
• Eu adoraria adicionar você como colaborador a este repositório para que você ainda possa manter diretamente, e talvez ir com solicitações pull ou o que for melhor.

Quanto a você ter medo de que as pessoas usando sua liberdade sejam cortadas. Eu presumiria que como o MaterialDrawer é a subdependência do seu projeto, as pessoas verificam regularmente este repositório, pois ele contém a biblioteca principal.

Se a renomeação do pacote for inevitável, acho que a melhor aposta seria apenas descontinuar tudo com um aviso apontando para a nova fonte. A atualização seria uma questão de alterar as importações se o dsl não mudar.

Acho que seria ótimo ter um módulo extra para extensões, dado o suporte oficial e melhor visibilidade.
O problema passa a ser uma mudança de propriedade, sobre a qual não estou em posição de comentar.

As outras dependências principais como FastAdapter e Iconics também podem precisar de dsl (ou pelo menos algumas melhorias no kotlin), mas não há realmente uma boa organização para agrupá-lo, além de todos eles serem liderados por Mike Penz

Seu código-fonte viveria diretamente ao lado do núcleo neste repositório, dando-lhe visibilidade total para as pessoas que usam o MaterialDrawer.

Isso faz sentido, ele poderia residir neste repositório como um módulo separado e, portanto, um artefato separado: +1:

Eu adoraria adicionar você como colaborador a este repositório para que você ainda possa manter diretamente, e talvez ir com solicitações pull ou o que for melhor.

Eu certamente gostaria de continuar sendo o mantenedor principal deste módulo e contribuir com ele o mais diretamente possível. Esta é a minha maior reivindicação à fama na comunidade de código aberto até agora, então é um projeto muito, muito importante para mim. Suponho que você queira alterar seu ID de grupo para corresponder ao da biblioteca base, em vez de ser co.zsmb ? Que tal o nome do pacote? Seria bom se qualquer um deles pudesse ser mantido, mas acho que também estou disposto a desistir deles, se necessário, e apenas me contentar que meu trabalho alcance mais pessoas.

Eu presumiria que como o MaterialDrawer é a subdependência do seu projeto, as pessoas verificam regularmente este repositório, pois ele contém a biblioteca principal.

Não tenho certeza se as pessoas estão verificando até a página do meu repositório. Posso imaginar muitas pessoas adicionando a dependência uma vez e, em seguida, apenas atualizando-a com base nas dicas do IDE.

Se a renomeação do pacote for inevitável, acho que a melhor aposta seria apenas descontinuar tudo com um aviso apontando para a nova fonte. A atualização seria uma questão de alterar as importações se o dsl não mudar.

Acho que essa seria a melhor abordagem possível, infelizmente não conheço nenhuma maneira de redirecionar as pessoas após alterar as coordenadas. Então, eu poderia lançar uma versão falsa que coloque muitas mensagens de depreciação e talvez tenha algum -DEPRECATED postfix no nome da versão também.

Além da migração de coordenadas, mais uma consideração técnica é que mudei para publicar minha biblioteca no MavenCentral e preferiria muito mais que ela continuasse disponível nesse repositório, se possível - até escrevi um artigo em um ponto sobre os problemas que enfrentei pessoalmente usando o jcenter. Você não poderia publicá-lo sob meu ID de grupo, é claro, porque tenho usado minhas próprias chaves GPG para assinar os artefatos, mas se o ID de grupo fosse alterado, seria possível.

Isso não é um problema se você deseja apenas publicar todas essas bibliotecas do jcenter, mas eu realmente recomendaria a abordagem MavenCentral (embora seja reconhecidamente muito tediosa) e ficaria mais feliz se meu trabalho fosse distribuído por lá.

Darei uma longa resposta aos primeiros tópicos mais tarde.

Relacionado aos seus comentários sobre o MavenCentral . Eu concordo absolutamente. Eu ainda publico minhas bibliotecas no maven central também, e ainda assino minhas bibliotecas por meio de uma chave GPG para garantir sua integridade. Porque na minha opinião é muito importante ter essa forma de verificar se o artefato foi publicado de uma fonte confiável.
Acabei de adicionar a opção via jCenter, pois oferece uma maneira mais rápida e direta de fornecer atualizações. maven central tende a levar algum tempo para atualizar às vezes. Além disso, o formulário de sincronização do mavenCentral com o jCenter às vezes causava problemas para as pessoas. então decidi que publicarei para ambos. e ter os artefatos no jcenter com a descrição adequada e outras coisas. :)

Ah, ok, isso é uma ótima notícia então. Eu nunca soube que poderia puxar a biblioteca básica do MavenCentral também!

Então, em geral, eu acho que seria melhor ter o artefato no mesmo grupo hospedado, já que é comum (pelo menos eu faço isso regularmente) encontrar artefatos do mesmo grupo para ver se uma lib tem outros módulos ou algo assim. Além disso, torna mais fácil para as pessoas entenderem que funciona em conjunto.
Nome do pacote relacionado. Em geral, eu prefiro ter o mesmo que a biblioteca principal, apenas para tornar compreensível para as pessoas o que elas realmente importam em seus arquivos de origem.

Mas, com base no alcance de sua biblioteca e no fato de que muitas pessoas já a usam, acho que, por uma questão de simplicidade para a atualização, poderíamos manter o nome do pacote para as classes existentes e migrar lentamente para o nome do pacote das bibliotecas principais com novas classes .
Uma coisa que devemos definitivamente fazer é ter um cabeçalho de licença adequado nos arquivos de origem de sua DSL com seu nome para que essa visibilidade seja garantida. Também adicionando créditos para ele diretamente no README

Relacionado à fase de desaprovação. Meu sentimento seria que seria suficiente ter um aviso no repo e vincular as pessoas e fazer uma atualização com uma depreciação na classe principal para observar que as coisas foram movidas e que a dependência agora é mantida em outro lugar.
De alguma forma, existe uma possibilidade no maven central de especificar que uma biblioteca foi movida para um grupo diferente ou assim, mas não tenho ideia de como fazer isso: D

(apenas um aviso)
Acho que essa discussão ainda pode demorar um pouco mais, então provavelmente irei em frente e lancarei a v7.0.0 sem incluir uma DSL ainda.

Acho que descobrimos a maior parte das coisas de mesclagem, mas ainda tenho que fazer atualizações no DSL para a nova versão da biblioteca base. Se você deseja lançar o 7.0.0 em breve, deve fazer isso por conta própria, porque estarei um pouco atrasado em atualizar o DSL.

Quando eu terminar com isso, acho que podemos discutir rapidamente os detalhes de como movê-lo para este repositório. Parece que não sobrou nenhum problema técnico de bloqueio, só teremos que resolver alguns pequenos detalhes, provavelmente por chat ou algo assim.

@ zsmb13 soa bem para mim.

por falar nisso. Tive outra ideia que pode ser uma variante em potencial que poderíamos seguir.

Você mantém seu repo, nome do pacote. mas ajustamos o módulo para que siga a estrutura do módulo necessária para liberá-lo como parte da biblioteca principal. em seguida, inclua-o como submódulo git no repositório principal. depois disso, publicamos sob o mesmo pacote maven. e ter o README principal devidamente documentado e informado aos usuários.

Mas tudo isso podemos discutir em um chat como você propôs.

Alguma atualização? Com as mudanças recentes devido a outras atualizações de biblioteca, o dsl não pode ser usado até que também tenha um aumento de versão

Estória engraçada. @ zsmb13 e eu realmente nos conhecemos no kotlinconf esta semana 😂

Fechando isso por inatividade. Além disso, a v8 está usando uma nova API que é mais amigável ao kotlin e deve basicamente tornar o DSL kotlin obsoleto. :)

Abra para melhorias.

Muito obrigado pela grande discussão aqui.

Também nessa nota. Parabéns @ zsmb13 por se tornar um GDE: D

Concordo, na verdade não atualizei a biblioteca Kt wrapper após 7.x, porque não vejo como ela poderia fazer um trabalho muito melhor do que a biblioteca normal. Além disso, agora não poderia ser super transparente, já que você precisaria fazer as partes de configuração do XML para usar a biblioteca de qualquer maneira.