Re: velocity-1.4-dev.jar gone from Ibibli, what to do?

[Dennis Geurts]

Hi Jason,
 Unsure where to file the issue exactly I filed it here:
 http://jira.codehaus.org/browse/MAVEN-1719
 Dennis
 On 10/26/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> We¡re working on this and it'll be fixed in the next hours.
>
> On 10/26/05, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-10-26 at 14:09 +, Ruud Wijnands wrote:
> > > Is it possible that it has something to do with load balancing of
> servers?
> > > The problem got 'solved' about half an hour after I posted my mail.
> Via the
> > > webserver the file still were not there. I thing this is something
> that can
> > > go wrong when load balancing is applied, but the servers are not in
> sync.
> >
> > No, this is a problem on our end. With our sync'ing process and with
> > some code in m2. We're looking into it.
> >
> > > On 10/25/05, Ruud Wijnands <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I just removed my complete maven 1.0.2 repository to perform a full
> clean
> > > > build and download everything fresh.
> > > > I ran into the problem that now velocity-1.4-dev.jar cannot be
> downloaded.
> > > > When I look at the ibiblio site this seems correct.
> > > >
> > > > Has this been removed by mistake? How can I fix this? I don't have a
> local
> > > > copy.
> > > >
> > > > Regards,
> > > > Ruud Wijnands
> > > >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason at maven.org 
> > http://maven.apache.org
> >
> > Simplex sigillum veri. (Simplicity is the seal of truth.)
> >
> >
> > -
> > 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: velocity-1.4-dev.jar gone from Ibibli, what to do?

[Dennis Geurts]

Funny, I just noticed the same !!!
 If you can find it at
http://www.ibiblio.org/maven2/velocity/velocity/1.4-dev/
  I agree it's of course much nicer to be able to automatically download it
after a repo clean...
 as a side note:

It also seems that commons-logging-1.1-dev.jar is also missing...
(also available at maven2 repo)
http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1-dev/
 both jars are dependencies for various 'important' plugins (e.g. xdoclet
plugin)
Should I post a JIRA issue to request for an update of these plugins to
depend
on jars that are NOT development versions ??
 Dennis
 On 10/25/05, Ruud Wijnands <[EMAIL PROTECTED]> wrote:
>
> I just removed my complete maven 1.0.2 repository to perform a full clean
> build and download everything fresh.
> I ran into the problem that now velocity-1.4-dev.jar cannot be downloaded.
> When I look at the ibiblio site this seems correct.
>
> Has this been removed by mistake? How can I fix this? I don't have a local
> copy.
>
> Regards,
> Ruud Wijnands
>
>

Re: gRE: M2 and annotations

[Dennis Geurts]

It's probably the best to look at Sun's documentation
 APT (Annotation Processing Tool): 
http://java.sun.com/j2se/1.5.0/docs/guide/apt/index.html
 Annotations in general: 
http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
 Dennis
  p.s. I'm also not experienced myself with annotations to be giving others 
any well-funded advice
but there's something called "retention policy" i.e. you can supply to the 
compiler/ VM whether
it should expose the annotation metadata during runtime or not.
 Seems odd though that one VM (eclipse) does seem to expose it and another 
(maven w/ JUnit) does not.
Could it be that the 'tools.jar' is needed ?? (the APT api can be found in 
com.sun.mirror.* )
  
 On 9/11/05, Kaare Nilsen <[EMAIL PROTECTED]> wrote: 
