XDocket의 사용 법은 간단하다. 코드에 JavaDoc 태그를 사용하는 것 만으로도 XDoclet 태그를 추가한 것이다. 이런 태그들은 메타데이터의 보급자로서, 다른 파일을 생성하는 것보다 XDoclet이 사용된다.
XDoclet이 어떻게 사용되는지에 대한 완벽한 예제로서 아래의 샘플을 참고하라. 이 글은 당신의 코드에 XDoclet을 충분히 사용할 만하게 해준다.
전형적인 XDoclet 주석은 이와 같다.
[CODE]/** * This is the Account entity bean. It is an example of how to use the * EJBDoclet tags. * * @see Customer * * @ejb.bean * name="bank/Account" * type="CMP" * jndi-name="ejb/bank/Account" * local-jndi-name="ejb/bank/LocalAccount" * primkey-field="id" * * @ejb.finder * signature="java.util.Collection findAll()" * unchecked="true" * * @ejb.transaction * type="Required" * * @ejb.interface * remote-class="test.interfaces.Account" * * @ejb.value-object * match="*" * * @version 1.5 */ [/CODE]
위의 주석는 세가지의 주석으로 분리되어 있다 : 일반 주석, JavaDoc 태그, XDoclet 태그.
처음 두줄은 보통 주석이다. XDoclet 을 사용한다는 것이 일반 주석을 사용하지 않음을 말하는 것은 아니다.
위의 주석의 세번째 부분에 우리는 흥미를 가진다.
어떤 XDoclet 태그는 아래와 같은 부분으로 구성되어있다.
[CODE]@namespace.tag-name attribute-name="attribute value"[/CODE]
컨셉은 XML과 유사하고, 태그 이름과 부가적으로 속성의 집합을 가진다. 차이점은 문법이다.
태그들은 namespace로 묶여 있으며, 그 namespace 안에서 유일한 이름을 가진다. 태그들은 0개 이상의 속성을 가질 수 있고, 그 각각의 속성은 이름="값" 이 쌍으로 이루어진다.
위의 예제를 보면, 첫번째 태그가 ejb namespace에 있다는 것을 찾을 수 있고, 그것은 bean을 호출한다.
이 ejb.bean 태그는 EJB와 관계있는 데이터를 정의한다. 모든 EJB는 어떤 이름을 필요로하고, 그것은 여기에 명시된다. 이 namespace는 이름의 중복이 생기지 않게하는 장치이다.
Namespace는 ejb, web, jboss, weblogic, struts 등등을 포함한다. 이것이 관계있는 태그를 묶어놓은 간단한 방법이다. 개인적이 태그의 자세한 예제는 Tag Reference를 참고하라.
[CODE]@namespace.tag-name attribute-name="attribute value"[/CODE]
태그 값은 ant 프로퍼티로 설정될수 있다. 예를 들어:
[CODE]@jboss.create-table create="${jboss.create.table}" [/CODE]
'jboss.create.table'이 ant의 어디에 프로퍼리로 선언되어야 하는가 하는 것은 Jakarta Ant Documentation을 참고하라.
태 그들은 클래스와 메서드 양쪽 레벨에 있습니다.(또한 드믄 경우에 필드나 생성자 레벨). 일반 규칙에 따라, 정보가 클래스의 이름이나 타입에 따라서 결정된다면, 그렇게 될 것이다 - 그래서 그 정보를 태그로 표시할 것을 강요하지는 않는다. 이와 같은 한 예제는 아래의 ejb.bean 태그의 type 속성이다.
이 예제의 type은 Entity type(CMP or BMP)을 참조하지만, javax.ejb.SessionBean 인터페이스를 구현한 그 클래스의 type은 Stateful 이거나 Stateless 일 것이다.
그래서 위의 예제에는 'type'은 빠질 수도 있다.
XDoclet을 사용하기 위해서는 어떤 목적으로 사용할 것인지를 우선 결정해야한다. 보통 EJBDoclet과 WEBDoclet을 사용한다. 일반적으로 Ant용 XDoclet을 사용하여 설정파라미터를 설정한다. 여기 예제가 하나 있다.
[CODE]<path id="project.class.path"> <fileset dir="${lib.dir}"> <include name="*.jar"/> </fileset> </path> <target name="ejbdoclet" depends="prepare"> <taskdef name="ejbdoclet" classname="xdoclet.modules.ejb.EjbDocletTask" classpathref="project.class.path" /> <tstamp> <format property="TODAY" pattern="d-MM-yy"/> </tstamp> <ejbdoclet destdir="${generated.java.dir}" excludedtags="@version,@author" addedtags="@xdoclet-generated at ${TODAY}" ejbspec="2.0" > <fileset dir="${java.dir}"> <include name="**/*Bean.java"/> </fileset> <dataobject/> <packageSubstitution packages="persistence" substituteWith="interfaces"/> <remoteinterface pattern="{0}Remote"/> <localinterface pattern="{0}"/> <homeinterface /> <localhomeinterface/> <entitypk/> <entitycmp/> <deploymentdescriptor destdir="${build.dir}/ejb/META-INF"/> <jboss version="3.0" securityDomain="java:/jaas/samples" preferredRelationMapping="relation-table" datasource="java:/DefaultDS" datasourcemapping="Hypersonic SQL" destdir="${build.dir}/ejb/META-INF" /> </ejbdoclet> </target> <target name="compile" depends="ejbdoclet"> <!-- Compile EJBs --> <javac srcdir="${java.dir}:${generated.java.dir}" destdir="${build.dir}/ejb" includes="test/ejb/*.java, test/interfaces/*.java" > </target>[/CODE]
여기서 컴파일 대상은 EJBDoclet 대상에 의존적이다. 모든 home/local/remote 인터페이스, 기본 키, 데이터개체, 디플로이먼트 디스크립터 등이 컴파일 된 후에 생성된다는 의미이다. 사용자가 가정 먼저 해야할 것은 Ant용 EJBDoclet 작업을 정의 하는 것이다.(뭔소리지..)
'taskdef'를 사용하려면, ejbdoclet 작업할 할 클래스를 xdoclet.modules.ejb.EjbdocletTask 로 명시하라. 'classpathref'가 ID 'project.class.path'의 경로를 가리킨다는 것을 기억하라. 이 경로에는 모든 XDoclet jar 파일과 commons-loggins.jar 파일이 존재해야한다.
다음으로 ejbdoclet 작업을 설정 파라미터와 nested 원소의 집합으로 선언한다. 예를들어 'destdir'은 생성되는 파일을 어디에 둘 것인지 명시한다. 상속매커니즘이 있음을 안다면, 'destdir'을 각각의 nested 원소에 이 'destdirㅌ의 파라미터를 오버라이드 할 수 있다.(또는 보조작업으로 호출 할 수도 있다.) (대체 뭔소리여)
<deploymentdescriptor/> 는 정확하게 ; home, remove, pk, etc용 자바소스로부터 생성된 ejb-jar.xml 파일을 어딘가에 놓아둔다. 여기에서 설정가능한 파라미터들의 완전한 목록은 Ant Task Reference를 참고하라.
각 태스크는 기본적으로 내장 서브-태스크를 포함하고 있다. 그 중 몇가지는 필수적이다, 예를 들어 <remoteinterface/>와 <localinterface/>, 원격 혹은 지역(EJB 2.0만) 인터페이스가 없는 EJB를 상상이나 할 수 있겠는가? 그 이외의 작업은 부가적일 수 있다. 예를 들면 JBoss Application Server를 사용하지 않는다면 <jboss/>는 부가적이다
다음은 서브-태스크의 세번째 <template/>이다. 자신만의 템플릿 파일을 디자인하고 만들기를 원하는 경우 유용한다. 그래서 탬플릿 파일을 사용하는 XDoclet의 간단한 사용방법이 필요할 것이다. 아래의 예제를 보자.
[CODE] <taskdef name="templatedoclet" classname="xdoclet.DocletTask" classpathref="project.class.path" /> <templatedoclet destdir="${generated.java.dir}" excludedtags="@version,@author" > <fileset dir="${java.dir}"> <include name="**/*Bean.java"/> </fileset> <template templateFile="/mytemplate.xdt" destinationfile="mygeneratedfile.txt" /> </templatedoclet> [/CODE]
이렇게 이 태스크에 <template/> 원소를 넣고, 탬플릿 파일과 출력파일 이름(destdir파라미터에 표시된 디렉토리에 저장될 것이다.)의 경로를 명시하라. 이는 capabilities나 @tag들이나 @tag 들로부터 어떤 것을 생성하는 템플릿의 집합과 같은 XDoclet 프레임워크의 이점을 간단하게 얻고 싶어하는 창조적인 사람들에게 유용할 것이다.
이와같이 빌드할때마다, ejbdoclet은 실행하고 파일들을 갱신할 것이다.
XDoclet을 실행하기 위한 점검목록:
build.xml 스크립트를 수정
소스코드에 Xdoclet 태그를 추가.
Xdoclet ..???
이 메일링리스트는 가치있는 지식들을 제공하고, 개발자들은 xdoclet 사용자 목록에 은둔해있다. 그래서 자유롭게 질문하고, 의견을 내거나 XDoclet에 대한 논쟁을 할 수 있다.
번역완료
원문 : http://xdoclet.sourceforge.net/xdoclet/using.html
XDoclet이 어떻게 사용되는지에 대한 완벽한 예제로서 아래의 샘플을 참고하라. 이 글은 당신의 코드에 XDoclet을 충분히 사용할 만하게 해준다.
전형적인 XDoclet 주석은 이와 같다.
[CODE]/** * This is the Account entity bean. It is an example of how to use the * EJBDoclet tags. * * @see Customer * * @ejb.bean * name="bank/Account" * type="CMP" * jndi-name="ejb/bank/Account" * local-jndi-name="ejb/bank/LocalAccount" * primkey-field="id" * * @ejb.finder * signature="java.util.Collection findAll()" * unchecked="true" * * @ejb.transaction * type="Required" * * @ejb.interface * remote-class="test.interfaces.Account" * * @ejb.value-object * match="*" * * @version 1.5 */ [/CODE]
위의 주석는 세가지의 주석으로 분리되어 있다 : 일반 주석, JavaDoc 태그, XDoclet 태그.
처음 두줄은 보통 주석이다. XDoclet 을 사용한다는 것이 일반 주석을 사용하지 않음을 말하는 것은 아니다.
위의 주석의 세번째 부분에 우리는 흥미를 가진다.
어떤 XDoclet 태그는 아래와 같은 부분으로 구성되어있다.
[CODE]@namespace.tag-name attribute-name="attribute value"[/CODE]
컨셉은 XML과 유사하고, 태그 이름과 부가적으로 속성의 집합을 가진다. 차이점은 문법이다.
태그들은 namespace로 묶여 있으며, 그 namespace 안에서 유일한 이름을 가진다. 태그들은 0개 이상의 속성을 가질 수 있고, 그 각각의 속성은 이름="값" 이 쌍으로 이루어진다.
위의 예제를 보면, 첫번째 태그가 ejb namespace에 있다는 것을 찾을 수 있고, 그것은 bean을 호출한다.
이 ejb.bean 태그는 EJB와 관계있는 데이터를 정의한다. 모든 EJB는 어떤 이름을 필요로하고, 그것은 여기에 명시된다. 이 namespace는 이름의 중복이 생기지 않게하는 장치이다.
Namespace는 ejb, web, jboss, weblogic, struts 등등을 포함한다. 이것이 관계있는 태그를 묶어놓은 간단한 방법이다. 개인적이 태그의 자세한 예제는 Tag Reference를 참고하라.
[CODE]@namespace.tag-name attribute-name="attribute value"[/CODE]
태그 값은 ant 프로퍼티로 설정될수 있다. 예를 들어:
[CODE]@jboss.create-table create="${jboss.create.table}" [/CODE]
'jboss.create.table'이 ant의 어디에 프로퍼리로 선언되어야 하는가 하는 것은 Jakarta Ant Documentation을 참고하라.
태 그들은 클래스와 메서드 양쪽 레벨에 있습니다.(또한 드믄 경우에 필드나 생성자 레벨). 일반 규칙에 따라, 정보가 클래스의 이름이나 타입에 따라서 결정된다면, 그렇게 될 것이다 - 그래서 그 정보를 태그로 표시할 것을 강요하지는 않는다. 이와 같은 한 예제는 아래의 ejb.bean 태그의 type 속성이다.
이 예제의 type은 Entity type(CMP or BMP)을 참조하지만, javax.ejb.SessionBean 인터페이스를 구현한 그 클래스의 type은 Stateful 이거나 Stateless 일 것이다.
그래서 위의 예제에는 'type'은 빠질 수도 있다.
XDoclet을 사용하기 위해서는 어떤 목적으로 사용할 것인지를 우선 결정해야한다. 보통 EJBDoclet과 WEBDoclet을 사용한다. 일반적으로 Ant용 XDoclet을 사용하여 설정파라미터를 설정한다. 여기 예제가 하나 있다.
[CODE]<path id="project.class.path"> <fileset dir="${lib.dir}"> <include name="*.jar"/> </fileset> </path> <target name="ejbdoclet" depends="prepare"> <taskdef name="ejbdoclet" classname="xdoclet.modules.ejb.EjbDocletTask" classpathref="project.class.path" /> <tstamp> <format property="TODAY" pattern="d-MM-yy"/> </tstamp> <ejbdoclet destdir="${generated.java.dir}" excludedtags="@version,@author" addedtags="@xdoclet-generated at ${TODAY}" ejbspec="2.0" > <fileset dir="${java.dir}"> <include name="**/*Bean.java"/> </fileset> <dataobject/> <packageSubstitution packages="persistence" substituteWith="interfaces"/> <remoteinterface pattern="{0}Remote"/> <localinterface pattern="{0}"/> <homeinterface /> <localhomeinterface/> <entitypk/> <entitycmp/> <deploymentdescriptor destdir="${build.dir}/ejb/META-INF"/> <jboss version="3.0" securityDomain="java:/jaas/samples" preferredRelationMapping="relation-table" datasource="java:/DefaultDS" datasourcemapping="Hypersonic SQL" destdir="${build.dir}/ejb/META-INF" /> </ejbdoclet> </target> <target name="compile" depends="ejbdoclet"> <!-- Compile EJBs --> <javac srcdir="${java.dir}:${generated.java.dir}" destdir="${build.dir}/ejb" includes="test/ejb/*.java, test/interfaces/*.java" > </target>[/CODE]
여기서 컴파일 대상은 EJBDoclet 대상에 의존적이다. 모든 home/local/remote 인터페이스, 기본 키, 데이터개체, 디플로이먼트 디스크립터 등이 컴파일 된 후에 생성된다는 의미이다. 사용자가 가정 먼저 해야할 것은 Ant용 EJBDoclet 작업을 정의 하는 것이다.(뭔소리지..)
'taskdef'를 사용하려면, ejbdoclet 작업할 할 클래스를 xdoclet.modules.ejb.EjbdocletTask 로 명시하라. 'classpathref'가 ID 'project.class.path'의 경로를 가리킨다는 것을 기억하라. 이 경로에는 모든 XDoclet jar 파일과 commons-loggins.jar 파일이 존재해야한다.
다음으로 ejbdoclet 작업을 설정 파라미터와 nested 원소의 집합으로 선언한다. 예를들어 'destdir'은 생성되는 파일을 어디에 둘 것인지 명시한다. 상속매커니즘이 있음을 안다면, 'destdir'을 각각의 nested 원소에 이 'destdirㅌ의 파라미터를 오버라이드 할 수 있다.(또는 보조작업으로 호출 할 수도 있다.) (대체 뭔소리여)
<deploymentdescriptor/> 는 정확하게 ; home, remove, pk, etc용 자바소스로부터 생성된 ejb-jar.xml 파일을 어딘가에 놓아둔다. 여기에서 설정가능한 파라미터들의 완전한 목록은 Ant Task Reference를 참고하라.
각 태스크는 기본적으로 내장 서브-태스크를 포함하고 있다. 그 중 몇가지는 필수적이다, 예를 들어 <remoteinterface/>와 <localinterface/>, 원격 혹은 지역(EJB 2.0만) 인터페이스가 없는 EJB를 상상이나 할 수 있겠는가? 그 이외의 작업은 부가적일 수 있다. 예를 들면 JBoss Application Server를 사용하지 않는다면 <jboss/>는 부가적이다
다음은 서브-태스크의 세번째 <template/>이다. 자신만의 템플릿 파일을 디자인하고 만들기를 원하는 경우 유용한다. 그래서 탬플릿 파일을 사용하는 XDoclet의 간단한 사용방법이 필요할 것이다. 아래의 예제를 보자.
[CODE] <taskdef name="templatedoclet" classname="xdoclet.DocletTask" classpathref="project.class.path" /> <templatedoclet destdir="${generated.java.dir}" excludedtags="@version,@author" > <fileset dir="${java.dir}"> <include name="**/*Bean.java"/> </fileset> <template templateFile="/mytemplate.xdt" destinationfile="mygeneratedfile.txt" /> </templatedoclet> [/CODE]
이렇게 이 태스크에 <template/> 원소를 넣고, 탬플릿 파일과 출력파일 이름(destdir파라미터에 표시된 디렉토리에 저장될 것이다.)의 경로를 명시하라. 이는 capabilities나 @tag들이나 @tag 들로부터 어떤 것을 생성하는 템플릿의 집합과 같은 XDoclet 프레임워크의 이점을 간단하게 얻고 싶어하는 창조적인 사람들에게 유용할 것이다.
이와같이 빌드할때마다, ejbdoclet은 실행하고 파일들을 갱신할 것이다.
XDoclet을 실행하기 위한 점검목록:
build.xml 스크립트를 수정
소스코드에 Xdoclet 태그를 추가.
Xdoclet ..???
이 메일링리스트는 가치있는 지식들을 제공하고, 개발자들은 xdoclet 사용자 목록에 은둔해있다. 그래서 자유롭게 질문하고, 의견을 내거나 XDoclet에 대한 논쟁을 할 수 있다.
번역완료
원문 : http://xdoclet.sourceforge.net/xdoclet/using.html