Eclispse não funciona com o Bazaar 1.6 quando instalado com o Windows standalone installer

Se você estava tentando usar a nova versão do Bazaar, e optou pelo Windows standalone installer, acredito que terá o mesmo problema que eu ao tentar usar o plugin para o Eclipse:

A incapacidade de instalar o plugin XML-Output na versão 1.6 do Bazaar, quando usado o Windows standalone installer.

Tem outra mensagem, no Lanuchpad, do XML-Output falando do problema quando o Bazaar 1.6 foi instalando usando o Windows standalone installer.

O problema ocorre porque o instalador veio sem o arquivo SimpleXMLRPCServer.py, para resolver basta seguir os passos abaixo:

  1. Baixar o Bazaar 1.6 – Windows standalone installer;
  2. Executar o instalador;
  3. Baixar o plugin XML-Output 0.6.2, que é a versão mais atual quando eu escrevi este post.
  4. Descompactar o arquivo, bzr-xmloutput-0.6.2.tar.gz, para uma pasta na sua máquina;
  5. Copie o conteúdo da pasta para %BAZAAR_HOME%\plugins\xmloutput, onde %BAZAAR_HOME% é o lugar onde você instalou o Bazaar.
  6. Baixe o arquivo SimpleXMLRPCServer.py e copie-o para a pasta %BAZAAR_HOME%\plugins\xmloutput

Para confirmar que deu tudo certo abre um console e digite o comando: bzr plugins


O resultado deve ser algo parecido com:

————————————————————————————–

D:\Documents and Settings\acdesouza>bzr plugins
bzrtools 1.6.0
    Various useful plugins for working with bzr.

launchpad
    Launchpad.net integration plugin for Bazaar.

qbzr 0.9.3
    QBzr - Qt-based front end for Bazaar

svn 0.4.11
    Support for Subversion branches

xmloutput 0.6.2
    This plugin provides xml output for status, log, annotate, missing, info, version and plugins

————————————————————————————–

Pronto, seu Bazaar 1.6 já está funcionado e pronto para ser usado com o Eclipse.

Dúvidas e sugestões, espero nos comentários.

Instalando o Ruby, no Windows, sem o One-click Installer

Estava procurando reproduzir o ambiente Ruby, que eu tenho no Ubuntu, em uma estação Windows. Só que o instalador disponibilizado, é recheado de plugins. Por isso resolvi tentar a versão zipada.

Para minha surpresa, a instalação do pacote zipado é bem tranqüila e, quase, dispensa o One-Click Installer.

Abaixo, a lista de passos que eu segui para ter o ambiente funcionando redondo:

  1. Baixe o Ruby 1.8.6 Binary;
  2. Descompacte o arquivo em uma pasta: C:\ruby, por exemplo;
  3. Adicione a pasta C:\ruby\bin na sua variável de ambiente Path.

Instalando o RubyGems:

  1. Baixe o Rubygems;
  2. Descompacte o arquivo e execute o setup que existe na pasta bin.

Perfeito agora você tem um ambiente sem um mundo de plugins que o One-click Installer coloca no ambiente Windows.

UPDATE:

Para instalar gems basta usar o comando:

 gem install nome_do _gem.

Caso você esteja tentando instalar um gem atrás de um proxy com autenticação, defina a variável de ambiente HTTP_PROXY com a url para o proxy da sua rede:

set HTTP_PROXY=http://nome_de_usuario:senha_do_proxy@url_ou_ip_do_proxy:porta_do_proxy

Avaliando o Bazaar

Como já explicado, o Bazaar é um sistema de controle de versão distribuído, que eu estou usando em um projeto no trabalho. Neste texto irei listar os motivos para usá-lo e uma breve comparação com os seus concorrentes mais interessante: Mercurial e Git.

Por que usar o Bazaar?

  • Possui suporte a renomear e mover arquivos e pastas;
  • Possui suporte a migração de repositórios Subversion;
  • É multi-plataforma, incluindo Windows e Linux. Na verdade qualquer coisa que rode Python;
  • É suportado por uma empresa, Canonical, que mantém programadores dedicados ao projeto;
  • Possui suporte comercial, opcional;
  • É usado em projetos grandes;
  • É livre e gratuito;