> 
> Hi.
> I am compiling with source level of 1.5 by doing this :
> 
> org.apache.maven.plugins
> 
> maven-compiler-plugin
> 
> 1.5
> 1.5
> 
> 
> 
> But I do not know how to run annotation processor. (I am not that
> experienced with annotations myself, so I did not even know there was 
> one),
> so if anyone know how I do this I would be glad for any tips.
> 
> Best regards
> Kaare Nilseb
> 
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 11. september 2005 04:57
> To: Maven Users List
> Subject: Re: M2 and annotations
> 
> I'm not familiar with using Java5 annotations at this point, but I think 
> you
> 
> need to run the annotation processor first, or at least compile with 
> source
> level of 1.5. Have these been done?
> 
> - Brett
> 
> On 9/11/05, Kaare Nilsen <[EMAIL PROTECTED]> wrote:
> >
> > Hi I have a little problem.
> >
> >
> >
> > I am trying to make a testng plugin for maven2, but I have reached a 
> point
> > where I really don't know what to do.
> >
> > Here is the case:
> >
> >
> >
> > TestNG uses annotations and have an annotation called Test with fully
> > qualified name :" org.testng.annotations.Test"
> >
> > So..
> >
> > Then I have a testclass looking like this .
> >
> >
> >
> > package org.codehaus.mojo.testng;
> >
> > import org.testng.annotations.Test;
> >
> > public class ATest {
> >
> >
> >
> > @Test
> >
> > public void test(){
> >
> > System.out.println("A test is run");
> >
> > }
> >
> >
> >
> >
> >
> > And. Then I do like this:
> >
> >
> >
> > public void execute()
> >
> > throws MojoExecutionException
> >
> > {
> >
> > Object o = loader.loadClass("org.codehaus.mojo.testng.ATest
> > ").newInstance();
> >
> > Method[] met = o.getClass().getMethods();
> >
> > Class annotation = Class.forName("org.testng.annotations.Test");
> >
> > Object thisAnnotation = met[0].getAnnotation((Class)
> > annotation);
> >
> > }
> >
> >
> >
> > So far so good.. But this is what happens.
> >
> > When I run this plugin in eclipse with a junit test. thisAnnotation !=
> > null
> >
> > But when I run this plugin as a part of a maven build thisAnnotation ==
> > null
> >
> >
> >
> > Anyone have a clue of why this happens ?
> >
> >
> >
> > Best regards
> >
> > Kaare Nilsen
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: xdoclet dependency

[Dennis Geurts]

ok nicolas, thanks for the info (is must have copied it 'eons' ago and 
forgot about it afterwards),
 seems that some alteration is in order; either move/ copy the 
xjavadoc-1.0.*
to xjavadoc or the maven-xdoclet-plugin (version 1.2) should
incorporate a correct dependency.
 I do not think it is a good programming practice to define an invalid 
dependency
and subsequently requiring from the developer that it should copy the 
dependency
from its (apparently) default location to some other undocumented location.
  any comments ??
 dennis
 
 On 8/22/05, Nicolas De Loof <[EMAIL PROTECTED]> wrote: 
> 
> 
> xjavadoc-1.0.* exists on ibiblio with groupId 'xdoclet'
> latter versions (1.1) are registered under groupId xjavadoc.
> 
> 
> 
> Dennis Geurts a écrit :
> 
> >Dmitry,
> > maven-xdoclet-plugin depends on xjavadoc-1.0.2
> > this file seems to have disappeared from
> >ibiblio.org/maven <http://ibiblio.org/maven><http://ibiblio.org/maven>!
> > i do not know how to get it back there...
> > Dennis
> >
> > On 8/22/05, Dmitry Ochnev <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Hello Dennis,
> >>
> >>Monday, August 22, 2005, 3:01:35 PM, you wrote:
> >>
> >>
> >>
> >>>only for the xjavadoc jar, you should use a groupId of "xjavadoc" and
> >>>version "1.1"
> >>>for the xdoclet jars groupId="xdoclet" and version="1.2"
> >>>so:
> >>>
> >>>xjavadoc
> >>>xjavadoc
> >>>1.1
> >>>
> >>>
> >>>xdoclet
> >>>xdoclet
> >>>1.2
> >>>
> >>>
> >>>xdoclet
> >>>xdoclet-web-module
> >>>1.2
> >>>
> >>>
> >>>xdoclet
> >>>xdoclet-ejb-module
> >>>1.2
> >>>
> >>>etcetera...
> >>>Dennis
> >>>
> >>>
> >>It became better but it is still not working.
> >>Here is the part of the "project.xml":
> >>---begin---
> >>
> >>
> >>xdoclet
> >>1.2
> >>
> >>
> >>
> >>xdoclet
> >>xdoclet-web-module
> >>1.2
> >>
> >>
> >>
> >>xdoclet
> >>xdoclet-ejb-module
> >>1.2
> >>
> >>
> >>
> >>xjavadoc
> >>xjavadoc
> >>1.1
> >>
> >>
> >>
> >>xdoclet
> >>maven-xdoclet-plugin
> >>1.2
> >>plugin
> >>
> >>---end---
> >>
> >>And here is the output:
> >>---begin---
> >>Tag library requested that is not present: 'maven' in plugin: '
> >>maven-xdoclet-plugin-1.2'
> >>Attempting to download xjavadoc-1.0.2.jar.
> >>Response content length is not known
> >>Response content length is not known
> >>Response content length is not known
> >>WARNING: Failed to download xjavadoc-1.0.2.jar.
> >>
> >>BUILD FAILED
> >>File.. D:\apptest2\maven.xml
> >>Element... attainGoal
> >>Line.. 23
> >>Column 43
> >>The build cannot continue because of the following unsatisfied 
> dependency:
> >>
> >>xjavadoc-1.0.2.jar
> >>---end---
> >>
> >>Where is the error?
> >>
> >>
> >>
> >>--
> >>Best regards,
> >>Dmitry mailto:[EMAIL PROTECTED]
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> >
> 
> This message contains information that may be privileged or confidential 
> and is the property of the Capgemini Group. It is intended only for the 
> person to whom it is addressed. If you are not the intended recipient, you 
> are not authorized to read, print, retain, copy, disseminate, distribute, or 
> use this message or any part thereof. If you receive this message in error, 
> please notify the sender immediately and delete all copies of this message.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Re[8]: xdoclet dependency

[Dennis Geurts]

Dmitry,
 maven-xdoclet-plugin depends on xjavadoc-1.0.2
 this file seems to have disappeared from
ibiblio.org/maven!
 i do not know how to get it back there...
 Dennis

 On 8/22/05, Dmitry Ochnev <[EMAIL PROTECTED]> wrote: 
> 
> Hello Dennis,
> 
> Monday, August 22, 2005, 3:01:35 PM, you wrote:
> 
> > only for the xjavadoc jar, you should use a groupId of "xjavadoc" and
> > version "1.1"
> > for the xdoclet jars groupId="xdoclet" and version="1.2"
> > so:
> > 
> > xjavadoc
> > xjavadoc
> > 1.1
> > 
> > 
> > xdoclet
> > xdoclet
> > 1.2
> > 
> > 
> > xdoclet
> > xdoclet-web-module
> > 1.2
> > 
> > 
> > xdoclet
> > xdoclet-ejb-module
> > 1.2
> > 
> > etcetera...
> > Dennis
> 
> 
> It became better but it is still not working.
> Here is the part of the "project.xml":
> ---begin---
> 
> 
> xdoclet
> 1.2
> 
> 
> 
> xdoclet
> xdoclet-web-module
> 1.2
> 
> 
> 
> xdoclet
> xdoclet-ejb-module
> 1.2
> 
> 
> 
> xjavadoc
> xjavadoc
> 1.1
> 
> 
> 
> xdoclet
> maven-xdoclet-plugin
> 1.2
> plugin
> 
> ---end---
> 
> And here is the output:
> ---begin---
> Tag library requested that is not present: 'maven' in plugin: '
> maven-xdoclet-plugin-1.2'
> Attempting to download xjavadoc-1.0.2.jar.
> Response content length is not known
> Response content length is not known
> Response content length is not known
> WARNING: Failed to download xjavadoc-1.0.2.jar.
> 
> BUILD FAILED
> File.. D:\apptest2\maven.xml
> Element... attainGoal
> Line.. 23
> Column 43
> The build cannot continue because of the following unsatisfied dependency:
> 
> xjavadoc-1.0.2.jar
> ---end---
> 
> Where is the error?
> 
> 
> 
> --
> Best regards,
> Dmitry mailto:[EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Re[6]: xdoclet dependency

[Dennis Geurts]

Hi Dmitry,
 only for the xjavadoc jar, you should use a groupId of "xjavadoc" and 
version "1.1"
 for the xdoclet jars groupId="xdoclet" and version="1.2"
 so:
 
xjavadoc
xjavadoc
1.1

  
xdoclet
xdoclet
1.2

  
xdoclet
xdoclet-web-module
1.2

 
xdoclet
xdoclet-ejb-module
1.2

 etcetera...
 Dennis

 On 8/22/05, Dmitry Ochnev <[EMAIL PROTECTED]> wrote: 
> 
> Hello Jörg,
> 
> Monday, August 22, 2005, 1:58:33 PM, you wrote:
> 
> >> Attempting to download xjavadoc-1.2.jar.
> 
> > This does not exist. Latest release is 1.1.
> 
> It does exist: http://www.ibiblio.org/maven/xdoclet/jars/
> 
> > You should stay with
> > the original version (or at least check, that your used version of
> > XDoclet is compliant with the one of xjavadoc).
> 
> What do you mean "the original version"?
> 
> 
> --
> Best regards,
> Dmitry mailto:[EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Multiproject resources problem

[Dennis Geurts]

Mike,
 from your last e-mail can I conclude that tou are creating a new plugin 
called 'maven-multi-plugin'
that (among others) contains the goals 'build' ?
 or are you altering the plugin.jelly of the multiproject plugin ?
 another question: does 'project:build' resolve to a valid goal for the 
subprojects ??
 Furthermore: what are you really trying to accomplish ??
 I assumed you where having a multiproject setup and for only one of the 
subprojects, you just wanted to include the test-classes.
  


 
 would then essentially be the same as invoking 'maven multiproject:install' 
(assuming the subprojects are all of type jar)
where the 'special' subproject has a maven.xml with your resource 
definition, and the correct 'postGoal' to copy the test-classes.
 creating a new plugin for the specified behaviour is nice, but (although 
I'm not an expert) I think this is better
accomplished by doing something with the jelly code from 
'java:jar-resources' goal: 
  

 



  dennis


On 7/27/05, Michael Owen <[EMAIL PROTECTED]> wrote: 
> 
> 
> Yes. My problem now is that when I put this in plugin.jelly:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I get the error:
> 
> BUILD FAILED
> File.. C:\Documents and
> Settings\owenm\.maven\cache\maven-multiproject-plugi
> n-1.3.1\plugin.jelly
> Element... maven:param-check
> Line.. 207
> Column 54
> A goal to run must be specified, e.g.
> maven -Dgoal=clean multiproject:goal
> Total time: 3 seconds
> Finished at: Wed Jul 27 14:26:22 BST 2005
> 
> 
> Whereas if I put the same code in a local maven.xml file, it works??? The
> idea of putting the goal into a plugin is that I can share it with other
> projects later.
> 
> Mike
> 
> 
> >From: Dennis Geurts
> <[EMAIL PROTECTED]>>Reply-To: Dennis Geurts
> <[EMAIL PROTECTED]>>To: Maven Users List
> >Subject: Re: Multiproject resources
> problem>Date: Wed, 27 Jul 2005 14:40:42 +0200>>sorry
> 'java:jar-resources' that is...>>On 7/27/05, Dennis Geurts
> <[EMAIL PROTECTED]> wrote:> >> > great
> !!> > instead of running the tests twice, will it work to add as
> postGoal to> > 'test:compile' the goal 'jar:jar-resources'
> ?> > Dennis> > On 7/27/05, Michael Owen
> <[EMAIL PROTECTED]> wrote:> > >> >
> >> > > Spot on. :) Just figured it out myself too. I have to
> put a test:test> > > goal> > > before, so the test
> classes are compiled. So with the test being done> > >
> again> > > for jar:install, it means the tests are carried out
> twice.> > >> > > Mike> > >>
> > > >From: Dennis Geurts> >
> > <[EMAIL PROTECTED]>>Reply-To: Dennis
> Geurts> > > <[EMAIL PROTECTED]>>To:
> Maven Users List> > >
> >Subject: Re: Multiproject
> resources> > > problem>Date: Wed, 27 Jul 2005
> 14:16:31 +0200>>ok,> > > reasonable,
> just checking...> the 'java:jar-resources' goal that>
> > > should copy your test-classes comes>before the
> 'test:compile'> > > goal> could it be that you
> start with a clean (multi)project ??> > >
> the>'build/testclasses' dir will still be
> empty,>and you'll> > > copying all the files that
> are there (that is to say: none at>all)> > >
> ;-)> Dennis>> On 7/27/05, Michael
> Owen> > > <[EMAIL PROTECTED]>
> wrote:> >> >>> > >
> > No. I've changed it to put the test classes into that> > >
> directory.> >> > Mike>
> >> >> > >
> >From: Dennis Geurts>
> >> > >
> <[EMAIL PROTECTED]>>Reply-To: Dennis
> Geurts>> > > >
> <[EMAIL PROTECTED]>>To: Maven Users> >
> > List> >
> >Subject: Re:> > >
> Multiproject resources> > problem>Date: Wed, 27
> Jul> > > 2005 13:16:56> >> > >
> +0200>>Michael,> you> >
> > specify:>> >> > >
> ${basedir}/build/testclasses>>>
> > > > shouldn't that> >> > >
> 
> be:>${basedir}/target/test-classes>>>
> > > > ??> Dennis>> On
> 7/27/05, Michael> > > Owen> > <
> [EMAIL PROTECTED]> wrote:>> > >
> >> >>> > >
> Hi,>> > > >> > I have a prob

Re: Multiproject resources problem

[Dennis Geurts]

sorry 'java:jar-resources' that is...

On 7/27/05, Dennis Geurts <[EMAIL PROTECTED]> wrote: 
> 
> great !!
>  instead of running the tests twice, will it work to add as postGoal to 
> 'test:compile' the goal 'jar:jar-resources' ?
>  Dennis
>  On 7/27/05, Michael Owen <[EMAIL PROTECTED]> wrote: 
> > 
> > 
> > Spot on. :) Just figured it out myself too. I have to put a test:test 
> > goal
> > before, so the test classes are compiled. So with the test being done 
> > again 
> > for jar:install, it means the tests are carried out twice.
> > 
> > Mike
> > 
> > >From: Dennis Geurts
> > <[EMAIL PROTECTED]>>Reply-To: Dennis Geurts 
> > <[EMAIL PROTECTED]>>To: Maven Users List
> > >Subject: Re: Multiproject resources 
> > problem>Date: Wed, 27 Jul 2005 14:16:31 +0200>>ok,
> > reasonable, just checking...> the 'java:jar-resources' goal that
> > should copy your test-classes comes>before the 'test:compile' 
> > goal> could it be that you start with a clean (multi)project ??
> > the>'build/testclasses' dir will still be empty,>and you'll
> > copying all the files that are there (that is to say: none at>all) 
> > ;-)> Dennis>> On 7/27/05, Michael Owen
> > <[EMAIL PROTECTED]> wrote:> >> >> 
> > > No. I've changed it to put the test classes into that
> > directory.> >> > Mike> >> >
> > >From: Dennis Geurts> > 
> > <[EMAIL PROTECTED]>>Reply-To: Dennis Geurts>
> > > <[EMAIL PROTECTED]>>To: Maven Users 
> > List> > >Subject: Re:
> > Multiproject resources> > problem>Date: Wed, 27 Jul
> > 2005 13:16:56> > 
> > +0200>>Michael,> you
> > specify:>> >
> > ${basedir}/build/testclasses>>
> > > shouldn't that> > 
> > be:>${basedir}/target/test-classes>>
> > > ??> Dennis>> On 7/27/05, Michael
> > Owen> > < [EMAIL PROTECTED]> wrote:>
> > >> >>> > > Hi,>
> > >> > I have a problem when doing jar:install> > 
> > in a multiproject scenerio. In my> > individual project
> > I> > have:> >> >
> > > >> >
> > > >> > 
> > ${basedir}/build/testclasses>
> > >> > > >
> > **/*>> > > 
> > > > >
> > >> > > >> >
> > to include the testclasses into> > the produced jar when I do 
> > jar:install.> > This> >> > happens
> > when doing it for the individual project, but when done as a> >
> > goal> > for a multiproject goal ie:> 
> > >> >> >  > name="multi:build">> > > >
> > var="goal" value="jar:install"/>>
> > >> >  > name="multiproject:goal"/>> >> >
> > > >> > The testclasses don't
> > get put into> > the jar. Any help? Looked on the> 
> > > multiproject plugin> > documentation page and it says to use
> > ${basedir} to> > solve the> > problem, but I've
> > done that.> >> > Mike>> 
> > > >> >> >> >>
> > >
> > 
> > ->>
> > > > 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: Multiproject resources problem

[Dennis Geurts]

great !!
 instead of running the tests twice, will it work to add as postGoal to 
'test:compile' the goal 'jar:jar-resources' ?
 Dennis
 On 7/27/05, Michael Owen <[EMAIL PROTECTED]> wrote: 
> 
> 
> Spot on. :) Just figured it out myself too. I have to put a test:test goal
> before, so the test classes are compiled. So with the test being done 
> again
> for jar:install, it means the tests are carried out twice.
> 
> Mike
> 
> >From: Dennis Geurts
> <[EMAIL PROTECTED]>>Reply-To: Dennis Geurts
> <[EMAIL PROTECTED]>>To: Maven Users List
> >Subject: Re: Multiproject resources
> problem>Date: Wed, 27 Jul 2005 14:16:31 +0200>>ok,
> reasonable, just checking...> the 'java:jar-resources' goal that
> should copy your test-classes comes>before the 'test:compile'
> goal> could it be that you start with a clean (multi)project ??
> the>'build/testclasses' dir will still be empty,>and you'll
> copying all the files that are there (that is to say: none at>all)
> ;-)> Dennis>> On 7/27/05, Michael Owen
> <[EMAIL PROTECTED]> wrote:> >> >>
> > No. I've changed it to put the test classes into that
> directory.> >> > Mike> >> >
> >From: Dennis Geurts> >
> <[EMAIL PROTECTED]>>Reply-To: Dennis Geurts>
> > <[EMAIL PROTECTED]>>To: Maven Users
> List> > >Subject: Re:
> Multiproject resources> > problem>Date: Wed, 27 Jul
> 2005 13:16:56> >
> +0200>>Michael,> you
> specify:>> >
> ${basedir}/build/testclasses>>
> > shouldn't that> >
> be:>${basedir}/target/test-classes>>
> > ??> Dennis>> On 7/27/05, Michael
> Owen> > <[EMAIL PROTECTED]> wrote:>
> >> >>> > > Hi,>
> >> > I have a problem when doing jar:install> >
> in a multiproject scenerio. In my> > individual project
> I> > have:> >> >
> > >> >
> > >> >
> ${basedir}/build/testclasses>
> >> > > >
> **/*>> > >
> > > >
> >> > > >> >
> to include the testclasses into> > the produced jar when I do
> jar:install.> > This> >> > happens
> when doing it for the individual project, but when done as a> >
> goal> > for a multiproject goal ie:>
> >> >> >  name="multi:build">> > > >
> var="goal" value="jar:install"/>>
> >> >  name="multiproject:goal"/>> >> >
> > >> > The testclasses don't
> get put into> > the jar. Any help? Looked on the>
> > multiproject plugin> > documentation page and it says to use
> ${basedir} to> > solve the> > problem, but I've
> done that.> >> > Mike>>
> > >> >> >> >>
> >
> 
> ->>
> > > 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: Multiproject resources problem

[Dennis Geurts]

ok, reasonable, just checking...
 the 'java:jar-resources' goal that should copy your test-classes comes 
before the 'test:compile' goal
 could it be that you start with a clean (multi)project ?? the 
'build/testclasses' dir will still be empty,
and you'll copying all the files that are there (that is to say: none at 
all) ;-)
 Dennis

 On 7/27/05, Michael Owen <[EMAIL PROTECTED]> wrote: 
