RE: artifact deployment / ssh / plink
I don't think it can be done (at least I could not find out how). What I did was to
set up a public/private key between my machine and the deployment box (using puttygen)
and then using pageant (another putty tool).
Works like a champ...
-Original Message-
From: Nathan Coast [mailto:[EMAIL PROTECTED]
Sent: Friday, January 23, 2004 9:05 AM
To: Maven Users
Subject: artifact deployment / ssh / plink
Hi,
I'm trying to use the artifact plugin to deploy to my repo. from the
artifact plugin.
ant:exec dir=. executable=${commander}
ant:arg line=-l ${username} ${siteAddress}
'${assureDirectoryCommand} ${resolvedDirectory}'/
/ant:exec
When I run the deploy:artifact tag from maven it hangs. I grabbed the
command line by using maven -X. When I executed the command line by
hand it prompted for a password after which it then continued and
completed the mkdir task. I'm using plink (putty command line) anyone
know how I input the password when executing the artifcat tag from
within maven?
cheers
Nathan
-
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: artifact deployment / ssh / plink
Here a link to a pretty good resource on sourceforge about setting this sort of thing
up. Of course some of the steps are very specific to their environment...
http://sourceforge.net/docman/display_doc.php?docid=766group_id=1#sshkeygen
-Original Message-
From: Nathan Coast [mailto:[EMAIL PROTECTED]
Sent: Friday, January 23, 2004 9:13 AM
To: Maven Users List
Subject: Re: artifact deployment / ssh / plink
thanks, I'll give it a go
Ebersole, Steven wrote:
I don't think it can be done (at least I could not find out how). What I did was to
set up a public/private key between my machine and the deployment box (using
puttygen) and then using pageant (another putty tool).
Works like a champ...
-Original Message-
From: Nathan Coast [mailto:[EMAIL PROTECTED]
Sent: Friday, January 23, 2004 9:05 AM
To: Maven Users
Subject: artifact deployment / ssh / plink
Hi,
I'm trying to use the artifact plugin to deploy to my repo. from the
artifact plugin.
ant:exec dir=. executable=${commander}
ant:arg line=-l ${username} ${siteAddress}
'${assureDirectoryCommand} ${resolvedDirectory}'/
/ant:exec
When I run the deploy:artifact tag from maven it hangs. I grabbed the
command line by using maven -X. When I executed the command line by
hand it prompted for a password after which it then continued and
completed the mkdir task. I'm using plink (putty command line) anyone
know how I input the password when executing the artifcat tag from
within maven?
cheers
Nathan
-
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]
dependencies of dependencies
Just wondering if there is a way through maven to better manage the dependencies of my project's dependencies. For example, say I have a project whose deliverable/artifact is a war and further say I have utilized the propertieswar.bundletrue/war.bundle/properties on any number of the dependencies I have defined for that project. If those dependencies in turn have dependencies (especially of the run-time variety) it would be nice for the war plugin to pull those extended dependencies in along with the explicit dependencies. As it is, I instead have to manually add dependency definitions to my project for those extended dependencies. Is there a way to get maven to pull in those extended dependencies automagically during build? Just curious... Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies of dependencies
Unless I completely missed something, you are still managing these manually; you've just moved dealing with it from the project file to a pre-goal. What I was thinking of was: 1) war plugin starts to bundle, say hibernate's jar into the webapp because I specified it as a runtime library; 2) war plugin determines that hibernate, itself, has a number of runtime dependencies and bundles those (possible retreiving from repo) into the webapp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 12:49 PM To: [EMAIL PROTECTED] Subject: RE: dependencies of dependencies FYI, check out old archive messages referring to transitive dependencies. -john -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 1:49 PM To: Maven Users List Subject: dependencies of dependencies Just wondering if there is a way through maven to better manage the dependencies of my project's dependencies. For example, say I have a project whose deliverable/artifact is a war and further say I have utilized the propertieswar.bundletrue/war.bundle/properties on any number of the dependencies I have defined for that project. If those dependencies in turn have dependencies (especially of the run-time variety) it would be nice for the war plugin to pull those extended dependencies in along with the explicit dependencies. As it is, I instead have to manually add dependency definitions to my project for those extended dependencies. Is there a way to get maven to pull in those extended dependencies automagically during build? Just curious... Thanks, Steve - 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: including resources into target/classes
... In a way which keeps the package structure in which the resource was found intact... -Original Message- From: Ebersole, Steven Sent: Tuesday, January 20, 2004 9:13 AM To: Maven Users List Subject: including resources into target/classes I am trying to build a hibernate-backed app using maven, but noticed that the hibernate mapping files are not pulled over into the target/classes directory. How is this typically acheived using maven? - 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]
javadoc plugin
whenever I run the maven javadoc plugin, it does not generate any package information (package-list is blank and package-summary is missing). Any ideas what I am missing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven.username question
What is the explicit purpose of the maven.username property? Initially I had setup such that maven.username was a generic user for our development team on the machine serving as our internal remote repository and project web server. So that worked fine for all the deploy goals pushing out to that server. Then I started to think that it would be better to set up maven.username to be the developer's specific username (which is there NT userid, cvs username, unix account name, etc...). The problem I ran into with this, however, was on attempting to deploy the project website using site:deploy. The issue had to do with the fact that different users were now owners (it was actually the chmod command which failed). How does everyone usually handle this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
single artifact mantra and ejb projects
I have a question about the mantra that a single project should produce a single artifact. I can buy into that in every case I have run across or have thought about, except for projects involving ejb creation. Typically an ejb project will produce both an ejb-jar file as well as a client-jar file. But wouldn't that be two artifacts? I have read a lot of external docs on setting up j2ee projects using maven, most of which suggest a multi project layout. I can totally justify that for say a j2ee project producing an ear made up of sub ejb-jars and wars. But in the case of a stand-alone ejb-jar producing project or an ejb-jar producing subproject of an ear project it seems like overkill to define a subproject for the ejb-jar generation and the client-jar generation, especially when both are ultimately logically tied to the attainment of an ejb goal. Could someone help me out in my understanding here? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven jelly tag and build.properties properties
How is it possible to reference a property defined in one of the maven properties
files (specifically the ~/build.properties) in one of the maven jelly tags? The tag I
am trying to use is maven:makeRelativePath/. What I have tried so far is:
1) maven:makeRelativePath var=testDest basedir=${basedir}
path=${maven.test.dest} separator=/ /
2) maven:makeRelativePath var=testDest basedir=${basedir}
path=${context.getVariable('maven.test.dest')} separator=/ /
Plus some other off the wall stuff. But I could not get anything I tried to work. I
keep getting maven:makeRelativePath You must define an attribute called 'path' for
this tag error message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven jelly tag and build.properties properties
Same error message. Tried using a bunch of different plugin contexts (test, java,
idea)...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 1:43 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
How is it possible to reference a property defined in one of the maven properties
files (specifically the ~/build.properties) in one of the maven jelly tags? The tag
I am trying to use is maven:makeRelativePath/. What I have tried so far is:
1) maven:makeRelativePath var=testDest basedir=${basedir}
path=${maven.test.dest} separator=/ /
2) maven:makeRelativePath var=testDest basedir=${basedir}
path=${context.getVariable('maven.test.dest')} separator=/ /
what if you try
path='${pom.getPluginContext(maven-test-plugin).getVariable(maven.test.dest)}'
?
-- gd
-
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 jelly tag and build.properties properties
but this works for me even without the namespacing:
ant:echm.t.d = ${maven.test.dest}/ant:echo
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 2:51 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
Same error message. Tried using a bunch of different plugin contexts (test, java,
idea)...
do you import the test context by declaring the 'test' namespace ?
this works for me :
ant:echo xmlns:mytest=testm.t.d =
${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}/ant:echo
-- gd
-
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 jelly tag and build.properties properties
actually, my bad. it does not work. it is maven.build.dest that works, not
maven.test.dest
so what I have:
j:set var=outputMode value=${maven.idea.output.mode} /
j:set var=srcDestProp value=${maven.build.dest}/
j:set var=testDestProp value=${maven.test.dest}/
j:choose
j:when test=${outputMode=='single'}
option name=OUTPUT_MODE value=single/
option name=DEFAULT_OUTPUT_PATH value=$PROJECT_DIR$/bin/
/j:when
j:when test=${outputMode=='multiple'}
option name=OUTPUT_MODE value=multiple/
sourceToOutputPathMap
j:if test=${sourcesPresent}
maven:makeRelativePath var=srcDir basedir=${basedir}
path=${pom.build.sourceDirectory} separator=/ /
maven:makeRelativePath var=srcDest basedir=${basedir}
path=${srcDestProp} separator=/ /
j:set var=DEF_OUTPUT value=${srcDest}/
mapEntry sourcePath=$$PROJECT_DIR$$/${srcDir}
outputPath=$$PROJECT_DIR$$/${srcDest} /
/j:if
j:if test=${unitTestSourcesPresent}
maven:makeRelativePath var=testDir basedir=${basedir}
path=${pom.build.unitTestSourceDirectory} separator=/ /
maven:makeRelativePath var=testDest basedir=${basedir}
path=${testDestProp} separator=/ /
j:set var=DEF_OUTPUT value=${testDest}/
mapEntry sourcePath=$$PROJECT_DIR$$/${srcDir}
outputPath=$$PROJECT_DIR$$/${testDest} /
/j:if
/sourceToOutputPathMap
option name=DEFAULT_OUTPUT_PATH
value=$$PROJECT_DIR$$/${DEF_OUTPUT} /
/j:when
j:otherwise
option name=DEFAULT_OUTPUT_PATH value=/
option name=OUTPUT_MODE value=single/
/j:otherwise
/j:choose
does not work because j:set var=testDestProp value=${maven.test.dest}/, sets
testDestProp equal to .
I also tried: j:set xmlns:mytest=test var=testDestProp
value=${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}/
to no avail.
Any thoughts? No idea why maven.build.dest would work, but not maven.test.dest...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 3:11 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
but this works for me even without the namespacing:
ant:echm.t.d = ${maven.test.dest}/ant:echo
uh ! right.. it works when it is defined in the properties file.. i
forgot your original question.. my bad
-- gd
-
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 jelly tag and build.properties properties
Thanks for the help. What I did was to simply (re?)define it in the specific
plugin.properties file to be its defined default using
maven.test.dest=${maven.build.dir}/test-classes, and everything started working.
Woohoo...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 4:56 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
actually, my bad. it does not work. it is maven.build.dest that works, not
maven.test.dest
heres my understanding of it, i may be wrong - correct me if am :
maven.build.dest should always be available (core behavorial property),
maven.test.dest is being made available by the test plugin,
so to look it up we have to use the context of the test plugin..
however, if specified in build.properties, this late property becomes
always available. the few tests ive just made tend to confirm it (using
both ${maven.test.dest} and ${pom.getPluginContext...) and
j:set xmlns:mytest=test var=testDestProp
value=${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}/
does work just fine for me, returning the expected result.
-- gd
-
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 jelly tag and build.properties properties
Not sure if any of the developers of the idea plugin are around here, but I basically
modified my plugin locally because it was not fully defining the intellij project
files for me correctly. This change was specifically to the v3 resources.
Specifically, it was not:
1) setting up any compiler output path(s) at all;
2) correctly setting up cvs support
My local version defines one new property (maven.idea.output.mode=single/multiple).
Depending on the value set, project.jelly appropriately sets the intellij OUTPUT_MODE
abd DEFAULT_OUTPUT_PATH properties, and possibly the sourceToOutputPathMap element.
Also made changes to workspace.jelly to get cvs support working after plugin execution.
If you're interested in the source or patch, let me know...
-Original Message-
From: Ebersole, Steven
Sent: Wednesday, January 14, 2004 5:30 PM
To: Maven Users List
Subject: RE: maven jelly tag and build.properties properties
Thanks for the help. What I did was to simply (re?)define it in the specific
plugin.properties file to be its defined default using
maven.test.dest=${maven.build.dir}/test-classes, and everything started working.
Woohoo...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 4:56 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
actually, my bad. it does not work. it is maven.build.dest that works, not
maven.test.dest
heres my understanding of it, i may be wrong - correct me if am :
maven.build.dest should always be available (core behavorial property),
maven.test.dest is being made available by the test plugin,
so to look it up we have to use the context of the test plugin..
however, if specified in build.properties, this late property becomes
always available. the few tests ive just made tend to confirm it (using
both ${maven.test.dest} and ${pom.getPluginContext...) and
j:set xmlns:mytest=test var=testDestProp
value=${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}/
does work just fine for me, returning the expected result.
-- gd
-
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]
deploy goals
Is it possible to use Maven's deploy goals against a server using simple password authentication without the server password challenge hanging the build? If so, I have been unable to find docs on how to acheive that and was hoping someone could point me towards those docs. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven and java version
The majority of our projects utilize java 1.3.x, however we have begun migrating some over to 1.4.x. Is there a way I can specify this distinction to maven (something like maven.java.home) per-project? Or is setting JAVA_HOME prior to running the maven command the only way?
