Re: Is there any reason we have to resolve dependencies all the time?

[EMAIL PROTECTED] wrote: Yes, resolving dependencies all the time is a PITA. What's your suggested alternative? Do plugins declare whether they need the dependencies? Some other method of us guessing? Lazy evaluation I guess. Checking dependencies could be delayed until the moment

Torque bug

Playing around with the torque plugin. When attempting $maven torque:om-zip I get INTERNAL ERROR Reference made to goal 'check-om-zip' which has no definition. comments? - To unsubscribe, e-mail: [EMAIL

Re: Is there any reason we have to resolve dependencies all the time?

And there's the rub. That happens in the plugin manager up front -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Rafal Krzewski [EMAIL PROTECTED] wrote on 08/09/2003 08:33:17 PM: [EMAIL PROTECTED] wrote: Yes, resolving dependencies all the time is

Re: Torque bug

I fixed it in cvs. Prereqs of torque:om-zip was incorrect. Correct value is torque:check-om-zip instead of check-om-zip Emmanuel - Original Message - From: khote [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Sent: Monday, September 08, 2003 11:13 AM Subject: Torque bug

Re: Torque bug

guess I should have seen that myself, I did look in the plugin.jelly Thanks, Kevin - Original Message - From: Emmanuel Venisse [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED]; khote [EMAIL PROTECTED] Sent: Monday, September 08, 2003 2:29 AM Subject: Re: Torque bug I fixed

Re: How to output a jar element within maven.xml

Shouldn't this go in the Jelly docs, as it's not a feature of Maven per se. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Paul Libbrecht [EMAIL PROTECTED] wrote on 08/09/2003 09:05:21 PM: Cool, that's exactly what I was missing. Please then add

Re: How to output a jar element within maven.xml

Good point if indeed the ant plugin does this but I feel it should not as it is not a problem in jelly, the blank-namespace (note, this is different than the default-namespace) is not pre-registred as it is in Maven. Actually I'm still not clear about the ant tag-library role in there... for

RE: Is there any reason we have to resolve dependencies all the t ime?

[EMAIL PROTECTED] wrote: Yes, resolving dependencies all the time is a PITA. What's your suggested alternative? My understanding is that the problem is that the plugin manager resolves dependencies long before any goal is executed. If that's true, I suggest the following: 1) If the

Re: Is there any reason we have to resolve dependencies all the t ime?

Laird Nelson wrote: Andy Jefferson wrote: You could take it further and think of the whole issue of dependencies and the fact that there are basically 3 'types' ... build, test, and runtime. Or: each plugin has dependencies, and the java:compile one fills its dependency list from the POM,

Re: Is there any reason we have to resolve dependencies all the time?

[EMAIL PROTECTED] wrote: Yes, resolving dependencies all the time is a PITA. What's your suggested alternative? Do plugins declare whether they need the dependencies? Some other method of us guessing? If the project dependencies list had a clue as to which type of dependency they are, then they

Re: Maven and XDoclet templates (repost with clarification)

Konstantin Priblouda wrote: It depends whether you use plugin goals or set up ant targets in maven.xml If you use xdoclet:webdoclet then you can specify properties in project.properties / build.properties like: maven.xdoclet.webdoclet.jsptaglib.0=false So, how should the property be named in

RE: Is there any reason we have to resolve dependencies all the t ime?

Either way, the project specific dependencies would not need to be resolved until the proper plugin needed them. The **:compile plugins would grab the build dependencies plus whatever else it needed (like test dependencies for the test:compile). There may be plugins that fit into more than

Re: Maven and XDoclet templates (repost with clarification)

--- Ciaran Treanor [EMAIL PROTECTED] wrote: Konstantin Priblouda wrote: It depends whether you use plugin goals or set up ant targets in maven.xml If you use xdoclet:webdoclet then you can specify properties in project.properties / build.properties like:

RE: How to create xdoc xml?

In addition to all the other recommendations, if you are developing a plug-in, the plug-in plug-in (see http://maven.apache.org/reference/plugins/plugin/) is useful. Sri -Original Message- From: Harden ZHU [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 8:30 PM To: [EMAIL

Re: Is there any reason we have to resolve dependencies all the t ime?

On Mon, 2003-09-08 at 09:33, Berin Loritsch wrote: Laird Nelson wrote: Andy Jefferson wrote: You could take it further and think of the whole issue of dependencies and the fact that there are basically 3 'types' ... build, test, and runtime. Or: each plugin has dependencies,

Re: Is there any reason we have to resolve dependencies all the t ime?

Berin Loritsch wrote: Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Yes, that's my point. We're in agreement. Laird

Re: Is there any reason we have to resolve dependencies all the t ime?

Laird Nelson wrote: Berin Loritsch wrote: Right. However as long as we can merge the dependencies at the proper time, we could fix the blind loading and resolving of all dependencies until we really need them. Yes, that's my point. We're in agreement. :) It appears that there is a post 1.0

weblogic plugin

Hi, Does anyone have a weblogic plugin for weblogic 8.1? The weblogic tasks I'm looking for are things like the ejbgen tasks and jsp / ejb validation and compilation? Thanks Nathan - To unsubscribe, e-mail: [EMAIL

Re: weblogic plugin

I've found these plugins mentioned http://www.nordija.dk/opencms/download/maven-weblogic-plugin-src.zip seems to be concered with starting / stoping server and deployment http://www.casadeslug.com/mavenmods/docs/ seems to be concered with starting / stoping server and deployment (can't find

Re: Multiproject Problem

Your 'MASTER' project included in the list of reactored projects and shouldn't be. Could you try upgrading to the released multiproject? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Bateman, Patrick eMEDIA [EMAIL PROTECTED] wrote on 08/09/2003

Re: Is there any reason we have to resolve dependencies all the t ime?

Cool. Got a patch? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Laird Nelson [EMAIL PROTECTED] wrote on 09/09/2003 01:46:09 AM: Berin Loritsch wrote: Right. However as long as we can merge the dependencies at the proper time, we could fix the

Re: Is there any reason we have to resolve dependencies all the time?

How many different depTypes do you see. From what you've described before, it looks like almost one per plugin. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ news [EMAIL PROTECTED] wrote on 08/09/2003 11:41:30 PM: [EMAIL PROTECTED] wrote: Yes,

RE: Is there any reason we have to resolve dependencies all the t ime?

And for things like creating the dependency classpath? Where Ant removes non-existent files and paths? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Lester Ward [EMAIL PROTECTED] wrote on 08/09/2003 11:17:58 PM: [EMAIL PROTECTED] wrote: Yes,

Re: Only one way to have same build reqs?

See MAVEN-463. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ news [EMAIL PROTECTED] wrote on 09/09/2003 03:37:01 AM: When I originally started setting up my build environment, it seems that the only maven.xml or projects.properties files that are ever