| Autor |
Mensagem |
|
|
Eu criei um plugin do Maven e estou com dificuldade para atualizá-lo, muito estranho. Por mais que eu altere o código o Eclipse sempre executa a versão mais antiga. Já fiz o deploy do artefato no repositório e verifiquei que o .class está com o código mais recente, assim como meu repositório local (diretório .m2). Eu já fiz um teste apagando o arquivo JAR do plugin do repositório local e notei que mesmo assim o plugin foi executado, o que me leva a acreditar que o Eclipse está executando o plugin de outro local.
Alguém saberia dizer o que pode estar acontecendo? De onde o Eclipse lê os plugins do Maven?
|
 |
|
|
O Mac OS vem ganhando mercado e consequentemente moral pra impor certas coisas. Esta é a minha opinião. 
Vamos ver qual será a reação da Oracle (será que haverá uma?).
|
|
|
|
Oi, nois_159!
Você poderia ser mais específico? Assim fica mais fácil ajudá-lo.
Abraços!
|
|
|
|
|
Use BB Code pra formatar seu código, fica ruim sem formatação.
|
|
|
|
|
Vale a pena conhecer o Redmine, estamos usando na empresa onde trabalho e ele tem ajudado muito.
|
|
|
|
Alguém sabe se existe algum jeito seguro de fazer isso? Tenho que testar um código que utiliza equals() e a coisa simplesmente não funciona. 
Abraços!
|
|
|
|
ricardosoares wrote:Se lhe pagam aqúem da sua capacidade de produção, talvez a falha esteja na sua falta de capacidade de administrar sua carreira. Não é um defeito, é uma caraterística de algumas pessoas. Há consultores para tal.
ricardosoares wrote:Mantenha o nível que este forum merece. Sem ofensas, por favor.
E o que você escreveu não é ofensa?? 
|
|
|
|
Mauricio Linhares wrote:
bonfarj wrote:Talvez não tenha me expressado bem, hehe. Eu quis dizer que, considerando o "mundo real", até podem existir atributos para a associação, mas para o seu modelo esse atributo é totalmente irrelevante e não será considerado. Sendo assim, isso não será refletivo no banco e não porque esteja errado e sim porque não faz sentido.
Como eu disse, isso é geralmente, não sempre.
Só acho improvável que haja um atributo na associação e quem está desenvolvendo o modelo resolva ignorar esse atributo intencionalmente pra ficar com a tabela de associação simples. A não ser que o modelo que está sendo criado pra aplicação seja também uma coisa muito simples, que não precise captar realmente a abstração;
Sim, isso mesmo. Estou partindo do princípio de que o modelo é uma abstração do mundo real, não precisamos pegar tudo, apenas o que for relevante para o nosso contexto.
Um exemplo: imagine que eu tenha um relacionamento N-N entre jogadores e times onde eles já jogaram (um jogador já jogou em uma ou N equipes e uma equipe já teve N jogadores). Eu poderia incluir como atributo desta associação a temporada na qual o jogador X jogou na equipe Y, mas talvez isto não seja necessário para o meu modelo. Consequentemente, meu modelo físico do banco poderia usar uma tabela associativa "simples".
Abraços,
|
|
|
|
Mauricio Linhares wrote:
bonfarj wrote:Achei isso meio controverso. Por mais que possam existir atributos em uma determinada associação, pode ser que para o seu modelo ele não seja relevante e vc tenha como resultado no modelo físico do banco apenas uma tabela associativa "simples". Posso estar enganado, mas não vejo como algo errado este tipo de tabela associativa.
Se no modelo físico já uma coluna de dados na tabela associativa e isso não é refletido no modelo da aplicação, ou o banco de dados ou a aplicação estão modelados de forma incorreta. Não existem dois modelos.
Talvez não tenha me expressado bem, hehe. Eu quis dizer que, considerando o "mundo real", até podem existir atributos para a associação, mas para o seu modelo esse atributo é totalmente irrelevante e não será considerado. Sendo assim, isso não será refletivo no banco e não porque esteja errado e sim porque não faz sentido.
Abraços,
|
|
|
|
Mauricio Linhares wrote:Muitos materiais sobre orientação a objetos e modelagem de bancos de dados dizem que tabelas associativas não são comuns, porque a maior parte das associações tem algum "dado" a mais que termina virando uma coluna na tabela associativa e fazendo com que ela não seja mais uma simples tabela associativa. Então, associações N:N diretas normalmente simbolizam pouco conhecimento do modelo em questão (ou que você tem um problema bem incomum pra ser resolvido).
Achei isso meio controverso. Por mais que possam existir atributos em uma determinada associação, pode ser que para o seu modelo ele não seja relevante e vc tenha como resultado no modelo físico do banco apenas uma tabela associativa "simples". Posso estar enganado, mas não vejo como algo errado este tipo de tabela associativa.
Abraços,
|
|
|
|
Verdade, mas se pensarmos em performance boa parte das "boas práticas" de BD vai pro saco, normalização etc. Sendo assim, acho estranho que este professor tenha ressaltado que tabelas associativas não são uma boa, deve ter alguma outra razão que não consigo ver.
Abraços,
|
|
|
|
André Fonseca wrote:uma vez eu trabalhei num lugar onde tinha uma tabela que tinha 13 chaves extrangeiras dentro dela, algo como
tabela produto
id_produto
id_item1
id_item2
...
id_item13
ou seja, produto só pode ter no máximo 13 itens, se tiver um 14 item vai ter que usar um alter table ai..
uma das vantagens de voce ter uma tabela associativa é vc evitar isso.. agora tudo depende to tipo de BD que vc vai usar, se a query (join) que vc vai ter que usar para recuperar os dados vai ficar pesado, etc..
Peço desculpas por atuar como coveiro, mas essa realmente me deixou impressionado, não vejo razão para isto.
E aproveitando, gostaria de saber por que este professor afirma que não é uma boa usar tabelas associativas, fiquei curioso.
Abraços,
|
|
|
|
|
O texto parece interessante, mas não é notícia.
|
|
|
|
Marcio_Nogueira wrote:Mais uma linguagem tentando um lugar ao sol. O mercado já está saturado (e de saco cheido) do surgimento de tantas linguagens que se dizem "revolucionárias". 
Não vejo dessa forma, acho natural o surgimento de novas linguagens (revolucionárias ou não). Eu mexi um pouco com R numa matéria da faculdade (Probabilidade e Estatística), nem sabia que aquela sintaxe do software R também era chamada de R. Se ele usasse uma outra linguagem (ex: Java) seria mais complicado de usar.
Abraços a todos!
|
|
|
|
O problema é que a retro-compatibilidade tornou-se um peso muito grande para a evolução da linguagem. FORK JÁ! 
|
|
|
|