Problemas que me incomodam

  • É, visivelmente, mais lento do que os concorrentes: Mercurial e Git;
  • Falta um cliente que não seja em linha de comando que esteja no mesmo nivel do TortoiseCVS ou SmartCVS. O TortoiseBzr está sendo distribuído com a versão 1.6. Eu concordo que não doí usar a interface por linha de comando, mas tem desenvolvedor que esta acostumado com o Windows. E nada o convence de que há casos em que linha de comando é mais produtivo;
  • O plugin do Bazaar para o Eclipse ainda deixa a desejar, se comparado, por exemplo, ao Subversive para o Subversion;
  • O TortoiseBzr ainda está no começo, mas parece promissor.

As funcionalidade que sinto falta no plugin para o Eclipse são:

Fontes de consulta

Concorrentes

Git

Criado por Linus Torvalds para substituir o BitKeeper, usando as lições aprendidas com o uso diário deste. O Git é usado para suportar o processo de desenvolvimento do kernel Linux.

Suas principais características são:

  • Suporta os requisitos de Linus Torvalds, para o Linux.
  • É, absurdamente, rápido;
  • Possui desenvolvedores de altíssimo nível;
  • É muito rápido, mesmo;
  • Suporta renomear e mover arquivos e pastas;
  • Tem uma ferramenta de merge muito boa. Ele inclusive consegue, sob certas circunstâncias, acompanhar que um método saiu de um arquivo para outro.
  • Já falei que ele é rápido?

Infelizmente nem tudo são flores…

Mercurial – Hg

O pessoal da Mozilla e do OpenSolaris gostou dele.

É muito rápido, se comparado com o Bazaar.

Ele tem recebido boas criticas. Inclusive, o pessoal da Mozilla o comparou com o Bazaar, mas com uma versão beeem antiga:

Além disso, já possui uma boa ferramenta: TortoiseHg.

Ainda assim, sinto falta de “alguém de peso” suportando o desenvolvimento. Quando eu digo suportando, eu me refiro a forma que a Canonical está fazendo com o Bazaar.

Na verdade, esta falta, é apenas porque acredito que o Hg poderá ser superado pelo Bazaar, da mesma forma que o Ubuntu vem fazendo com as distribuições mais antigas.

Críticas, dúvidas e sugestões serão muito bem vindas. Para isso é só comentar aqui embaixo…

Software de controle de versão sem um servidor

Você está procurando um software de controle de versão, ou de código-fonte, que não precise de um servidor? Um software de controle de versão que rode no Windows, Linux ou MacOS?

Provavelmente você está procurando um sistema de controle de versão distribuído. Atualmente eu estou usando um chamado Bazaar.

Desde que o Linus Torvalds deixou de usar o BitKeeper e criou o Git, que os sistemas de controle de versão começaram a adotar a característica de descentralizar a localização do repositório.

É claro que já existiam outros antes disso, o próprio BitKeeper, mas dá uma olhada na adoção destas ferramentas por empresas, no Brasil, e projetos open-source. O_o

O fato de descentralizar o repositório muda a forma como você trabalha com Gerência de Código-Fonte, SCM em inglês:

  • O desempenho é maior, uma vez que todas as operações são realizadas localmente. Sem depender da rede;
  • O backup do repositório é feito naturalmente, uma vez que cada desenvolvedor representa um backup remoto dos fontes;
  • Não depende de configuração, ou mesmo existência de um servidor. Sabe a arquitetura P2P? Pois é, essa é a idéia;
  • Não precisa dar permissão, para realizar o commit, a nenhum dos desenvolvedores do projeto. Basta que uma pessoa ou grupo tenha essa permissão. E, mesmo assim os colaboradores poderão controlar as alteração que ele vem fazendo;
  • Dada a característica de que tudo é um branch, os sistemas de controle de versão distribuídos possuem um suporte a merges, muito superior aos seus concorrentes centralizados;
  • Quem resolve os conflitos gerados por mudanças no código é a pessoa que fez as mudanças e não você, quem está baixando as atualizações.
  • Você pode dar mais commits, sem quebrar o código de outro desenvolvedor, e se beneficiar mais da funcionalidade de revert.

Isso são características destas ferramentas, mas não necessariamente vantagens, ou desvantagens, apenas características.

Por exemplo, ter vários backups remotos dificulta saber qual o mais recente. Esse controle passa a ser feito pelo processo adotado pela equipe. Mas por outro lado, dificulta termos backups corrompidos, afinal de contas eles estão sendo usados.