> 
> 
> No. I've changed it to put the test classes into that directory.
> 
> Mike
> 
> >From: Dennis Geurts
> <[EMAIL PROTECTED]>>Reply-To: Dennis Geurts
> <[EMAIL PROTECTED]>>To: Maven Users List
> >Subject: Re: Multiproject resources
> problem>Date: Wed, 27 Jul 2005 13:16:56
> +0200>>Michael,> you specify:>
> ${basedir}/build/testclasses>
> shouldn't that
> be:>${basedir}/target/test-classes>
> ??> Dennis>> On 7/27/05, Michael Owen
> <[EMAIL PROTECTED]> wrote:> >> >>
> > Hi,> >> > I have a problem when doing jar:install
> in a multiproject scenerio. In my> > individual project I
> have:> >> > > >
> > >
> ${basedir}/build/testclasses> >
> > > **/*>
> > > > > >
> > >> > to include the testclasses into
> the produced jar when I do jar:install.> > This> >
> happens when doing it for the individual project, but when done as a
> goal> > for a multiproject goal ie:> >> >
> > >  var="goal" value="jar:install"/>> >
> > >
> > >> > The testclasses don't get put into
> the jar. Any help? Looked on the> > multiproject plugin
> documentation page and it says to use ${basedir} to> > solve the
> problem, but I've done that.> >> > Mike>
> >> >> >> >
> ->
> > 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: Multiproject resources problem

[Dennis Geurts]

Michael,
 you specify:
 ${basedir}/build/testclasses
 shouldn't that be:
${basedir}/target/test-classes
 ??
 Dennis

 On 7/27/05, Michael Owen <[EMAIL PROTECTED]> wrote: 
> 
> 
> Hi,
> 
> I have a problem when doing jar:install in a multiproject scenerio. In my
> individual project I have:
> 
> 
> 
> ${basedir}/build/testclasses
> 
> **/*
> 
> 
> 
> 
> to include the testclasses into the produced jar when I do jar:install. 
> This
> happens when doing it for the individual project, but when done as a goal
> for a multiproject goal ie:
> 
> 
> 
> 
> 
> 
> The testclasses don't get put into the jar. Any help? Looked on the
> multiproject plugin documentation page and it says to use ${basedir} to
> solve the problem, but I've done that.
> 
> Mike
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [m102] Using multiproject with plugin projects ?

