Jar:deploy and ssh password

When I run jar:deploy it gets to: jar:jar: [echo] Moving target/sx.util-1.1.3.jar to the . And hangs. >From looking at the plug-in code (and a few error messages due to incorrect property settings) I know it calls "ssh" at this stage. Now, if I run the specific command from the

RE: Keeping your test source code in a separate, but parallel source tree

> So, back to my question. Why is this a best practice? Maybe > it's a common > practices, possibly a standard practiced, but no one has yet > convinced me > it's best practice. FWIW, I like the separate package hierarchy because it keeps the "regular" code packages less cluttered. I feel like

what's maven-new?

Hello, All! Have heard the codename "maven-new" several times. Ibiblio has such seciton in repository. What is it? A separate project? Part of this project? - Anton P.S. Sorry for the silly question. I'm really at a loss :) -

Re: Keeping your test source code in a separate, but parallelsource tree

On Sat, 2003-07-12 at 14:43, Bill Lynch wrote: > I agree - I prefer to manage 2 separate directories and I think it's easier to > understand projects if they're structured that way. But, I do think you're right > - it'd be great if Maven could handle either approach. Well, I don't think it woul

Re: Keeping your test source code in a separate, but parallelsource tree

On Sat, 2003-07-12 at 20:02, Dave Ford wrote: > So, back to my question. Why is this a best practice? It's what we have chosen for reasons I mentioned in my previous email and we've embodied those choices in the test plugin. > Maybe it's a common > practices, possibly a standard practiced, but

Re: Keeping your test source code in a separate, but parallel source tree

> The advantage I see is that you get to have test code that has > package-level access Actually, you get that by placing them in the same directory also. So that's not really an advantage. > and because it's in a separate tree, it's easy to > build binaries that don't include all the test code...

Re[2]: Multiple source module to build one deployment unit in one step.. .

Err.. I have forgotten the last stroke to CVSROOT/modules. Now the full set of directives looks like fake11 -d fake/sub1 pr1/sub1 subsub11 subsub12 fake12 -d fake/sub2/subsub21 pr1/sub2/subsub21 \ subsubsub211 \ subsubsub212 \ subsubsub213 fake2 -d fake/sub3 pr2/sub3 fake -a fake11 fa

Re: Multiple source module to build one deployment unit in one step.. .

Hello Sebastien! BS> I know it looks like a strange question, but i just want to make sure maven BS> isn't designed for this kind of behaviour (in maven, one deployment unit is BS> one cvs module, and eventually other deployment units delared via BS> dependencies, isn't it ?)... You can probably

J2EE project : EAR/WAR/JAR - web site generation

I have a J2EE project, and currently have things under one Maven project. I have been building with Ant, but want to swap to Maven for more than just project management and site generation. Reading of various articles suggests that I split the current project as follows Top level project - dep

Problems with xref and linkcheck

Hi, I am using beta-9-SNAPSHOT and have just used the linkcheck to good effect - thanks. The results can be seen at http://maven.melati.org/linkcheck.html, (any comments welcome) the remaining problems seem to be xref generated: 1. If code contains then xref creates

Re: Keeping your test source code in a separate, but parallel sourcetree

Brendan, I do exactly as Dave Ford does - I keep my unit test classes in the same packages as the production code under test. I find it good for the same reasons as Dave outlines, and separating them at delivery time using ant in a fileset is very very simple (once you stick to a consistent namin

RE: Keeping your test source code in a separate, but parallelsource tree

On Sat, 2003-07-12 at 13:57, Brendan Lawlor wrote: > I do exactly as Dave Ford does - I keep my unit test classes in the same > packages as the production code under test. I find it good for the same > reasons as Dave outlines, and separating them at delivery time using ant > in a fileset is very

RE: Keeping your test source code in a separate, but parallel source tree

I do exactly as Dave Ford does - I keep my unit test classes in the same packages as the production code under test. I find it good for the same reasons as Dave outlines, and separating them at delivery time using ant in a fileset is very very simple (once you stick to a consistent naming conventi

Re: Keeping your test source code in a separate, but parallel source tree

On Saturday, July 12, 2003, at 12:20 PM, Dave Ford wrote: The Maven web site lists "Keeping your test source code in a separate, but parallel source tree" as best practices. Q1: Why is this a best practice? It just seems like an extra thing to maintain to me, making package name refactoring for

Re: Keeping your test source code in a separate, but parallelsource tree

On Sat, 2003-07-12 at 12:20, Dave Ford wrote: > The Maven web site lists "Keeping your test source code in a separate, but > parallel source tree" as best practices. > > Q1: Why is this a best practice? It just seems like an extra thing to > maintain to me, making package name refactoring for trou

Keeping your test source code in a separate, but parallel source tree

The Maven web site lists "Keeping your test source code in a separate, but parallel source tree" as best practices. Q1: Why is this a best practice? It just seems like an extra thing to maintain to me, making package name refactoring for troublesome. I've been placing my test class next to the tes