Melhor maneira de gerenciar dependências do projeto?

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.

Blz darlan_machado ja vou pequisar e estudar sobre maven !!!

Maven é uma tecnologia válida de ser estudada, mas superada pelo Gradle. Eu recomendo que você estude este.

realmente a build tool mais promissora e Gradle:

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.

quais as vantagens do Gradle em relação ao Maven?

Por que mais de 10 anos depois de ter sido inserido, Gradle não superou o Maven?

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.

agora surgiu outra duvida as apis que tem no maven tambem existem no gradle ?

eu acho que sou muito iniciante para usar o maven ou Gradle vou continuar estudando !!!

no que o Gradle é mais poderoso?

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$%@$#%$

Também compartilho desse pensamento!

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.

aaaaaaaaaaaaa muleke …