date:20031209

On Tue, 2003-12-09 at 19:19, Jeffrey Bonevich wrote:
> Jason -
> 
> Saw your post on Maven Dairies regarding Maven IDE.
> 
> http://blogs.codehaus.org/projects/maven/archives/000276.html
> 
> Just curious, what is a 'Maven IDE' and what would the relationship be 
> with mevenide project?

I've always wanted to write a small IDE so I'm going to make one based
entirely on Maven. I'm leveraging several commercial packages in
particular all the Jide Software Components and JGoodies. The JideSoft
stuff in particular focuses on IDE components things like dockable
windows and toolboxes and a slew of other components and the JGoodies
stuff has superb l&f tools, great form support and good components as
well. So with these two packages I'm hoping to make a very simple tool
to start with for navigating projects and building them. Later I'll
expand and add an editor (I have one based on the MIT lic'd version of
JEdit) and various other things. All this stuff will be BSD lic'd and
I'll give whatever I can away barring any restrictions imposed by using
the commercial components. But I can live with that because I want to
make a quality tool, quickly, that works and there are thousands of man
hours in the two packages above that I just wouldn't be able to
replicate. And I don't want to, I just want to make an IDE.

Eventually I will integrate Werkflow and Drools to try and work toward
making a tool to help with things like stringent release processes, site
management and whatever else I've thought about but forget ATM. In this
I will probably integrate some serious visualization stuff using either
the YWorks graph packages or the JViews components from ILOG. These run
anywhere from 3-6k and possible runtime/distribution fees so this
incarnation will not be free. 

I have honestly not looked at Mevenide in quite some time but I'm sure
we could share a lot or all of the model, but I have zero interest in
SWT and even less in Eclipse. I'm an IDEA fan so that's what I'll be
trying to emulate but I'm certain the entire model could be shared
between Mevenide and my thingy.

[1] http://www.jidesoft.com/company/index.htm
[2] http://www.jgoodies.com/
[3] http://www.yworks.com/en/products_yfiles_about.htm
[4] http://www.ilog.com/products/jviews/
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

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

Re: Leading slash gets removed from navigation.xml hrefs during site generation

Thanks, dIon. What I'm seeing with my site gen is that
${toplevelProject}/xdocs/navigation.xml is used for the main and each
subproject's index.html file. One of my subprojects has an
xdocs/navigation.xml file, but it's not being used.

Is there a property I should be setting to get to use the subproject's
navigation.xml file?

On Wed, 10 Dec 2003, at 11:07:54 [GMT +1100] [EMAIL PROTECTED]
wrote:

> "Jefferson K. French" <[EMAIL PROTECTED]> wrote on 10/12/2003 09:30:32 AM:

>> Thanks, Ben. I didn't realize that about /absolute//.
>> 
>> When I said "absolute path" what I really should have said was "all
>> subproject hrefs relative to the parent project". I was trying to get
>> the generated hrefs in the subprojects to begin with "/multiproject"
>> instead of "multiproject", but the leading slash keeps going away.
>> 
>> It turns out, though, that my main problem is my
>> multiproject/navigation.xml file is not being used. I did not realize
>> this at first, since its contents are very similar to
>> xdocs/navigation.xml.
>> 
>> I'm currently tracing through plugin code to see how this works, but
>> my assumption is that multiproject/navigation.xml will be used by each
>> subproject. Is that correct? If so, is there a property I need to set
>> to make this happen?

> No the multiproject/navigation.xml (for beta10 I think) and 
> ${toplevelProject}/xdocs/navigation.xml will NOT be used for all 
> subprojects.

> This would be nice, but it's unimplemented functionality at this point.
> --
> dIon Gillard, Multitask Consulting
> Blog:  http://blogs.codehaus.org/people/dion/





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

-- 
mailto:[EMAIL PROTECTED]



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

RE: Need help getting jcoverage to work

2003-12-09 Thread VLADIMIR TERZIC

i can't get jcoverage to work from maven either...

thanks
vlad

>>> [EMAIL PROTECTED] 12/09/03 06:28PM >>>
Not sure if its related, but in making the AndroMDA maven plugin work
(inside Eclipse), I found that I had to split up my Ant taskdef and its
invocation into 2 separate maven/jelly goals.

An init goal to do the taskdef and then a separeate goal to run the task.
The second goal declared the init goals as a prereq.

This was *only* when running maven from within Eclipse. When the exact same
maven project was run from a command-line I did not have any trouble

Matthew

> -Original Message-
> From: Gilles Dodinet [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 10, 2003 9:36 AM
> To: Maven Users List
> Subject: Re: Need help getting jcoverage to work
>
>
> vlad,
>
> i am using eclipse as well and ive encountered some problem with
> jcoverage too. i cannot retell precisely what the symptoms were but from
> what i remember, the main issue was that the testcases were instrumented
> along with the application classes (and thus the stats were biased). im
> aware that this problem is quite different from yours, altho i reply in
> hope it could lead you to some solution.
>
> the problem faced came from the fact that i didnt specify different
> output folders for test and app classes (in eclipse project propeties).
> also before building the site (or running the report for that matters)
> the target/ directory wasnot cleaned. so, as jcoverage plugin
> instruments all classes under ${maven.build.dest}, testcases were
> instrumented as well. perhaps your problem is related to an eclipse
> configuration thingie as was mine ?
>
> not sure that will help but i hope it will at least give some ideas..
>
> -- gd
>
> VLADIMIR TERZIC wrote:
>
> >i am using eclipse with maven and i get errors when i try to run
> jcoverage on my project.
> >(i guess i should mention that i am able to run clover maven
> task just fine)
> >
> >i have my source in src/java and my test source code in src/test
> >
> >i don't have any jcoverage properties set and when i try to run
> jcoverage only classes from /src/java directory get instrumented
> (nothing in the package structure bellow). at that point i get IO
> exception for coverage.xml file missing in target/jcoverage
> >
> >i would appreciate some help ;-)
> >
> >thanks
> >vlad
> >
> >
> >-
> >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]

maven-project and embedding

Gilles,

You might want to take a look at the maven-project component now as it's
what I would like to use as the basis of a little Maven IDE and I know
you're working on Mevenide.

What I'm particularly interested in are your thoughts on changes that
might happen to the project while the project is being manipulated by
the IDE (or any other project using maven-project that might change the
project itself).

Currently there are a set of methods that are not being tested because
I'm not exactly what the best way to handle changes being pushed back
into the project. An important distinction to note now in the components
is that the model and the project, which is built from the model, are
now separate.

It may very well be that the only thing the that will be changed is the
model itself, but I'm not sure. I'm just wondering what your use cases
have been. I'm also interested because I would like to pick a path so I
can incorporate those into maven-project and knock off the remaining 30%
to be covered.

I will take a look at Mevenide but if you can look at the new components
to provide any feedback that would be great. I think you'll find these
are a lot cleaner for embedding and full recursive inheritance now
appears to be working from the tests that are currrently there.

-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

RE: Need help getting jcoverage to work

2003-12-09 Thread J. Matthew Pryor

Not sure if its related, but in making the AndroMDA maven plugin work
(inside Eclipse), I found that I had to split up my Ant taskdef and its
invocation into 2 separate maven/jelly goals.

An init goal to do the taskdef and then a separeate goal to run the task.
The second goal declared the init goals as a prereq.

