Eu não vejo problema dessa forma!
Mas se quiserem alterar para o projeto, pode alterar, apenas fiz um código de exemplo, e se quiserem criar um novo, que criem!
Cv, calma.Ele teve uma idéia.No momento somos um conjunto de idéias que estão tentando se associar para um fim.Não há requisitos.Há necessidades.O que tiver de ser aproveitado, será. 
Antes idéias confusas, e a vontade de fazer, do que palavras vazias.
Calma cara, o homem fala o que quer e faz o que pode.
Sua presença é Bem-Vinda e sua colaboração mais ainda.Apenas fique esperto pois críticas virão(o que é normal!), e todo mundo o fará.Os códigos que tenho aqui estão BEEM piores que esse.
Jah te passei meu ICQ via PM.
[quote]
Para CEP e UF há ainda a obrigatoriedade de tratar um possível erro, pois pode-se passar uma UF ou CEP inválidos. Aguardo sugestões. [/quote]
trate-as.(as exceções) Para CEP vc tah seguindo o link do Velo?
Grivon, tô instalando o wincvs.Se até amanhã eu não me acertar, peço um help para vc.
Iron, você também pode usar o jCVS www.jcvs.org, é bom, é fácil, roda em java, não exige nenhum dependência. E eu o utilizo no Windows e no Linux, principalmente no Linux.
O Wincvs é muito legal também, e é feito em Python.
O repositório será mesmo o do java.net?
Sim.Será lah memso.
[quote=Ironlynx][quote]
Para CEP e UF há ainda a obrigatoriedade de tratar um possível erro, pois pode-se passar uma UF ou CEP inválidos. Aguardo sugestões. [/quote]
trate-as.(as exceções) Para CEP vc tah seguindo o link do Velo? [/quote]
Na verdade o lugar correto de tratar essa Exception é onde um objeto tipo Endereco estiver sendo criado.
Endereco end = new EnderecoBasico(); // ou New EnderecoValido()
end.setLogradougo('Avenida Rio Branco');
end.setNumero('156');
end.setComplemento('1010');
end.setBairro('Centro');
end.Cidade('Rio de Janeiro');
try {
end.setUf('RJ');
// na classe EnderecoValido poderia ser setUf(new UF('RJ');
} catch (EnderecoException endex) {
// trata aqui algo como new UF('XX') -
// UF inválida gera UFException,
// dentro de EnderecoValido é tratada e
// repassa uma EnderecoException
}
try {
end.setCep('20102543');
// na classe EnderecoValido poderia ser setCep(new Cep('20102543');
} catch (EnderecoException endex) {
// trata aqui o erro do CEP
}EnderecoBasico é uma classe que tem um string para cada campo do endereco e implementa a interface endereco. Ela não testa nem valida UF, CEP ou Logradouro (acho que logradoudo não tem validação).
EnderecoValido é uma classe que no lugar de String para UF, CEP e Logradouro tem um objeto de cada uma dessas classes e faz a validação que a classe determinar em sua implementação.
O programador usa a que melhor lhe convier.
ATENÇÃO: Já fizemos o registro do domínio brazilutils.org, portanto quem estiver fazendo algum código já pode colocar os pacotes da seguinte forma:
org.brazilutils.*
org.brazilutils.currency
org.brazilutils.id
org.brazilutils.tribute
etc…
Grivon: se você concordar, poderia usar o pacoe org.brazilutils.address para classes de endereço, inclusive Logradouro. Não precisa criar subpacotes, por enquanto não vejo nada tão grande só para endereços. Se vai fazer uma interface para Logradouro seria bom colocar os métodos getNomeLogradouro() e getTipoLogradouro(). Na maioria dos sistemas logradouro é “Rua Riachuelo”, mas para sistemas de distribuidores de energia e telefônicas separar o tipo do logradouro é crucial. Se tiver tempo implemente um método que receba um logradouro inteiro e desmembre estas duas partes, seria bem útil.
Alguem me da um motivo serio pra os nomes dos pacotes, metodos e documentacao do codigo serem em ingles!? “org.brazilutils.currency” soa esquisitissimo pra mim, ja que 99,999999999999% + 1 dos usuarios dessa API vao ser brasileiros ou lusófonos, non? 
Pessoalmente também acho que deveríamos “aportuguesar” tudo, mas acho que também vai ter alguma coisa de uso geral (brasileiros ou não), assim o Ironlinx começou fazendo em inglês e assim foi. O próprio nome do projeto é com “z”.
Talvez fique alguma coisa em português. As classes de endereço por exemplo estão sendo feitas com nomes em português. Ainda não teve nem uma reunião, assim que acontecer acho que devemos tomar uma decisão quanto a língua utilizada.
Uma boa solução seria colocar a documentação nas duas línguas.
Também sou a favor de deixar toda a documentação, especificação e projeto em português. Afinal, apenas ela é destinado a tal público!
Epa! Pessoal, o projeto pode ser BrazilUtils, mas tem tudo será de requisitos brasileiros… isso é um conjunto de utilitários(nacionais ou não!), medidas por exemplo(KM para milhas,cm para pés…) podem (e devem) ser universalizadas.Moedas(.currency), pow será (uma vez pronto) relativamente fácil mudar uma classe que diz um número em reais para libras não acha(chato é fazê-la 100% pq eu tô apanhando de uma aqui…ugh!)?
O projeto em si, não se destina só a métricas nacionais(vou até mudar a descrição q está falando isso).
Ah outras coisas como converter binário para ascii e por aí vai…
Eu pensei em termos um pack geral(.utilities) onde o pessoal possa contribuir com o que quiser nesse aspecto de utilitários para um programador(conversões de base,manipulação de imagem, ou qualquer código q seja um serviço de corno, e vc leve muito tempo pensando para chegar em lugar nenhum…contribuam!).
Cv, se vc perceber, esse projeto está sendo aquele banco de códigos q há tempos o pessoal tava querendo fazer e ficava só na promessa, agora estamos tentando…
Se eu for voto vencido, eu aceito a documentação todo em português numa boa…apesar disso cortar uma “universalização do projeto”.
Claro que temos diretrizes básicas(validações-impostos e ids, pack monetários, pesos e medidas ), mas a idéia é não amarrá-lo, a exceção do pack principal(o de validações!).
Vamos tentar chegar a um acordo sobre a questão da língua. Concordo com o Ironlinx que o projeto não tem só coisas do Brasil (apesar do nome sugerir), sendo assim, acho que para padronizar os nomes dos pacotes e das classes em inglês parece a melhor decisão.
Por outro lado, se não houver uma documentação em português a API limita muito o grupo de possíveis usuários no Brasil. Isso pra não falar que muitas empresas costumam encrencar com documentações que não sejam em português.
SUGESTÂO: os pacotes tipo org.brazilutils.metrics, org.brazilutils.currency devem ficar com as classes e documentação em inglês. Os pacotes de uso praticamente exclusivo de progamas brasileiros tipo org.brazilutils.endereco, podem ficar em português. Inclusive os pacotes em português poderiam todos ficar dentro de org.brazilutils.br.* o que ficasse fora de br caracteriza que é de uso geral.
+1 Ingles nas classes
+100 Ingles OU Portugues, sem misturar
Bom, quinta-feira faremos uma reunião online ás 21horas para discutirmos esses e outros problemas.Aguardem o anuncio oficial da reunião.
Qual quinta? E online por IRC?
Axo q foi quinta passada… feriado 
VELO
Velo, é nessa próxima quinta(28/04)!
Vou dar um UP no tópico q falava isso para o pessoal não ficar perdido!
[quote=Ironlynx]Velo, é nessa próxima quinta(28/04)!
Vou dar um UP no tópico q falava isso para o pessoal não ficar perdido! [/quote]
Online via o que? 
Mais uma ferramentinha útil pro canivete suiço: formatar tempo em unidades, tipo, passo 1934853ms e ele me retorna uma string dizendo que são 32 minutos XX segundos … e por ai vai.
To procurando aqui mas nao acho :roll: … se nao achar mesmo eu contribuo com esse negocio pq vou precisar de qq jeito