[ http://jira.jboss.com/jira/browse/JBAS-334?page=comments#action_12311484 
]
     
SourceForge User commented on JBAS-334:
---------------------------------------


Attachment
SourceForge Username: igorfie.
Description: deployer that works with JBoss 3.2.
Filename: eclipse-deployer.sar.
URL:https://sourceforge.net/tracker/download.php?group_id=22866&atid=376687&file_id=43317&aid=639141

> Eclipse deployer
> ----------------
>
>          Key: JBAS-334
>          URL: http://jira.jboss.com/jira/browse/JBAS-334
>      Project: JBoss Application Server
>         Type: Patch
>     Reporter: SourceForge User
>     Assignee: Scott M Stark

>
>
> SourceForge Submitter: igorfie .
> Attached eclipse-deployer.sar contains both .class 
> and .java files. It is compiled for JBoss 4.0, if anyone 
> interested I'll attach version for 3.x. Following is a 
> content of corresponding README file
> Rational.
> Consider the following approximation of development 
> process using jboss 
> and eclipse:
> 1. you write you code
> 2. you run ant script that
>   + runs XDocLet to generate code and deployment 
> descriptiors
>   + compiles the code
>   + packages the code together with all required jars
>     into ear file (or single jar)
>   + copies packaged ejb into SERVER/deploy
> 3. jboss hot/re/deploys your ejb
> 4. you debug your code
> 5. you repeat steps 1-4 until you are happy with the 
> code.
> The major problem with this process is significant time 
> (in order of 
> minutes for non-trivial projects) necessary to execute 
> steps 2 and 3 
> and proposed eclipse deployer tries to address this 
> issue. Here how
> improved process would look like:
> 1. you write you code and rely on eclipse's autobuild to 
> compile it
> 2. from time to time you run XDocLet and compile 
> generated code in 
>    eclipse
> 3. jboss hot/re/deploys your ejb; alternatively, eclipse 
> can do
>    hot code replace with jdk 1.4+
> 4. you debug your code
> 5. you repeat steps 1-4 until you are happy with the 
> code.
> See TODO for current problems/limitations.
> Installation and configuration.
> Drop eclipse-deployer.sar into SERVER/deploy 
> directory. This installs
> two additional MBeans "jboss.eclipse:service=Deployer" 
> and
> "jboss.eclipse:service=EJBDeployer". No special 
> configuration is
> required.
> You do not need to configure anything in Eclipse at the 
> moment. In fact,
> eclipse does not have to be running to use the deployer.
> Eclipse project structure.
> Make sure that one of project's source folders has 
> META-INF directory
> with appropriate ejb-jar.xml and jboss.xml. For example, 
> most of my
> projects have the following layout
> project/
>   src/
>   generated/
>     META-INF/
>       ejb-jar.xml
>       jboss.xml
> This way eclipse will automatically maintain ejb-jar-like 
> file
> structrure in project's output folder.
> Deployment.
> You have to feed your project's location to MainDeployer 
> somehow. There are
> few options available -- via JMX console, via
> SERVER/conf/jboss-service.xml or using 
> JBOSS_HOME/bin/deployer.bat.
> Regardless of the way you choose, eclipse deployer will 
> deploy your
> project as well as all other projects and jar files specified 
> in
> project's build path.
> Redeployment.
> This part sucks at the moment. You must use JMX 
> console to access MainDeployer
> and you must invoke "redeploy" with exact resolved URL 
> of your project. For 
> example, on my windows machine even though I used 
> "s:\eclipse.workspace\ejbs\" as a parameter to 
> MainDeployer.deploy invocation,
> I have to specify "file:/S:/eclipse.workspace/ejbs" as a 
> parameter to 
> MainDeployer.redeploy (note "s"=>"S", "\"=>"/" and no 
> trailing slash).
> See TODO for other problems with redeployment and 
> some ideas that might be
> used to improve the situation.
> Controlling what gets deployed.
> There are cases when a jar file is needed during compile 
> time but must
> not be deployed into JBoss. Example of such files is 
> ejb.jar
> (definition of standard EJB interfaces). In order to prevent 
> deployment
> of such kind of libraries you need to create a 
> file ".classpath.jboss"
> in your project's root directory that defines what should 
> *not* be
> deployed. Here is an example:
> ============= .classpath.jboss =============
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath-filter>
>   <excludes kind="workspace" path="/test-
> project/libs/junit.jar"/>
>   <excludes kind="var" path="ORACLE_JDBC"/>
> </classpath-filter>
> ============= .classpath.jboss =============

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to