[Dennis Geurts]

Haryon,
 I also came across this issue.
my resolution was as follows:
 For all the projects, I specified the 'maven.multiproject.type' property to 
'war', 'jar', 'ear', whatever; 
for the 'special' project I set the abovementioned property to 'mygoal'
 Furthermore, in the maven.xml (of this special project) I defined two new 
goals called 
 'mygoal:mygoal' and 'mygoal:install'
 In your case the goals would (could/ should) be:
 
 

 
 


 As such, the normal projects can be as simple as you want, and don't even 
need a maven.xml
and both 'maven multiproject:artifact' and 'maven multiproject:install' do 
the things you want it to do...
  Hope this helps,
 Dennis
 On 7/22/05, Haryon <[EMAIL PROTECTED]> wrote: 
> 
> Hi,
> 
> multiproject:install does TYPE:install on every subprojects, where
> TYPE is the project type (jar, war, etc. based on what we input in
> projects.properties).
> 
> But when TYPE is 'plugin', it will do plugin:install. But if I'm not
> mistaken plugin:install doesn't put the plugin jar in the repository
> but instantiate and run the plugin on the current maven installation.
> I need to use plugin:repository-install.
> 
> I could try a multiproject:goal -Dgoal=repository-install, but I have
> jar projects there too, that need jar:install not
> jar:repository-install.
> 
> Help :) any advice on how you would proceed ?
> 
> I would create a my-install goal on every project, on jars that would
> attainGoal install, and on plugins that would attain
> repository-install. But I find that very bad (needs edit maven.xml in
> every project I create in the multiproject tree).
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Alternate build step

[Dennis Geurts]

Reis,
 To get your colleagues 'hot' for maven (if that's what's going on), check 
out the maven-ant-plugin
while you are fully mavenized, your colleagues can still use ant...
 http://maven.apache.org/reference/plugins/ant/
 Dennis


 On 7/21/05, Reid Pinchback <[EMAIL PROTECTED]> wrote: 
> 
> 
> Thanks to everybody. I now have Maven working exactly
> as I want it to. Not bad, 3 pieces of advice from
> one request, all of them useful in combination. :-)
> 
> Final solution was:
> 
> - specify the sourceDirectory
> - override the java:compile goal
> - specify checkstyle as (currently) the
> only report I want.
> 
> JDepend was one of the default reports, and it definitely
> forced a compile to happen. Something I want to use
> eventually, but not the most immediate priority. I'll
> tackle more of the Ant-to-Maven conversion later so we
> can use other reports, but for now I'll just be happy
> if availability of the checkstyle reports curbs folks
> from littering code with bogus imports and introducing
> method names like setFOO_BAR and getFOO_BAR.
> 
> 
> 
> --- David Jackman <[EMAIL PROTECTED]> wrote:
> 
> > Then what I would do is list those reports you care about in the reports
> > section of the project.xml. Some of those reports may require that the
> > code gets compiled first. If you can't do the compile with maven, then
> > you won't be able to include those reports.
> 
> 
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Why is Websphere EJB files genereated, but not JBoss?

[Dennis Geurts]

"C:\opt\local\blackhawk\fastforward\consumerManagerBean-ejbjar-subproject\target\xdoclet\ejbdoc
let" does not exist!
  
  



 On 7/21/05, Mick Knutson <[EMAIL PROTECTED]> wrote: 
> 
> I added just that jar, and now the build breaks:
> =
> jar:install:
> 
> 
> build:end:
> 
> build:start:
> 
> multiproject:install-callback:
> [echo] Running ejb:install for Consumer Manager EJB
> ejb:init:
> java:prepare-filesystem:
> [mkdir] Created dir:
> 
> C:\opt\local\blackhawk\fastforward\consumerManagerBean-ejbjar-subproject\target\classes
> 
> java:compile:
> xdoclet:ejbdoclet:
> 
> generateJunitTests:
> [echo] generate.junit.tests is: true
> [echo] generate.junit.tests is set to true - will generate junit tests
> 
> [echo] Compiling to
> 
> c:\opt\local\blackhawk\fastforward\consumerManagerBean-ejbjar-subproject/target/classes
> [echo]
> ==
> 
> NOTE: Targetting JVM 1.4, classes
> will not run on earlier JVMs
> 
> ==
> 
> 
> BUILD FAILED
> File.. C:\Documents and
> Settings\mknut01\.maven\cache\maven-multiproject-plugin-1.3.1\plugin.jelly
> Element... maven:reactor
> Line.. 217
> Column 9
> Unable to obtain goal [multiproject:install-callback] -- C:\Documents and
> Settings\mknut01\.maven\cache\maven-java-plugin-1.5\plug
> in.jelly:63:48:  srcdir
> 
> "C:\opt\local\blackhawk\fastforward\consumerManagerBean-ejbjar-subproject\target\xdoclet\ejbdoc
> let" does not exist!
> Total time: 37 seconds
> Finished at: Thu Jul 21 12:08:20 PDT 2005
> 
> c:\opt\local\blackhawk\fastforward>
> 
> 
> 
> 
> 
> 
> 
> >From: Dennis Geurts <[EMAIL PROTECTED]>
> >Reply-To: Dennis Geurts <[EMAIL PROTECTED]>
> >To: Maven Users List 
> >Subject: Re: Why is Websphere EJB files genereated, but not JBoss?
> >Date: Thu, 21 Jul 2005 19:51:44 +0200
> >
> >Hi Mick,
> > You'll probabley have to add to the list of dependencies:
> > 
> >xdoclet
> >xdoclet-jboss-module
> >1.2.3
> >
> > Dennis
> >
> > On 7/21/05, Mick Knutson <[EMAIL PROTECTED]> wrote:
> > >
> > > ManagerBean:
> > > ===
> > > /**
> > > * Bean implementation class for Enterprise Bean: ConsumerManagerBean
> > > *
> > > * @ejb.bean name="ConsumerManager"
> > > * display-name="Consumer Manager Session Bean"
> > > * type="Stateless"
> > > * view-type="local"
> > > * local-jndi-name="local/ConsumerManagerLocal"
> > > *
> > > local-business-interface="com.blackhawk.ff.service.ConsumerManager"
> > > *
> > > * @ejb.home local-extends="javax.ejb.EJBLocalHome"
> > > * @ --ejb.interface local-extends="ConsumerManager,
> > > javax.ejb.EJBLocalObject"
> > > * @ejb.interface local-extends="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"
> > > *
> > > * @ --mock.generate
> > > * @ejb.util generate="physical"
> > > * @ejb.transaction type="Required"
> > > * @ejb.transaction-type type="Container"
> > > * @ejb.permission unchecked="true"
> > > */
> > >
> > >
> > > project.xml dependancies:
> > > =
> > > 
> > > xdoclet
> > > xjavadoc
> > > 1.0.2
> > > 
> > >
> > > 
> > > xdoclet
> > > xdoclet
> > > 1.2.3
> > > 
> > >
> > > 
> > > xdoclet
> > > xdoclet-xdoclet-module
> > > 1.2.3
> > > 
> > >
> > > 
> > > xdoclet
> > > xdoclet-ejb-module
> > > 1.2.3
> > > 
> > >
> > > 
> > > jboss
> > > jboss-j2ee
> > > 3.2.1
> > > 
> > >
> > > 
> > > xdoclet
> > > xdoclet-ibm-module
> > > 1.2.3
> > > 
> > >
> > > 
> > > x

Re: EJB client jars

[Dennis Geurts]

Hi Ken,
 the thing is (AFAIK) as follows (others: please correct me if i'm wrong):
 If you run ejb:ejb in the target-directory the 'final.name.jar' is created 
that contains *all* classes.
 however, if you run ejb:ejb-client, the client jar is created that only 
contains the (local and) remote interfaces, 
which is all you need as a client user (right ??)
 So as another project that depends on this project you only need the client 
interfaces !
 This is therefore the jar that ends up in the 
repository/${projectId}/jars/${projectId}-${version}.jar
(by means of the install-goal)
 in the project target-directory, a distinction needs to be made between the 
jar that contains all classes ${artifactID}-${version}.jar
and the one that only contains the interfaces ${artifactID}-${version}-
client.jar.
 the EJB -jar that contains ALL classes is during the install nicely copied 
to repository/${projectId}/*ejbs*/${projectId}-${version}.jar
  so to wrap it up:
 if you're only interested in the client interfaces (happens most of the 
time)
you add the dependency:
 projectId
artifactId
version
*jar*
  If you really need the ejb as dependency (which possibly is not a good 
idea)
 you add the dependency:
projectId
artifactId
version
*ejb*
artifactId-version.jar <-- i don't really know if this is 
neccessary
  Hope this all is true...
 Dennis
   

 On 7/21/05, Ballard, Ken <[EMAIL PROTECTED]> wrote: 
> 
> In Maven 1.0.2, I can create an EJB client jar by running ejb:ejb-client.
> I'm left with a myproject-ejb-1.0-client.jar. But then when I run
> ejb:install-client it uploads it to the repository as 
> myproject-ejb-1.0.jar.
> In the plugin.jelly for the ejb plugin, the ejb:install-client goal looks
> like this:
> 
> 
> 
> 
> 
>  prereqs="ejb:ejb-client"
> description="Install the ejb client in the local repository">
> 
>  artifact="${maven.ejb.build.dir}/${maven.final.name
> }-client.jar"
> type="jar"
> project="${pom}"/>
> 
> 
> 
> Why don't I see the "-client" part of the file name in the repository? 
> Also,
> every once in a while I'll run a goal and it will create a "ejb-clients"
> folder in my repository, but why isn't my client jar being installed 
> there?
> Then, once I have the client jar in the repository, how should I declare a
> dependency on it in the project.xml? Like this:
> 
> 
> myproject
> myproject-ejb
> ${pom.currentVersion}
> 
> true
> true
> true
> 
> 
> 
> Would that work?
> 
> Thanks,
> Ken
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Why is Websphere EJB files genereated, but not JBoss?

[Dennis Geurts]

Hi Mick,
 You'll probabley have to add to the list of dependencies:
  
xdoclet
xdoclet-jboss-module
1.2.3

  Dennis

 On 7/21/05, Mick Knutson <[EMAIL PROTECTED]> wrote: 
> 
> ManagerBean:
> ===
> /**
> * Bean implementation class for Enterprise Bean: ConsumerManagerBean
> *
> * @ejb.bean name="ConsumerManager"
> * display-name="Consumer Manager Session Bean"
> * type="Stateless"
> * view-type="local"
> * local-jndi-name="local/ConsumerManagerLocal"
> *
> local-business-interface="com.blackhawk.ff.service.ConsumerManager"
> *
> * @ejb.home local-extends="javax.ejb.EJBLocalHome"
> * @ --ejb.interface local-extends="ConsumerManager,
> javax.ejb.EJBLocalObject"
> * @ejb.interface local-extends="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"
> *
> * @ --mock.generate
> * @ejb.util generate="physical"
> * @ejb.transaction type="Required"
> * @ejb.transaction-type type="Container"
> * @ejb.permission unchecked="true"
> */
> 
> 
> project.xml dependancies:
> =
> 
> xdoclet
> xjavadoc
> 1.0.2
> 
> 
> 
> xdoclet
> xdoclet
> 1.2.3
> 
> 
> 
> xdoclet
> xdoclet-xdoclet-module
> 1.2.3
> 
> 
> 
> xdoclet
> xdoclet-ejb-module
> 1.2.3
> 
> 
> 
> jboss
> jboss-j2ee
> 3.2.1
> 
> 
> 
> xdoclet
> xdoclet-ibm-module
> 1.2.3
> 
> 
> 
> xdoclet
> xdoclet-mockobjects-module
> 1.2
> 
> 
> xdoclet
> xdoclet-web-module
> 1.2.3
> 
> 
> 
> 
> project.properties:
> 
> 
> #//---//
> #// XDoclet Configuration
> maven.xdoclet.ejbdoclet.entitybmp.0=false
> maven.xdoclet.ejbdoclet.entitycmp.0=true
> maven.xdoclet.ejbdoclet.entityfacade.0=true
> maven.xdoclet.ejbdoclet.entitypk.0=true
> 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.session.0=false
> maven.xdoclet.ejbdoclet.utilobject.0=true
> maven.xdoclet.ejbdoclet.utilobject.0.cacheHomes=true
> maven.xdoclet.ejbdoclet.utilobject.0.includeGUID=true
> 
> maven.xdoclet.ejbdoclet.deploymentdescriptor.0=true
> 
> maven.xdoclet.ejbdoclet.deploymentdescriptor.0.destDir=${maven.build.dir}/xdoclet/ejbdoclet/META-INF
> 
> 
> maven.xdoclet.ejbdoclet.valueobject.0=true
> maven.xdoclet.ejbdoclet.fileset.0.sourcedir=${basedir}/src/java
> 
> 
> 
> #//---//
> #// The following items are used to generate JBoss specific files.
> #// We are using JBoss for local development, so the build must co-deploy
> onto JBoss and Websphere.
> maven.xdoclet.ejbdoclet.jboss.0=true
> maven.xdoclet.ejbdoclet.jboss.0.useIds=true
> maven.xdoclet.ejbdoclet.jboss.0.Version=4.0
> maven.xdoclet.ejbdoclet.jboss.0.createTable=true
> maven.xdoclet.ejbdoclet.jboss.0.datasource=java:/defaultDS
> maven.xdoclet.ejbdoclet.jboss.0.datasourceMapping=DB2
> maven.xdoclet.ejbdoclet.jboss.0.xmlencoding=UTF-8
> maven.xdoclet.ejbdoclet.jboss.0.validateXML=true
> 
> 
> maven.xdoclet.ejbdoclet.jboss.0.destDir=${basedir}/target/xdoclet/ejbdoclet/META-INF
> #maven.xdoclet.ejbdoclet.jboss.0.mergeDir=${maven.build.dir}/temp/mergedir
> 
> 
> 
> #//---//
> #// The following items are used to generate Websphere specific files.
> #// We are using Websphere for production releases, so the build must
> co-deploy onto JBoss and Websphere.
> maven.xdoclet.ejbdoclet.websphere.0=true
> maven.xdoclet.ejbdoclet.websphere.0.useIds=true
> maven.xdoclet.ejbdoclet.websphere.0.Version=5.1
> maven.xdoclet.ejbdoclet.websphere.0.xmlencoding=UTF-8
> maven.xdoclet.ejbdoclet.websphere.0.validateXML=true
> 
> 
> maven.xdoclet.ejbdoclet.websphere.0.destDir=${basedir}/target/xdoclet/ejbdoclet/META-INF
> 
> 
> 
> The WAS 5.1 xmi files are created just fine, but not the JBoss files
> (jboss.xml).
> 
> 
> 
> 
> Thank You
> Mick Knutson
> 
> Sr. Java/J2EE Consultant
> BASE logic, inc.
> (415) 648-1804 (S.F., CA)
> http://www.BASELogic.com
> 
> HP Consulting Services (Walnut Creek, CA)
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: EJBDoclet in Maven

[Dennis Geurts]

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:
> 
> 
> 
> 
> 
> xdoclet
> 
> xdoclet
> 
> 2.0
> 
> 
> 
> 
> 
> xdoclet
> 
> xdoclet-ejb-module
> 
> 1.2.3
> 
> 
> 
> 
> 
> xdoclet
> 
> xdoclet-jboss-module
> 
> 1.2
> 
> 
> 
> 
> 
> And this is my maven.xml:
> 
> 
> 
>  
> xmlns:j="jelly:core"
> 
> xmlns:maven="jelly:maven"
> 
> xmlns:ant="jelly:ant"
> 
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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.
> 
>

Re: EJBDoclet in Maven

[Dennis Geurts]

loaded from ant
> loade
> r
> [DEBUG] Registering SubTask dao (xdoclet.modules.ejb.dao.DaoSubTask) to
> DocletTa
> sk xdoclet.modules.ejb.EjbDocletTask
> [DEBUG] Finding class xdoclet.modules.ejb.entity.ValueObjectSubTask
> [DEBUG] Class xdoclet.modules.ejb.entity.ValueObjectSubTask loaded from 
> ant
> load
> er
> [DEBUG] Resource xdoclet/modules/ejb/entity/resources/valueobject.xdt 
> loaded
> fro
> m ant loader
> [DEBUG] Registering SubTask valueobject
> (xdoclet.modules.ejb.entity.ValueObjectS
> ubTask) to DocletTask xdoclet.modules.ejb.EjbDocletTask
> [DEBUG] Finding class xdoclet.modules.jboss.ejb.JBossSubTask
> [DEBUG] Class xdoclet.modules.jboss.ejb.JBossSubTask loaded from ant 
> loader
> [DEBUG] Registering SubTask jboss (xdoclet.modules.jboss.ejb.JBossSubTask)
> to Do
> cletTask xdoclet.modules.ejb.EjbDocletTask
> [DEBUG] Finding class xdoclet.modules.web.WebDocletTask
> [DEBUG] Finding class xdoclet.modules.web.WebDocletTask
> [DEBUG] Finding class xdoclet.modules.web.WebDocletTask
> [DEBUG] Finding class xdoclet.modules.web.WebDocletTask
> [ejbdoclet] [DEBUG] Class org.apache.tools.ant.Project loaded from
> parent lo
> ader
> [ejbdoclet] [DEBUG] Finding class xdoclet.ConfigParamIntrospector
> [ejbdoclet] [DEBUG] Class xdoclet.ConfigParamIntrospector loaded from
> ant lo
> ader
> [ejbdoclet] [DEBUG] Class java.lang.SecurityException loaded from parent
> loa
> der
> [ejbdoclet] [DEBUG] Class java.lang.reflect.InvocationTargetException
> loaded
> from parent loader
> [ejbdoclet] [DEBUG] Class java.lang.NoSuchMethodException loaded from
> parent
> loader
> [ejbdoclet] [DEBUG] Finding class
> xdoclet.ConfigParamIntrospector$NullObject
> 
> [ejbdoclet] [DEBUG] Class xdoclet.ConfigParamIntrospector$NullObject
> loaded
> from ant loader
> [ejbdoclet] [DEBUG] Class java.lang.reflect.Method loaded from parent
> loader
> 
> [ejbdoclet] [DEBUG] Class java.lang.reflect.Modifier loaded from parent
> load
> er
> [ejbdoclet] [DEBUG] 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

