RE: need to build a SAR file not a JAR file

[Ballard, Ken]

Brad,

There's a Maven SAR plugin. See:
http://docs.codehaus.org/display/SM/Maven+SAR+plugin. Does this help you?

Thanks,
Ken 

-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 02, 2006 12:25 AM
To: Maven Users List
Subject: need to build a SAR file not a JAR file

Hey there,

I'm need to build a SAR file for JBoss deployment, which is essentially the
same as a JAR file, with a different extension (.sar rather than .jar). Can
someone tell me how this can be accomplished?  Thanks!

Brad

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: need to build a SAR file not a JAR file

[Ballard, Ken]

Sorry for my previous post. Henry's response is more current.

Ken 

-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 02, 2006 12:25 AM
To: Maven Users List
Subject: need to build a SAR file not a JAR file

Hey there,

I'm need to build a SAR file for JBoss deployment, which is essentially the
same as a JAR file, with a different extension (.sar rather than .jar). Can
someone tell me how this can be accomplished?  Thanks!

Brad

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[M2] [M1] Multiproject dependencies question

[Ballard, Ken]

This is a question for Maven 1  2, although I know that the answers will be
different.

Let's say that I have a multiproject with subprojects. Some build jars, one
builds a war, a couple that build an ejb jar and an ejb client jar, and one
builds an ear. Now let's say that I need the Spring jar in a jar subproject
or two, the war subproject, an ejb subproject, and the ear subproject. When
I upgrade to Spring 1.2.6, I need to go upgrade all the project.xml (M1) or
pom.xml (M2) files. There's a good chance for missing something there. In
M1, I could define custom property in the project.properties file like
spring.jar.version. But would this be the best practice, or is there a
better way? And what about M2, which doesn't use a project.properties file?

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Missing something about reports

[Ballard, Ken]

Howard,

I was pleasantly surprised to see your post on the Maven mailing list. After
reading a blog you wrote a while back (Moving Away from Maven from
http://howardlewisship.com/blog/2004/05/moving-away-from-maven.html), I
figured that you were moving your projects away from Maven. Am I right to
assume that you are giving it another chance? I think that the more good
projects that use Maven the better Maven will become. Although I haven't
used Tapestry or Hivemind, I've heard a lot of good things. So I hope that
my reading of a Ship-Maven rapprochement are correct.

Thanks,
Ken

-Original Message-
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 18, 2005 2:15 PM
To: Maven Users List
Subject: Re: Missing something about reports

Sure ... looks like just the wrong version for me; I'll try some other
reports and see if I get correct results.

Besides ${project}, are there any other special symbols that can go in
site.xml?

On 11/18/05, Vincent Massol [EMAIL PROTECTED] wrote:
 Hi Howard,

  -Original Message-
  From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
  Sent: vendredi 18 novembre 2005 18:02
  To: users@maven.apache.org
  Subject: Missing something about reports
 
  So, I'm missing something about reports.
 
  I want to include a clover report in my site documentation.
 
  I've added an entry to my pom.xml:
 
 plugin
 artifactIdmaven-clover-plugin/artifactId
 /plugin
 
  And my site.xml includes ${projects} (the standard set do appear).
 
  However, nothing about Clover appears when I run the site goal, and 
  nothing appears in target/site:

 [snip]

 Not sure what's wrong. I've just tried it on a sample I have and it 
 worked fine for me.

 That said you're probably using the first alpha version of the plugin. 
 I've made several improvements to it since then but they are currently 
 in svn trunk. Also you should know that currently the Clover plugin 
 works only with Maven 2.0.1 as there's a bug in Maven 2.0 that prevents it
from working.
 We're trying to find a workaround so that the first released version 
 of the Clover plugin works with Maven 2.0.

 So I see 2 options for you:
 a) wait till the next version of the clover plugin (should be 
 relatively quick now - I'd say within a 2 weeks time frame)
 b) build m2 from svn trunk.

 All that said your problem may be coming from something else too but I 
 don't have any idea right now about what it could be...

 Thanks
 -Vincent


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support and project work.
http://howardlewisship.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [M2] How to designate what classes go in the ejb client jar

[Ballard, Ken]

Done. It's http://jira.codehaus.org/browse/MNG-1477. Thanks, Brett.

Ken 

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 08, 2005 8:39 PM
To: Maven Users List
Subject: Re: [M2] How to designate what classes go in the ejb client jar

It seems the excludes weren't made configurable as they should have been.
Can you file a request in JIRA?

- Brett