O paper de Ian Clatworthy, desenvolvedor do Bazaar, sobre sistemas de controle de versão distribuídos procura demonstrar as vantagens de se adotar este modelo e dá sugestões sobre como escolher uma ferramenta, dentre as opções existentes. Há também, uma explicação sobre DVCS no site BetterExplained, versão ilustrada.

Eu estou testando, em um projeto no trabalho, o Bazaar-VCS. Ferramenta apoiada pela Canonical – já ouviu falar na empresa sim. É a mesma que mantem o Ubuntu Linux e o emprego do Ian, o cara do paper ali de cima.

Também darei uma olhada no Mercurial que vejo como principal concorrente dele. Uma vez que suas características são semelhantes.
Minha escolha, para teste do Bazaar, foi feita pensando em seu suporte a renomear e mover arquivos e pastas.

Críticas, dúvidas e sugestões serão muito bem vindas. Para isso é só comentar aqui embaixo…

Tomcat Realm: Controle de acesso gerenciado pelo Container Web

Vou aproveitar o post do Urubatan ensinando como fazer um login com JSF para explicar como delegar, para o container web, o serviço de autenticação e autorização.

Neste exemplo explicarei como configurar uma aplicação web para ser autenticada pelo Tomcat, que será o Container Web usado no texto. Caso você use o Jetty, dê uma olhada em como fazer um Realm no Jetty.

Ah?! Como assim, o que é um Realm?
<conceito>
Realm: é uma base de dados que contém a informação de usuário, senha e as roles deste usuário no sistema
</conceito>

Não sabe o que é role?
<conceito>
Role: Lembra da parte de modelagem de sistema? Mais precisamente, lembra da definição dos casos de uso? Lembram que para executar um UC é necessário informar o ator que o executa? Ótimo. Cada um desses atores é uma role, ou melhor, um papel que um usuário precisa ter para executar o UC.
</conceito>

Para começar, vou demonstrar a configuração de um Realm do Tomcat. O Realm que eu estou usando prevê que os dados estão em um banco de dados relacional, neste caso o PostgreSQL. Para isso é necessário a criação das tabelas no postgre.
————————————————————————————————————-
tabela_usuario
——————
coluna_login texto ficará o nome do usuário
coluna_senha texto ficará a senha do usuário

tabela_roles
——————
coluna_nome_role texto ficará o nome da role
coluna_login texto ficará o nome do usuário com acesso a role
————————————————————————————————————-
Não precisa de uma tabela de roles, porque as roles são fixas, lembra? Elas representam os atores do caso de uso, certo?
Eu sei (cof) que, às vezes, (cof, cof) não dá tempo de fazer casos de uso(cof, cof, cof). Então pega o caderno, onde você escreveu a analise do sistema, e vê quem é que pode executar esta funcionalidade. Simples, não?

Neste caso, o ream Esta configuração deve ficar em um arquivo chamado context.xml na pasta META-INF, que fica na raiz do seu WAR:

/META-INF/context.xml -------------------------------------------------------------------------

<?xml version=”1.0″ encoding=”utf-8″?>
<Context displayName=”reteste” reloadable=”true”>
<Resource name=”jdbc/stripessec”
auth=”Container”
type=”javax.sql.DataSource”
maxActive=”10″
maxIdle=”3″
username=”nome_de_usuario_do_banco”
password=”senha_do_usuario_do_banco”
driverClassName=”org.postgresql.Driver”
url=”jdbc:postgresql://localhost:5432/database_criado_no_postgre”/>

<Realm className=”org.apache.catalina.realm.DataSourceRealm” debug=”99″
dataSourceName=”jdbc/stripessec” localDataSource=”true”
userTable=”tabela_usuario”
userNameCol=”coluna_login”
userCredCol=”coluna_senha”
userRoleTable=”table_permissao”
roleNameCol=”coluna_nome_permissao” />

</Context>
---------------------------------------------------------------------------------------------

No exempo eu criei um DataSource, para um database no banco PostgreSQL, que também servirá para o resto da aplicação. E criei um Realm JDBC. Que, basicamente é falar o quais as tabelas e quais as colunas que representa os usuários e as permissões dele.

Depois do context.xml criado, escrevo, no web.xml, as informações necessárias para a aplicação usar o Realm e o DataSource:

/WEB-INF/web.xml --------------------------------------------------------------------------

<?xml version=”1.0″ encoding=”UTF-8″?>

<web-app xmlns=”http://java.sun.com/xml/ns/j2ee&#8221;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221;
xsi:schemaLocation=”http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd&#8221;
version=”2.4″>

<!– ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ –>
<!– Configuração do DataSource. –>
<!– ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ –>
<resource-ref>
<description>Web Database</description>
<res-ref-name>jdbc/stripessec</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

<!– ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ –>
<!– Configuração da autenticação e autorização. –>
<!– ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ –>

<security-constraint>
<display-name>Área Restrita</display-name>
<web-resource-collection>
<web-resource-name>Arquivos protegidos por login</web-resource-name>
<url-pattern>/jsp/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>systemuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>StripesSecRealm</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>systemuser</role-name>
</security-role>

</web-app>

---------------------------------------------------------------------------------------------

Estou disponibilizando o DataSource para o resto da aplicação e declarando o Realm, com configurado para proibir o acesso, para usuário não autenticados, aos arquivos dentro da pasta jsp, que por sua vez está na raiz do WAR. Aqui é um bom lugar para colocar uma URL comum as Actions do seu framework MVC, desta forma o acesso a elas também será proibido.

Estas são as páginas de login e de erro, respectivamente, que ficarão na raiz do meu WAR:

/login.jsp -----------------------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="pt-br">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>.:: Autenticação ::.</title>

</head>
<body>
<form method="POST" action="<%= response.encodeURL("j_security_check") %>" >
<fieldset title="Informe login e senha">
<legend>Login</legend>

<label for="j_username">Login:</label>
<input type="text" name="j_username" class="textBox"/><br/>

<label for="j_password">Senha:</label>
<input type="password" name="j_password" class="textBox"/><br/>

</fieldset>
<p align=”center”>
<input type=”submit” value=”Log In”/>
</p>
</form>
</body>
</html>
---------------------------------------------------------------------------------------------

Notem a falta total de TagLibs. Se não fosse a preocupação em garantir que vai funcionar, independente do contexto em que será feito o deploy, poderia ser um arquivo HTML.


/error.jsp ------------------------------------------------------------------------------------

<html
<head>
<title>Erro ao tentar autenticar usuário</title>
</head>
<body>

<p>

Usuário ou senha inválidos.<br/>

Verifique o nome de usuário e a senha e <a href="<%= response.encodeURL("login.jsp") %>">tente novamente</a>.

</p>

</body>
</html>

---------------------------------------------------------------------------------------------

Outra vantagem é que mesmo que seja tentado acessar a url diretamente, o container irá redirecionar para a página de login.

Após a autenticação, o container se encarrega de abrir a URL solicitada inicialmente. Este comportamento é perfeito para permitir seus usuários a colocar as partes do sistema que ele mais utiliza em seus favoritos(a.k.a. bookmarks).


Esta é a página protegida pelo Realm. :
/jsp/home.jsp -------------------------------------------------------------------------------
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<h1>Página protegida pelo Realm.</h1>
</body>
</html>

---------------------------------------------------------------------------------------------
Para acessar esta página, o usuário precisa da permissão "
systemuser”, isto é, no banco de dados, na tabela de associação entre o usuário e as roles tem que ter o login dele e o systemuser como role.

Para essa autenticação, a única dependência é o driver JDBC para o PostgreSQL, neste caso, na pasta $TOMCAT_HOME/common/lib.

  1. Alguma sugestão de melhoria nas explicações? Ficou alguma dúvida?
  2. Poderiam contribuir com formas de burlar esta autenticação? Se elas existirem?
  3. Alguma outra sugestão para o texto?

Atualmente eu tenho usado a autenticação apenas em meus freelances, uma vez que no trabalho a aplicação é desktop. Mais um motivo para eu preferir aplicações web… 😀

P.S.: Caso dê alguma caca neste post, dá um desconto, porque é o primeiro que eu publico usando o Google Docs 🙂

Instalação do Subversion no Ubuntu 7.04 – Feisty Fawn