Re: EJBDoclet in Maven

[Dennis Geurts]

 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)
> Root cause
> srcdir
> "C:\workspaces\dfs\poc-v0018-middletier\dfs\ear\target\xdoclet\ejbdoclet"
> does not exist!
> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:671)
> at org.apache.tools.ant.Task.perform(Task.java:341)
> 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

Re: Unit testing verbosity

[Dennis Geurts]

Hi Dan, 
 After testing, did you have a look at the files in 'target\test-reports' ??
 Dennis

 On 7/15/05, Dan Bradley <[EMAIL PROTECTED]> wrote: 
> 
> I'm new to Maven, but can't find an resolution to this problem: unit
> tests don't run with enough verbosity to be useful. When I run unit
> tests that fail, there is nothing reported other than that the tests
> failed. For example:
> 
> [junit] Running com.foo.FooTest
> [junit] Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 1.875 sec
> [junit] [ERROR] TEST com.foo.FooTest FAILED
> 
> If I want to see the reason the test failed I have to generate the
> site and then look at the HTML output, which takes a lot longer, but
> does provide the full reason for failure:
> 
> Error creating bean with name 'com.foo.FooTest' defined in null:
> Unsatisfied dependency expressed through bean property 'fooManager':
> There are 2 beans of type [class com.foo.FooTest] for autowire by
> type. There should have been 1 to be able to autowire property
> 'productManager' of bean 'com.foo.FooTest'.
> 
> Is there a way to get the failure reason on the command line?
> 
> In a separate problem, when I run test:ui it appears to have a
> different classpath than when running test. Is there a way to make
> sure these are the same? When running the Swing test runner from Maven
> I get classpath-related errors in my unit tests that don't appear when
> I run the console tests.
> 
> Thanks
> 
> Dan Bradley
> [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [M2] Mix between Provided and Test Scopes

[Dennis Geurts]

Hi David,
 I encountered the same problem a while ago.
 The following was suggested: 
 'The workaround is to split your war files and your sources. Put all your
java sources in an other project and add them in the new jar dep of your 
war.'
  So, make a multi module project, one 'jar-project' containing all classes 
( servletapi in compile scope )
and a 'war-project' that depends on the 'jar-project' ( runtime scope )
 the tests are then run while installing the 'jar-project'
 and the war-project will automatically package the 'jar-project.jar' 
 Dennis


 On 7/15/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote: 
> 
> On Thu, 14 Jul 2005, David H. DeWolf wrote:
> 
> What you could do is depend on a pom, test,
> that itself depends on the servlet api.
> 
> -- Kenney
> 
> > I'm attempting to utilize the servlet api within some mock tests (in
> > addition to needing it to compile my main source). I have attempted to
> > mark the scope of the servlet api in the following manners:
> >
> > 1) Provided Scope
> > 2) Test Scope
> > 3) Two Separate Dependencies of Provided Scope AND Test Scope
> >
> > And none of these seem to work. When the scope is 'provided', the tests
> > throw a class not found exception. When the scope is 'test' the main
> > source fails to compile. When I attempt to use both, it appears as
> > though the second dependency is ignored.
> >
> > Has anyone else encountered this and found a work around?
> >
> > Thanks,
> >
> > David
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Local Repository Issue

[Dennis Geurts]

Hi Dylan,
 Could you try and remove the j2ee-1.4.jar part ??
 the other tags should suffice ...
  btw, your command says 'maven -0 ...' I assume you want to run in offline 
mode.
The -0 ( minus-zero ) should then be -o ( minus-ooh )
 
Dennis
 On 7/15/05, Dylan Stamat <[EMAIL PROTECTED]> wrote: 
> 
> I'm having problems getting Maven (1.0.2) to find .JAR files in my local
> repository. Basic problem, but I can't get it to work for the life of me.
> Here is my setup:
> 
> My repository is in the default location (/.maven/repository/), and I 
> added
> a path to a j2ee .JAR I placed in this directory... ie:
> /.maven/repository/j2ee/jars/j2ee-1.4.jar
> 
> Here is my dependency entry in the project.xml. I even tried using the 
> 
> tag to explicitly name the file, with no luck:
> 
> 
> j2ee
> j2ee
> 1.4
> jar
> j2ee-1.4.jar
> 
> 
> I'm running: "maven -0 jar:jar", and I get the following error:
> "The build cannot continue because of the following unsatisfied 
> dependency:
> j2ee-1.4.jar"
> 
> Any help would be appreciated ! Thanks !
> ==
> Dylan
> 
>

Re: Add other repository [m2]

[Dennis Geurts]

Wilfred,
 I must confess I never used the 'repo override' myself... ;-)
 people: correct me if I'm wrong !!
 I guess since you want to always override you best create a profile that 
always
'activates' e.g.
  

jdk-1.5

1.5




my own repo
My own Repository
http://localhost:8080/myownrepo/maven2
default
always



Dennis


 On 7/14/05, Peter van de Hoef <[EMAIL PROTECTED]> wrote: 
> 
> If you specify a plugin repository in your POM, like:
> 
> 
> 
> my-plugins
> My Plugin Repository
> http://repository.mycompany.org
> 
> 
> 
> then, this plugin repository is always consulted before the central maven 
> plugin repository.
> At least, that is what I experience. I'm using the latest from SVN. Could 
> this be different for alpha-3 or whatever
> version you are using?
> 
> HTH,
> Peter
> 
> 
> Wilfred Springer wrote:
> > I have seen this URL, thanks. In fact, I even tried a number of things
> > to understand how it works, but I'm not sure if I'm required to
> >
> > add a mirror
> > add a server
> > add a profile with a repository
> >
> > What do you suggest?
> >
> > Thanks,
> >
> > Wilfred
> >
> > On Thu, 2005-07-14 at 16:34, Dennis Geurts wrote:
> >
> >>try this URL:
> >> http://maven.apache.org/maven2/maven-settings/settings.html
> >>
> >>Dennis
> >> On 7/14/05, Wilfred Springer <[EMAIL PROTECTED]> wrote:
> >>
> >>>All,
> >>>
> >>>I want my project to check for a maven plugin from my own repository,
> >>>before trying the http://repo1.maven.org/maven2/plugins repository. Any
> >>>clues?
> >>>
> >>>Thanks,
> >>>
> >>>Wilfred
> >>>
> >>>--
> >>>_
> >>>Wilfred Springer Phone : +31 (0)3 3451 5736
> >>>Software Architect Mobile : +31 (0)6 2295 7321
> >>>Client Solutions Fax : +31 (0)3 3451 5734
> >>>Enterprise Web Services Mail : [EMAIL PROTECTED]
> >>>Sun Microsystems Netherlands AIM : wilfred springer
> >>>http://blogs.sun.com/wilfred/
> >>>
> >>>
> >>>NOTICE: This email message 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 email and destroy all copies of the original
> >>>message.
> >>>
> >>>
> >>>-
> >>>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: Add other repository [m2]

[Dennis Geurts]

try this URL:
 http://maven.apache.org/maven2/maven-settings/settings.html

Dennis
 On 7/14/05, Wilfred Springer <[EMAIL PROTECTED]> wrote: 
> 
> All,
> 
> I want my project to check for a maven plugin from my own repository,
> before trying the http://repo1.maven.org/maven2/plugins repository. Any
> clues?
> 
> Thanks,
> 
> Wilfred
> 
> --
> _
> Wilfred Springer Phone : +31 (0)3 3451 5736
> Software Architect Mobile : +31 (0)6 2295 7321
> Client Solutions Fax : +31 (0)3 3451 5734
> Enterprise Web Services Mail : [EMAIL PROTECTED]
> Sun Microsystems Netherlands AIM : wilfred springer
> http://blogs.sun.com/wilfred/
> 
> 
> NOTICE: This email message 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 email and destroy all copies of the original
> message.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [m2] i18n .properties files in war

