Rep:Project Descriptor Creation Tool

2003-11-07 Thread Emmanuel Venisse
You can use the genapp plugin.

Emmanuel

-Message d'origine-
De: Vikas Phonsa [EMAIL PROTECTED]
A: 'Maven Users List' [EMAIL PROTECTED]
Date: 06/11/03
Objet: Project Descriptor Creation Tool

Hi Everybody,

On maven website I read about some tool being developed to generate a
project descriptor automatically.

I was thinking about either getting or developing something like that
for my
projects but would surely prefer to use something supplied with maven.

So I wanted to know what kind of a tool would that be ? Some GUI program
that takes entries or some command line based program ?

And when is that tool scheduled come ?


Thanks

Vikas



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

_
Envie de discuter en live avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France


_
Un mot doux à envoyer? Une sortie ciné à organiser? Faites le en temps
réel avec MSN Messenger! C'est gratuit!   http://ifrance.com/_reloc/m
_
Envie de discuter en live avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France


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



ApsectJ javadoc

2003-11-07 Thread Neil Blue
Hello,

I am trying to use the aspectj plugin. So far compilation is fine, however when I try 
to use the aspectj:ajdoc goal, I get the following error:

File.. file:/home/nblue/.maven/plugins/maven-aspectj-plugin-1.1/
Element... ant:ajdoc
Line.. 108
Column 56
java.lang.IllegalAccessError: tried to access field 
com.sun.tools.doclets.HtmlWriter.configuration from class 
org.aspectj.tools.doclets.standard.AbstractStandard
Total time: 3 seconds
Finished at: Fri Nov 07 09:54:37 GMT 2003

Do I need extra dependancies for this to work?

Thanks
Neil

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



plugin plugin

2003-11-07 Thread Oliver Nölle
We use maven in a corporate setting and in general it does quite a good job.

There are some aspects that we have problems with (maven-rc1, win2k):

The plugin plugin:

We developed a new plugin containing some corporate-specific goals.

I did not understand the semantics of plugin:install and plugin:deploy:
In analogy to normal projects and to jar:install and jar:deploy I would
have expected
- plugin:install to install the plugin on my local machine
- plugin:deploy to deploy the plugin in our central repository (on a
different machine, I am normally the only one using my machine) so that
others can download it

But the documentation on
http://maven.apache.org/reference/developers/developer-guide.html describes
quite different semantics, especially there seems to be no way to deploy the
plugin to the central repository?

When invoking plugin:deploy I get a warning that I don't understand (it
seems to be hardcoded into the plugin, ie. it appears every time regardless
of any tests, does that make sense?)
echo message= 
  Warning: Contents of ${maven.home}/plugins/${maven.final.name}.jar does
not match
  the unpacked contents of ${maven.plugin.unpacked.dir}/${maven.final.name}
directory.
/echo


Then I found on the website about releasing maven plugins the following
command to deploy a plugin:
maven -DgroupId=maven -Dtype=plugin -Dartifact=/path/to/file
repository:copy-artifact