This was *only* when running maven from within Eclipse. When the exact same
maven project was run from a command-line I did not have any trouble

Matthew

> -Original Message-
> From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2003 9:36 AM
> To: Maven Users List
> Subject: Re: Need help getting jcoverage to work
>
>
> vlad,
>
> i am using eclipse as well and ive encountered some problem with
> jcoverage too. i cannot retell precisely what the symptoms were but from
> what i remember, the main issue was that the testcases were instrumented
> along with the application classes (and thus the stats were biased). im
> aware that this problem is quite different from yours, altho i reply in
> hope it could lead you to some solution.
>
> the problem faced came from the fact that i didnt specify different
> output folders for test and app classes (in eclipse project propeties).
> also before building the site (or running the report for that matters)
> the target/ directory wasnot cleaned. so, as jcoverage plugin
> instruments all classes under ${maven.build.dest}, testcases were
> instrumented as well. perhaps your problem is related to an eclipse
> configuration thingie as was mine ?
>
> not sure that will help but i hope it will at least give some ideas..
>
> -- gd
>
> VLADIMIR TERZIC wrote:
>
> >i am using eclipse with maven and i get errors when i try to run
> jcoverage on my project.
> >(i guess i should mention that i am able to run clover maven
> task just fine)
> >
> >i have my source in src/java and my test source code in src/test
> >
> >i don't have any jcoverage properties set and when i try to run
> jcoverage only classes from /src/java directory get instrumented
> (nothing in the package structure bellow). at that point i get IO
> exception for coverage.xml file missing in target/jcoverage
> >
> >i would appreciate some help ;-)
> >
> >thanks
> >vlad
> >
> >
> >-
> >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: Leading slash gets removed from navigation.xml hrefs during site generation

2003-12-09 Thread dion

"Jefferson K. French" <[EMAIL PROTECTED]> wrote on 10/12/2003 09:30:32 AM:

> Thanks, Ben. I didn't realize that about /absolute//.
> 
> When I said "absolute path" what I really should have said was "all
> subproject hrefs relative to the parent project". I was trying to get
> the generated hrefs in the subprojects to begin with "/multiproject"
> instead of "multiproject", but the leading slash keeps going away.
> 
> It turns out, though, that my main problem is my
> multiproject/navigation.xml file is not being used. I did not realize
> this at first, since its contents are very similar to
> xdocs/navigation.xml.
> 
> I'm currently tracing through plugin code to see how this works, but
> my assumption is that multiproject/navigation.xml will be used by each
> subproject. Is that correct? If so, is there a property I need to set
> to make this happen?

No the multiproject/navigation.xml (for beta10 I think) and 
${toplevelProject}/xdocs/navigation.xml will NOT be used for all 
subprojects.

This would be nice, but it's unimplemented functionality at this point.
--
dIon Gillard, Multitask Consulting
Blog:  http://blogs.codehaus.org/people/dion/





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

[SOOT] Maven IDE

2003-12-09 Thread Jeffrey Bonevich

Jason -

Saw your post on Maven Dairies regarding Maven IDE.

http://blogs.codehaus.org/projects/maven/archives/000276.html

Just curious, what is a 'Maven IDE' and what would the relationship be 
with mevenide project?

jeff

--
jeff bonevich
mailto: [EMAIL PROTECTED]
"Any sufficiently advanced technology is indistinguishable from magic."
Arthur C. Clarke
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
Rich Cook
"All programmers are playwrights and all computers are lousy actors."
Unknown
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Need help getting jcoverage to work

2003-12-09 Thread Gilles Dodinet

vlad,

i am using eclipse as well and ive encountered some problem with
jcoverage too. i cannot retell precisely what the symptoms were but from
what i remember, the main issue was that the testcases were instrumented
along with the application classes (and thus the stats were biased). im
aware that this problem is quite different from yours, altho i reply in
hope it could lead you to some solution.

the problem faced came from the fact that i didnt specify different
output folders for test and app classes (in eclipse project propeties).
also before building the site (or running the report for that matters)
the target/ directory wasnot cleaned. so, as jcoverage plugin
instruments all classes under ${maven.build.dest}, testcases were
instrumented as well. perhaps your problem is related to an eclipse
configuration thingie as was mine ?

not sure that will help but i hope it will at least give some ideas..

-- gd

VLADIMIR TERZIC wrote:

i am using eclipse with maven and i get errors when i try to run jcoverage on my
project.
(i guess i should mention that i am able to run clover maven task just fine)
i have my source in src/java and my test source code in src/test

i don't have any jcoverage properties set and when i try to run jcoverage only classes from /src/java directory get instrumented (nothing in the package structure bellow). at that point i get IO exception for coverage.xml file missing in target/jcoverage

i would appreciate some help ;-)

thanks
vlad
-
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: Leading slash gets removed from navigation.xml hrefs during site generation

Thanks, Ben. I didn't realize that about /absolute//.

When I said "absolute path" what I really should have said was "all
subproject hrefs relative to the parent project". I was trying to get
the generated hrefs in the subprojects to begin with "/multiproject"
instead of "multiproject", but the leading slash keeps going away.

It turns out, though, that my main problem is my
multiproject/navigation.xml file is not being used. I did not realize
this at first, since its contents are very similar to
xdocs/navigation.xml.

I'm currently tracing through plugin code to see how this works, but
my assumption is that multiproject/navigation.xml will be used by each
subproject. Is that correct? If so, is there a property I need to set
to make this happen?

Thanks.

  Jeff

On Wed, 10 Dec 2003, at 06:56:34 [GMT +1000] Ben Walding wrote:

> You probably want something like 
> /absolute/multiproject/${reactorProject.name}

> Jefferson K. French wrote:

>>I've read through several postings about multiproject site navigation
>>in the archives, and downloaded the WebShop example, but I'm still
>>unable to get absolute paths to work in my subprojects.
>>
>>My multiproject/navigation.xml contains:
>>
>>  
>>#foreach ($reactorProject in $reactorProjects)
>>  ...
>>
>>In fact, the same thing happens with the hrefs in the parent's
>>xdocs/navigation.xml file.
>>
>>Any ideas what I could be doing wrong?
>>
>>I'm using RC2 built from CVS on 11/25/03. My xdoc plugin is
>>1.5-SNAPSHOT. Looks like its files have not been updated since my
>>11/25/03 install.
>>
>>Jeff
>>
>>  
>>

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

-- 
mailto:[EMAIL PROTECTED]

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

RE: location of generated source

2003-12-09 Thread Steve Garcia

It does seem like code generation is a more common strategy today than it
was a couple of years ago.  Back in 2000 we never generated any code, but
tools today make it so easy to generate Java code.  The Maven POM does
support a  element which can alleviate some
frustration, and you can also (as mentioned below) modify the
maven.compile.src.dir property (or whatever it is) with the mavenAddPath Ant
Task.

I think it would be great if the POM somehow accomodated the notion of
generated source code directory.  

I also remember one of the outstanding, low-priority tasks from the Maven
website was to introduce to the POM the notion of a sample application.
More compilable code that, in this case, is not part of the project source
tree but somewhere else.  One could make little Maven projects, one per
sample application, and maybe that is the solution to take when POM
inheritance becomes a little more stable.