On 11/9/05, Ballard, Ken [EMAIL PROTECTED] wrote:
 In M1.0.2, I put this:

 maven.ejb.client.base.excludes=**/*EJB.class,**/*Bean.class,**/*CMP.cl
 ass,** /*Session.class,**/*LocalHome.class,**/*Local.class

 in my project.properties. Does anyone know how to achieve this in M2?

 Thanks,
 Ken

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[M2] How to designate what classes go in the ejb client jar

[Ballard, Ken]

In M1.0.2, I put this:

maven.ejb.client.base.excludes=**/*EJB.class,**/*Bean.class,**/*CMP.class,**
/*Session.class,**/*LocalHome.class,**/*Local.class

in my project.properties. Does anyone know how to achieve this in M2?

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[M1.0.2] Question about best practice for SNAPSHOT jars

[Ballard, Ken]

We're periodically deploying SNAPSHOT verions so that developers can work on
projects that depend on projects that are being actively developed and get
the latest changes. It works, but the problem is that with developers using
jar:deploy (or ear:deploy, etc) themselves to deploy their artifacts to the
remote repository, nothing prevents them from deploying artifacts that are
compiled from source that hasn't been checked in. If we have CruiseControl
deploy our SNAPSHOT artifacts then we know everything that is being shared
has been checked in. Does this sound like a best practice or am I missing
the point? It wouldn't put CruiseControl on the critical path because it
wouldn't be used to deploy officially versioned artifacts. Does anyone know
of a better way?

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[M102] SCM plugin and multiprojects

[Ballard, Ken]

Say you have a multiproject like this

mymultiproject
+- project.xml
+- project.properties
+- common/
|  +- project.xml
|  +- project.properties
+- subprojecta
|  +- src/
|  |  +- main/
|  |  |  +- java/
|  |  |  |  +- com
|  |  |  |  |  +- ...
|  |  |  +- resources/
|  |  +- site/
|  |  |  +- xdoc/
|  |  +- test/
|  | +- java/
|  |+- com
|  |   +- ...
|  +- target/
|  +- project.xml
+- subprojectb
   +- src/
   |  +- main/
   |  |  +- java/
   |  |  |  +- com
   |  |  |  |  +- ...
   |  |  +- resources/
   |  +- site/
   |  |  +- xdoc/
   |  +- test/
   | +- java/
   |+- com
   |   +- ...
   +- target/
   +- project.xml

The currentVersion element is in common/project.xml, but when I run the
scm plugin from mymultiproject to tag it and set the version, it adds a new
currentVersion element to mymultiproject/project.xml with the new current
version. The mymultiproject/project.xml extends common/project.xml with the
line extendcommon/project.xml/extend. So after running the plugin,
mymultiproject/project.xml has the new currentVersion element that the scm
plugin added and is accurate. But it also has the currentVersion element
that it gets by extending common/project.xml which is no longer accurate. I
can live with the plugin adding a new currentVersion element to
mymultiproject/project.xml, but I need to make sure it's consistent with the
one in common/project.xml. Is there a way to do that? I suppose I could
script it in my maven.xml, but I want to make sure there isn't a way to do
this without scripting before I go down that path. Or should I not be using
the scm plugin this way with multiprojects?

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[m102] unreleased scm plugin 1.5.1

[Ballard, Ken]

I know I can get the unreleased scm plugin 1.5.1 out of subversion, but I
don't know where that subversion repository is. This is probably a really
dumb question, but can someone tell me where that repository is?

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [M1.0.2] SCM plugin

[Ballard, Ken]

Cool! Thanks for the reply, Brett. I'll post any other questions or comments
on the SCM plugin mailing list.

Regards,
Ken

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 07, 2005 6:37 PM
To: Maven Users List
Subject: Re: [M1.0.2] SCM plugin

We'd accept that change as a patch to the SCM plugin, since that's how the
m2 release plugin works.

- Brett

On 10/8/05, Ballard, Ken [EMAIL PROTECTED] wrote:
 I'm using the SCM plugin to do versioned releases and I love it. I 
 have a question that I wanted to ask so that I don't go scripting 
 something in my maven.xml that I didn't need to script. Here's my 
 situation: after I've used the SCM plugin to set the version and tag, I
want the currentVersion
 element in my project.xml file to be set to SNAPSHOT (maybe at some 
 point we'll want to distinguish between 1.2-SNAPSHOT and 1.3-SNAPSHOT, 
 but for now we don't need to). I want to do this because 
 deploy-snapshot has been deprecated and because it communicates that 
 once you make a change to the code that was versioned and tagged, 
 you're building SNAPSHOTs rather than the version that you previously
released.

 It would really be helpful to hear opinions (especially from people 
 that worked on the SCM plugin) before I write the script.

 Thanks,
 Ken

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[M1.0.2] SCM plugin

[Ballard, Ken]

I'm using the SCM plugin to do versioned releases and I love it. I have a
question that I wanted to ask so that I don't go scripting something in my
maven.xml that I didn't need to script. Here's my situation: after I've used
the SCM plugin to set the version and tag, I want the currentVersion
element in my project.xml file to be set to SNAPSHOT (maybe at some point
we'll want to distinguish between 1.2-SNAPSHOT and 1.3-SNAPSHOT, but for now
we don't need to). I want to do this because deploy-snapshot has been
deprecated and because it communicates that once you make a change to the
code that was versioned and tagged, you're building SNAPSHOTs rather than
the version that you previously released. 

It would really be helpful to hear opinions (especially from people that
worked on the SCM plugin) before I write the script.

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Versioning

[Ballard, Ken]

I'd like to only declare a version number in one place. Given the
opportunity, we'll mix them up at some point if the potential exists. I'd
rather not have to tag it with a version number in our SCM and give it a
version number in Maven. I'd like to only worry about incrementing the
version number in one place. Can that be done?

Thanks,

Ken Ballard

DFS Java Team Lead, NCLeads

ACS Government Healthcare Solutions

919.855.5756

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Versioning

[Ballard, Ken]

CVS and Subversion support keyword setting:

Like CVS, Subversion supports keywords that can be expanded in files, such
as $Id$, $Date$, $Revision$, etc. By default, these properties
(svn:keywords) are not set on files
[http://www.middleware.vt.edu/doku.php?id=middleware:subversion]. 

Could I use one of these keywords like the one for version id $Id$ and maybe
%revision$ in the currentVersion element of my project.xml files so that
the version numbering is driven by Subversion rather than me trying to keep
the Subversion version number in sync with my Maven version number?

Thanks,
Ken

-Original Message-
From: dan tran [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 30, 2005 12:53 PM
To: Maven Users List
Subject: Re: Versioning

Ken,
 Could you elaborate more in one place? like in one pom, and have all sub
poms to inherite it?
If so, you are not alone. Currently, you have to declare at least the
parent's pom version for each sub pom.
 I doubt you can get away not tagging the SCM. without the tag, you can't
retreive the exact source to reproduce the artifact.
 Hope it helps.
 -D
 On 9/30/05, Ballard, Ken [EMAIL PROTECTED] wrote:

 I'd like to only declare a version number in one place. Given the 
 opportunity, we'll mix them up at some point if the potential exists. 
 I'd rather not have to tag it with a version number in our SCM and 
 give it a version number in Maven. I'd like to only worry about 
 incrementing the version number in one place. Can that be done?

 Thanks,

 Ken Ballard

 DFS Java Team Lead, NCLeads

 ACS Government Healthcare Solutions

 919.855.5756

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Versioning

[Ballard, Ken]

Aha! I was hoping it did that. I must have misread the plugin specs. I'll
look at the SCM plugin again. Thanks!

-Original Message-
From: Doug Douglass [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 30, 2005 2:17 PM
To: Maven Users List
Subject: Re: Versioning

Ballard, Ken wrote:

CVS and Subversion support keyword setting:

Like CVS, Subversion supports keywords that can be expanded in files, 
such as $Id$, $Date$, $Revision$, etc. By default, these properties
(svn:keywords) are not set on files
[http://www.middleware.vt.edu/doku.php?id=middleware:subversion]. 

Could I use one of these keywords like the one for version id $Id$ and 
maybe %revision$ in the currentVersion element of my project.xml 
files so that the version numbering is driven by Subversion rather than 
me trying to keep the Subversion version number in sync with my Maven
version number?

Thanks,
Ken

  

Ken,

Unless I'm missing what you're trying to accomplish, doesn't the SCM plugin,
in m1 at least, accomplish what you're after. When you execute maven
scm:prepare-release, it prompts for a version and a tag and updates both the
project.xml (currentVersion and versions) and SCM.

If you could accomplish using the CVS keywords in currentVersion, do you
really want every checkin of project.xml to produce new artifact versions?
This seems a lot more problematic then just using a SNAPSHOT version until
a release is ready, then using scm:prepare-release.

DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[M1] dist plugin

[Ballard, Ken]

All,

Quick question. Can I use the dist plugin to do a source distribution
(dist:deploy-src) to my local repository? I wasn't able to get it to work.
Can it be used for this? Am I using the wrong plugin?

Thanks,
Ken


Ken Ballard

DFS Java Team Lead, NCLeads

ACS Government Healthcare Solutions

919.855.5756

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [M1] dist plugin

[Ballard, Ken]

I thought it was working, but it's not. It puts the distributions directory
at the base of my project not in my local repository. Does anybody have an
example for this? I have this in my project.properties

...
maven.repo.list=R1
#settings for repository 'R1'
maven.repo.R1=file://C:\\Documents and Settings\\kballard\\.maven
maven.repo.R1.directory=repository
... 

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 16, 2005 9:20 AM
To: 'Maven Users List'
Subject: RE: [M1] dist plugin

I got it to work. False alarm. 

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED]
Sent: Friday, September 16, 2005 9:16 AM
To: 'users@maven.apache.org'
Subject: [M1] dist plugin

All,

Quick question. Can I use the dist plugin to do a source distribution
(dist:deploy-src) to my local repository? I wasn't able to get it to work.
Can it be used for this? Am I using the wrong plugin?

Thanks,
Ken


Ken Ballard

DFS Java Team Lead, NCLeads

ACS Government Healthcare Solutions

919.855.5756

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [M1] dist plugin

[Ballard, Ken]

Got it to work:

...
maven.repo.list=R1
#settings for repository 'R1'
maven.repo.R1=file://c
maven.repo.R1.directory=/Documents and Settings/kballard/.maven/repository
... 

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 16, 2005 10:14 AM
To: 'Maven Users List'
Subject: RE: [M1] dist plugin

I thought it was working, but it's not. It puts the distributions directory
at the base of my project not in my local repository. Does anybody have an
example for this? I have this in my project.properties

...
maven.repo.list=R1
#settings for repository 'R1'
maven.repo.R1=file://C:\\Documents and Settings\\kballard\\.maven
maven.repo.R1.directory=repository
... 

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED]
Sent: Friday, September 16, 2005 9:20 AM
To: 'Maven Users List'
Subject: RE: [M1] dist plugin

I got it to work. False alarm. 

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED]
Sent: Friday, September 16, 2005 9:16 AM
To: 'users@maven.apache.org'
Subject: [M1] dist plugin

All,

Quick question. Can I use the dist plugin to do a source distribution
(dist:deploy-src) to my local repository? I wasn't able to get it to work.
Can it be used for this? Am I using the wrong plugin?

Thanks,
Ken


Ken Ballard

DFS Java Team Lead, NCLeads

ACS Government Healthcare Solutions

919.855.5756

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [ANN] Article on building J2EE projects with Maven 1.1

[Ballard, Ken]

Vincent,

I tried to check out the source from SVN, but it doesn't seem to all be
there. I could be checking it out incorrectly. Could you check if you get a
chance.

Thanks,
Ken

P.S.
Great article! 

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 09, 2005 7:29 AM
To: 'Maven Users List'
Subject: [ANN] Article on building J2EE projects with Maven 1.1

Just wanted to let you know that my article about building J2EE projects
with Maven is up on http://www.onjava.com/pub/a/onjava/2005/09/07/maven.html

Warning: It requires Maven 1.1 beta 2 which will be out in the coming few
days.

Cheers,
-Vincent
Check http://www.mavenbook.org for Maven tips


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [ANN] Article on building J2EE projects with Maven 1.1

[Ballard, Ken]

Vincent,

Sorry, I was doing something incorrectly. Thanks for checking though! 

Thanks,
Ken
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 09, 2005 9:51 AM
To: 'Maven Users List'
Subject: RE: [ANN] Article on building J2EE projects with Maven 1.1

Hi Ken,

 -Original Message-
 From: Ballard, Ken [mailto:[EMAIL PROTECTED]
 Sent: vendredi 9 septembre 2005 15:44
 To: 'Maven Users List'
 Subject: RE: [ANN] Article on building J2EE projects with Maven 1.1
 
 Vincent,
 
 I tried to check out the source from SVN, but it doesn't seem to all 
 be there. I could be checking it out incorrectly. Could you check if 
 you get a chance.

I've just tried it again and it works for me. The URL is
http://www.mavenbook.org/svn/mdn/code/j2ee

Thanks
-Vincent


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [ANN] Maven EJB Plugin 1.7 released

[Ballard, Ken]

 The old way of specifying a dependency on an ejb-client jar doesn't seem to
work anymore. Is there a new way to do it? Here's how I did it before for a
war project:

dependency
  groupIdmyStuff/groupId
  artifactIdmyStuff-blah-ejb/artifactId
  version1.0/version
  properties
war.bundletrue/war.bundle
war.manifest.classpathtrue/war.manifest.classpath
  /properties
/dependency

Any suggestions?

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED] 
Sent: Saturday, August 27, 2005 10:24 AM
To: users@maven.apache.org; dev@maven.apache.org
Subject: [ANN] Maven EJB Plugin 1.7 released

We are pleased to announce the Maven EJB Plugin 1.7 release! 

http://maven.apache.org/reference/plugins/ejb/

EJB Plugin for Maven 

Changes in this version include:

  Fixed bugs:

o Make the ejb creation work even if there are not sources. 
o Fixed default property values in the web site documentation. Issue: 
  MPEJB-12. 
o EJB client jar can now be generated and deployed/installed automatically
by
  the standard goals ( ejb, ejb:ejb, ejb:installand ejb:deploy). Previous
  goals dedicated to ejb client have been deprecated. There is a new
property
  maven.ejb.client.generatewhich decides whether or not to generate the ejb
  client jar. It defaults to true. Issue: MPEJB-2. 
o Added new EJB type handler that supports ejband ejb-clienttypes. This
fixes
  the bug with ejb:install/deploy-clientnot uploading the client jar. Issue:

  MPEJB-16. Thanks to H�¯�¿�½vard Bj�¯�¿�½stad. 

  Changes:

o By default do not generate client EJB. I believe this is a more common
  default that generating as generation of client EJBs is only required for
  distributed apps which are not so common.  

To automatically install the plugin, type the following on a single line:

maven plugin:download
  -Dmaven.repo.remote=http://www.ibiblio.org/maven,
http://cvs.apache.org/repository/
  -DgroupId=maven
  -DartifactId=maven-ejb-plugin
  -Dversion=1.7

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-ejb
-plugin-1.7.jar
 

Have fun!
-The Maven EJB Plugin development team
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [ANN] Maven EJB Plugin 1.7 released

[Ballard, Ken]

I see the ejb-clients folder in my repository, but ejb-install seems to put
the client jar in the ejbs folder.

Thanks,
Ken 

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 31, 2005 10:08 AM
To: 'Maven Users List'
Cc: '[EMAIL PROTECTED]'
Subject: RE: [ANN] Maven EJB Plugin 1.7 released

 The old way of specifying a dependency on an ejb-client jar doesn't seem to
work anymore. Is there a new way to do it? Here's how I did it before for a
war project:

dependency
  groupIdmyStuff/groupId
  artifactIdmyStuff-blah-ejb/artifactId
  version1.0/version
  properties
war.bundletrue/war.bundle
war.manifest.classpathtrue/war.manifest.classpath
  /properties
/dependency

Any suggestions?

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 27, 2005 10:24 AM
To: users@maven.apache.org; dev@maven.apache.org
Subject: [ANN] Maven EJB Plugin 1.7 released

We are pleased to announce the Maven EJB Plugin 1.7 release! 

http://maven.apache.org/reference/plugins/ejb/

EJB Plugin for Maven 

Changes in this version include:

  Fixed bugs:

o Make the ejb creation work even if there are not sources. 
o Fixed default property values in the web site documentation. Issue: 
  MPEJB-12. 
o EJB client jar can now be generated and deployed/installed automatically
by
  the standard goals ( ejb, ejb:ejb, ejb:installand ejb:deploy). Previous
  goals dedicated to ejb client have been deprecated. There is a new
property
  maven.ejb.client.generatewhich decides whether or not to generate the ejb
  client jar. It defaults to true. Issue: MPEJB-2. 
o Added new EJB type handler that supports ejband ejb-clienttypes. This
fixes
  the bug with ejb:install/deploy-clientnot uploading the client jar. Issue:

  MPEJB-16. Thanks to H�¯�¿�½vard Bj�¯�¿�½stad. 

  Changes:

o By default do not generate client EJB. I believe this is a more common
  default that generating as generation of client EJBs is only required for
  distributed apps which are not so common.  

To automatically install the plugin, type the following on a single line:

maven plugin:download
  -Dmaven.repo.remote=http://www.ibiblio.org/maven,
http://cvs.apache.org/repository/
  -DgroupId=maven
  -DartifactId=maven-ejb-plugin
  -Dversion=1.7

For a manual installation, you can download the plugin here:
http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-ejb
-plugin-1.7.jar
 

Have fun!
-The Maven EJB Plugin development team
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [ANN] Maven EJB Plugin 1.7 released

[Ballard, Ken]

No problem. Thanks, Vincent. 

-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 31, 2005 11:07 AM
To: 'Maven Users List'
Subject: RE: [ANN] Maven EJB Plugin 1.7 released

Hi Ken,

 -Original Message-
 From: Ballard, Ken [mailto:[EMAIL PROTECTED]
 Sent: mercredi 31 août 2005 16:08
 To: 'Maven Users List'
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: [ANN] Maven EJB Plugin 1.7 released
 
  The old way of specifying a dependency on an ejb-client jar doesn't 
 seem to work anymore. Is there a new way to do it? Here's how I did it 
 before for a war project:
 
 dependency
   groupIdmyStuff/groupId
   artifactIdmyStuff-blah-ejb/artifactId
   version1.0/version
   properties
 war.bundletrue/war.bundle
 war.manifest.classpathtrue/war.manifest.classpath
   /properties
 /dependency
 
 Any suggestions?

You need to specify the type:

typeejb-client/type

We need to add documentation for this. Also be careful that you need Maven
1.1 for this to work. This should have been specified in the release
notes... Sorry about that.

-Vincent


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Source dependency

[Ballard, Ken]

 I have a question about two of my projects. One is an interfaces and domain
beans project and the other is the implementations of those interfaces. The
interfaces and domain beans project jar goes on the client and both go on
the server. I need to run hibernate doclet to generate the hbm.xml files for
the domain beans. Now since hibernate is part of the implementation, I don't
need hbm.xml files on the client. So I want the hbm.xml files to go in the
implementations jar file. How do I generate the hbm.xml files based on the
interfaces and domain beans project in the implementations project? It seems
like the implementations project has a dependency on the source of the other
project. How do I declare that (If that's the way to go)? And how do I tell
hibernatedoclet to look there?

Thanks,
Ken

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: A bug in the Maven plugin for XDoclet?

[Ballard, Ken]

I finally got it to work without creating an AbstractSLSB.java. I did this:

/**
 * XDoclet-based session bean. The class must be declared public according
to
 * the EJB specification. To generate the EJB related files to this EJB: -
Add
 * Standard EJB module to XDoclet project properties - Customize XDoclet
 * configuration for your appserver - Run XDoclet Below are the
xdoclet-related
 * tags needed for this EJB.
 * 
 * @ejb.bean name=TestService display-name=Test Service
 *   description=Session facade for the Test Service
 *   jndi-name=ejb/LicensingService type=Stateless
view-type=both
 *   local-business-interface=com.test.TestService
 * @ejb.env-entry name=ejb/BeanFactoryPath type=java.lang.String
 *value=applicationContext.xml
 * @ejb.home local-extends=javax.ejb.EJBLocalHome
 *   extends=javax.ejb.EJBHome
 * @ejb.interface local-extends=javax.ejb.EJBLocalObject
 *extends=javax.ejb.EJBObject
 *
 * @author kballard
 */