Okay, I wanted to look up what the goal copy-artifact exactly does (okay,
it's almost clear, but...)
Two issues:
- the plugins on the website
http://maven.apache.org/reference/plugins/optional/optional.html are not
sorted alphabetically (minor)
- the goal copy-artifact is not documented (major, because this is quite
annoying for a user who just found what he thinks he needs and then it's not
documented (or for someone who will simply not know about existing
functionalities)


Anyway, I got it working and my plugin deployed.

Then I wanted to download it (on a different machine):
Using plugin:download I was wondering where the downloaded plugin is
installed to.
It took me a while to find out that the plugin successfully downloads but
apparently immediately deletes the downloaded file. After I added a line to
the jelly.xml it worked:

  delete includeEmptyDirs=true verbose=false
fileset dir=${maven.plugin.unpacked.dir}
  include name=*.cache/
  include name=**/.processed /
  include name=${artifactId}-*/** /
  exclude name=${artifactId}-${version}.jar /!-- this line
added by oliver --
/fileset
  /delete



Okay, I finally succeeded, but with just too many obstacles that are not
necessary to my mind (and that might prevent other users from using maven
and/or writing plugins for maven).


Summary:
- what about deploying a plugin and the semantics of the plugin:deploy goal,
do I have a wrong understanding?
- PLEASE keep the documentation in a good and up-to-date state, it just eats
up hours at the moment to find out certain things! (example: how should a
new user find out that he can/should use groupId and artifactId for
dependencies, if almost all the samples on the website contain the old
id-only version? See eg. http://maven.apache.org/start/integrate.html)
(especially as maven easily enables you to deploy the sitedoc of a plugin
within the same step that performs the release, I am a bit disappointed
about the quality and up-to-date status of plugins)
- conceptual question: what about site-doc for older versions? Maybe the
docs were not too old but too new, and the goal does not exist any more in
the CVS version, shouldn't there be the old sitedoc for a project available,
too (eg. deployed as another artifact?)
- is the missing exclude-line a bug, should I raise an issue in JIRA for it
(there doesn't exist one yet)




Okay, I hope you take this as constructive criticism, and thanks for all the
work done so far!


Oliver Nölle



--
Oliver Nölle
BMW Car IT GmbH
Munich


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



RE: war plugin : [maven.caller.call.compile-java] is not defined

2003-11-07 Thread Vincent Massol


 -Original Message-
 From: Michal Maczka [mailto:[EMAIL PROTECTED]
 Sent: 06 November 2003 11:42
 To: Maven Users List
 Subject: Re: war plugin : [maven.caller.call.compile-java] is not
defined
 
 Vincent Massol wrote:
 
 Hi Eric,
 
 No. It's because you seem not to have installed the caller plugin...
My
 guess is that you have only taken the war plugin from HEAD without
 taking it's dependencies. Actually, thinking about it, we should add
a
 dependency in the war plugin on the caller plugin so that it gets
 automatically downloaded.
 
 -Vincent
 
 
 Vincent!
 I really like your idea of Well Know Goals which  is implemented in
 Caller Plugin but I think ... that this plugin should be dropped.
 
 In particular case of java:compile goal - it's java plugin which is
 badly written.
 
 I don't think we need a central point for wiring goals.
 
 Existence of caller plugin just shows that  we need to have a well
 defined and *extendable* workflow.

Yes. My implementation of this workflow is a poor man's implementation
but it satisfied my immediate need. Feel free to improve it provided you
keep the same feature. :-)

 
 Lets's concentrate on java plugin:
 java:compile process can be divided into 3 steps:
   a) generation of java classes (with plugin  xdoclet, jaxb, castor)
   b) compilation with e.g javac/aspectj compiler

I don't think so. The java plugin is about java. It's NOT about aspectj,
nor is it about any extension to the java language like xdoclet or
whatever. I would not want to tie the java plugin with aspectj.

   c) applictaion of bytecode ehancers (like kodo, ascpectj )

same here.

 
 
 a)
 foreach codeGenerator in codeGenerator do:
attainGoal name=${codeGenerator}:generate/
 end;
 b)
 java:compile (calls javac:compile or aspectj:compile or
 eclipse-compiler:compile)
 
 c)
 foreach byteCodeEnhancer in byteCodeEnhancers do:
attainGoal name=$byteCodeEnhancer}:enhace/
 end;
 
 
 
 IMHO the best solution will be to
 
 a) rename  java:compile goal to javac:compile
 
 add java:compile which does what you have tried to do with caller
plugin.

I had thought about this solution is course (as it is much simpler to
implement than the caller plugin). However, I don't like the coupling it
introduces. Granted the caller plugin is one coupling but the idea was
to have one coupling instead of several and actually the next step was
to transform the caller plugin in java code and put that inside Maven
core. 

I think the aspectj aspect must be completely independent of the java
plugin. It should be possible to replace the java plugin by the aspectj
plugin (or by any other custom implementation) seamlessly. 

Regards,
-Vincent


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



RE: cactus plugin and overring war:war

2003-11-07 Thread Vincent Massol
Hi Sean,

Does it work with the version 1.6dev of the Cactus plugin (now that it
has moved to Cactus)? Could you try with 1.6dev-20031031?

To install it, type:

maven plugin:download -DartifactId=cactus-maven -DgroupId=cactus
-Dversion=1.6dev-20031031 

Note: Make sure you've removed older versions from .maven/plugins and
from mavenhome/plugins.

(see http://jakarta.apache.org/cactus/integration/maven/using.html for
details).

Thanks
-Vincent

 -Original Message-
 From: Sean Timm [mailto:[EMAIL PROTECTED]
 Sent: 06 November 2003 08:09
 To: Maven Users List
 Subject: RE: cactus plugin and overring war:war
 
 Brett Porter [mailto:[EMAIL PROTECTED] wrote:
 
  Incidentally, I've just had exactly this error, using the
  maven-cactus-plugin-3.1 distributed with RC1. I had to add
  junit to my project with the root classloader, although at
  this point I'm not sure why as the cactus plugin seems to be
  doing everything it should.
 
 I ran into this issue as well.  I think it may be something similar to
 the issue described in the Ant FAQ
 (http://ant.apache.org/faq.html#delegating-classloader), but I haven't
 looked into it too closely to know for sure.
 
 -- Sean T.
 
 -
 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: Javadoc: No source files and no packages have been specified.

2003-11-07 Thread Mark R. Diggory
This was it, I have been including a global project.xml file and the 
package defined in it was incorrect. My solution is to define the 
packages in the local project.xml instead.

thanks

[EMAIL PROTECTED] wrote:
Have you tried a packagecom.foo.bar/package tag under project? The
javadoc plugin source uses that as the packagenames element of the Ant
javadoc task.
Between that and the build.sourceDirectory element, that's all I can
see... Are your sourceDirectory tags and similar within the build
tags?
Nick


-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED] 
Sent: 06 November 2003 17:01
To: Maven Users List
Subject: Javadoc: No source files and no packages have been specified.

I feel kinda stupid, but what am I missing here?

Maven output 

C:\Eclipse3.0\workspace\myprojectmaven javadoc:generate
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc1-SNAPSHOT
Attempting to download maven-SNAPSHOT.jar.

BUILD FAILED
No source files and no packages have been specified.
Total time: 5 seconds
Finished at: Thu Nov 06 11:57:22 EST 2003
project.xml-

?xml version=1.0?
project
.
 
nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress
sourceDirectorysrc/main/java/sourceDirectory
	
unitTestSourceDirectorysrc/test/java/unitTestSourceDirectory
aspectSourceDirectory/
resources
resource
directorysrc/main/resources/directory
includes
include**/*/include
/includes
/resource
/resources
unitTest
includes
include**/*Test.java/include
/includes
excludes
exclude**/RepositoryTest.java/exclude
/excludes
resources
resource
directorysrc/test/resources/directory
includes
include**/*/include
/includes
/resource
/resources
/unitTest
/build

reports
reportmaven-jdepend-plugin/report
reportmaven-checkstyle-plugin/report
reportmaven-javadoc-plugin/report
/reports
/project
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
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]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


XSL transform in Maven?

2003-11-07 Thread Neil Blue
Hello,

I have an XML file that I would like to transform with an XSL file that I have. I 
can't seem to find a way to do this in Maven. Please can someone point me in the right 
direction.

Thanks
Neil

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



Réf. : XSL transform in Maven?

2003-11-07 Thread Nicolas . CHALUMEAU
Take a look at :
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=149msgNo=3359
It may help.

Nicolas






Neil Blue [EMAIL PROTECTED]
07/11/2003 16:45
Veuillez répondre à Maven Users List

 
Pour :  [EMAIL PROTECTED]
cc : 
Objet : XSL transform in Maven?


Hello,

I have an XML file that I would like to transform with an XSL file that I 
have. I can't seem to find a way to do this in Maven. Please can someone 
point me in the right direction.

Thanks
Neil

-
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]



scm:perform-release

2003-11-07 Thread Eric Taix
 
Hi,
 
Windows 2K
maven-1.0rc1
 
 
I'm trying to use scm:perform-release goal. The checkout work fine, but when maven try 
to create a new process for the perform goal i've got a build failed. I try with the 
most simple goal : clean and it also failed.
 
Here is my command line :
 
maven -Dmaven.scm.bootstrap.goal=clean -Dmaven.scm.cvs.module=module1 
-Dmaven.scm.cvs.sticky.tag=tag1 scm:perform-release
 
And here is the console output :
 
BUILD FAILED
File file/D:/BuildSystem/tools/maven-1.0-rc1/plugins/maven-scm-plugin-1.1/
Element ant:exec
Line 154
Error 2
 
I try to find what can be the root of this error and i think i found.
 
In maven-scm-plugin-1.1 the jelly script use this ant tag :
ant:exex dir=${maven.scm.checkout.dir}/${maven.scm.cvs.module} executable=maven 
failonerror=true
  ant:arg line=${maven.scm.bootstrap.goals}/
/ant:exec
 
The Ant exec error n°2 is when executable can't be found. In fact on Windows system a 
bat file can be lauch by just maven (.bat is optionnal). But with Ant you have to 
specify the extension of your file. In maven distribution there is a maven file for 
unix and maven.bat for windows.
 
So on windows i have to change executable=maven by executable=maven.bat[Eric Taix] 
 and it work fine... 
 
 
 
Hope this can help you and perhaps there's a better solution
 
Eric T.
 


Rep:scm:perform-release

2003-11-07 Thread Emmanuel Venisse
Could you add an issue into Jira? I fixed this asap.

Emmanuel

-Message d'origine-
De: Eric Taix [EMAIL PROTECTED]
A: [EMAIL PROTECTED] Apache. Org (E-mail) [EMAIL PROTECTED]
Date: 07/11/03
Objet: scm:perform-release

 
Hi,
 
Windows 2K
maven-1.0rc1
 
 
I'm trying to use scm:perform-release goal. The checkout work fine, but
when maven try to create a new process for the perform goal i've got a
build failed. I try with the most simple goal : clean and it also
failed.
 
Here is my command line :
 
maven -Dmaven.scm.bootstrap.goal=clean -Dmaven.scm.cvs.module=module1
-Dmaven.scm.cvs.sticky.tag=tag1 scm:perform-release
 
And here is the console output :
 
BUILD FAILED
File
file/D:/BuildSystem/tools/maven-1.0-rc1/plugins/maven-scm-plugin-1.1/
Element ant:exec
Line 154
Error 2
 
I try to find what can be the root of this error and i think i found.
 
In maven-scm-plugin-1.1 the jelly script use this ant tag :
ant:exex dir=${maven.scm.checkout.dir}/${maven.scm.cvs.module}
executable=maven failonerror=true
  ant:arg line=${maven.scm.bootstrap.goals}/
/ant:exec
 
The Ant exec error n°2 is when executable can't be found. In fact on
Windows system a bat file can be lauch by just maven (.bat is
optionnal). But with Ant you have to specify the extension of your file.
In maven distribution there is a maven file for unix and maven.bat
for windows.
 
So on windows i have to change executable=maven by
executable=maven.bat[Eric Taix]  and it work fine... 
 
 
 
Hope this can help you and perhaps there's a better solution
 
Eric T.
 


_
Un mot doux à envoyer? Une sortie ciné à organiser? Faites le en temps
réel avec MSN Messenger! C'est gratuit!   http://ifrance.com/_reloc/m
_
Envie de discuter en live avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France


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



RE: scm:perform-release

2003-11-07 Thread Eric Taix
OK

-Message d'origine-
De : Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 7 novembre 2003 17:50
À : Maven Users List
Objet : Rep:scm:perform-release


Could you add an issue into Jira? I fixed this asap.

Emmanuel

-Message d'origine-
De: Eric Taix [EMAIL PROTECTED]
A: [EMAIL PROTECTED] Apache. Org (E-mail) [EMAIL PROTECTED]
Date: 07/11/03
Objet: scm:perform-release

 
Hi,
 
Windows 2K
maven-1.0rc1
 
 
I'm trying to use scm:perform-release goal. The checkout work fine, but
when maven try to create a new process for the perform goal i've got a
build failed. I try with the most simple goal : clean and it also
failed.
 
Here is my command line :
 
maven -Dmaven.scm.bootstrap.goal=clean -Dmaven.scm.cvs.module=module1
-Dmaven.scm.cvs.sticky.tag=tag1 scm:perform-release
 
And here is the console output :
 
BUILD FAILED
File
file/D:/BuildSystem/tools/maven-1.0-rc1/plugins/maven-scm-plugin-1.1/
Element ant:exec
Line 154
Error 2
 
I try to find what can be the root of this error and i think i found.
 
In maven-scm-plugin-1.1 the jelly script use this ant tag :
ant:exex dir=${maven.scm.checkout.dir}/${maven.scm.cvs.module}
executable=maven failonerror=true
  ant:arg line=${maven.scm.bootstrap.goals}/
/ant:exec
 
The Ant exec error n°2 is when executable can't be found. In fact on
Windows system a bat file can be lauch by just maven (.bat is
optionnal). But with Ant you have to specify the extension of your file.
In maven distribution there is a maven file for unix and maven.bat
for windows.
 
So on windows i have to change executable=maven by
executable=maven.bat[Eric Taix]  and it work fine... 
 
 
 
Hope this can help you and perhaps there's a better solution
 
Eric T.
 


_
Un mot doux à envoyer? Une sortie ciné à organiser? Faites le en temps
réel avec MSN Messenger! C'est gratuit!   http://ifrance.com/_reloc/m
_
Envie de discuter en live avec vos amis ? Télécharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France


-
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: war plugin : [maven.caller.call.compile-java] is not defined

2003-11-07 Thread Michal Maczka


 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 07, 2003 3:57 PM
 To: 'Maven Users List'
 Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined




  -Original Message-
  From: Michal Maczka [mailto:[EMAIL PROTECTED]
  Sent: 06 November 2003 11:42
  To: Maven Users List
  Subject: Re: war plugin : [maven.caller.call.compile-java] is not
 defined
 
  Vincent Massol wrote:
 
  Hi Eric,
  
  No. It's because you seem not to have installed the caller plugin...
 My
  guess is that you have only taken the war plugin from HEAD without
  taking it's dependencies. Actually, thinking about it, we should add
 a
  dependency in the war plugin on the caller plugin so that it gets
  automatically downloaded.
  
  -Vincent
  
  
  Vincent!
  I really like your idea of Well Know Goals which  is implemented in
  Caller Plugin but I think ... that this plugin should be dropped.
 
  In particular case of java:compile goal - it's java plugin which is
  badly written.
 
  I don't think we need a central point for wiring goals.
 
  Existence of caller plugin just shows that  we need to have a well
  defined and *extendable* workflow.

 Yes. My implementation of this workflow is a poor man's implementation
 but it satisfied my immediate need. Feel free to improve it provided you
 keep the same feature. :-)

 
  Lets's concentrate on java plugin:
  java:compile process can be divided into 3 steps:
a) generation of java classes (with plugin  xdoclet, jaxb, castor)
b) compilation with e.g javac/aspectj compiler

 I don't think so. The java plugin is about java. It's NOT about aspectj,
 nor is it about any extension to the java language like xdoclet or
 whatever. I would not want to tie the java plugin with aspectj.

c) applictaion of bytecode ehancers (like kodo, ascpectj )

 same here.

 
 
  a)
  foreach codeGenerator in codeGenerator do:
 attainGoal name=${codeGenerator}:generate/
  end;
  b)
  java:compile (calls javac:compile or aspectj:compile or
  eclipse-compiler:compile)
 
  c)
  foreach byteCodeEnhancer in byteCodeEnhancers do:
 attainGoal name=$byteCodeEnhancer}:enhace/
  end;
 
 
 
  IMHO the best solution will be to
 
  a) rename  java:compile goal to javac:compile
 
  add java:compile which does what you have tried to do with caller
 plugin.

 I had thought about this solution is course (as it is much simpler to
 implement than the caller plugin). However, I don't like the coupling it
 introduces. Granted the caller plugin is one coupling but the idea was
 to have one coupling instead of several and actually the next step was
 to transform the caller plugin in java code and put that inside Maven
 core.

 I think the aspectj aspect must be completely independent of the java
 plugin. It should be possible to replace the java plugin by the aspectj
 plugin (or by any other custom implementation) seamlessly.


I fact I meant that java:compile is a place where java source are
compiled.
If they are compiled with javac, eclipse compiler, jikes, aspectj
(could be that aspectj compiler is as fact in compiling java sources when no
aspect are provided as any other java compiler)
is no so important to me.


You can have also things like:

jsp:compile
ejb:compile
xmlc:compile
etc

so I think that name java:compile is quite appropriate.

but the name of the plugin/goal is in fact of second importance here.
I am just advocating against central place when goals are wired together.

As I think that usage of preGoals/postGoals should be avoided in plugins
(it's the case right now) we should possibly try to define merge points
of the build process (as the workflow)  and let other plugins be
participants of this process.

For me the ultimate goal  would be to make entire process clickable so
almost no scripting in maven.xml file is needed

So what will be nice is to let other plugins
a) do some actions before java:compile is executed (e.g. let source
generators generate java source files)
b) modify byte code produced by java compiler.

regards

Michal



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



RE: Réf. : XSL transform in Maven?

2003-11-07 Thread Neil Blue
Thank you that has got me started. The ant style target needs a trax processor, do you 
know what one should be used?

Here is what I am using:

${systemScope.setProperty('java.xml.transform.TransformerFactory', 
   'org.apache.xalan.xsltc.trax.TransformerFactoryImpl')}
echo message=${java.xml.transform.TransformerFactory}/
style 
in=simple.xml
out=${maven.docs.dest}/simple.out.xml
style=src/xsl/dia.xsl
classpathref=maven.dependency.classpath
processor=trax/

but I get the error:

${systemScope.setProperty('java.xml.transform.TransformerFactory', 
   'org.apache.xalan.xsltc.trax.TransformerFactoryImpl')}
echo message=${java.xml.transform.TransformerFactory}/
style 
in=simple.xml
out=${maven.docs.dest}/simple.out.xml
style=src/xsl/dia.xsl
classpathref=maven.dependency.classpath
processor=trax/

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: 07 November 2003 16:16
To: Maven Users List
Subject: Réf. : XSL transform in Maven?


Take a look at :
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=149msgNo=3359
It may help.

Nicolas






Neil Blue [EMAIL PROTECTED]
07/11/2003 16:45
Veuillez répondre à Maven Users List

 
Pour :  [EMAIL PROTECTED]
cc : 
Objet : XSL transform in Maven?


Hello,

I have an XML file that I would like to transform with an XSL file that I 
have. I can't seem to find a way to do this in Maven. Please can someone 
point me in the right direction.

Thanks
Neil

-
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: war plugin : [maven.caller.call.compile-java] is not defined

2003-11-07 Thread Vincent Massol


 -Original Message-
 From: Michal Maczka [mailto:[EMAIL PROTECTED]
 Sent: 07 November 2003 18:01
 To: Maven Users List
 Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined

[snip]

  I think the aspectj aspect must be completely independent of the
java
  plugin. It should be possible to replace the java plugin by the
aspectj
  plugin (or by any other custom implementation) seamlessly.
 
 
 I fact I meant that java:compile is a place where java source are
 compiled.
 If they are compiled with javac, eclipse compiler, jikes, aspectj
 (could be that aspectj compiler is as fact in compiling java sources
when
 no
 aspect are provided as any other java compiler)
 is no so important to me.

Yep, except that aspects not java classes. So java:compile would not
fit. However aspectj:compile would... :-)

 
 
 You can have also things like:
 
 jsp:compile
 ejb:compile
 xmlc:compile
 etc

aspectj:compile

 
 so I think that name java:compile is quite appropriate.

Nope, not for me... ;-)

 
 but the name of the plugin/goal is in fact of second importance here.
 I am just advocating against central place when goals are wired
 together.

Which is exactly why I introduced the caller plugin. It is to unwire
dependencies between plugins! :-)

 
 As I think that usage of preGoals/postGoals should be avoided in
plugins
 (it's the case right now) we should possibly try to define merge
points
 of the build process (as the workflow)  and let other plugins be
 participants of this process.

Yep, but isn't this exactly what the caller plugin does? Again, I do
agree that it would be better written in java and inside Maven core.
I've defined a merge point as a WKG (Well-Known Goal).

 
 For me the ultimate goal  would be to make entire process clickable
so
 almost no scripting in maven.xml file is needed

yep. With the caller plugin you simply need to provide a GUI for editing
the WKG properties.

 
 So what will be nice is to let other plugins
 a) do some actions before java:compile is executed (e.g. let source
 generators generate java source files)

For end users, sure. For plugins I'm not sure it's really needed,
provided the plugins are small and focused enough. But why not.

 b) modify byte code produced by java compiler.

Or replace the java plugin by your own one. BTW, this is not possible to
do easily with the current aspectj version as it doesn't support weaving
bytecodes on a directory (only on a jar). Hence the reason for all the
above... ;-)

Regards,
-Vincent


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



RE: Réf. : XSL transform in Maven?

2003-11-07 Thread Neil Blue
OK I have this working now.

mkdir dir=trans/

${systemScope.setProperty('javax.xml.transform.TransformerFactory','org.apache.xalan.processor.TransformerFactoryImpl')}
  style
basedir=${basedir}
destdir=trans extension=.xml
style=dia.xsl
includes=simple.xml/

using xml-apis 2.0.2
xalan 2.5.1
xerces 2.4.0

the trasformation I am using is from jase, and it requires a layout class 
org.jase.DiagLayout. Is there a way to put this on the classpath through maven?

Neil

-Original Message-
From: Neil Blue 
Sent: 07 November 2003 17:12
To: Maven Users List
Subject: RE: Réf. : XSL transform in Maven?


Thank you that has got me started. The ant style target needs a trax processor, do you 
know what one should be used?

Here is what I am using:

${systemScope.setProperty('java.xml.transform.TransformerFactory', 
   'org.apache.xalan.xsltc.trax.TransformerFactoryImpl')}
echo message=${java.xml.transform.TransformerFactory}/
style 
in=simple.xml
out=${maven.docs.dest}/simple.out.xml
style=src/xsl/dia.xsl
classpathref=maven.dependency.classpath
processor=trax/

but I get the error:

${systemScope.setProperty('java.xml.transform.TransformerFactory', 
   'org.apache.xalan.xsltc.trax.TransformerFactoryImpl')}
echo message=${java.xml.transform.TransformerFactory}/
style 
in=simple.xml
out=${maven.docs.dest}/simple.out.xml
style=src/xsl/dia.xsl
classpathref=maven.dependency.classpath
processor=trax/

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: 07 November 2003 16:16
To: Maven Users List
Subject: Réf. : XSL transform in Maven?


Take a look at :
http://nagoya.apache.org/eyebrowse/ReadMsg?listId=149msgNo=3359
It may help.

Nicolas






Neil Blue [EMAIL PROTECTED]
07/11/2003 16:45
Veuillez répondre à Maven Users List

 
Pour :  [EMAIL PROTECTED]
cc : 
Objet : XSL transform in Maven?


Hello,

I have an XML file that I would like to transform with an XSL file that I 
have. I can't seem to find a way to do this in Maven. Please can someone 
point me in the right direction.

Thanks
Neil

-
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: war plugin : [maven.caller.call.compile-java] is not defined

2003-11-07 Thread Michal Maczka
[...]
 Yep, but isn't this exactly what the caller plugin does? Again, I do
 agree that it would be better written in java and inside Maven core.
 I've defined a merge point as a WKG (Well-Known Goal).

I agree.

Just to explain myslef

I tried to explain ( I am sick today :(  so it's not going well)

That in goal war:init:


 goal name=war:init
description=Initialize the file system and attain any necessary goals

ant:available property=webSourcesPresent type=dir
  file=${maven.war.src}/

j:if test=${sourcesPresent == 'true'}
  caller:call goalInterface=compile-java/
  attainGoal name=test:test/
/j:if

ant:property name=maven.war.final.name
  value=${pom.artifactId}.war/

  /goal

There should be no call to caller plugin


just something like

j:if test=${sourcesPresent == 'true'}
  atainGoal name=x:compile/  (e.g x:compile=java:compile)
  attainGoal name=test:test/
/j:if

and it should be up to (just an example - I am not imposing anything) java
plugin to handle this call (In place of WKG there will be WKG in Well Know
Plugin).
It's like you are looking up well know service (interface) and call it
while with caller plugin it's like you are looking up the name of the
service before calling it.
(I hope that difference is clear)

So as a consequnce (as I see it)  war plugin should not depend on caller
plugin and we should put inside java plugin a logic which binds a call to
compile
goal to particual executor.


Michal



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



Modifying jar plugin

2003-11-07 Thread Vikas Phonsa
Hi Everybody,

I am using a project directory structure different than the one specified by
maven and have updated the basic properties accordingly.

I have

maven.build.dir=${basedir}


And the jar plugin by default would place the generated jar in
maven.build.dir but I want to place that in ${maven.build.dir}/builds

What would be the best way to do that. I have looked into the jelly script
code for the jar plugin:

ant:jar
  jarfile=${maven.build.dir}/${maven.final.name}.jar
  basedir=${maven.build.dest}
  index=${maven.jar.index}
  compress=${maven.jar.compress}
  excludes=${maven.jar.excludes} 


In the above ant task (and at other places in script) I can use another user
define property like ${maven.jar.dest} instead of ${maven.build.dir}.

But is there another way I can achieve my desired functionality without
modifying the jar plugin ?

Please guide.

Thanks

Vikas
  
[EMAIL PROTECTED]

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



RE: Modifying jar plugin

2003-11-07 Thread Michal Maczka


 -Original Message-
 From: Vikas Phonsa [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 07, 2003 7:50 PM
 To: 'Maven Users List'
 Subject: Modifying jar plugin


 Hi Everybody,

 I am using a project directory structure different than the one
 specified by
 maven and have updated the basic properties accordingly.

 I have

 maven.build.dir=${basedir}


 And the jar plugin by default would place the generated jar in
 maven.build.dir but I want to place that in ${maven.build.dir}/builds

 What would be the best way to do that. I have looked into the jelly script
 code for the jar plugin:

 ant:jar
   jarfile=${maven.build.dir}/${maven.final.name}.jar
   basedir=${maven.build.dest}
   index=${maven.jar.index}
   compress=${maven.jar.compress}
   excludes=${maven.jar.excludes}


 In the above ant task (and at other places in script) I can use
 another user
 define property like ${maven.jar.dest} instead of ${maven.build.dir}.

 But is there another way I can achieve my desired functionality without
 modifying the jar plugin ?

 Please guide.

You can write your own script which will replace jar plugin.


Michal



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



RE: war plugin : [maven.caller.call.compile-java] is not defined

2003-11-07 Thread Vincent Massol


 -Original Message-
 From: Michal Maczka [mailto:[EMAIL PROTECTED]
 Sent: 07 November 2003 19:36
 To: Maven Users List
 Subject: RE: war plugin : [maven.caller.call.compile-java] is not
defined

[snip]

 That in goal war:init:
 
 
  goal name=war:init
 description=Initialize the file system and attain any necessary
 goals
 
 ant:available property=webSourcesPresent type=dir
   file=${maven.war.src}/
 
 j:if test=${sourcesPresent == 'true'}
   caller:call goalInterface=compile-java/
   attainGoal name=test:test/
 /j:if
 
 ant:property name=maven.war.final.name
   value=${pom.artifactId}.war/
 
   /goal
 
 There should be no call to caller plugin
 
 
 just something like
 
 j:if test=${sourcesPresent == 'true'}
   atainGoal name=x:compile/  (e.g
x:compile=java:compile)
   attainGoal name=test:test/
 /j:if
 
 and it should be up to (just an example - I am not imposing anything)
 java
 plugin to handle this call (In place of WKG there will be WKG in Well
Know
 Plugin).

I would not like at all that the java plugin has to know about all the
other plugins (like the aspectj plugin, the xdoc plugin, etc).

If we have:
 
j:if test=${sourcesPresent == 'true'}
  atainGoal name=x:compile/  (e.g
x:compile=java:compile)
  attainGoal name=test:test/
/j:if

And if there is some interception, then it is *very* misleading because
the reader will think the java plugin will be called but in practice it
will be some other plugin's goal.

I definitely prefer the notion of common interfaces (WKG). It seems
logical to me that the war plugin would use one WKG for compilation.

 It's like you are looking up well know service (interface) and call
it
 while with caller plugin it's like you are looking up the name of the
 service before calling it.
 (I hope that difference is clear)

No... Either I don't understand or I don't agree... :-)

 
 So as a consequnce (as I see it)  war plugin should not depend on
caller
 plugin and we should put inside java plugin a logic which binds a
call
 to
 compile
 goal to particual executor.

-1, unless I understand what you're saying... ;-)

My internal logic tells me that it's always high in the chain that you
make choices about different implementations to use and not the other
way around.

What do others think? Am I really dumb and not understanding what our
friend Michal is saying?

Thanks
-Vincent



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



RE: war plugin : [maven.caller.call.compile-java] is not defined

2003-11-07 Thread Michal Maczka


 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 07, 2003 9:08 PM
 To: 'Maven Users List'
 Subject: RE: war plugin : [maven.caller.call.compile-java] is not defined




  -Original Message-
  From: Michal Maczka [mailto:[EMAIL PROTECTED]
  Sent: 07 November 2003 19:36
  To: Maven Users List
  Subject: RE: war plugin : [maven.caller.call.compile-java] is not
 defined

 [snip]

  That in goal war:init:
 
 
   goal name=war:init
  description=Initialize the file system and attain any necessary
  goals
 
  ant:available property=webSourcesPresent type=dir
file=${maven.war.src}/
 
  j:if test=${sourcesPresent == 'true'}
caller:call goalInterface=compile-java/
attainGoal name=test:test/
  /j:if
 
  ant:property name=maven.war.final.name
value=${pom.artifactId}.war/
 
/goal
 
  There should be no call to caller plugin
 
 
  just something like
 
  j:if test=${sourcesPresent == 'true'}
atainGoal name=x:compile/  (e.g
 x:compile=java:compile)
attainGoal name=test:test/
  /j:if
 
  and it should be up to (just an example - I am not imposing anything)
  java
  plugin to handle this call (In place of WKG there will be WKG in Well
 Know
  Plugin).

 I would not like at all that the java plugin has to know about all the
 other plugins (like the aspectj plugin, the xdoc plugin, etc).


Me neither
what I want to have (writen with caller plugin sematic)

 goal name=java:compile
j:if test=${sourcesPresent == 'true'}
   caller:call goalInterface=compile-java/
   /j:if
 /goal


 If we have:

 j:if test=${sourcesPresent == 'true'}
   atainGoal name=x:compile/  (e.g
 x:compile=java:compile)
   attainGoal name=test:test/
 /j:if

 And if there is some interception, then it is *very* misleading because
 the reader will think the java plugin will be called but in practice it
 will be some other plugin's goal.



Exactly that's the point.  java plugin and java:compile plugin will be
always called and should be always called!.
So you can add prepostGoals for java:compile

and the do

maven.caller.call.compile-java = javac:compile
or
maven.caller.call.compile-java = jikes:compile


if you call
caller:call goalInterface=compile-java/ from war plugin you have to
change blocks like

preGoal name=java:compile
do something here
.preGoal


every time you want to change a compiler.

Michal



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



Re: navigation.xml - empty html links are generated

2003-11-07 Thread Leif Nelson
OK.  So, here it is again.

1)  Install Beta-10.  Run maven site:generate (navigation.html 
works.  there are valid links in there)
2)  Upgrade to RC-1.  Run maven site:generate (navigation.html is 
broken.  All links go nowhere)
3)  Delete c:\documents and settings\userid\.maven\plugins
4)  Run RC-1 site:generate.  navigation.html works now.   Conflicting 
plugin versions?  I guess so.

So, from now on, is the upgrade process include deleting your 
~\.maven\plugins dir?  I assume that's a yes.

Thanks,

--Leif

At 05:54 PM 10/17/2003 +0200, you wrote:
Leif Nelson wrote:

I had exactly the same problem when going from beta-10 to rc1.  After 
hearing that someone else had the same problem, I did the obvious, and 
started with a fresh project.  I found, that I had a navigation.xml in my 
xdocs that looks like this:
?xml version=1.0 encoding=ISO-8859-1?
project name=My Project
  titleMy Project/title
  body
menu name=Overview
  item name=Goals   href=/goals.html/
  item name=Featureshref=/features.html/
  item name=News and Status href=/status.html/
  item name=Getting Started href=/start/index.html/
  item name=Reference   href=/ref/index.html/
  menu name=Custom Reports
!-- Add more custom reports here --
  /menu
  item name=Powered By  href=/powered.html/
/menu
  /body
/project
And, I also found that when doing:
maven xdoc:generate-from-pom
It doesn't generate any navigation.xml file.  So, I removed my 
navigation.xml file...  And guess what, I now have working navigation again.
So, I guess the question is...  what's wrong with a navigation.xml that 
looks like the one above?  It generates links that are all empty.
That's the point. I am not sure whether there is sth. wrong with the 
navigation.xml. I do not see any errors. I have tried this with a very 
simple navigation.xml and it didn't work either with RC-1. So the problem 
is somewhere else to my mind.

-marek

-
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]


including source in jar

2003-11-07 Thread Vikas Phonsa
Hi,
Can I have the jar goal generate a jar that includes the source code file
also beside the .class files.

Thanks

Vikas



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



Re: including source in jar

2003-11-07 Thread Leif Nelson
I have this in my maven.xml to generate a separate sources zip, when 
building a jar.

  postGoal name=jar:jar 
echocreating sources zip from ${maven.src.dir}/echo
zip
 zipfile=${maven.build.dir}/${maven.final.name}-src.zip
 basedir=${maven.src.dir} 
 excludes=**/**.class 
   /zip
  /postGoal
Enjoy,

--Leif

At 01:18 PM 11/7/2003 -0800, you wrote:
Hi,
Can I have the jar goal generate a jar that includes the source code file
also beside the .class files.
Thanks

Vikas



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


anyone using webserver goal?

2003-11-07 Thread Kelly Sonderegger
I can't seem to find the documentation on webserver goal available
property values.
e.g.  the doc talks about properties such as maven.webserver.name but
doesn't specify what valid names are.

anyone have an idea.

Thanks,
Kelly Sonderegger

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



java.lang.OutOfMemoryError

2003-11-07 Thread Rauf, Saleem
Hi 
 
I am getting java.lang.OutOfMemoryError, see below:
 
BUILD FAILED
File.. file:/D:/Documents and Settings/srauf/.maven/plugins/maven-xdoc-plugin-1.4/
Element... x:parse
Line.. 101
Column 46
java.lang.OutOfMemoryError
Total time: 8 minutes 13 seconds
Finished at: Fri Nov 07 17:58:55 CST 2003
 
Has anyone ran across this?
 
Thanks,
-S

 


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

How do I move maven.log?

2003-11-07 Thread Scott Brickner
Maven is littering my project folders with maven.log files, none of
which say anything useful (just info on the running time). Is there some
officially supported way for me to make it put that log somewhere else?
Or to suppress it entirely when things are running fine?


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



Re: java.lang.OutOfMemoryError

2003-11-07 Thread dion
Sure,

set MAVEN_OPTS=-Xmx512m

or something similar
--
dIon Gillard, Multitask Consulting
Blog:  http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc


Rauf, Saleem [EMAIL PROTECTED] wrote on 08/11/2003 11:09:42 AM:

 Hi 
 
 I am getting java.lang.OutOfMemoryError, see below:
 
 BUILD FAILED
 File.. file:/D:/Documents and Settings/srauf/.
 maven/plugins/maven-xdoc-plugin-1.4/
 Element... x:parse
 Line.. 101
 Column 46
 java.lang.OutOfMemoryError
 Total time: 8 minutes 13 seconds
 Finished at: Fri Nov 07 17:58:55 CST 2003
 
 Has anyone ran across this?
 
 Thanks,
 -S
 
 
 
 
 -
 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]



build and resource and sourceDirectory and dependency and Maven maven site:generate Question

2003-11-07 Thread Rauf, Saleem
 
 
Hi 
 
 
I am new Maven, I have few questions
 
1.)  Currently I have all my jar files for the code to complie in  
/sporty2g/distribution/lib, Can copy to /target/classes by doing the following when I 
run maven site:generate:
resources
resource
   directory/sporty2g/distribution/lib/directory
 targetPath/distribution/lib/targetPath
  /resource
  /resources 