[Dennis Geurts]

maven 1.x maybe ??
 I was fooled myself too when I started getting to know maven 2...
 Dennis

 On 7/13/05, Adam Hardy <[EMAIL PROTECTED]> wrote: 
> 
> I don't know where I picked up the instruction to run war:war. I see
> it's not on the list of common lifecycle phases on the website.
> 
> Rather misleadingly (obviously in my case) the output from war:war
> contains this:
> 
> [INFO] [war:war]
> [INFO] Copy webapp resources to
> /home/adam/java/projects/garg-web/target/garg-web
> 
> 
> Hence the reason I thought my pom was wrong, since it was carrying out
> the webapp resources copy operation. The 'resources' mentioned here then
> do not include *.properties files - I wish it had been clearer. It may
> save future maven users a bit of pain by changing that 'resources' to
> something more explicit (if anyone reading this is in such a position).
> 
> 
> Thanks for the help,
> 
> Adam
> 
> 
> 
> 
> Dennis Geurts on 13/07/05 15:09, wrote:
> > Hi Adam,
> > what's the command you supply ??
> > 'm2 war:war' or 'm2 package' (it should be the latter)
> > this might be a stupid question, but is the '
> > ApplicationResources.properties' file
> > located at the 'src/main/resources' location in yout project ?
> > Dennis
> >
> >
> > On 7/13/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
> >
> >>I have exhausted the mailing list archives and the documentation on the
> >>website and I cannot see why my .properties file is not being included
> >>in my war, since my pom.xml appears to be correct. The file is not
> >>copied into the target directory nor is it included in the war file.
> >>
> >>I see from the archives that other people appear to be managing this 
> fine.
> >>
> >>Here is my pom.xml (shortened):
> >>
> >>
> >>http://maven.apache.org/POM/4.0.0";
> >>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >>maven-v4_0_0.xsd">
> >>4.0.0
> >>com.mystuff
> >>mystuff-web
> >>war
> >>1.0-SNAPSHOT
> >>
> >>
> >>
> >>
> >>
> >>mystuff-web
> >>
> >>
> >>src/main/resources
> >>
> >>ApplicationResources.properties
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>I tried it with a targetPath element too, but with no joy either.
> >>
> >>Thanks
> >>Adam
> >>
> >>-
> >>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] i18n .properties files in war

[Dennis Geurts]

Hi Adam,
 what's the command you supply ?? 
 'm2 war:war' or 'm2 package' (it should be the latter)
 this might be a stupid question, but is the '
ApplicationResources.properties' file
located at the 'src/main/resources' location in yout project ?
 Dennis


 On 7/13/05, Adam Hardy <[EMAIL PROTECTED]> wrote: 
> 
> I have exhausted the mailing list archives and the documentation on the
> website and I cannot see why my .properties file is not being included
> in my war, since my pom.xml appears to be correct. The file is not
> copied into the target directory nor is it included in the war file.
> 
> I see from the archives that other people appear to be managing this fine.
> 
> Here is my pom.xml (shortened):
> 
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> maven-v4_0_0.xsd">
> 4.0.0
> com.mystuff
> mystuff-web
> war
> 1.0-SNAPSHOT
> 
> 
> 
> 
> 
> mystuff-web
> 
> 
> src/main/resources
> 
> ApplicationResources.properties
> 
> 
> 
> 
> 
> 
> 
> I tried it with a targetPath element too, but with no joy either.
> 
> Thanks
> Adam
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: [m2] adding an existing tld to a war file

[Dennis Geurts]

On 7/12/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: 
> 
> 
> 
> Dennis Geurts wrote:
> > Thanks Emmanuel,
> > If I'm not mistaken, the spring-1.0.2.tld is not added to the war at
> > all... I'll check as soon as possible...
> 
> Add a jira issue

 done: http://jira.codehaus.org/browse/MNG-579

> I also notice that the maven-eclipse-plugin will add the dependency of 
> type
> > 'tld' to the classpath, resulting
> > in an incorrect build classpath in eclipse. (but I'll look into this 
> first
> > in more detail) 

Add a jira issue

  done: http://jira.codehaus.org/browse/MNG-578
  
> pertaining question #2:
> > You mention the word 'workaround'. Does this mean you consider it a bug
> > that jar of scope 'provided'
> > are not available in 'test' scope ??
> 
> It isn't a bug. I don't know for the moment if we'll extend this scope
> for tests or if we'll create a new scope.

  ok, please be careful not to add too many scopes !!
  p.s. This is my first-time-jira-issueing-experience, so please correct me 
if the issues where too vague..
 Dennis 

> > (btw, thanks: the workaround will resolve the issue !!!)
> > Dennis
> > On 7/12/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> >
> >>
> >>
> >>Dennis Geurts wrote:
> >>
> >>>Hi all,
> >>>I'm using maven 2.0-alpha-3.
> >>>To get used to the new structure in maven2 I started converting some of
> >>
> >>my
> >>
> >>>projects to maven2 and came up with the following:
> >>>1)
> >>>Suppose I want to package a war file and want to include the
> >>>spring-1.0.2.tld in /WEB-INF
> >>>how do I go about automatically inserting this file at all ?
> >>>I added the dependency as follows:
> >>>
> >>>
> >>>spring
> >>>spring
> >>>1.0.2
> >>>tld
> >>>runtime
> >>>
> >>
> >>it's correct. Do you have an error? a wrong destination?
> >>
> >>
> >>>Did I miss a feature in the maven-war-plugin ?
> >>>Should I use the maven-resource-plugin ?
> >>>2)
> >>>the second thing I noticed was the fact that
> >>>when I set the scope of the *servletapi* dependency to 'provided' (to
> >>>prevent inclusion in the war file), my tests that contain references
> >>>to the 'javax.servlet' packages fail to compile. Is there a workaround
> >>
> >>to
> >>
> >>>include the dependencies in the 'provided' scope
> >>>into the 'test' scope ?
> >>
> >>The workaround is to split your war files and your sources. Put all your
> >>java sources in an other projet and add them in the new jar dep of your
> >>war.
> >>
> >>Emmanuel
> >>
> >>
> >>-
> >>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] adding an existing tld to a war file

[Dennis Geurts]

Thanks Emmanuel,
  If I'm not mistaken, the spring-1.0.2.tld is not added to the war at 
all... I'll check as soon as possible...
 I also notice that the maven-eclipse-plugin will add the dependency of type 
'tld' to the classpath, resulting
in an incorrect build classpath in eclipse. (but I'll look into this first 
in more detail)
 pertaining question #2:
 You mention the word 'workaround'. Does this mean you consider it a bug 
that jar of scope 'provided'
are not available in 'test' scope ??
 (btw, thanks: the workaround will resolve the issue !!!)
 Dennis
 On 7/12/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: 
> 
> 
> 
> Dennis Geurts wrote:
> > Hi all,
> > I'm using maven 2.0-alpha-3.
> > To get used to the new structure in maven2 I started converting some of 
> my
> > projects to maven2 and came up with the following:
> > 1)
> > Suppose I want to package a war file and want to include the
> > spring-1.0.2.tld in /WEB-INF
> > how do I go about automatically inserting this file at all ?
> > I added the dependency as follows:
> >
> > 
> > spring
> > spring
> > 1.0.2
> > tld
> > runtime
> > 
> 
> it's correct. Do you have an error? a wrong destination?
> 
> > Did I miss a feature in the maven-war-plugin ?
> > Should I use the maven-resource-plugin ?
> > 2)
> > the second thing I noticed was the fact that
> > when I set the scope of the *servletapi* dependency to 'provided' (to
> > prevent inclusion in the war file), my tests that contain references
> > to the 'javax.servlet' packages fail to compile. Is there a workaround 
> to
> > include the dependencies in the 'provided' scope
> > into the 'test' scope ?
> 
> The workaround is to split your war files and your sources. Put all your
> java sources in an other projet and add them in the new jar dep of your 
> war.
> 
> Emmanuel
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

[m2] adding an existing tld to a war file

[Dennis Geurts]

Hi all,
 I'm using maven 2.0-alpha-3.
 To get used to the new structure in maven2 I started converting some of my 
projects to maven2 and came up with the following:
 1)
 Suppose I want to package a war file and want to include the 
spring-1.0.2.tld in /WEB-INF
how do I go about automatically inserting this file at all ? 
 I added the dependency as follows:
 

spring
spring
1.0.2
tld
runtime

Did I miss a feature in the maven-war-plugin ?
Should I use the maven-resource-plugin ?
  2)