The single java source tree is an elegant solution but sometimes its
difficult to work with model.

-Original Message-
From: Kevin Hagel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 09, 2003 1:42 PM
To: Maven Users List
Subject: Re: location of generated source


I agree completely.  It would also be nice to see some documentation
regarding xdoclet settings in project.properties, how they map to values
that are used by xdoclet.  If I hadn't been so busy trying to write an
xdoclet module myself, I would still be regularly lost on this.

maven.xdoclet.hibernatedoclet.0=true
maven.xdocelt.hibernatedoclet.0.fileset=blah

and so on.  I actually find it easier to use ant taskdefs in my maven.xml,
rather than use the maven settings that the xdoclet plugin suggests.


Kevin

- Original Message - 
From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 1:38 PM
Subject: RE: location of generated source


> I'm in a similar situation in my project.  Originally built using 
> mainly
BMP
> entity beans, I'm at a point of reevaluation and thinking about 
> hibernate. I think for the time being I'll stick with the generated 
> classes in the target directory, and see if I "need" them saved in 
> CVS.
>
> I can't think of many J2EE applications that aren't using xdoclet, so
maybe
> it would be a good idea to put together a "Best Practices" guide for 
> this kind of thing?  I'm sure there are several people using maven 
> that have these same questions.  I think maven does a great job at 
> handling it, but with several different options, a short HOWTO might 
> be beneficial to
newbies
> (and the not so newbielike myself).
>
> Ryan
>
> -Original Message-
> From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 09, 2003 3:28 PM
> To: Maven Users List
> Subject: Re: location of generated source
>
> I haven't dealt with XDoclet and EJBs much beyond experimentation.  
> I'm staying away from entity beans anyway, since I'm using hibernate.  
> when
the
> project gets to the point where I want remote access, I'm plan to use 
> Stateless Session Beans only.
>
> I mostly use it right now for hibernate and jmx/jboss stuff, and I'm 
> busy trying to write a module for handling springframework stuff.
>
> I can suggest an experiment maybe ...?  do a touch *.* and run 
> xdoclet,
then
> run it again ...?
>
> - Original Message -
> From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> To: "'Maven Users List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 09, 2003 1:27 PM
> Subject: RE: location of generated source
>
>
> > Thanks for the response.
> > Do you find the build to be fast enough for doing incremental 
> > builds?  I mean, even if xdoclet doesn't generate the files in 
> > question, does the timestamp check take unnecessarily long?  The 
> > reason I was thinking of taking my generated files out of 
> > 'target/xdoclet', was because the interfaces and utility classes it 
> > generates are so rarely updated, that
> the
> > constant refreshing of the classes becomes tedious.  How large is 
> > your project and what do you use xdoclet for (entity and session 
> > ejbs,
> taglibs)?
> >
> > Thanks again.
> > Ryan
> >
> > -Original Message-
> > From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 09, 2003 3:18 PM
> > To: Maven Users List
> > Subject: Re: location of generated source
> >
> > I always put XDoclet-generated files in 
> > target/xdoclet/hibernatedoclet, target/xdoclet/springdoclet, that 
> > kind of thing. Isn't it true that XDoclet won't bother re-creating 
> > your generated
classes
> > if the timestamps on the source and destination files match?  I mean 
> > is there a force=false kind of setting or something?
> >
> > You can also set
> > maven -DdoXDoclet=true
> > on the command line and just
> > 
> > xdoclet things
> > copy xdoclet-generated source over to src/java... 
> >
> > - Original Message -
> > From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> > To: "'Maven Users

Re: location of generated source

I agree completely.  It would also be nice to see some documentation
regarding xdoclet settings in project.properties, how they map to values
that are used by xdoclet.  If I hadn't been so busy trying to write an
xdoclet module myself, I would still be regularly lost on this.

maven.xdoclet.hibernatedoclet.0=true
maven.xdocelt.hibernatedoclet.0.fileset=blah

and so on.  I actually find it easier to use ant taskdefs in my maven.xml,
rather than use the maven settings that the xdoclet plugin suggests.


Kevin

- Original Message - 
From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 1:38 PM
Subject: RE: location of generated source


> I'm in a similar situation in my project.  Originally built using mainly
BMP
> entity beans, I'm at a point of reevaluation and thinking about hibernate.
> I think for the time being I'll stick with the generated classes in the
> target directory, and see if I "need" them saved in CVS.
>
> I can't think of many J2EE applications that aren't using xdoclet, so
maybe
> it would be a good idea to put together a "Best Practices" guide for this
> kind of thing?  I'm sure there are several people using maven that have
> these same questions.  I think maven does a great job at handling it, but
> with several different options, a short HOWTO might be beneficial to
newbies
> (and the not so newbielike myself).
>
> Ryan
>
> -Original Message-
> From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 09, 2003 3:28 PM
> To: Maven Users List
> Subject: Re: location of generated source
>
> I haven't dealt with XDoclet and EJBs much beyond experimentation.  I'm
> staying away from entity beans anyway, since I'm using hibernate.  when
the
> project gets to the point where I want remote access, I'm plan to use
> Stateless Session Beans only.
>
> I mostly use it right now for hibernate and jmx/jboss stuff, and I'm busy
> trying to write a module for handling springframework stuff.
>
> I can suggest an experiment maybe ...?  do a touch *.* and run xdoclet,
then
> run it again ...?
>
> - Original Message - 
> From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> To: "'Maven Users List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 09, 2003 1:27 PM
> Subject: RE: location of generated source
>
>
> > Thanks for the response.
> > Do you find the build to be fast enough for doing incremental builds?  I
> > mean, even if xdoclet doesn't generate the files in question, does the
> > timestamp check take unnecessarily long?  The reason I was thinking of
> > taking my generated files out of 'target/xdoclet', was because the
> > interfaces and utility classes it generates are so rarely updated, that
> the
> > constant refreshing of the classes becomes tedious.  How large is your
> > project and what do you use xdoclet for (entity and session ejbs,
> taglibs)?
> >
> > Thanks again.
> > Ryan
> >
> > -Original Message-
> > From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 09, 2003 3:18 PM
> > To: Maven Users List
> > Subject: Re: location of generated source
> >
> > I always put XDoclet-generated files in target/xdoclet/hibernatedoclet,
> > target/xdoclet/springdoclet, that kind of thing.
> > Isn't it true that XDoclet won't bother re-creating your generated
classes
> > if the timestamps on the source and destination files match?  I mean is
> > there a force=false kind of setting or something?
> >
> > You can also set
> > maven -DdoXDoclet=true
> > on the command line and just
> > 
> > xdoclet things
> > copy xdoclet-generated source over to src/java...
> > 
> >
> > - Original Message - 
> > From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> > To: "'Maven Users List'" <[EMAIL PROTECTED]>
> > Sent: Tuesday, December 09, 2003 8:07 AM
> > Subject: location of generated source
> >
> >
> > > Where do most maven developers place generated files (ex: xdoclet)?
> > > I've been developing a maven project for the past 6 months and have
been
> > > dumping all generated files into 'target' to avoid saving into CVS.
> Now,
> > > with over 200 generated classes, and little change, I'd like to avoid
> > having
> > > xdoclet run EACH java:compile.  So, here are my two options as I see
> them:
> > >
> > > 1.  create a separate subproject, and have the generated interfaces
> saved
> > in
> > > src/java to "appease" maven.  Add a task into maven.xml to regenerate
> the
> > > classes only when needed.
> > >
> > > 2.  save the files in src/java-gen (or something like that), and
modify
> > > maven.xml to add that location to the maven.src.path (is that the
right
> > > property?).
> > >
> > > what do others do out there?
> > >
> > > Ryan
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >

RE: location of generated source

2003-12-09 Thread Sonnek, Ryan

I'm in a similar situation in my project.  Originally built using mainly BMP
entity beans, I'm at a point of reevaluation and thinking about hibernate.
I think for the time being I'll stick with the generated classes in the
target directory, and see if I "need" them saved in CVS.

I can't think of many J2EE applications that aren't using xdoclet, so maybe
it would be a good idea to put together a "Best Practices" guide for this
kind of thing?  I'm sure there are several people using maven that have
these same questions.  I think maven does a great job at handling it, but
with several different options, a short HOWTO might be beneficial to newbies
(and the not so newbielike myself).

Ryan

-Original Message-
From: Kevin Hagel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 09, 2003 3:28 PM
To: Maven Users List
Subject: Re: location of generated source

I haven't dealt with XDoclet and EJBs much beyond experimentation.  I'm
staying away from entity beans anyway, since I'm using hibernate.  when the
project gets to the point where I want remote access, I'm plan to use
Stateless Session Beans only.

I mostly use it right now for hibernate and jmx/jboss stuff, and I'm busy
trying to write a module for handling springframework stuff.

I can suggest an experiment maybe ...?  do a touch *.* and run xdoclet, then
run it again ...?

- Original Message - 
From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 1:27 PM
Subject: RE: location of generated source


> Thanks for the response.
> Do you find the build to be fast enough for doing incremental builds?  I
> mean, even if xdoclet doesn't generate the files in question, does the
> timestamp check take unnecessarily long?  The reason I was thinking of
> taking my generated files out of 'target/xdoclet', was because the
> interfaces and utility classes it generates are so rarely updated, that
the
> constant refreshing of the classes becomes tedious.  How large is your
> project and what do you use xdoclet for (entity and session ejbs,
taglibs)?
>
> Thanks again.
> Ryan
>
> -Original Message-
> From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 09, 2003 3:18 PM
> To: Maven Users List
> Subject: Re: location of generated source
>
> I always put XDoclet-generated files in target/xdoclet/hibernatedoclet,
> target/xdoclet/springdoclet, that kind of thing.
> Isn't it true that XDoclet won't bother re-creating your generated classes
> if the timestamps on the source and destination files match?  I mean is
> there a force=false kind of setting or something?
>
> You can also set
> maven -DdoXDoclet=true
> on the command line and just
> 
> xdoclet things
> copy xdoclet-generated source over to src/java...
> 
>
> - Original Message - 
> From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> To: "'Maven Users List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 09, 2003 8:07 AM
> Subject: location of generated source
>
>
> > Where do most maven developers place generated files (ex: xdoclet)?
> > I've been developing a maven project for the past 6 months and have been
> > dumping all generated files into 'target' to avoid saving into CVS.
Now,
> > with over 200 generated classes, and little change, I'd like to avoid
> having
> > xdoclet run EACH java:compile.  So, here are my two options as I see
them:
> >
> > 1.  create a separate subproject, and have the generated interfaces
saved
> in
> > src/java to "appease" maven.  Add a task into maven.xml to regenerate
the
> > classes only when needed.
> >
> > 2.  save the files in src/java-gen (or something like that), and modify
> > maven.xml to add that location to the maven.src.path (is that the right
> > property?).
> >
> > what do others do out there?
> >
> > Ryan
> >
> > -
> > 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]

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

Re: location of generated source

One other thing
http://ant.apache.org/manual/CoreTasks/uptodate.html

maybe you can do the uptodate test yourself to see if it's necessary to run
xdoclet.

- Original Message - 
From: "Kevin Hagel" <[EMAIL PROTECTED]>
To: "Maven Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 1:28 PM
Subject: Re: location of generated source


> I haven't dealt with XDoclet and EJBs much beyond experimentation.  I'm
> staying away from entity beans anyway, since I'm using hibernate.  when
the
> project gets to the point where I want remote access, I'm plan to use
> Stateless Session Beans only.
>
> I mostly use it right now for hibernate and jmx/jboss stuff, and I'm busy
> trying to write a module for handling springframework stuff.
>
> I can suggest an experiment maybe ...?  do a touch *.* and run xdoclet,
then
> run it again ...?
>
> - Original Message - 
> From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> To: "'Maven Users List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 09, 2003 1:27 PM
> Subject: RE: location of generated source
>
>
> > Thanks for the response.
> > Do you find the build to be fast enough for doing incremental builds?  I
> > mean, even if xdoclet doesn't generate the files in question, does the
> > timestamp check take unnecessarily long?  The reason I was thinking of
> > taking my generated files out of 'target/xdoclet', was because the
> > interfaces and utility classes it generates are so rarely updated, that
> the
> > constant refreshing of the classes becomes tedious.  How large is your
> > project and what do you use xdoclet for (entity and session ejbs,
> taglibs)?
> >
> > Thanks again.
> > Ryan
> >
> > -Original Message-
> > From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 09, 2003 3:18 PM
> > To: Maven Users List
> > Subject: Re: location of generated source
> >
> > I always put XDoclet-generated files in target/xdoclet/hibernatedoclet,
> > target/xdoclet/springdoclet, that kind of thing.
> > Isn't it true that XDoclet won't bother re-creating your generated
classes
> > if the timestamps on the source and destination files match?  I mean is
> > there a force=false kind of setting or something?
> >
> > You can also set
> > maven -DdoXDoclet=true
> > on the command line and just
> > 
> > xdoclet things
> > copy xdoclet-generated source over to src/java...
> > 
> >
> > - Original Message - 
> > From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> > To: "'Maven Users List'" <[EMAIL PROTECTED]>
> > Sent: Tuesday, December 09, 2003 8:07 AM
> > Subject: location of generated source
> >
> >
> > > Where do most maven developers place generated files (ex: xdoclet)?
> > > I've been developing a maven project for the past 6 months and have
been
> > > dumping all generated files into 'target' to avoid saving into CVS.
> Now,
> > > with over 200 generated classes, and little change, I'd like to avoid
> > having
> > > xdoclet run EACH java:compile.  So, here are my two options as I see
> them:
> > >
> > > 1.  create a separate subproject, and have the generated interfaces
> saved
> > in
> > > src/java to "appease" maven.  Add a task into maven.xml to regenerate
> the
> > > classes only when needed.
> > >
> > > 2.  save the files in src/java-gen (or something like that), and
modify
> > > maven.xml to add that location to the maven.src.path (is that the
right
> > > property?).
> > >
> > > what do others do out there?
> > >
> > > Ryan
> > >
> > > -
> > > 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]
>


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

Re: location of generated source

I haven't dealt with XDoclet and EJBs much beyond experimentation.  I'm
staying away from entity beans anyway, since I'm using hibernate.  when the
project gets to the point where I want remote access, I'm plan to use
Stateless Session Beans only.

I mostly use it right now for hibernate and jmx/jboss stuff, and I'm busy
trying to write a module for handling springframework stuff.