Inside build

1a.) If question 1 is sucess in copying the jars into /target.classes, Then can I use 
the jar files copied in /target/classes in maven when run maven site:generate: 
instead of using the following dependency tag, My reason of asking this because I 
have like 45 jar files, and wondering if I can just make maven point a directory 
instead of listing each jar file in  dependency tag.

dependencies dependency
  groupIdxmlunit/groupId
  artifactIdxmlunit/artifactId
  version1.0/version
/dependency
   /dependencies

2.)According maven-project.xsd the xml schema for project.xml file, it states that 
build element can have  zero to many sourceDirectory elements as stated below. Well 
when I put multiple  sourceDirectory elements in my body element, it doesn't complain 
about project.xml, but when run maven site:generate, it only looks at one of  
sourceDirectory element  and processes it, and ignores the other one. see Below for my 
example: 


   1.)   sourceDirectory/sporty2g/home/ejb/generated-src/java/sourceDirectory
2.)  sourceDirectory/sporty2g/home/web/src/java/sourceDirectory
Note: for some reason in this case it agnores 1.), but picks up 2.) . If this is the 
way it works, then Why does xml schema for project.xml allows you to have multiple 
sourceDirectory element.

maven-project.xsd the xml schema for project.xml file:

xs:element name=build
xs:complexType
  xs:sequence