For some reason, you need to explicitly set more attributes than when doing
it with ANT. As long as it works...

Thanks,
Ken

-Original Message-
From: Mick Knutson [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 20, 2005 12:22 PM
To: [EMAIL PROTECTED]; users@maven.apache.org
Subject: Re: A bug in the Maven plugin for XDoclet?

I had the same exact isue, and I resolved this by creating an 
AbstractSLSB.java file that extended Springs Abstract Session bean class, 
then my XDoclet Bean extends that, and XDoclet was fine.


public abstract class AbstractSLSB extends AbstractStatelessSessionBean {

}


/**
* Bean implementation class for Enterprise Bean: ConsumerManagerBean
*
* @ejb.beanname=ConsumerManager
*  display-name=Consumer Manager Session Bean
*  type=Stateless
*  view-type=local
*  local-jndi-name=local/ConsumerManager
*
* @ejb.home local-extends=javax.ejb.EJBLocalHome
* @ejb.interface local-extends=ConsumerManager, javax.ejb.EJBLocalObject
*
* @jboss.container-configuration name=Standard Stateless SessionBean
*
* @websphere.container-configuration name=Standard Stateless SessionBean
* @websphere.bean
*
* @ejb.env-entry   name=ejb/BeanFactoryPath
*  type=java.lang.String
*  value=applicationContext.xml
*
* @ejb.util generate=physical
* @ejb.transaction type=Required
* @ejb.transaction-type type=Container
* @ejb.permission unchecked=true
*/
public class ConsumerManagerBean extends AbstractSLSB
implements ConsumerManager {

.
}



From: Stephane Nicoll [EMAIL PROTECTED]
Reply-To: Stephane Nicoll [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Subject: Re: A bug in the Maven plugin for XDoclet?
Date: Wed, 20 Jul 2005 16:23:41 +0200

Ken,

The maven plugin is just a wrapper around the ant task and the Xdoclet
guys manage this plugin themselves so you should contact them.

Cheers,
Stéphane

On 7/20/05, Ballard, Ken [EMAIL PROTECTED] wrote:
  Is this a bug in the Maven plugin for XDoclet (I'm using version 1.2.3)?
  When using EJBDoclet with ANT, you can write a Stateless Session Bean 
that
  extends Spring's EJB support class
  org.springframework.ejb.support.AbstractStatelessSessionBean and XDoclet
  will generate the appropriate interfaces and descriptors. With the 
XDoclet
  plugin for Maven you can only write a Stateless Session Bean that 
implements
  javax.ejb.SessionBean and get the correct results. Otherwise EJBDoclet
  generates interfaces that extend fictitious classes. For example, if you
  have a Stateless Session Bean that extends AbstractStatelessSessionBean,
  instead of generating a RemoteInterface that extends 
javax.ejb.EJBObject,
  ejbdoclet creates a RemoteInterface that extends a fictitious class. It
  takes the word AbstractStatelessSessionBean, and either adds Remote to 
the
  end of it if you specified
  maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote in your
  project.properties or just strips off Bean leaving you with
  org.springframework.ejb.support.AbstractStatelessSession which also does

not
  exist. I've scoured the earth looking for any documentation, blog, or
  anything that will tell me how to get around this. I haven't found 
anything.
  Is this a bug?
 
  Thanks,
  Ken
  CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, 
is
  for the sole use of the intended recipient(s) and may contain 
confidential
  and privileged information. Any unauthorized review, use, disclosure or
  distribution is prohibited. If you are not the intended recipient, 
please
  contact the sender by reply e-mail and destroy all copies of the 
original
  message.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


--
.::You're welcome ::.

-
To unsubscribe, e-mail: [EMAIL

RE: A bug in the Maven plugin for XDoclet?

[Ballard, Ken]

Thanks, I'll post it to their list.

-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 20, 2005 10:24 AM
To: Maven Users List
Subject: Re: A bug in the Maven plugin for XDoclet?

Ken, 

The maven plugin is just a wrapper around the ant task and the Xdoclet
guys manage this plugin themselves so you should contact them.

Cheers,
Stéphane

On 7/20/05, Ballard, Ken [EMAIL PROTECTED] wrote:
 Is this a bug in the Maven plugin for XDoclet (I'm using version 1.2.3)?
 When using EJBDoclet with ANT, you can write a Stateless Session Bean that
 extends Spring's EJB support class
 org.springframework.ejb.support.AbstractStatelessSessionBean and XDoclet
 will generate the appropriate interfaces and descriptors. With the XDoclet
 plugin for Maven you can only write a Stateless Session Bean that
implements
 javax.ejb.SessionBean and get the correct results. Otherwise EJBDoclet
 generates interfaces that extend fictitious classes. For example, if you
 have a Stateless Session Bean that extends AbstractStatelessSessionBean,
 instead of generating a RemoteInterface that extends javax.ejb.EJBObject,
 ejbdoclet creates a RemoteInterface that extends a fictitious class. It
 takes the word AbstractStatelessSessionBean, and either adds Remote to the
 end of it if you specified
 maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote in your
 project.properties or just strips off Bean leaving you with
 org.springframework.ejb.support.AbstractStatelessSession which also does
not
 exist. I've scoured the earth looking for any documentation, blog, or
 anything that will tell me how to get around this. I haven't found
anything.
 Is this a bug?
 
 Thanks,
 Ken
 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
 for the sole use of the intended recipient(s) and may contain confidential
 and privileged information. Any unauthorized review, use, disclosure or
 distribution is prohibited. If you are not the intended recipient, please
 contact the sender by reply e-mail and destroy all copies of the original
 message.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-- 
.::You're welcome ::.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem using AbstractStatelessSessionBean with Maven's XDoclet p lugin

[Ballard, Ken]

Thanks, again to Dennis Geurts for getting me most of the way there. I'm
much closer now. I'm generating stuff. The problem is that my EJBs use
Springs EJB support classes, so instead of implementing
javax.ejb.SessionBean they extend
org.springframework.ejb.support.AbstractStatelessSessionBean.
AbstractStatelessSessionBean implements javax.ejb.SessionBean, but I
implement javax.ejb.SessionBean again because that was the only way to get
XDoclet to work with it when I was working with ANT. When I adapted Dennis'
example, the sources files that were generated extended fictitious classes
like, in the case of the remote interface,
org.springframework.ejb.support.AbstractStatelessSessionRemote when it
should have been javax.ejb.EJBObject. It did that for all of the interfaces
that it generated. 

 

The class with the xdoclet tags looks like this:

 

/**

 * XDoclet-based session bean. The class must be declared public according
to

 * the EJB specification. To generate the EJB related files to this EJB: -
Add

 * Standard EJB module to XDoclet project properties - Customize XDoclet

 * configuration for your appserver - Run XDoclet Below are the
xdoclet-related

 * tags needed for this EJB.

 * 

 * @ejb.bean name=ReportingService display-name=DFS Reporting Service

 *   description=Session facade for the jBPM workflow engine

 *   jndi-name=ejb/ReportingService type=Stateless
view-type=both

 *
local-business-interface=com.acs.nc.dfs.common.report.ReportingService

 * @ejb.env-entry name=ejb/BeanFactoryPath type=java.lang.String

 *value=applicationContext.xml

 * @author kballard

 */

public class ReportingServiceEJB extends AbstractStatelessSessionBean
implements

ReportingService, SessionBean {

 

...

}

 

And the one I used to be able to generate with XDoclet looks like this:

 

/*

 * Generated by XDoclet - Do not edit!

 */

package com.acs.nc.dfs.common.report.ejb;

 

/**

 * Remote interface for ReportingService.

 * @xdoclet-generated at ${TODAY}

 * @copyright The XDoclet Team

 * @author XDoclet

 * @version ${version}

 */

public interface ReportingServiceRemote

   extends javax.ejb.EJBObject

{

...

}

 

It seems to be substituting the word Bean in AbstractStatelessSessionBean
with Remote, Local, etc. respectively. Any ideas about how I can correct
this?

 

Thanks,

Ken

 

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

RE: EJBDoclet in Maven

[Ballard, Ken]

)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:92)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:84)

at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa
g.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor
mAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
Final Memory: 18M/32M
Total time: 5 seconds
Finished at: Mon Jul 18 16:29:23 EDT 2005

See anything?

Thanks,
Ken

-Original Message-
From: Dennis Geurts [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 18, 2005 4:14 PM
To: Maven Users List
Subject: Re: EJBDoclet in Maven

mmhh,
 let's not forget the j2ee interfaces...
 it is also recommended to let generated source files be created in the 
target directory instead
of creating them alongside your own source files...
 Dennis
 On 7/18/05, Ballard, Ken [EMAIL PROTECTED] wrote: 
 
 Thanks, but it still isn't working, although it builds successfully.
 
 Here's the output form running
 maven -X xdoclet:ejbdoclet:
 
 [DEBUG] Finding class xjavadoc.DefaultXTag
 [DEBUG] Class xjavadoc.DefaultXTag loaded from ant loader
 [DEBUG] Class java.lang.IllegalArgumentException loaded from parent loader
 [DEBUG] Finding class xjavadoc.XDoc
 [DEBUG] Finding class xjavadoc.event.XTagListener
 [DEBUG] Class java.util.EventListener loaded from parent loader
 [DEBUG] Class xjavadoc.event.XTagListener loaded from ant loader
 [DEBUG] Class xjavadoc.XDoc loaded from ant loader
 [DEBUG] Class java.util.Iterator loaded from parent loader
 [DEBUG] Class java.util.EventObject loaded from parent loader
 [DEBUG] Finding class xjavadoc.event.XTagEvent
 [DEBUG] Class xjavadoc.event.XTagEvent loaded from ant loader
 [DEBUG] Class java.lang.StringIndexOutOfBoundsException loaded from parent
 loade
 r
 [DEBUG] Class java.io.IOException loaded from parent loader
 [DEBUG] Class java.io.Reader loaded from parent loader
 [DEBUG] Class java.io.StringReader loaded from parent loader
 [DEBUG] Finding class xjavadoc.JavaDocReader
 [DEBUG] Class java.io.FilterReader loaded from parent loader
 [DEBUG] Class xjavadoc.JavaDocReader loaded from ant loader
 [DEBUG] Class java.lang.System loaded from parent loader
 [DEBUG] Class java.util.LinkedList loaded from parent loader
 [DEBUG] Finding class xjavadoc.XExecutableMember
 [DEBUG] Finding class xjavadoc.XMember
 [DEBUG] Class xjavadoc.XMember loaded from ant loader
 [DEBUG] Class xjavadoc.XExecutableMember loaded from ant loader
 [DEBUG] Class java.lang.UnsupportedOperationException loaded from parent
 loader
 [DEBUG] Finding class xjavadoc.Util
 [DEBUG] Class xjavadoc.Util loaded from ant loader
 [DEBUG] Class java.io.FileFilter loaded from parent loader
 [DEBUG] Finding class xjavadoc.Util$1
 [DEBUG] Class xjavadoc.Util$1 loaded from ant loader
 [DEBUG] Finding class xjavadoc.Util$2
 [DEBUG] Class xjavadoc.Util$2 loaded from ant loader
 [DEBUG] Finding class xdoclet.loader.ModuleFinder
 [DEBUG] Class xdoclet.loader.ModuleFinder loaded from ant loader
 [DEBUG] Class java.util.zip.ZipException loaded from parent loader
 [DEBUG] Class java.util.zip.ZipEntry loaded from parent loader
 [DEBUG] Class java.util.jar.JarEntry loaded from parent loader
 [DEBUG] Class java.io.FileInputStream loaded from parent loader
 [DEBUG] Class java.io.InputStream loaded from parent loader
 [DEBUG] Finding class xdoclet.loader.ModuleFinder$1
 [DEBUG] Class xdoclet.loader.ModuleFinder$1 loaded from ant loader
 [DEBUG] Class

Directory Structure conventions for multiprojects

[Ballard, Ken]

Maven team,

We're adopting Maven and I want to set up my directory structure with strict
adherence to Maven conventions. We're in the early phases of a project, so
I'm thinking that that will save us the most time in the future. I found
Maven: A Developer's Workbook and the conventions page
[http://maven.apache.org/reference/conventions.html] of the Maven website to
be very helpful, but I just want to validate my structure.

I have this structure:

myproject/
+- acceptance/
|  +- test/
|  |  +- java/
|  |  |  +- ...
|  +- maven.xml
|  +- project.xml
|  +- project.properties
+- common/
|  +- project.xml
|  +- project.properties
+- ear/
|  +- src/
|  |  +- main/
|  |  |  +- application/
|  |  |  |  +- META-INF/
|  |  |  +- ejb/
|  |  |  |  +- META-INF/
|  |  |  +- java/
|  |  |  |  +- com
|  |  |  |  |  +- ...
|  |  |  +- resources/
|  |  +- test/
|  | +- java/
|  |+- com
|  |   +- ...
|  +-target/
|  +- maven.xml
|  +- project.xml
|  +- project.properties
+-implementations/
|  +- src/
|  |  +- main/
|  |  |  +- java/
|  |  |  |  +- com
|  |  |  |  |  +- ...
|  |  |  +- resources/
|  |  +- site/
|  |  |  +- xdoc/
|  |  +- test/
|  | +- java/
|  |+- com
|  |   +- ...
|  +-target/
|  +- project.xml
+-interfaces/
|  +- src/
|  |  +- main/
|  |  |  +- java/
|  |  |  |  +- com
|  |  |  |  |  +- ...
|  |  |  +- resources/
|  |  +- site/
|  |  |  +- xdoc/
|  |  +- test/
|  | +- java/
|  |+- com
|  |   +- ...
|  +-target/
|  +- project.xml
+-web/
|  +- src/
|  |  +- main/
|  |  |  +- java/
|  |  |  |  +- com
|  |  |  |  |  +- ...
|  |  |  +- resources/
|  |  +- site/
|  |  |  +- xdoc/
|  |  +- test/
|  |  |  +- java/
|  |  | +- com
|  |  |+- ...
|  |  +- webapp/
|  | +-WEB-INF/
|  +-target/
|  +- project.xml
+- maven.xml
+- project.xml
+- project.properties


The .war file will be deployed to the web server and the .ear file will be
deployed to an app server on a different box. myproject-web.war needs to
contain the myproject-interfaces.jar and a client jar(s) for the EJB(s)
(I'll need to figure out how to generate these with Maven).
myproject-ear.ear needs myproject-interfaces.jar and
myproject-implementations.jar (and the EJBs, of course). The acceptance
project is for acceptance (or functional) tests.

Does this directory structure strictly adhere to the Maven conventions?

Thanks,
Ken
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
  


begin 600 MyMavenDirStructure.txt
M;7EP[EMAIL PROTECTED]GP@(LM('1EW0O#0I\(!\
M(`K+2!J879A+PT*?[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL 
PROTECTED]@+BXN#0I\(`K+2!M879E;BYX;6P-
MGP@(LM('!R;VIE8W0NUL#0I\(`K+2!PF]J96-T+G!R;W!EG1I97,-
MBLM(-O;6UO;B\-GP@(LM('!R;VIE8W0NUL#0I\(`K+2!PF]J96-T
M+G!R;W!EG1I97,-BLM(5AB\-GP@(LM('-R8R\-GP@('P@(LM(UA
M:6XO#0I\(!\(!\(`K+2!A'!L:6-A=EO;B\-GP@('P@('P@('P@(LM
M($U%5$$M24Y+PT*?[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL 
PROTECTED]@96IB+PT*?[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL 
PROTECTED][EMAIL PROTECTED]@
M345402U)3D8O#0I\(!\(!\(`K+2!J879A+PT*?[EMAIL PROTECTED][EMAIL 
PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]@
M8V]M#0I\(!\(!\(!\(!\(`K+2`N+BX-GP@('P@('P@(LM(')EV]U
MF-ER\-GP@('P@(LM('1EW0O#0I\(!\(`@(`K+2!J879A+PT*?`@
M?`@(`@([EMAIL PROTECTED]@8V]M#0I\(!\(`@(`@(`@(`K+2`N+BX-GP@(LM
M=%R9V5T+PT*?[EMAIL PROTECTED]@;6%V96XNUL#0I\(`K+2!PF]J96-T+GAM;`T*
M?[EMAIL PROTECTED]@')O:F5C=YPF]P97)T:65S#0HK+6EMQE;65N=%T:6]NR\-
MGP@(LM('-R8R\-GP@('P@(LM(UA:6XO#0I\(!\(!\(`K+2!J879A
M+PT*?[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL 
PROTECTED]@8V]M#0I\(!\(!\(!\(!\(`K+2`N+BX-
MGP@('P@('P@(LM(')EV]UF-ER\-GP@('P@(LM('-I=4O#0I\(!\
M(!\(`K+2!X9]C+PT*?[EMAIL PROTECTED][EMAIL 
PROTECTED]@=5S=\-GP@('P@(`@(LM(IA
M=F$O#0I\(!\(`@(`@(`K+2!C;VT-GP@('P@(`@(`@(`@(LM(XN
[EMAIL PROTECTED][EMAIL 
PROTECTED])G970O#0I\(`K+2!PF]J96-T+GAM;`T**RUI;G1EF9A
M8V5S+PT*?[EMAIL PROTECTED]@W)C+PT*?[EMAIL PROTECTED][EMAIL 
PROTECTED]@;6%I;B\-GP@('P@('P@(LM
M(IA=F$O#0I\(!\(!\(!\(`K+2!C;VT-GP@('P@('P@('P@('P@(LM
M([EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL 
PROTECTED]@F5S;W5R8V5S+PT*?[EMAIL PROTECTED][EMAIL PROTECTED]@VET92\-
MGP@('P@('P@(LM('AD;V,O#0I\(!\(`K+2!T97-T+PT*?[EMAIL PROTECTED]`@(`@
M*RT@:F%V82\-GP@('P@(`@(`@(LM(-O;0T*?[EMAIL PROTECTED]`@(`@(`@(`@
[EMAIL PROTECTED](`K+71AF=E=\-GP@(LM('!R;VIE8W0NUL#0HK+7=E
M8B\-GP@(LM('-R8R\-GP@('P@(LM(UA:6XO#0I\(!\(!\(`K+2!J
M879A+PT*?[EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL 
PROTECTED]@8V]M#0I\(!\(!\(!\(!\(`K+2`N
M+BX-GP@('P@('P@(LM(')EV]UF-ER\-GP@('P@(LM('-I=4O#0I\
M(!\(!\(`K+2!X9]C+PT*?[EMAIL PROTECTED][EMAIL 
PROTECTED]@=5S=\-GP@('P@('P@(LM
M(IA=F$O#0I\(!\(!\(`@(`K+2!C;VT-GP@('P@('P@(`@(`@(LM
M([EMAIL 

RE: EJBDoclet in Maven

[Ballard, Ken]

] [DEBUG] Class xdoclet.XDocletMain loaded from ant loader
[DEBUG] Adding reference: ejbdoclet.java.compile.src.set -

[echo] Compiling to
C:\workspaces\dfs\poc-v0018-middletier\dfs\ear/target/cl
asses
[javac] [DEBUG] fileset: Setup scanner in dir
C:\workspaces\dfs\poc-v0018-mi
ddletier\dfs\ear\src\main\java with patternSet{ includes: [] excludes:
[**/packa
ge.html] }
[javac] [VERBOSE]
com\acs\nc\dfs\common\report\ejb\ReportingServiceEJB.java
omitted as com/acs/nc/dfs/common/report/ejb/ReportingServiceEJB.class is up
to d
ate.
[javac] [VERBOSE] com\acs\nc\dfs\common\wf\ejb\WorkflowServicesEJB.java
omit
ted as com/acs/nc/dfs/common/wf/ejb/WorkflowServicesEJB.class is up to date.
[javac] [VERBOSE] com\acs\nc\dfs\lic\ejb\LicensingServiceEJB.java
omitted as
 com/acs/nc/dfs/lic/ejb/LicensingServiceEJB.class is up to date.
[javac] [DEBUG] fileset: Setup scanner in dir
C:\workspaces\dfs\poc-v0018-mi
ddletier\dfs\ear\target\xdoclet\ejbdoclet with patternSet{ includes: []
excludes
: [**/package.html] }
attaining goal build:end
popping off [EMAIL PROTECTED] for
org.apache.mave
[EMAIL PROTECTED] in maven-antlr-plugin:maven-antlr-plugin
popping off [EMAIL PROTECTED] for
org.apache.maven.
[EMAIL PROTECTED] in maven-java-plugin:maven-java-plugin
popping off [EMAIL PROTECTED] for
org.apache.mave
[EMAIL PROTECTED] in
maven-xdoclet-plugin:maven-xdoclet-plugin
popping off [EMAIL PROTECTED] for
org.apache.maven
[EMAIL PROTECTED] in dfs:dfs-ear
BUILD SUCCESSFUL
Final Memory: 18M/32M
Total time: 4 seconds
Finished at: Mon Jul 18 16:36:40 EDT 2005

See anything?

Thanks,
Ken

-Original Message-
From: Ballard, Ken [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 18, 2005 4:31 PM
To: 'Maven Users List'
Subject: RE: EJBDoclet in Maven

Okay, I changed maven.xdoclet.ejbdoclet.destDir to be
${maven.build.dir}/xdoclet/ejbdoclet in project.properties. And I have this
for the j2ee dependency:

dependency
groupIdjboss/groupId
artifactIdjboss-j2ee/artifactId
version4.0.0DR4/version
/dependency

When I run maven -X java:compile, I get:

[DEBUG] Registering SubTask homeinterface
(xdoclet.modules.ejb.home.HomeInterfac
eSubTask) to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.entity.EntityBmpSubTask
[DEBUG] Class xdoclet.modules.ejb.entity.EntityBmpSubTask loaded from ant
loader

[DEBUG] Resource xdoclet/modules/ejb/entity/resources/entitybmp.xdt loaded
from
ant loader
[DEBUG] Registering SubTask entitybmp
(xdoclet.modules.ejb.entity.EntityBmpSubTa
sk) to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.intf.RemoteInterfaceSubTask
[DEBUG] Class xdoclet.modules.ejb.intf.RemoteInterfaceSubTask loaded from
ant lo
ader
[DEBUG] Resource xdoclet/modules/ejb/intf/resources/remote.xdt loaded from
ant l
oader
[DEBUG] Registering SubTask remoteinterface
(xdoclet.modules.ejb.intf.RemoteInte
rfaceSubTask) to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.entity.EntityCmpSubTask
[DEBUG] Class xdoclet.modules.ejb.entity.EntityCmpSubTask loaded from ant
loader

[DEBUG] Resource xdoclet/modules/ejb/entity/resources/entitycmp.xdt loaded
from
ant loader
[DEBUG] Registering SubTask entitycmp
(xdoclet.modules.ejb.entity.EntityCmpSubTa
sk) to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.lookup.LookupObjectSubTask
[DEBUG] Class xdoclet.modules.ejb.lookup.LookupObjectSubTask loaded from ant
loa
der
[DEBUG] Resource xdoclet/modules/ejb/lookup/resources/lookup.xdt loaded from
ant
 loader
[DEBUG] Registering SubTask utilobject
(xdoclet.modules.ejb.lookup.LookupObjectS
ubTask) to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.intf.LocalInterfaceSubTask
[DEBUG] Class xdoclet.modules.ejb.intf.LocalInterfaceSubTask loaded from ant
loa
der
[DEBUG] Resource xdoclet/modules/ejb/intf/resources/local.xdt loaded from
ant lo
ader
[DEBUG] Registering SubTask localinterface
(xdoclet.modules.ejb.intf.LocalInterf
aceSubTask) to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.mdb.MdbSubTask
[DEBUG] Class xdoclet.modules.ejb.mdb.MdbSubTask loaded from ant loader
[DEBUG] Resource xdoclet/modules/ejb/mdb/resources/mdb.xdt loaded from ant
loade
r
[DEBUG] Registering SubTask mdb (xdoclet.modules.ejb.mdb.MdbSubTask) to
DocletTa
sk xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.session.SessionSubTask
[DEBUG] Class xdoclet.modules.ejb.session.SessionSubTask loaded from ant
loader
[DEBUG] Resource xdoclet/modules/ejb/session/resources/session.xdt loaded
from a
nt loader
[DEBUG] Registering SubTask session
(xdoclet.modules.ejb.session.SessionSubTask)
 to DocletTask xdoclet.modules.ejb.EjbDocletTask
[DEBUG] Finding class xdoclet.modules.ejb.home.LocalHomeInterfaceSubTask
[DEBUG] Class xdoclet.modules.ejb.home.LocalHomeInterfaceSubTask loaded from
ant
 loader
[DEBUG

RE: EJBDoclet in Maven

[Ballard, Ken]

] Class java.lang.Void loaded from parent loader
[ejbdoclet] [DEBUG] Class java.beans.Introspector loaded from parent
loader
[ejbdoclet] [DEBUG] Class java.lang.Character loaded from parent loader
[ejbdoclet] [DEBUG] Finding class javax.ejb.EntityBean
[ejbdoclet] [DEBUG] Finding class javax.ejb.EnterpriseBean
[ejbdoclet] [DEBUG] Class javax.ejb.EnterpriseBean loaded from ant
loader
[ejbdoclet] [DEBUG] Class javax.ejb.EntityBean loaded from ant loader
[ejbdoclet] [DEBUG] Finding class xjavadoc.filesystem.FileSourceSet
[ejbdoclet] [DEBUG] Class xjavadoc.filesystem.FileSourceSet loaded from
ant
loader
[ejbdoclet] [DEBUG] fileset: Setup scanner in dir
C:\workspaces\dfs\poc-v001
8-middletier\dfs\ear\src\main\java with patternSet{ includes:
[**/*Bean.java] ex
cludes: [] }
[ejbdoclet] [DEBUG] Class org.apache.tools.ant.DirectoryScanner loaded
from
parent loader
[ejbdoclet] [DEBUG] Finding class xjavadoc.filesystem.AbstractFile
[ejbdoclet] [DEBUG] Class xjavadoc.filesystem.AbstractFile loaded from
ant l
oader
[ejbdoclet] [DEBUG] Finding class xdoclet.XDocletMain
[ejbdoclet] [DEBUG] Class xdoclet.XDocletMain loaded from ant loader
[DEBUG] Adding reference: ejbdoclet.java.compile.src.set -
attaining goal build:end
popping off [EMAIL PROTECTED] for
org.apache.maven
[EMAIL PROTECTED] in
maven-xdoclet-plugin:maven-xdoclet-plugin
popping off [EMAIL PROTECTED] for
org.apache.maven
[EMAIL PROTECTED] in dfs:dfs-ear
BUILD SUCCESSFUL
Final Memory: 17M/32M
Total time: 5 seconds
Finished at: Mon Jul 18 15:51:29 EDT 2005

Any ideas?

Thanks,
Ken
-Original Message-
From: Dennis Geurts [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 18, 2005 3:33 PM
To: Maven Users List
Subject: Re: EJBDoclet in Maven

Hi Ken,
 I did a quick scan of your mail, and noticed the dependency to the 
jmx-module isn't there...
I think this dependency is needed for ejbdoclet to work.
 please try a 'maven -X' to see a more verbose output.
 hope it helps, if you need more help, just ask.
 Dennis
 On 7/18/05, Ballard, Ken [EMAIL PROTECTED] wrote: 
 
 Anyone,
 
 
 
 I can't get ejbdoclet to work in Maven. I think I've seen every post out
 there and I still seem to be missing something. I have hibernatedoclet
 working without any problems, but ejbdoclet doesn't generate anything. 
 It's
 the same code that I was using ejbdoclet to generate classes and 
 descriptors
 in ANT, so I'm confident that it works. I just think I have Maven 
 configured
 incorrectly.
 
 
 
 I'm using the following in the project.properties file:
 
 
 
 maven.xdoclet.ejbdoclet.ejbspec=2.0
 
 [EMAIL PROTECTED] at 
 ${TODAY},@copyright
 
 Affiliated Computer Services, [EMAIL PROTECTED] xxx
 
 [EMAIL PROTECTED],@author
 
 #maven.xdoclet.ejbdoclet.mergeDir=
 
 maven.xdoclet.ejbdoclet.verbose=true
 
 maven.xdoclet.ejbdoclet.destDir=${maven.src.dir}
 
 
 
 maven.xdoclet.ejbdoclet.fileset.0=true
 
 
 
 maven.xdoclet.ejbdoclet.fileset.0.includes=**/*.java
 
 
 
 maven.xdoclet.ejbdoclet.deploymentdescriptor.0=false
 
 

maven.xdoclet.ejbdoclet.deploymentdescriptor.0.destDir=${maven.src.dir}/META
 -INF
 
 
 
 maven.xdoclet.ejbdoclet.entitybmp.0=false
 
 maven.xdoclet.ejbdoclet.entitycmp.0=false
 
 maven.xdoclet.ejbdoclet.entitypk.0=false
 
 maven.xdoclet.ejbdoclet.homeinterface.0=true
 
 maven.xdoclet.ejbdoclet.localhomeinterface.0=true
 
 maven.xdoclet.ejbdoclet.localinterface.0=true
 
 maven.xdoclet.ejbdoclet.remoteinterface.0=true
 
 maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote
 
 maven.xdoclet.ejbdoclet.session.0=false
 
 maven.xdoclet.ejbdoclet.utilobject.0=false
 
 maven.xdoclet.ejbdoclet.valueobject.0=false
 
 maven.xdoclet.ejbdoclet.strutsform.0=false
 
 
 
 I have these XDoclet dependencies in my project.xml:
 
 
 
 dependency
 
 groupIdxdoclet/groupId
 
 artifactIdxdoclet/artifactId
 
 version2.0/version
 
 /dependency
 
 dependency
 
 groupIdxdoclet/groupId
 
 artifactIdxdoclet-ejb-module/artifactId
 
 version1.2.3/version
 
 /dependency
 
 dependency
 
 groupIdxdoclet/groupId
 
 artifactIdxdoclet-jboss-module/artifactId
 
 version1.2/version
 
 /dependency
 
 
 
 And this is my maven.xml:
 
 
 
 project
 
 xmlns:j=jelly:core
 
 xmlns:maven=jelly:maven
 
 xmlns:ant=jelly:ant
 
 
 
 
 
 preGoal name=java:compile
 
 attainGoal name=xdoclet:ejbdoclet/
 
 /preGoal
 
 
 
 /project
 
 
 
 My dir structure is:
 
 
 
 +- ear/
 
 +- src/
 
 | +- main/
 
 | | +- application/
 
 | | | +- META-INF/
 
 | | +- ejb/
 
 | | | +- META-INF/
 
 | | +- java/
 
 | | | +- com
 
 | | | | +- ...
 
 | | +- resources/
 
 | +- test/
 
 | +- java/
 
 | +- com
 
 | +- ...
 
 +-target/
 
 +- maven.xml
 
 +- project.xml
 
 +- project.properties
 
 
 
 When I run maven -X xdoclet:ejbdoclet it says BUILD SUCCESSFUL, but
 nothing is generated. Does anybody have any idea about what I'm doing
 incorrectly?
 
 
 
 Thanks,
 
 Ken
 
 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
 for the sole use of the intended recipient(s

EJBDoclet in Maven

[Ballard, Ken]

Anyone,

 

I can't get ejbdoclet to work in Maven. I think I've seen every post out
there and I still seem to be missing something. I have hibernatedoclet
working without any problems, but ejbdoclet doesn't generate anything. It's
the same code that I was using ejbdoclet to generate classes and descriptors
in ANT, so I'm confident that it works. I just think I have Maven configured
incorrectly. 

 

I'm using the following in the project.properties file:

 

maven.xdoclet.ejbdoclet.ejbspec=2.0

[EMAIL PROTECTED] at ${TODAY},@copyright 

Affiliated Computer Services, [EMAIL PROTECTED] xxx

[EMAIL PROTECTED],@author

#maven.xdoclet.ejbdoclet.mergeDir=

maven.xdoclet.ejbdoclet.verbose=true

maven.xdoclet.ejbdoclet.destDir=${maven.src.dir}

 

maven.xdoclet.ejbdoclet.fileset.0=true

 

maven.xdoclet.ejbdoclet.fileset.0.includes=**/*.java

 

maven.xdoclet.ejbdoclet.deploymentdescriptor.0=false

maven.xdoclet.ejbdoclet.deploymentdescriptor.0.destDir=${maven.src.dir}/META
-INF

 

maven.xdoclet.ejbdoclet.entitybmp.0=false

maven.xdoclet.ejbdoclet.entitycmp.0=false

maven.xdoclet.ejbdoclet.entitypk.0=false

maven.xdoclet.ejbdoclet.homeinterface.0=true

maven.xdoclet.ejbdoclet.localhomeinterface.0=true

maven.xdoclet.ejbdoclet.localinterface.0=true

maven.xdoclet.ejbdoclet.remoteinterface.0=true

maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote

maven.xdoclet.ejbdoclet.session.0=false

maven.xdoclet.ejbdoclet.utilobject.0=false

maven.xdoclet.ejbdoclet.valueobject.0=false

maven.xdoclet.ejbdoclet.strutsform.0=false

 

I have these XDoclet dependencies in my project.xml:

 

dependency

groupIdxdoclet/groupId

artifactIdxdoclet/artifactId

version2.0/version

/dependency

dependency

groupIdxdoclet/groupId

artifactIdxdoclet-ejb-module/artifactId

version1.2.3/version

/dependency

dependency

groupIdxdoclet/groupId

artifactIdxdoclet-jboss-module/artifactId

version1.2/version

/dependency

 

And this is my maven.xml:

 

project

   xmlns:j=jelly:core

   xmlns:maven=jelly:maven

   xmlns:ant=jelly:ant

  

 

preGoal name=java:compile

attainGoal name=xdoclet:ejbdoclet/

/preGoal

 

/project

 

My dir structure is:

 

+- ear/

   +- src/

   |  +- main/

   |  |  +- application/

   |  |  |  +- META-INF/

   |  |  +- ejb/

   |  |  |  +- META-INF/

   |  |  +- java/

   |  |  |  +- com

   |  |  |  |  +- ...

   |  |  +- resources/

   |  +- test/

   | +- java/

   |+- com

   |   +- ...

   +-target/

   +- maven.xml

   +- project.xml

   +- project.properties

 

When I run maven -X xdoclet:ejbdoclet it says BUILD SUCCESSFUL, but
nothing is generated. Does anybody have any idea about what I'm doing
incorrectly?

 

Thanks,

Ken

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.