I can suggest an experiment maybe ...?  do a touch *.* and run xdoclet, then
run it again ...?

- Original Message - 
From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 1:27 PM
Subject: RE: location of generated source


> Thanks for the response.
> Do you find the build to be fast enough for doing incremental builds?  I
> mean, even if xdoclet doesn't generate the files in question, does the
> timestamp check take unnecessarily long?  The reason I was thinking of
> taking my generated files out of 'target/xdoclet', was because the
> interfaces and utility classes it generates are so rarely updated, that
the
> constant refreshing of the classes becomes tedious.  How large is your
> project and what do you use xdoclet for (entity and session ejbs,
taglibs)?
>
> Thanks again.
> Ryan
>
> -Original Message-
> From: Kevin Hagel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 09, 2003 3:18 PM
> To: Maven Users List
> Subject: Re: location of generated source
>
> I always put XDoclet-generated files in target/xdoclet/hibernatedoclet,
> target/xdoclet/springdoclet, that kind of thing.
> Isn't it true that XDoclet won't bother re-creating your generated classes
> if the timestamps on the source and destination files match?  I mean is
> there a force=false kind of setting or something?
>
> You can also set
> maven -DdoXDoclet=true
> on the command line and just
> 
> xdoclet things
> copy xdoclet-generated source over to src/java...
> 
>
> - Original Message - 
> From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
> To: "'Maven Users List'" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 09, 2003 8:07 AM
> Subject: location of generated source
>
>
> > Where do most maven developers place generated files (ex: xdoclet)?
> > I've been developing a maven project for the past 6 months and have been
> > dumping all generated files into 'target' to avoid saving into CVS.
Now,
> > with over 200 generated classes, and little change, I'd like to avoid
> having
> > xdoclet run EACH java:compile.  So, here are my two options as I see
them:
> >
> > 1.  create a separate subproject, and have the generated interfaces
saved
> in
> > src/java to "appease" maven.  Add a task into maven.xml to regenerate
the
> > classes only when needed.
> >
> > 2.  save the files in src/java-gen (or something like that), and modify
> > maven.xml to add that location to the maven.src.path (is that the right
> > property?).
> >
> > what do others do out there?
> >
> > Ryan
> >
> > -
> > 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: location of generated source

2003-12-09 Thread Sonnek, Ryan

Thanks for the response.
Do you find the build to be fast enough for doing incremental builds?  I
mean, even if xdoclet doesn't generate the files in question, does the
timestamp check take unnecessarily long?  The reason I was thinking of
taking my generated files out of 'target/xdoclet', was because the
interfaces and utility classes it generates are so rarely updated, that the
constant refreshing of the classes becomes tedious.  How large is your
project and what do you use xdoclet for (entity and session ejbs, taglibs)?

Thanks again.
Ryan

-Original Message-
From: Kevin Hagel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 09, 2003 3:18 PM
To: Maven Users List
Subject: Re: location of generated source

I always put XDoclet-generated files in target/xdoclet/hibernatedoclet,
target/xdoclet/springdoclet, that kind of thing.
Isn't it true that XDoclet won't bother re-creating your generated classes
if the timestamps on the source and destination files match?  I mean is
there a force=false kind of setting or something?

You can also set
maven -DdoXDoclet=true
on the command line and just

xdoclet things
copy xdoclet-generated source over to src/java...


- Original Message - 
From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 8:07 AM
Subject: location of generated source


> Where do most maven developers place generated files (ex: xdoclet)?
> I've been developing a maven project for the past 6 months and have been
> dumping all generated files into 'target' to avoid saving into CVS.  Now,
> with over 200 generated classes, and little change, I'd like to avoid
having
> xdoclet run EACH java:compile.  So, here are my two options as I see them:
>
> 1.  create a separate subproject, and have the generated interfaces saved
in
> src/java to "appease" maven.  Add a task into maven.xml to regenerate the
> classes only when needed.
>
> 2.  save the files in src/java-gen (or something like that), and modify
> maven.xml to add that location to the maven.src.path (is that the right
> property?).
>
> what do others do out there?
>
> Ryan
>
> -
> 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: [newbie] jar:deploy

2003-12-09 Thread Leif Nelson

Go read about the "jar" plugin...  You want the deploy properties in the 
properties section.

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

--Leif

At 03:18 PM 12/9/2003 -0600, you wrote:
How do I configure maven to deploy my release jars to a central repository 
within my company?  Is it accomplished by using FTP, and if so, how to I 
tell maven what the ftp url and login creditentials are?

Thanks,
Timothy


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

Need help getting jcoverage to work

2003-12-09 Thread VLADIMIR TERZIC

i am using eclipse with maven and i get errors when i try to run jcoverage on my 
project.
(i guess i should mention that i am able to run clover maven task just fine)

i have my source in src/java and my test source code in src/test

i don't have any jcoverage properties set and when i try to run jcoverage only classes 
from /src/java directory get instrumented (nothing in the package structure bellow). 
at that point i get IO exception for coverage.xml file missing in target/jcoverage

i would appreciate some help ;-)

thanks
vlad


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

Re: location of generated source

I always put XDoclet-generated files in target/xdoclet/hibernatedoclet,
target/xdoclet/springdoclet, that kind of thing.
Isn't it true that XDoclet won't bother re-creating your generated classes
if the timestamps on the source and destination files match?  I mean is
there a force=false kind of setting or something?

You can also set
maven -DdoXDoclet=true
on the command line and just

xdoclet things
copy xdoclet-generated source over to src/java...


- Original Message - 
From: "Sonnek, Ryan" <[EMAIL PROTECTED]>
To: "'Maven Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 8:07 AM
Subject: location of generated source


> Where do most maven developers place generated files (ex: xdoclet)?
> I've been developing a maven project for the past 6 months and have been
> dumping all generated files into 'target' to avoid saving into CVS.  Now,
> with over 200 generated classes, and little change, I'd like to avoid
having
> xdoclet run EACH java:compile.  So, here are my two options as I see them:
>
> 1.  create a separate subproject, and have the generated interfaces saved
in
> src/java to "appease" maven.  Add a task into maven.xml to regenerate the
> classes only when needed.
>
> 2.  save the files in src/java-gen (or something like that), and modify
> maven.xml to add that location to the maven.src.path (is that the right
> property?).
>
> what do others do out there?
>
> Ryan
>
> -
> 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]

[newbie] jar:deploy

2003-12-09 Thread Timothy Bennett

How do I configure maven to deploy my release jars to a central 
repository within my company?  Is it accomplished by using FTP, and if 
so, how to I tell maven what the ftp url and login creditentials are?

Thanks,
Timothy


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

Re: Leading slash gets removed from navigation.xml hrefs during site generation

I'm using the root context for one thing, and the site project page uses a
different context.  I'm also putting it all in a WAR and dumping it into my
JBoss deploy directory.

To enable this, for example with image paths,


and then do an ant replace:

  



  
  
  
  


  

  

Maven uses site, site:site, site:init kind of thing, I sort of stole that
nomenclature for site-init kind of thing.

This way I don't have to worry about what the site generation is doing or
not, at least I'm not having the same problem that you are having.

- Original Message - 
From: "Ben Walding" <[EMAIL PROTECTED]>
To: "Maven Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 12:56 PM
Subject: Re: Leading slash gets removed from navigation.xml hrefs during
site generation