the second thing I noticed was the fact that
when I set the scope of the *servletapi* dependency to 'provided' (to 
prevent inclusion in the war file), my tests that contain references
to the 'javax.servlet' packages fail to compile. Is there a workaround to 
include the dependencies in the 'provided' scope
into the 'test' scope ?
  thanks in advance,
 Dennis Geurts

Re: Question: maven 1 - native plugin usage

[Dennis Geurts]

Hi Ruud, 
 What you want is certainly possible...
 Although I haven't used this plugin on a linux platform (yet) I hope I'm 
able 
to get you up and running: 
 (but please provide your compiler/ linker args yourself :-) )
 in your properties file:
 
maven.native.compiler.name=gcc
maven.native.link=executable /// or shared if you want to 

maven.native.compiler.arg.start= 
maven.native.compiler.arg.mid= 
maven.native.compiler.arg.end= 

maven.native.linker.arg.start= 
maven.native.linker.arg.mid= 
maven.native.linker.arg.end = 

after "maven native" the executable (or .so file) ends up in 
'target/native/'

and is named '_' (underscore), for the executable or 'lib_.so' for the 
shared library
If it's a libary, the file is copied to: ${maven.build.dir}/native/lib${
pom.artifactId}-${pom.currentVersion}.so

This is done (i think) for your convenience, but you can easily create a 
postGoal yourself to copy the executable
(the 'underscore' file) to a human readable name.

I always read the project.jelly. Even if you don't know jelly you can 
'infer' from the jelly code how the properties are used
and why things happen.

Hope this helps, feel free to ask more...

  Dennis

 On 7/7/05, Ruud Wijnands <[EMAIL PROTECTED]> wrote: 
> 
> Hi,
> 
> I am new to maven and I would like to find out whether or not it is
> possible to build native c++ code via the native plugin. I have a few
> requirements and after investigating the native plugin I think they
> are not meet.
> 
> By studying the plugin I have the impression that I can only build
> shared libraries, since the native:compile target is always renamed to
> something like -.so Is that true?
> 
> Here are my requirements:
> - build a set of c++ files into a single shared library for linux
> - build a set of c++ files into a single static library for linux
> - build a c++ file into an application
> - link against third-party libraries
> - provide include paths to thirdparty libraties
> - set compiler and link flags
> 
> If the stuff mentioned above is possible, does anyone have an or some
> examples for me?
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Different Java Versions for different sub-projects?

[Dennis Geurts]

Aidan,
 I don't know if this'll solve your problem, but isn't is enough
to specify the following properties:
 maven.compile.source=1.4
maven.compile.target=1.4
 for the projects that need to compile with jdk1.4 compatibility ??
 http://maven.apache.org/reference/plugins/java/properties.html
 provides more info.
 Dennis
 

 On 7/1/05, Aidan Donohoe <[EMAIL PROTECTED]> wrote: 
> 
> Hi,
> 
> Does anybody know if there is there is a way to specify different JDKs
> for different projects?
> 
> I have two sub projects, one of which must be compiled and ran with JDK
> 1.5 and another which should be compiled and ran with JDK 1.4.
> 
> Is there a property which I can change which will point maven to a
> different JDK before compiling a project?
> Or would I have to dynamically change JAVA_HOME - but would this be
> possible?
> 
> Thanks for any info,
> 
> Aidan.
> (Using Maven 1.0.2)
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: m2 site plugin property not recognized

[Dennis Geurts]

Hi Heiko,
 If I understand correctly, you run 'm2 site:site', and you wonder
why the output ends up in 'target/site' instead of in '${basedir}/www'.
 shouldn't you specify the 'outputDirectory' property instead ??
  Dennis

 On 7/1/05, puschteblume <[EMAIL PROTECTED]> wrote: 
> 
> Hi
> 
> I have following entry in pom.xml:
> 
> 
> 
> src/main
> 
> 
> org.apache.maven.plugins
> maven-site-plugin
> 
> ${basedir}/www
> 
> 
> 
> 
> 
> 
> But the site is deployed to /target directory. Do you know if I have
> missed something?
> 
> Thanks Heiko
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: How can I have the xdoclet generated files be included in the compile?

[Dennis Geurts]

Aidan,
 I guess you want something like this:
 Suppose the generated source code location is referred to with '${gen.dir}' 

( 'target/xdoclet/ejbdoclet' in your case )
then you can make sure they get compiled at the same time as your
manually typed java files do, by defining the following preGoal:
  

 


please note that it is stated in the documentation that including sources in 
such a way
is discouraged. As you mention correctly, it is unwise to copy the generated 
source files
into the 'official' source directory (src/main/java).
 furthermore, as an eclipse fan I must add that by adding the property: 
 'maven.eclipse.classpath.include=${gen.dir}'
to your project and subsequently executing 'maven eclipse'
the generated source file are also included in the classpath of your eclipse 
project.
 a 'clean project' in eclipse could delete the generated sources
this can be prevented by adding the property: 'maven.gen.src=${gen.dir}'
   Dennis
  
 On 6/17/05, Pascal Thivent <[EMAIL PROTECTED]> wrote: 
> 
> Hi
> 
> i think that the maven.ejb.includes property of the maven ejb plugin
> is what you're looking for.
> 
> Regards,
> 
> On 6/17/05, Aidan Donohoe <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am generating java files from xdoclet (into target/xdoclet/ejbdoclet),
> > and I want these files to be included in the compilation along with the
> > src directory.
> >
> > Do I have to copy them into the src dir? (which seems nasty)
> > Or is there a better/right way to do this?
> >
> > Thanks for any info,
> >
> > Aidan.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> --
> Pascal
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Maven and ejbdoclet/xdoclet examples

[Dennis Geurts]

Hi nathan,
 
the thing is, maven does not complain about missing dependencies ( for instance, the jmx-module is needed, but if you don't add its jar to the list of dependencies, maven won't tell !!) <-- maybe this is even the cause you're experiencing failure to generate the interfaces...

 
running 'maven -X ...' will probably warn you saying:  "missing 'xxx.jar' " but it will be easy to miss
 
 
I myself have used ejbdoclet in combination with middlegen. I personally didn't like to use the ejbdoclet plugin. Instead, I used
the ant task from within maven:
 
- relevant dependencies in project.xml are included in deps.txt

- relevant properties are included in props.txt
 
Since I used the Ant task, I needed to define some extra goals in the maven.xml
 
- relevant goals are included in goals.txt
 
I really hope this helps getting you on the road. 
 
Since I'm new at this list, please excuse me if this is totally off topic...
 
Dennis Geurts
 
 
On 6/16/05, Nathan Sowatskey <[EMAIL PROTECTED]> wrote:
HiI have tried to follow the examples that I can find for Maven andxdoclet, and I have it apparently running, that it doesn't complain
about dependencies, but it doesn't seem to be processing my EJB togenerate the interfaces and deployment descriptors that I expect.I can get this to work with Ant, but not Maven it seems.Does anyone have any pointers to a project that I could peruse to get
some hints please? I looked at geronimo, but it doesn't seem to employejbdoclet.Many thanksNathan--Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id
NathanCisco - [EMAIL PROTECTED]-To unsubscribe, e-mail: 
[EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]


servletapi
servletapi
2.3
jar


xdoclet
xdoclet
1.2
jar


xdoclet
xdoclet-web-module
1.2
jar
http://xdoclet.sf.net/


xdoclet
xdoclet-ejb-module
1.2
jar
http://xdoclet.sf.net/


xdoclet
xdoclet-jmx-module
1.2
jar
http://xdoclet.sf.net/


xdoclet
xjavadoc
1.0.2
jar
http://xdoclet.sf.net/


xdoclet
maven-xdoclet-plugin
1.2
plugin
http://xdoclet.sf.net/


xdoclet
xdoclet-jboss-module
1.2
jar

gen.dir=${maven.build.dir}/middlegen/cmp20

ejb.dir=${maven.build.dir}/xdoclet/ejbdoclet
ejb.meta.dir=${maven.build.dir}/xdoclet/ejb

xdoclet.ejbdoclet.mergedir=${maven.src.dir}/merge/xdoclet/ejbdoclet

maven.eclipse.classpath.include=target/middlegen/cmp20/,target/xdoclet/ejbdoclet

maven.war.webapp.dir=${maven.build.dir}/xdoclet/webdoclet
maven.xdoclet.webdoclet.0=true
maven.xdoclet.webdoclet.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
maven.xdoclet.webdoclet.0.mergeDir=${maven.src.dir}/merge/xdoclet
maven.xdoclet.webdoclet.deploymentdescriptor.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
maven.xdoclet.webdoclet.deploymentdescriptor.0.mergeDir=${maven.src.dir}/merge/xdoclet
  



  











  
  

  

   








  
Creating LocalHome Interfaces





Creating Local Interfaces



  

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