Problemas ao arrancar o Eclipse

Ao arrancar o Eclipse, poderá acontecer que ele não consiga arrancar derivado a algum problema.

A janela seguinte poderá ser mostrada:

Este problema de o Eclipse não conseguir arrancar deveu-se a um crash no Windows com o Eclipse aberto, que derivou num encerramento inesperado do Eclipse, o que levou a um estado inconsistente do espaço de trabalho do Eclipse.


Para começar ao olhar para o log do Eclipse (ficheiro .log localizado na directoria <localizacao_workspace>\.metadata) consegue-se emcontar o erro

!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.


Uma possível solução para a resolução do problema é a seguinte:

1. Ir à directoria <localizacao_workspace>\.metadata\plugins\org.eclipse.core.resources
2. Apagar o ficheiro .snap
3. Arrancar o eclipse

O problema ficou resolvido.

Caso não tenha ficado resolvido existem outras técnicas. Consultar, por exemplo, o link abaixo.

Referência:  http://www.lazylab.org/197/eclipse/eclipse-hanging-on-startup-repair-corrupt-workspace/

Eclipse: Alterar o valor por defeito do @author

Para alterar o valor por defeito da propriedade @author no Eclipse basta simplesmente editar o ficheiro eclipse.ini com o valor seguinte (adicionar no final do ficheiro):

-Duser.name=NovoNomeDoAutor

Por defeito o nome colocado na @author é o do utilizador logado. Se for feito conforme indicado acima, a @autor passa a conter o valor indicado após o =, neste caso NovoNomeDoAutor.

 

Como não executar testes no maven

Por vezes é necessário não executar os testes num projecto maven. 

Ou porque não é o ambiente apropriado, ou porque se está com pressa e não se quer que 

os testes executem, etc.

Através da linha de comandos é simples.

Basta especificar a opção: -DskipTests

Caso se esteja por exemplo no Eclipse e se esteja com problemas com falhas nos testes 

e se quer que o maven do Eclipse não execute os testes, então pode-se criar uma nova 

configuração de Run para o maven e aí indicar que se quer saltar os testes.

Para evitar no próprio projecto (pom.xml) que os testes sejam executados, basta 

incluir na parte dos plugins o seguinte bloco:

 <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-surefire-plugin</artifactId>
     <version>2.12</version>
     <configuration>
       <skipTests>true</skipTests>
     </configuration>
   </plugin>

Importar/Exportar preferências no Eclipse

Quando se cria um novo Workspace em Eclipse as preferências são reinicializadas e todas as configurações que se tenha feito noutro Workspace desaparecem nesse novo Workspace.

Para copiar as preferências de um outro Workspace para um novo (ou se quer fazer uma cópia de salvaguarda das preferências actuais do Eclipse) basta fazer o seguinte no Workspace do qual se quer fazer a cópia:

File -> Export -> General -> Preferences.

Pode-se especificar exactamente o que é para ser exportado.

Isto faz com que seja criado um ficheiro com as preferências.

Para importar basta, no Workspace onde se quer aplicar as preferências:

File -> Import -> General -> Preferences

e seleccionar o ficheiro do qual importar as preferências.

Recuperando ficheiros apagados no Eclipse

Eis aqui algo que dá sempre jeito saber: Como recuperar ficheiros apagados no eclipse.

Como sabem, se apagarem um ficheiro no eclipse ele não irá parar à Reciclagem. Se se aperceberem de imediato do erro, podem fazer "Undo Delete" (CTRL + Z), caso contrário existe uma solução.

Sobre o projecto (ou em qualquer package da src) no qual querem recuperar o ficheiro, cliquem com o botão da direita e escolham "Restore from Local History....". Daqui aparece uma janela, na qual, do lado esquerdo estão os ficheiros apagados. É só seleccionar os ficheiros a recuperar e clicar no botão "Restore".

E pronto, ficheiro recuperado

Atalhando no Eclipse

Para todos os que usam o Eclipse, aqui está uma maneira engraçada de começarem a ser mais produtivos. Um plugin que permite, à medida que vão usando o eclipse, interiorizar os atalhos de teclado para chegarem às funcionalidades que estão a usar, e ás quais, chegaram com o rato.