> You probably want something like
> /absolute/multiproject/${reactorProject.name}
>
> Jefferson K. French wrote:
>
> >I've read through several postings about multiproject site navigation
> >in the archives, and downloaded the WebShop example, but I'm still
> >unable to get absolute paths to work in my subprojects.
> >
> >My multiproject/navigation.xml contains:
> >
> >  
> >#foreach ($reactorProject in $reactorProjects)
> >  ...
> >
> >In fact, the same thing happens with the hrefs in the parent's
> >xdocs/navigation.xml file.
> >
> >Any ideas what I could be doing wrong?
> >
> >I'm using RC2 built from CVS on 11/25/03. My xdoc plugin is
> >1.5-SNAPSHOT. Looks like its files have not been updated since my
> >11/25/03 install.
> >
> >Jeff
> >
> >
> >
>
>
> -
> 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: Leading slash gets removed from navigation.xml hrefs during site generation

2003-12-09 Thread Ben Walding

You probably want something like 
/absolute/multiproject/${reactorProject.name}

Jefferson K. French wrote:

I've read through several postings about multiproject site navigation
in the archives, and downloaded the WebShop example, but I'm still
unable to get absolute paths to work in my subprojects.
My multiproject/navigation.xml contains:

 
   #foreach ($reactorProject in $reactorProjects)
 But the leading slash is always missing from the resulting index.html
file:
 ...

In fact, the same thing happens with the hrefs in the parent's
xdocs/navigation.xml file.
Any ideas what I could be doing wrong?

I'm using RC2 built from CVS on 11/25/03. My xdoc plugin is
1.5-SNAPSHOT. Looks like its files have not been updated since my
11/25/03 install.
   Jeff

 



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

Re: maven:reactor and test:match

2003-12-09 Thread Javier Ramos

Thanks, this works!!


- Original Message - 
From: "Jefferson K. French" <[EMAIL PROTECTED]>
To: "Maven Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 2:58 PM
Subject: Re: maven:reactor and test:match