Terminei de instalar o servidor, dos meus freelances, com o Subversion. E para ter certeza de que não vou esquecer como fazer isso, estou escrevendo o que eu fiz dos dois tutoriais que eu segui.

  1. Instalar o Ubuntu Server sem selecionar as opções de LAMP ou DNS Server
  2. No meu caso, que tem um HD de 40GB, dividi as partições da seguinte forma:
    • 255MB, swap
    • 05GB, /
    • 04GB, /usr
    • 10GB, /srv
    • 20GB, /home

    A primeira informação é o tamanho da partição e a segunda o ponto de montagem. Tirando a partição swap, estou usando o sistema de arquivos EXT3 em todas elas.

  3. Instalar o Apache e o SVN:
    • sudo apt-get install apache2 subversion libapache2-svn
  4. Criar o diretório onde ficarão os repositórios do SVN:
    • sudo mkdir /srv/svn
  5. Criar o repositório. Aqui seria um bom momento para restaurar o backup, quando for o caso:
    • sudo svnadmin create /srv/svn/{repositorio}
  6. Dar acesso ao Apache para esses diretórios:
    • sudo chown -R www-data:www-data /srv/svn
  7. Configurar o módulo webdav do subversion
    1. sudo vim /etc/apache2/mods-enabled/dav_svn.conf
    2. Descomentar a tag <Location /svn>. No início e no fim do arquivo.
    3. Descomentar a opção DAV svn
    4. Descomentar a opção SVNParentPath /var/lib/svn e mudar o caminho para a localização do repositório: /srv/svn. Foi escolhido essa ao invés da SVNPath para termos mais de um repositório nesta mesma pasta.
    5. Descomentar a opção AuthzSVNAccessFile /etc/apache2/dav_svn.authz. Para habilitar o controle de acesso aos projetos usando o arquivo informado. Mais informação sobre como criar o arquivo podem ser vistas no livro vermelho do Subversion, na seção Per-Directory Access Control. Infelizmente, na versão em português este capítulo ainda não foi traduzido.
    6. Descomentar, para habilitar a autenticação, as três linhas:
      1. AuthType Basic
      2. AuthName “Subversion Repository”
      3. AuthUserFile /etc/apache2/dav_svn.passwd
      4. Adicione a linha: Require valid-user
      5. Salve o arquivo. Para isso, aperte a tecla ESC digite “:wq” sem as aspas e pressione enter
  8. Crie um usuário para acessr o SVN:
    • sudo htpasswd -cm /etc/apache2/dav_svn.passwd <username>
    • O parâmetro -c só é necessário para o primeiro usuário, pois é usado para criar o arquivo. Para os seguintes apenas o -m resolve, que é usado para criptografar a senha com o MD5.
  9. Reiniciar o apache
    • sudo /etc/init.d/apache2 restart

Estou querendo fazer melhorias como:

Alguém teria alguma sugestão ou correção para esse tutorial ou para o script?

Fontes:

Shell-Script para backup automático dos repositórios do Subversion

Fiz um script para backup dos repositórios do Subversion.

Este script está sendo usado no Ubuntu Linux Server versão 6.10 7.04(atualizei o servidor) , mas deve funcionar na maioria das outras distros. Mesmos as que não derivam o Debian.

Para usá-lo siga os seguintes passos:

  1. Copie o script para o servidor;
  2. Configure com os diretórios de sua preferência. Isso é feito modificando as variáveis:
    1. SVN_ROOT_REPOS: diretório onde estão os repositórios do SVN;
    2. BACKUP_PATH: onde será criado os arquivos de backup.
  3. Dê permissão de execução para o scrip:
    1. chmod +x svn_backup.sh

Como melhorias que eu gostaria de adicionar:

  • Leonardo: Apagar os arquivos de dump depois que eles forem compactados. Ok
  • Garantir que somente os arquivos de dump serão gravados no zip. Ok
  • Agendar o script no cron;
  • Copiar o arquivo zipado para outro servidor;
  • Gerar um Hash MD5 para o arquivo de backup e enviar junto do arquivo;
  • Testar o arquivo recebido usando o Hash MD5.

Vocês teriam alguma sugestão? Outra funcionalidade que eu não tenha pensado? Uma forma de fazer as mesmas coisas mais facilmente?

Fontes:

P.S.: Como o WordPress não deixa eu subir arquivos .sh coloquei a extensão “doc”.

UPDATE: Saiu no BR-Linux um post com um script, em Python, para backup do Subversion e Trac.