Ou seja, sempre que usarem o rato para invocar uma determinada funcionalidade (refactoring por exemplo), o plugin alerta-vos com uma tip qual o atalho a usar (no caso do refactoring ALT + SHIFT + M).

É engraçado de usar, e, parecendo que não, se não tirarem as mãos do teclado, irão ser muito mais produtivos. A interiorização dos atalhos é feito naturalmente, em vez de se andar a decorar listas de comandos que depois se esquece rapidamente.

Actualizem via install manager com o URL: http://update.mousefeed.com

Bons atalhos! :-D

Axis2 no Eclipse

Quando se corre o Axis2 Code Generator no eclipse e se obtém uma InvocationTargetException, pensa-se que é um problema nosso. Por incrível que pareça, até pode não ser. Depois de ter perdido horas neste erro, eis aqui a solução.

São necessários vários "artifícios" para se conseguir colocar o Axis2 Code Generator (versão 1.4.1) a funcionar no eclipse (versão europa).

Antes de mais referir que na realidade a versão 1.4.1 que se descarrega do site do Axis2 é a versão 1.3.0. E isto é um problema.

Para se conseguir gerar algo é necessário efectuar os seguintes passos no local onde está instalado o plugin no eclipse (...\eclipse\plugins\Axis2_Codegen_Wizard_1.3.0):

• Copiar para a pasta lib os jars seguintes:

- backport-util-concurrent-3.1.jar
- geronimo-stax-api_1.0_spec-1.0.1.jar
- jsr173_1.0_api.jar

• Copiar o seguinte para o ficheiro plugin.xml
  

<library name="lib/backport-util-concurrent-3.1.jar">
<export name="*"/>
</library>
<library name="lib/geronimo-stax-api_1.0_spec-1.0.1.jar">
<export name="*"/>
</library>
<library name="lib/jsr173_1.0_api.jar">
<export name="*"/>
</library>

• Mudar no ficheiro plugin.xml a versão de 1.3.0 para 1.4.0
  

<plugin
id="Axis2_Codegen_Wizard"
name="Axis2 Codegen Wizard Plug-in"
version="1.4.0"

• Alterar o nome da pasta do plugin para o número da nova versão (de Axis2_Codegen_Wizard_1.3.0 para Axis2_Codegen_Wizard_1.4.0)

E pronto adeus excepção e temos o eclipse a gerar que nem um doido. :-D

Actualização

Links para as libs

• jsr173_1.0
• geronimo-stax-api_1.0_spec-1.0.1
• backport-util-concurrent-3.1

Configurando o Eclipse Ganymede com o Weblogic

O servidor aplicacional Weblogic não vem com uma configuração disponível no eclipse Ganymede. Para ter o Weblogic disponível na configuração dos Servers no eclipse, é necessário fazer um update que está disponível no site:

https://eclipse-plugin.projects.dev2dev.bea.com/update

Depois de instalado, o eclipse já encontrará os servidores Weblogic.

Adicionando Itens aos Menus de Lançamento do Eclipse (XXX as)

A lógica de adicionar um novo item a um menu de Eclipse de lançamento (Run As, Debug As) deve ser feita de modo diferente de adicionar um item a um outro qualquer menu (seja menu, toolbal ou popupmenu).

Um item a ser colocado num menu de lançamento tem de estender

Forçar um Plug-In de Eclipse a Ser Carregado

Quando se desenvolve um plug-in para Eclipse (versão 3.3 ou superior) que necessita de adicionar itens a menus, e o estado destes itens dependem de condições (por exemplo a opção estar activa ou não), então, estas condições só serão verificadas se o plug-in já estiver sido carregado.

Para não obrigar o plug-in a ser carregado cada vez que o Eclipse é iniciado (gastando recursos sem necessidade), existem 2 opções que permitem que as condições sejam verificadas, mesmo se o plug-in ainda não estiver sido carregado, quando os itens têm de ser mostrados em menus:
- Uma é ter activa a opção - Activate this plug-in when one of its classes is loaded
- Outra é ter a opção na condição forcePlugInActivation a true

