O IBM® SCLM Developer Toolkit
fornece a capacidade de gerenciar, construir e implementar os projetos Eclipse
no SCLM. Para utilizar esse recurso, você deve primeiro mapear o projeto Eclipse para o SCLM. Para mapear um projeto Eclipse para o SCLM, selecione o projeto, clique com o botão do mouse e selecione Equipe- (Team-)>Compartilhar Projeto (Share Project).
Usando a função Compartilhar Projeto, você pode obter o projeto Java™ do
ambiente de trabalho do Eclipse e mapeá-lo para o provedor de serviços da equipe SCLM. Cada arquivo de origem Java ,
junto a arquivos relacionados como .properties e .xml podem,
então, ser gerenciados pelo SCLM e armazenados como membros no servidor.
Nota: Uma opção
é fornecida no ISPF principal baseada no painel SCLM que pode ser usado para criar um
projeto SCLM para controlar o COBOL tradicional e a origem PL/I. Você pode usar isso
como um ponto de partida para desenvolver seu próprio projeto SCLM.
Essa forma de estrutura do projeto múltiplo
não é mapeada diretamente para o SCLM. Associar um projeto SCLM a outro projeto SCLM para fornecer algum formulário de estrutura do projeto agregada
é uma desvantagem porque o SCLM na realidade não mapeia dependências de projeto cruzadas. Entretanto, manter toda a origem relacionada em um projeto SCLM único, significa que o SCLM manterá dependências e, portanto, saberá o efeito em uma parte se uma outra parte relacionada
for alterada. O SCLM fornece meios pelos quais é possível suportar essa estrutura de
projetos múltiplos dentro de um projeto SCLM único.
Os projetos SCLM podem ser definidos com tipos de origem
múltipla. Cada tipo pode conter um projeto único.
Se tentássemos armazenar projetos Eclipse múltiplos no SCLM
sem alguma forma de segregação, então, os arquivos .classpath e
.project de cada projeto seriam sobrescritos como se cada projeto fosse incluído no SCLM. A utilização de tipos de origens diferentes permite
que esses arquivos, e todos os outros associados a esse projeto, sejam armazenados
com segurança no SCLM.
Por exemplo:
Esse mapeamento resultaria no armazenamento independente dos projetos dentro
do SCLM, usando o tipo como o principal diferenciador:
Por exemplo, o EJB1 é armazenado no projeto SCLM, SCLMPRJ1, no tipo EJB1.
Usando essa estrutura, você pode "mapear" a estrutura do projeto para tipos independentes dentro do projeto SCLM.
Nota: - Não é necessário mapear um nome de projeto no
IDE para o nome do tipo SCLM. Esses nomes existem independentemente um do outro.
- Os nomes de tipos são restritos a oito caracteres, portanto um projeto chamado "Novo
projeto sem erros" não poderia ter o nome de tipo correspondente "Novo projeto
sem erros". É preciso usar a imaginação: "SEMERROS"!
Portanto, é importante que a estrutura do projeto
SCLM seja planejada para acomodar o mapeamento de diferentes projetos baseados em
IDE para a estrutura do projeto SCLM único. Isso se deve ao fato de que, em projetos SCLM
grandes, a inclusão de tipos de projetos adicionais pode não ser uma questão trivial, já
que isso requer uma alteração na definição do projeto SCLM, uma reconstrução da definição
do projeto SCLM e a alocação de conjuntos de dados para os novos tipos.
Essa forma de estrutura não está restrita a projetos no estilo J2EE, mas pode também
se aplicar a qualquer situação em que vários projetos estão sendo desenvolvidos, com
alguma forma de dependência entre eles.
O uso de tipos SCLM múltiplos para armazenar projetos individuais também refere-se à
operação da estrutura ARCHDEF para a construção desses projetos.
O arquivo ARCHDEF contém a lista de arquivos
que compõem uma construção. No contexto J2EE, uma construção pode resultar em um arquivo EAR
que é composto de uma série de arquivos WAR e JAR. Esse isolamento de projetos é
semelhante à estrutura de tipos que define o projeto no SCLM. Tendo um ARCHDEF de alto nível que referencia as partes que compõem a construção, você pode ter um ambiente de construção estruturado.
Isso está relacionado à definição
eficiente da estrutura do projeto ao definir os tipos no SCLM.
A definição de projeto de um modo
estruturado também permite:
- Migração de arquivos de um tipo de projeto SCLM ou ARCHDEF para um projeto,
sem a necessidade de conhecer partes individuais.
- A estrutura ARCHDEF baseada na definição de tipo também
permite que as dependências do projeto sejam mapeadas com mais eficiência. É comum
que os projetos se refiram a outros projetos na área de trabalho. O uso da palavra-chave SCLM INCL em ARCHDEFs suporta o conceito que os outros projetos, referenciados por outros ARCHDEFS, podem ser incluídos
pelo aninhamento de ARCHDEFs em ARCHDEFs de nível mais alto.
- Ao construir aplicativos com referências
ou dependências em outros objetos de construção, como JARs, outros projetos ou outras
classes, há várias abordagens:
- O projeto deve referir-se a um JAR, mas não espera-se que seja parte
do pacote de construção final, então, o arquivo de biblioteca pode ser copiado para o sistema
CLASSPATH usando o serviço de Upload JARS no Developer Toolkit. Como efeito disso, esse serviço será disponibilizado a partir de um
projeto SCLM diferente. No tempo de construção, as referências do projeto ao JAR serão resolvidas. Entretanto, no tempo de execução, o JAR deverá estar disponível em uma
instrução PATH.
- Referencie um JAR que esteja no mesmo projeto SCLM
utilizando a propriedade CLASSPATH_JARS_FILES no script de construção.
- Incluir a referência ao JAR por meio da instrução INCLD no
ARCHDEF. Isso construirá o aplicativo com a referência de biblioteca no
pacote de construção final.
- Incluir o projeto como um projeto ARCHDEF aninhado do INCL SCLM.
- Incluir o JAR dependente no diretório CLASSPATH
Recomendações
- Identifique a composição do projeto J2EE em termos de EJBs, aplicativos da Web etc.,
para que essa estrutura seja definida e possa ser utilizada para planejar a estrutura do
projeto SCLM
- Para cada componente do projeto J2EE, crie um tipo correspondente no
projeto SCLM. É útil oferecer alguma
forma de convenção de nomenclatura significativa para suportar isso.
- Como podem ocorrer alterações nos requisitos do projeto, vale a pena criar definições
de tipos adicionais para permitir uniformidade adicional de outros componentes (como EJBs
adicionais). Serviços adicionais podem ser previstos por meio da estrutura de
tipos.
- Você pode nomear os projetos independentemente do tipo SCLM, mas algumas correlações
facilitarão a administração.
- O mapeamento de projetos múltiplos para um projeto SCLM único é suportado pela construção de tipos. É útil também aplicar uma estrutura de
pacotes que considere a definição de tipo para esse projeto.
- As convenções de pacote no estilo Java também devem ser definidas no nível de projeto
para evitar a probabilidade de conflitos de nomenclatura de origem.
- Se o ambiente de desenvolvimento IDE estiver estruturado com projetos múltiplos,
aconselha-se replicar essa estrutura no SCLM utilizando tipo.