> Have you tried adding this:
>
>   
>
> before invoking ?
>
> On Tue, 9 Dec 2003, at 13:27:27 [GMT +0100] Javier Ramos wrote:
>
> > Hello,
>
> > I have setup a maven project that contains several subprojects. I
would like to be able to use maven:reactor element inside a goal in the
master project to trigger execution of a subset of the
> > unit tests in every subproject. If I do it manually inside each
subproject, the command syntax looks like:
>
> > maven -Dtestmatch=*DB* test:match
>
> > but in the maven:reactor element I don´t know if it is possible to
include the variable 'testmatch'. I browsed the documentation with no
success.
>
> > Can anyone provide some help?
>
> > Thanks in advance,
>
> > Javier Ramos
>
> -- 
> mailto:[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: Clover plugin won't recognize my licensed clover jar

2003-12-09 Thread Joe Germuska

On Dec 8, 2003, at 4:55 PM, Chad Woolley wrote:

Hi,

I am trying to use the maven clover plugin.  In the properties for the 
plugin, it says I can specify maven.clover.jar property which "Allows 
the user to override the Clover jar. This is especially useful as the 
Clover jars are license-signed for a specific project so you might 
want to use different jars for different projects."

I do have a licensed jar in my lib dir, which I downloaded from 
Clover's website using my license key.  In my project.properties I 
have: "maven.clover.jar=${basedir}/lib/clover.jar"

have you also got
maven.jar.override=on
in your properties?
I don't user clover, but I do override jars, and it works when I use 
both the maven.jar.override as well as the specific overrides.

Joe

--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
 "We want beef in dessert if we can get it there."
  -- Betty Hogan, Director of New Product Development, National 
Cattlemen's Beef Association




smime.p7s
Description: S/MIME cryptographic signature

Re: Is it possible to keep unit tests in the same directories as production classes?

2003-12-09 Thread Chad Woolley

Wow.  Sorry, didn't mean to start such a firestorm.  The reason 
mentioned below is the only *legitimate* reason I can think of,
and I guess it doesn't hold up too well.

Don't get me wrong, I follow the recommended structure on my own 
open-source project, and I am reaping the benefits of it by using almost 
all of the report plugins.

It's just that I'm probably not going to be able to convince my team at 
work to change the project structure, and therefore will probably not be 
able to use some (many?) of the maven plugins.

However, if I had my vote, I'd still leave the "backdoor" way of doing 
this available, but people are on their own if they try it (until they 
ask a question on the mailing list and start this thread all over). 
Hmm, you could even print out an ugly, descriptive warning message if 
the dir trees point to the same place - would that be an acceptable 
compromise?

Thanks to everyone for their time and input, and thanks for the great tool.

-- Chad

Jeffrey D. Brekke wrote:
[Jason's clear and correct description clipped]


But I am curious: name one single advantage to putting test and
application sources together. Basically the arguments for it have
been "I want to do it so I should be able to" which is not likely to
be taken seriously around here.


The only one I have ever heard was something along the lines that it
is easier to see the test code filenames next to the production code
filenames in a listing in your editor/ide.
IDE's provide a way to quickly find or list test code, and in emacs I
just change src/java to src/test/java ( and vice-versa ) in the path
when opening another file.




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

Leading slash gets removed from navigation.xml hrefs during site generation

I've read through several postings about multiproject site navigation
in the archives, and downloaded the WebShop example, but I'm still
unable to get absolute paths to work in my subprojects.

My multiproject/navigation.xml contains:

  
#foreach ($reactorProject in $reactorProjects)
  ...

In fact, the same thing happens with the hrefs in the parent's
xdocs/navigation.xml file.

Any ideas what I could be doing wrong?

I'm using RC2 built from CVS on 11/25/03. My xdoc plugin is
1.5-SNAPSHOT. Looks like its files have not been updated since my
11/25/03 install.

Jeff

-- 
mailto:[EMAIL PROTECTED]



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

RE: user.home location

thanks,

user.home it's right property that i want to modify because i want to
put a global build.properties for all maven projects so if i had
understand the Maven's user guide the ${user.home}/ is the location
where i can put it.

-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: mardi 9 décembre 2003 17:03
To: Maven Users List
Subject: RE: user.home location


Stéphane Philippart wrote on Tuesday, December 09, 2003 4:47 PM:

> Hi (re),
> 
> I use maven under windows XP and it's appear that the default
> location for the ${user.home} property is C:\Documents and
> Settings\. 
> 
> Can i change this value (and where can i change it) to d:\foo for
> example ?

user.home is a Java system property:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#getPropert
ies()

You can set it, but have to do so everytime calling java.

BUT, I suppose you refer to the location of the locqal Maven repo
itself. This can be changed setting property maven.home.local in
build.properties. Have a look in Maven's User Guide:
http://maven.apache.org/reference/user-guide.html#Maven%20Setup

Regards,
Jörg

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

location of generated source

2003-12-09 Thread Sonnek, Ryan

Where do most maven developers place generated files (ex: xdoclet)?
I've been developing a maven project for the past 6 months and have been
dumping all generated files into 'target' to avoid saving into CVS.  Now,
with over 200 generated classes, and little change, I'd like to avoid having
xdoclet run EACH java:compile.  So, here are my two options as I see them:

1.  create a separate subproject, and have the generated interfaces saved in
src/java to "appease" maven.  Add a task into maven.xml to regenerate the
classes only when needed.

2.  save the files in src/java-gen (or something like that), and modify
maven.xml to add that location to the maven.src.path (is that the right
property?).

what do others do out there?  

Ryan

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

RE: user.home location

2003-12-09 Thread Geddes, Mark (ANTS)

Use the property maven.home.local
See
http://maven.apache.org/reference/user-guide.html#Properties%20Processing

-Original Message-
From: Stéphane Philippart [mailto:[EMAIL PROTECTED] 
Sent: 09 December 2003 15:47
To: Maven Users List (E-mail)
Subject: user.home location

Hi (re),

I use maven under windows XP and it's appear that the default location
for the ${user.home} property is C:\Documents and Settings\.

Can i change this value (and where can i change it) to d:\foo for
example ?

Thanks.

Stef

-

To unsubscribe, e-mail: [EMAIL PROTECTED]

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

***
This communication (including any attachments) contains confidential information.  If 
you are not the intended recipient and you have received this communication in error, 
you should destroy it without copying, disclosing or otherwise using its contents.  
Please notify the sender immediately of the error.

Internet communications are not necessarily secure and may be intercepted or changed 
after they are sent.  Abbey National Treasury Services plc does not accept liability 
for any loss you may suffer as a result of interception or any liability for such 
changes.  If you wish to confirm the origin or content of this communication, please 
contact the sender by using an alternative means of communication.

This communication does not create or modify any contract and, unless otherwise 
stated, is not intended to be contractually binding.

Abbey National Treasury Services plc. Registered Office:  Abbey National House, 2 
Triton Square, Regents Place, London NW1 3AN.  Registered in England under Company 
Registration Number: 2338548.  Regulated by the Financial Services Authority (FSA).
***

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

RE: user.home location

2003-12-09 Thread Jörg Schaible

Stéphane Philippart wrote on Tuesday, December 09, 2003 4:47 PM:

> Hi (re),
> 
> I use maven under windows XP and it's appear that the default
> location for the ${user.home} property is C:\Documents and
> Settings\. 
> 
> Can i change this value (and where can i change it) to d:\foo for
> example ?

user.home is a Java system property:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#getProperties()

You can set it, but have to do so everytime calling java.

BUT, I suppose you refer to the location of the locqal Maven repo itself. This can be 
changed setting property maven.home.local in build.properties. Have a look in Maven's 
User Guide:
http://maven.apache.org/reference/user-guide.html#Maven%20Setup

Regards,
Jörg

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

user.home location

Hi (re),
 
I use maven under windows XP and it's appear that the default location
for the ${user.home} property is C:\Documents and Settings\.
 
Can i change this value (and where can i change it) to d:\foo for
example ?
 
Thanks.
 
Stef
 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]

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

Re: Maven in action

2003-12-09 Thread Martin Skopp

On Tue, 2003-12-09 at 08:07, [EMAIL PROTECTED] wrote:
> I search some screenshots or web-installations of maven. I also need some 
> "management"-like descriptions of maven. Knows someone some good links?

http://maven.apache.org/misc/powered.html
http://maven.apache.org/goals.html
-- 
Martin Skopp
Riege Software International GmbH
Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com
 
This email is intended to be viewed with a nonproportional font.
Public Key on http://www.keyserver.net, Key-ID: 3D4027B5
Fingerprint: 1970 C78D 9A1D 99FA 5CE4  5C0D 29E6 6A95 3D40 27B5



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

RE: xdoclet:ejbdoclet and weblogic

it's seems ok when i add this dependency and the dependency on
xdoclet-web-module-1.2b4.jar.


Thanks a lot !


-Original Message-
From: Geddes, Mark (ANTS) [mailto:[EMAIL PROTECTED]
Sent: mardi 9 décembre 2003 15:19
To: 'Maven Users List'
Subject: RE: xdoclet:ejbdoclet and weblogic



Do you have the equivalent of this in your project.xml?


xdoclet+bea-module
1.2b4



-Original Message-
From: Stéphane Philippart
[mailto:[EMAIL PROTECTED] 
Sent: 09 December 2003 14:11
To: Maven Users List
Subject: xdoclet:ejbdoclet and weblogic


Hello,

I am new to maven and i have a problem with the xdoclet plugin when i
generating ejb for weblogic.

What i want is to generate the weblogic-ejb-jar.xml in a specific
directory. In my properties file i put : 
...
maven.xdoclet.ejbdoclet.weblogic.0 = true
maven.xdoclet.ejbdoclet.weblogic.0.Version=6.1
maven.xdoclet.ejbdoclet.weblogic.0.destDir=${basedir}/src/META-INF
...

When i launch xdoclet:ejbdoclet the file isn't created !

What i do wrong ?

Thanks for your answers.

Stef

Maven version : 1.10 RC 1
xDoclet version : 1.2b3 (files are named 1.2b4 !)


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



***
This communication (including any attachments) contains confidential
information.  If you are not the intended recipient and you have
received this communication in error, you should destroy it without
copying, disclosing or otherwise using its contents.  Please notify the
sender immediately of the error.

Internet communications are not necessarily secure and may be
intercepted or changed after they are sent.  Abbey National Treasury
Services plc does not accept liability for any loss you may suffer as a
result of interception or any liability for such changes.  If you wish
to confirm the origin or content of this communication, please contact
the sender by using an alternative means of communication.

This communication does not create or modify any contract and, unless
otherwise stated, is not intended to be contractually binding.

Abbey National Treasury Services plc. Registered Office:  Abbey National
House, 2 Triton Square, Regents Place, London NW1 3AN.  Registered in
England under Company Registration Number: 2338548.  Regulated by the
Financial Services Authority (FSA).

***


-
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: xdoclet:ejbdoclet and weblogic

2003-12-09 Thread Tim Chen

Correct me if I'm wrong but 1.2b4 is just another name for 1.2b3
Apparently the naming of the two got confused.
-Tim
Konstantin Priblouda wrote:

--- "Geddes, Mark (ANTS)" <[EMAIL PROTECTED]>
wrote:
 

Do you have the equivalent of this in your
project.xml?
		
			xdoclet+bea-module
			1.2b4
		
   

I would recommend 1.2b3 built from current CVS...

regards,

=
[ Konstantin Pribluda ( ko5tik ) ]
Zu Verstärkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] für die Festanstellung. 
Arbeitsort: Mainz 
Skills:  Programieren, Kentnisse in OpenSource-Bereich
[ http://www.pribluda.de ]

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



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

RE: xdoclet:ejbdoclet and weblogic

2003-12-09 Thread Konstantin Priblouda

--- "Geddes, Mark (ANTS)" <[EMAIL PROTECTED]>
wrote:
> 
> Do you have the equivalent of this in your
> project.xml?
> 
>   
>   xdoclet+bea-module
>   1.2b4
>   

I would recommend 1.2b3 built from current CVS...

regards,

=
[ Konstantin Pribluda ( ko5tik ) ]
Zu Verstärkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] für die Festanstellung. 
Arbeitsort: Mainz 
Skills:  Programieren, Kentnisse in OpenSource-Bereich
[ http://www.pribluda.de ]

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

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

RE: xdoclet:ejbdoclet and weblogic

2003-12-09 Thread Geddes, Mark (ANTS)


Do you have the equivalent of this in your project.xml?


xdoclet+bea-module
1.2b4



-Original Message-
From: Stéphane Philippart [mailto:[EMAIL PROTECTED] 
Sent: 09 December 2003 14:11
To: Maven Users List
Subject: xdoclet:ejbdoclet and weblogic


Hello,

I am new to maven and i have a problem with the xdoclet plugin when i
generating ejb for weblogic.

What i want is to generate the weblogic-ejb-jar.xml in a specific
directory. In my properties file i put : 
...
maven.xdoclet.ejbdoclet.weblogic.0 = true
maven.xdoclet.ejbdoclet.weblogic.0.Version=6.1
maven.xdoclet.ejbdoclet.weblogic.0.destDir=${basedir}/src/META-INF
...

When i launch xdoclet:ejbdoclet the file isn't created !

What i do wrong ?

Thanks for your answers.

Stef

Maven version : 1.10 RC 1
xDoclet version : 1.2b3 (files are named 1.2b4 !)


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


***
This communication (including any attachments) contains confidential information.  If 
you are not the intended recipient and you have received this communication in error, 
you should destroy it without copying, disclosing or otherwise using its contents.  
Please notify the sender immediately of the error.

Internet communications are not necessarily secure and may be intercepted or changed 
after they are sent.  Abbey National Treasury Services plc does not accept liability 
for any loss you may suffer as a result of interception or any liability for such 
changes.  If you wish to confirm the origin or content of this communication, please 
contact the sender by using an alternative means of communication.

This communication does not create or modify any contract and, unless otherwise 
stated, is not intended to be contractually binding.

Abbey National Treasury Services plc. Registered Office:  Abbey National House, 2 
Triton Square, Regents Place, London NW1 3AN.  Registered in England under Company 
Registration Number: 2338548.  Regulated by the Financial Services Authority (FSA).
***


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

xdoclet:ejbdoclet and weblogic

Hello,

I am new to maven and i have a problem with the xdoclet plugin when i
generating ejb for weblogic.

What i want is to generate the weblogic-ejb-jar.xml in a specific
directory. In my properties file i put : 
...
maven.xdoclet.ejbdoclet.weblogic.0 = true
maven.xdoclet.ejbdoclet.weblogic.0.Version=6.1
maven.xdoclet.ejbdoclet.weblogic.0.destDir=${basedir}/src/META-INF
...

When i launch xdoclet:ejbdoclet the file isn't created !

What i do wrong ?

Thanks for your answers.

Stef

Maven version : 1.10 RC 1
xDoclet version : 1.2b3 (files are named 1.2b4 !)


-
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: maven:reactor and test:match

2003-12-09 Thread Deepak Sable

Hi ,

I want to use Maven to build my java application.
I have an existing CVS Respository and have a project in it which other developers can 
checkout.
Everyone is using Eclipse as IDE to access CVS.
Now how do i use Maven in the existing project so that I can build it.I have gone thru 
the apache.org site 
but did not find any useful information that will help me make my existing project 
work with 
Maven.

But I was wondering if there is any document which
will help me use Maven with an existing project in my CVS Repository .

Thanks in advance
deepak

-Original Message-
From: Jefferson K. French [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 7:28 PM
To: Maven Users List
Subject: Re: maven:reactor and test:match

Have you tried adding this:

before invoking ?

On Tue, 9 Dec 2003, at 13:27:27 [GMT +0100] Javier Ramos wrote:

> Hello,

> I have setup a maven project that contains several subprojects. I would like to 
> be able to use maven:reactor element inside a goal in the master project to trigger 
> execution of a subset of the
> unit tests in every subproject. If I do it manually inside each subproject, the 
> command syntax looks like:

> maven -Dtestmatch=*DB* test:match

> but in the maven:reactor element I don´t know if it is possible to include the 
> variable 'testmatch'. I browsed the documentation with no success.

> Can anyone provide some help?

> Thanks in advance,

> Javier Ramos

-- 
mailto:[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: maven:reactor and test:match

Have you tried adding this:

  

before invoking ?

On Tue, 9 Dec 2003, at 13:27:27 [GMT +0100] Javier Ramos wrote:

> Hello,

> I have setup a maven project that contains several subprojects. I would like to 
> be able to use maven:reactor element inside a goal in the master project to trigger 
> execution of a subset of the
> unit tests in every subproject. If I do it manually inside each subproject, the 
> command syntax looks like:

> maven -Dtestmatch=*DB* test:match

> but in the maven:reactor element I don´t know if it is possible to include the 
> variable 'testmatch'. I browsed the documentation with no success.

> Can anyone provide some help?

> Thanks in advance,

> Javier Ramos

-- 
mailto:[EMAIL PROTECTED]



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

Re: Is it possible to keep unit tests in the same directories as production classes?

2003-12-09 Thread Jeffrey D. Brekke

> On Tue, 09 Dec 2003 08:23:27 -0500, Jason van Zyl <[EMAIL PROTECTED]> said:

[Jason's clear and correct description clipped]

> But I am curious: name one single advantage to putting test and
> application sources together. Basically the arguments for it have
> been "I want to do it so I should be able to" which is not likely to
> be taken seriously around here.

The only one I have ever heard was something along the lines that it
is easier to see the test code filenames next to the production code
filenames in a listing in your editor/ide.

IDE's provide a way to quickly find or list test code, and in emacs I
just change src/java to src/test/java ( and vice-versa ) in the path
when opening another file.

-- 
=
Jeffrey D. Brekke   [EMAIL PROTECTED]
Wisconsin,  USA [EMAIL PROTECTED]
[EMAIL PROTECTED]


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

RE: Is it possible to keep unit tests in the same directories as production classes?

On Tue, 2003-12-09 at 06:38, Kevin Pearcey wrote:
> If we take a step back from the best practice of what source files to put
> where this all fits into a general re-occurring theme on this mail list
> about maven best practice which the developers really should make a decision
> about and enforce within the maven POM:
> 
> Should the POM allow complex filepath/fileset definitions or not?
> 
> If the syntax of the POM is defined such that a file set can contain
> selection rules with one or more file paths then any plugin that doesn't
> handle this is broken and should get fixed. If the driving goal of maven
> best practice is that source should be grouped under separate directories
> then re-write the POM rules to only allow this simple definition - NO
> special cases.
> 
> Thoughts?

Eventually that's what we would like to strive for: one clear way of
doing things but it is unlikely we can arrive at that by design. In the
case of tests specific includes or excludes are allowed and though in
most cases we could probably avoid them entirely it's something that
could be moved toward.

For example, if over time there were tools provided by Maven to name all
test cases in a stanard, clear and descriptive way then we could
probably get away with just specifying a directory but consistent naming
in tests is not something we currently have.

Many of things Maven currently does that seem off are most often a
direct result of one of the core developers trying to do something, for
better or worse. For example the addition of sourceModifications were
added when I tried to build commons-logging which has a JDK1.4 adapter
which must be excluded when building with JDK1.3.

I personally would like to make many more restrictions on what's
possible but I think this will only be an option as Maven comes into
more widespread use and people making comments like yourself who see
some value in simplying the whole process by limiting some options.

> Kevin Pearcey
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

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

RE: Is it possible to keep unit tests in the same directories as production classes?