Senhores sera uma pergunta bem iniciante mas que e de grande valor pra min e para os inciantes como eu, eu estou apredendo a programar e java e vi que alguns funções ou api nao sei ao certo como chamar sao adicionadas no netbeans através de jdk ou seja no caso da api rxtx eu baixei e adicionei na pasta do jdk em um local especifico e ai passou a funcionar mas tem algumas que so funciona se voce importar direto para o projeto e consequentemente ele vai junto com o projeto mas ainda tenho algumas duvidas de como proceder para ate mesmo nao entupir meu netbeans com um monte de coisa !
Todos as funçoes adicionais que preciso sao classes criadas e que eu posso incorporar a um projeto ?
sao chamadas de api mas o sistema trata como uma classe ou e diferente ?
qual a forma correta para eu adicionar um api colocando na pasta do jdk ou cada uma tem sua forma de instalar ?
a forma correta de chamar e api ?
oque e o maven ? como usa-lo ? como ele funciona ?
vi algumas pessoas colocado linhas de codigo assim:
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.0.0-beta3</version>
</dependency>
para ser usado no mavem como isso funciona ???
Vamos pelo começo.
O título não dá uma ideia correta sobre a questão.
Eu sugeriria algo como: “Melhor maneira de gerenciar dependências do projeto”.
Pois, o teu problema não é o uso do netbeans, mas como fazer para que determinada dependência seja adicionada e esteja disponível ao teu projeto.
Vamos lá, está usando maven? Então use-o.
Não usa maven? Já tentou aprender sobre ele? Ou algum similar, como gradle?
Definido isso, vem as exceções. Algumas raras dependências não são disponibilizadas via maven ou similares.
Daí, você realmente precisa baixar o jar e incluir o mesmo no teu projeto.
senhores me surgiu uma duvida vi que tanto a maven quanto gradle sao ferramentas de construçao e pelo que vi tenho que inicia meu projeto nela e depois usando a estrutura que ela me fornece vou passar a trabalhar com meu IDE é isso ??
Isso, você trabalha com uma IDE que suporta. Acho que hoje em dia todas suportam, mas eu aconselho (como sempre) que você use o IntelliJ, mesmo que seja a Community Edition.
Também tem como iniciar o Gradle dentro de um projeto já existente. No IntelliJ ele faz isso automaticamente se você quiser.
Caramba, faz tempo que não vejo o @kicolobo por aqui.
E, faço dele a minha pergunta.
Vejo o gradle muito forte nos projetos mobile (android). Mas, nunca vi nenhum projeto para outras coisas usarem ele.
E, claro, é a minha percepção profissional, pode ser que eu tenha tido o azar de nunca ter trabalhado em equipes/projetos/empresas com isso.
Discussão validissima da Taverna. Vou citar o que penso ser a melhor resposta:
IMHO: por sua importância histórica na gestão de dependências com repositório central, a base legada de sistemas utilizando Maven é enorme. Isso pesa muito. Sem falar na quantidade de plugins que foram criados e amadurecidos e estão no coração de jobs de integração contínua por aí. Essas tecnologias estruturantes que conseguem algum pioneirismo e possuem uma arquitetura de plugins da comunidade sempre geram esse fenômeno (ex: Eclipse). Então sei lá… Não fosse pela questão estética, não creio que o Maven apresente alguma deficiência funcional gritante que motive a migração massiva e natural para algo novo que viesse a suprir uma possível lacuna. No próprio site do Gradle, a comparação com Maven é bem oblíqua (https://gradle.org/maven-vs-gradle/ ).
Eu considero Maven mais simples de usar que Gradle, embora o Gradle seja bem mais poderoso…
Ele fica mais na Taverna do que aqui. Talvez por que ele seja o idealizador daquele fórum? Talvez.
De um ponto de vista prático, Gradle lhe dá todo o poder de uma linguagem de programação dinâmica na hora de compilar, testar e distribuir o seu projeto, enquanto Maven força uma abordagem declarativa com passos praticamente pré-definidos.
Quando eu comecei a usar o maven, pois isso não se ensina na faculdade, eu odiava essa m$%@$#%$.
Com o tempo, assim como qualquer coisa na vida, você acostuma.
Quando estava bem tranquilo, aparece o Android e o gradle (eu nunca tinha ouvido falar do gradle antes disso).
Bacana, legal, mas, cadê o pom.xml? Onde defino profile? Como faço para executar um plugin? Como faço para rodar o deploy e já atualizar o jboss? (ok, android não roda no jboss).
Esse tipo de coisa corriqueira, mas essencial, me manteve distante do gradle. Como, profissionalmente, sempre estive envolvidos em projetos maven, acabo que lembro do gradle como “aquela ferramenta que faz o que o maven faz”.
Ah, continuo achando o maven uma m$%@$#%$
Minhas experiências anteriores com Gradle em nível de aprendizado e estudo não foram as melhores, eu também o conheci na mesma época em que surgiu o Android, profissionalmente sempre trabalhei em projetos com Maven, até hoje não tive nenhum problema com o uso do Maven.
Qual a vantagem e o poder de uma linguagem de programação dinâmica na hora de compilar, testar e distribuir o projeto?
Quando tive meu primeiro contato com Gradle - no seu lançamento - até achava que isto seria uma vantagem bacana e tal. Aí percebi que nunca usei estes recursos e, ainda pior, não eram necessários.
Pouca gente sabe, mas é possível você invocar scripts Ant ou mesmo Groovy com Maven, tipo na hora de customizar um pacote, coisas assim, que são extremamente pontuais.
Na prática geração de pacotes e compilação é algo que deveria ser padrão: na minha experiência quando começamos a customizar isto estamos fazendo bobagem.
E é aí que o valor do Maven surge: ele padroniza as coisas no universo Java, te define um ciclo de vida muito bem definido, muito prático inclusive.
A única questão é a documentação que ainda é ruim. Disse “ainda”? É algo que já estou resolvendo, fica como cenas do próximo capítulo
A questão da documentação, no meu entender, é padrão para os projetos que nasceram ou foram encubados na Apache. São muito rasos, não cobrem nada além do mais básico. Isso para tudo que passou por lá.
Eu penso que minhas dificuldades e, consequentemente, dissabores com o maven se originam no fato de que eu nunca estudei o mesmo e fui aprendendo enquanto trabalhava.
Esse tipo de coisa deveria ser proibida, mas, como um amigo dizia “aprende no dev, testa em homolog e corrige em produção”.
Sobre o gradle, eu realmente concordo com tudo o que disse.