A opção forcePluginActivation só aparece para condições do tipo test. Se os menus estiverem a ser mal disponibilizados, pode-se forçar a criação de um teste "dummy" só para obrigar a carregar o plug-in, fazendo com que a partir daí os menus sejam correctamente disponibilizados.

Criação de Acções (Comandos) em Plug-Ins de Eclipse a Partir da Versão 3.3

As acções no Eclipse permitem estender os menus existentes, adicionar novos menus, criar botões nas toolbars, menus de popup, etc., que por sua vez podem (ou não) levar à execução de código.

As acções são essenciais na criação de novos plug-ins.

A partir da versão 3.3 do Eclipse (Europa), o mecanismo de criação de acções mudou radicalmente. Embora o mecanismo anterior de criação de acções através de actionSets ainda se mantenha, este por ser bastante limitado deve ser abandonado.

A partir de agora deve-se utilizar o mecanismo que foi baptizado de commands.

Os commands além de permitirem a separação real entre a definição de um comando e o código que o comando executa, alarga de sobremaneira as condições associadas ao comando. Estas condições permitem definir por exemplo quando um comando está visível, quando está activo, quando está acessível, etc. Os commands permitem também a reutilização em larga escala da definição do comando (coisa que com actionSets é impossível).

É necessário ter bastante cuidado quando se segue um tutorial para criação de um plug-in em Eclipse. Se já se está a desenvolver um plug-in para a versão 3.3 ou superior, então convém seguir tutoriais e exemplos que já utilizem a noção de comandos. Não é que tutoriais mais antigos eventualmente não funcionem, mas os comandos alargam e facilitam em larga escala o desenvolvimento.

Convém também notar que entre a versão 3.3 (Europa) e a 3.4 (Ganymede) a API dos comandos (e não só) sofreu alterações.

No link seguinte explica-se a noção de comandos:

http://www.ibm.com/developerworks/library/os-eclipse-3.3menu/index.html

Como criar um Plug-In de Eclipse

Eis um bom tutorial de como criar um plug-in de Eclipse:

http://www.javabeat.net/articles/26-introduction-to-eclipse-plugin-architecture-1.html

Uma boa referência, diria mesmo imprescindível, para começar a construir plug-ins em Eclipse de real qualidade, é o livro Eclipse: Building Commercial-Quality Plug-ins.

O próprio Eclipse vem com um conjunto de templates e exemplos pré-definidos que ajudam bastante no desenvolvimento de novos plug-ins.

Neste caso em particular, é bom aprender por exemplo, pois o desenvolvimento de novos plug-ins é bastante complexo e sem ser através de exemplos, tinha-se de saber bastante sobre a framework.

Para desenvolver novos plug-ins tem de se ter instalado o PDE (Plugin Development Environment)

O Eclipse na secção Help->Help Contents->Platform Plug-in Developer Guide, contém uma referência sobre o PDE e também a API completa do PDE. Esta referência é bastante útil durante o desenvolvimento de novos plug-ins.

Aqui à Gato do Tom!

Actualização

Vejam o 2º comentário. Ao que parece é uma melhor maneira de resolver o problema. Ainda não testei.
____________________________________________________________________

Bem, quando o eclipse se passa dos carretos às vezes são precisas medidas drásticas.

Num determinado projecto web, depois de configurar o TomCat no Window->Preferences->Server->Installed Runtimes, e de correr o projecto com sucesso no "Gato do Tom", passado algum tempo (sim, não é um mito, o software degrada-se...) o projecto ao compilar começou a dar um erro muito engraçado: Target runtime Apache Tomcat v5.5 is not defined.

Bem indo às propriedades do projecto, na parte do Server, ele estava lá. Contudo a mensagem aparecia na mesma. Depois de pesquisar na net por uma solução, nada encontrei que me ajudasse.

Fiz umas pesquisas na máquina local por "Gato do Tom" nos ficheiros do projecto e encontrei 2 entradas nos seguintes ficheiros:

• org.eclipse.jst.common.project.facet.core.prefs
• org.eclipse.wst.common.project.facet.core.xml

Comentei as entradas do "Gato do Tom" e voltei a abrir o projecto.

O erro desapareceu. É caso para dizer... "Aqui à Gato (do Tom)!".