xs:element ref=nagEmailAddress minOccurs=0/
xs:element ref=sourceDirectory minOccurs=0/
xs:element ref=sourceModifications minOccurs=0/
xs:element ref=unitTestSourceDirectory minOccurs=0/
xs:element ref=integrationUnitTestSourceDirectory minOccurs=0/
xs:element ref=aspectSourceDirectory minOccurs=0/
xs:element ref=unitTest minOccurs=0/
!-- no longer appears in build.java 
xs:element ref=integrationUnitTest minOccurs=0/
--
xs:element ref=resources minOccurs=0/
  /xs:sequence
/xs:complexType
  /xs:element

xs:element name=sourceDirectory type='xs:string'/

 

 

3.) If question 2 is an issue,which means I cannot process multiple sourceDirectory 
element, Then what is an work around this? Because my src code in located in 10 
diffrent directories, Here is where all the directories where my source code is 
located to process, just to create the site using maven.  

  sourceDirectory/sporty2g/home/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/home/ejb/src/java/sourceDirectory
  
  sourceDirectory/sporty2g/home/web/src/java/sourceDirectory
  
  
sourceDirectory/sporty2g/administration/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/administration/ejb/src/java/sourceDirectory
  
sourceDirectory/sporty2g/administration/web/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/administration/web/src/java/sourceDirectory
  
  sourceDirectory/sporty2g/bondadmin/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/bondadmin/ejb/src/java/sourceDirectory
  sourceDirectory/sporty2g/bondadmin/web/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/bondadmin/web/src/java/sourceDirectory
  
  sourceDirectory/sporty2g/cashmgt/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/cashmgt/ejb/src/java/sourceDirectory
  sourceDirectory/sporty2g/cashmgt/web/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/cashmgt/web/src/java/sourceDirectory
  
  sourceDirectory/sporty2g/defproc/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/defproc/ejb/src/java/sourceDirectory
  sourceDirectory/sporty2g/defproc/web/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/defproc/web/src/java/sourceDirectory
  
  sourceDirectory/sporty2g/doctrack/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/doctrack/ejb/src/java/sourceDirectory
  sourceDirectory/sporty2g/doctrack/web/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/doctrack/web/src/java/sourceDirectory
  
  
  sourceDirectory/sporty2g/eai/ejb/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/eai/ejb/src/java/sourceDirectory
  sourceDirectory/sporty2g/eai/web/generated-src/java/sourceDirectory
  sourceDirectory/sporty2g/eai/web/src/java/sourceDirectory
  
  sourceDirectory/sporty2g/servacct/ejb/generated-src/java/sourceDirectory