RE: Maven 1.1-beta3 maven-artifact-plugin 1.8
Well, I was about to... But when I reproduced it, I thought I'd dig a bit to see what might be wrong. I started by changing the NullKnownHostProvider by a FileKnownHostProvider which would validate my provider, then replaced the cached class files with the newly compiled ones. It worked fine... Then I reverted to NullKnownHostProvider, but it still worked fine!!! So, to recap, installing maven-artifact-plugin 1.8 as-is fails with host rejected error. Replacing its class files with the locally compiled trunk version fixes my problem. What changed between 1.8 and trunk? Seems to be the right thing, at least for me... ;-) And is there a 1.9-SNAPSHOT available somewhere? Steve On Thu, 2006-10-08 at 08:01 -0500, Jeff Jensen wrote: Hi Steve, Would you mind adding your details on the deploy error with m1.1b3 to this JIRA, please? http://jira.codehaus.org/browse/MPARTIFACT-71 On 8/9/06, Steve Molloy [EMAIL PROTECTED] wrote: Thanks, I guess I'll stick with 1.0.2 until the next release, hoping this issue will be fixed. Is there any ETA set for the next 1.1 release yet? Steve On Wed, 2006-09-08 at 08:23 -0500, Jeff Jensen wrote: Hi Steve, Yes, this is an issue I encountered as well. I have found that the 6/30 1.1-beta3-SNAPSHOT does not have this problem, but every release since then does. See 20060630/ here: http://people.apache.org/~aheritier/maven/1.X/snapshots/ We are researching the problem to find a fix. In the meantime, I suggest the 6/30 snapshot if you would like to use 1.1. It is very solid and the current one we use for our production work (we've used nearly every one of those snapshots all along as they were published). -Original Message- From: Steve Molloy [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 7:24 AM To: users@maven.apache.org Subject: Maven 1.1-beta3 maven-artifact-plugin 1.8 Hi, I just upgraded from maven 1.0.2 to 1.1-beta3, and got the maven-artifact-plugin 1.8 along with it. But Now I can't deploy any artifacts because scp refuses my host key, while scpexe just doesn't do anything at all, but doesn't complain... So, I've reverted back to 1.0.2 for now, but are there any plans for fixing these problems? (I'm running maven on JDK 1.5.0_07, on Fedora core 5). 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]
Maven 1.1-beta3 maven-artifact-plugin 1.8
Hi, I just upgraded from maven 1.0.2 to 1.1-beta3, and got the maven-artifact-plugin 1.8 along with it. But Now I can't deploy any artifacts because scp refuses my host key, while scpexe just doesn't do anything at all, but doesn't complain... So, I've reverted back to 1.0.2 for now, but are there any plans for fixing these problems? (I'm running maven on JDK 1.5.0_07, on Fedora core 5). Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 1.1-beta3 maven-artifact-plugin 1.8
Thanks, I guess I'll stick with 1.0.2 until the next release, hoping this issue will be fixed. Is there any ETA set for the next 1.1 release yet? Steve On Wed, 2006-09-08 at 08:23 -0500, Jeff Jensen wrote: Hi Steve, Yes, this is an issue I encountered as well. I have found that the 6/30 1.1-beta3-SNAPSHOT does not have this problem, but every release since then does. See 20060630/ here: http://people.apache.org/~aheritier/maven/1.X/snapshots/ We are researching the problem to find a fix. In the meantime, I suggest the 6/30 snapshot if you would like to use 1.1. It is very solid and the current one we use for our production work (we've used nearly every one of those snapshots all along as they were published). -Original Message- From: Steve Molloy [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 7:24 AM To: users@maven.apache.org Subject: Maven 1.1-beta3 maven-artifact-plugin 1.8 Hi, I just upgraded from maven 1.0.2 to 1.1-beta3, and got the maven-artifact-plugin 1.8 along with it. But Now I can't deploy any artifacts because scp refuses my host key, while scpexe just doesn't do anything at all, but doesn't complain... So, I've reverted back to 1.0.2 for now, but are there any plans for fixing these problems? (I'm running maven on JDK 1.5.0_07, on Fedora core 5). 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: Maven 1.1-beta3 maven-artifact-plugin 1.8
(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:180) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:79) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) at org.apache.maven.jelly.tags.werkz.MavenGoalTag $MavenGoalAction.performAction(MavenGoalTag.java:109) at org.apache.maven.werkz.Goal.fire(Goal.java:656) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:694) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:535) at org.apache.maven.cli.App.main(App.java:1318) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Root cause java.lang.NoClassDefFoundError: org/apache/maven/wagon/providers/ssh/AbstractSshWagon at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doDeploy(DefaultArtifactDeployer.java:316) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleDeploy(DefaultArtifactDeployer.java:119) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:90) at org.apache.maven.artifact.deployer.DeployBean.deploy(DeployBean.java:155) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:180) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:79) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:78) at org.apache.maven.jelly.tags.werkz.MavenGoalTag $MavenGoalAction.performAction(MavenGoalTag.java:109) at org.apache.maven.werkz.Goal.fire(Goal.java:656) at org.apache.maven.werkz.Goal.attain(Goal.java:592) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:694) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:535) at org.apache.maven.cli.App.main(App.java:1318) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Final Memory : 7M/17M Total time : 27 seconds Finished at : Wednesday, August 9, 2006 10:11:22 EDT AM On Wed, 2006-09-08 at 15:58 +0200, Arnaud HERITIER wrote: Steve, Even if you don't use this snapshot, can you test it to tell us if this one works also for you. We are searching what we changed since this snapshot and the official beta 3 to fix it in the RC1. We are trying to produce the RC1 at the end of the month. If the returns about it are good, we'll release the final 1.1 in september (probably in mid-september). It's why we need to have as many feedback as possible about this beta 3 to have less Release Candidates. Cheers Arnaud On 8/9/06, Steve Molloy [EMAIL PROTECTED] wrote: Thanks, I guess I'll stick with 1.0.2 until the next release, hoping this issue will be fixed. Is there any ETA set for the next 1.1 release yet? Steve On Wed, 2006-09-08 at 08:23 -0500, Jeff
Re: bundle problem
Couldn't you use project inheritance to have A extend B so that whenever B changes, it would be reflected in A. Steve On Fri, 2005-10-06 at 15:03 +, Iktorn wrote: Hi, I'v got following problem with jar libs. my web application (let say A ) depend on other part of the project (B) which have its own dependencies ( C,D.. etc) . But when I try to deploy 'A', subproject libs from B are not deployed to Tomcat and the site doesn't work properly. Is it possible to bundle 'C,D...' libs in B so that Tomcat could use them? (I dont want to add dependencies 'C,D..' to 'A' because when 'B' changes I would have to change also A's project.xml) Thanks in advance Artur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j:if ...
You might want to have a look at the available tag...
http://jakarta.apache.org/commons/jelly/libs/util/tags.html#util:available
Steve
On Wed, 2005-11-05 at 17:36 +0200, Arik Kfir wrote:
Gladly :)
sergiu gordea wrote:
Arik Kfir wrote:
Hi
Try this (the u is from jelly:util namespace):
u:file var=f name=/${my.file.property.name}/myfile.jar//
j:if test=${f.exists()}
...
/j:if
Thanks a lot,
Sergiu
sergiu gordea wrote:
Hi all,
I have a little problem.
We used ant in our project and now we migrated to maven.
I read that the ant unless is replaced with j:if, but it seems
that
tha test attribute must have a boolean value
j:if test=true ...
How can I check in maven if a file exists?
I need to write something like
j:if test=file.exists
ant:copy file=file to=destination
/j:if
Which is the correct syntax? Where can I find more jelly script
examples?
Thanks in advance,
Sergiu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiproject builds orderring
You could also set a dummy dependency between the 2 projects. Even if it's not actually used, it will provide your ordering. I know I used it for multi-level project trees, where I had, for instance, 3 components part of a core project, another 2 part of UI. So even if the UI project didn't actually depend on the core one (neither actually had code, just sub-projects), I had a dependency which ended up deploying an empty jar to our local repository but made sure that UI was always built after core... Steve On Thu, 2005-05-05 at 21:35 -0700, dan tran wrote: I asked for it eh? Any how, I took a look at the code involved, it is deep in ant's DirectoryScanner. Using maven.multiproject.includes is not fit. I settle for some jelly in maven.xml ;-) Thanks for the offer. -D On 5/5/05, Brett Porter [EMAIL PROTECTED] wrote: You can request it :) If you want to provide a patch for 1.1 I'd be happy to apply it. - Brett On 5/6/05, dan tran [EMAIL PROTECTED] wrote: actually, it does not have any orderring. Just the matter of which one shows up first in the directory list ;-) Can I request this feature? I am current using multiproejct plugin (reactor) to run one of my build systems which does not take advantage of maven's dependencies. (sorry, just cant) The orderring can be specified in maven.multiproject.includes. -D On 5/5/05, dan tran [EMAIL PROTECTED] wrote: Thanks Brett, It runs on the reverse alphabetical order ie tree2 got called first ;-) -Dan On 5/5/05, Brett Porter [EMAIL PROTECTED] wrote: currently it is alphabetical. - Brett On 5/6/05, dan tran [EMAIL PROTECTED] wrote: Hello, I have 2 sub trees, both does not depend on each other. root/ tree1/ tree2/ Can I make multiproject to build a specific tree first? -Dan - 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: Two artifacts for one project
Better yet, you should split your code in 2 projects, one for component,
and one for EJB which depends on the first one.
Steve
On Thu, 2005-05-05 at 19:36 +0200, Thomas Van de Velde wrote:
You should call ejb:install and jar:install. artifact:install is a
lower-level goal that should not be used directly.
When you call ejb:install, your ejb will be installed in an ejbs folder.
When you call jar:install, your jar is copied to a jars folder.
You can now use them as a dependency by setting typeejb/type or
typejar/type (The latter can be left out as by default dependencies
resolve to jar.
Thomas
On 5/5/05, Tran, Khiet [EMAIL PROTECTED] wrote:
Hi everyone,
We have a legacy directory structure of components that I want to convert
to
maven. The context I have is that for some components (maven project), a
custom ant-task generates two different jars for it.
root/
|component
project.xml
|target/
|-componentEjb-version.jar
|-component-version.jar
So for installing these into the repository, I am using the
artifact:install
goal with 2 different types: jar ejb, which installs 2 separate jars
into
the local repository. But I cannot retrieve one of the two jar as both
uses
the same pom.
My question is, is it possible for me to specify a different pom then the
current one ${pom} when using the goal artifact:install?
And if I am using the same pom for both artifacts of different types, how
do
I refer to both as dependencies. I've tried it but it does not work.
Thanks, Khiet.
scp vs scpexe
I have a bit of a problem understanding why these 2 (scp and scpexe) behave so differently. I know the scpexe actually calls the command while the other runs from java, but with my setup (Fedora Core 3, jdk 1.5, maven 1.0.2), the scpexe takes a very long time to complete, but works every single time. While the scp executes much faster but gives me sporadic SSH_MSG_DISCONNECT errors, sporadic in the sense that it never occurs at the same place, but still consistent enough to break any build that implies 2-3 artifact deployment. Are those known issues? I can keep things working using scpexe, but I'd really prefer getting the speed of scp... Any suggestions? Thanks, Steve
Re: scp vs scpexe
Wow, the change in sshd_config had no effect (I think Protocol 2,1 is actually default), but turning on nscd seems to have solved my problem... Thanks! Steve On Fri, 2005-22-04 at 11:10 -0400, eblack wrote: It probably has more to do with the authentication method on the server. Our developers recently were experiencing problems with cvs within eclipse, where the ext method worked fine(system command ssh) but not with extssh(eclipse builtin) after our sysadmin changed over to LDAP authentication. The problems were similiar to what you describe. Our system admin turned on nscd(name service cacher) and in the /etc/ssh/sshd_config file on the server, uncommented the line that said Protocol 2,1 since the default for ssh is protocol 2 but Eclipse uses protocol 1. Assuming that Eclipse uses some basic Java ssh/scp api and Maven does the same, the problem may be the same. Hope this helps. Eric On Fri, 2005-04-22 at 10:19 -0400, Maven Users List wrote: I have a bit of a problem understanding why these 2 (scp and scpexe) behave so differently. I know the scpexe actually calls the command while the other runs from java, but with my setup (Fedora Core 3, jdk 1.5, maven 1.0.2), the scpexe takes a very long time to complete, but works every single time. While the scp executes much faster but gives me sporadic SSH_MSG_DISCONNECT errors, sporadic in the sense that it never occurs at the same place, but still consistent enough to break any build that implies 2-3 artifact deployment. Are those known issues? I can keep things working using scpexe, but I'd really prefer getting the speed of scp... Any suggestions? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: seperate src and test directories
You need to add the tests in your POM, see http://maven.apache.org/start/ten-minute-test.html Steve On Fri, 2005-01-04 at 11:03 -0600, Durham David R Jr Contr 805 CSPTS/SCE wrote: I'd like to have normal class sources in: /src /package/SomeClass.java And tests in: /tests /package/SomeClassTest.java But I don't see a way to specify the source attribute for your tests. Is there a way to do this for the 'test' plugin? Thanks, - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven roadmap - should i stay or should i go
Huh... Exactly how much trouble are we talking about to switch custom plugins and such??? Is Jelly replaced? And if so, with what and why? Does it mean all the custom stuff I'm currently implementing will be thrown out if I upgrade to 2.x when it comes out? I'd like my stuff to be in production for more than a couple of months... Steve On Thu, 2005-24-03 at 19:05 +1100, Brett Porter wrote: Vincent has pretty well summed it up. I will try to clarify the document. Though the basic concepts are the same, Maven 2.x is really quite different, and it will require some work to move a project over to it. How much depends on how heavily you customise your Maven 1.x project - if you stick to the defaults and don't use Jelly, then it should be quite simple. Maven 1.x will still be developed until Maven 2.x is production ready (which is not going to be until later this year). - Brett On Thu, 24 Mar 2005 08:44:12 +0100, Vincent Massol [EMAIL PROTECTED] wrote: Hi Sejo, I'd personally go ahead with Maven 1.0.2. There should be a Maven 1.1 version before this summer too with several components from Maven2 backported. I believe the Maven2 team will make it as easy as possible for existing Maven users to switch to Maven2. Most of the Maven1 concepts will stay but will be implemented differently (new POM version for example). I'll let the Maven2 team comment further on details. -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: jeudi 24 mars 2005 08:22 To: Maven Users List Subject: maven roadmap - should i stay or should i go Hi all, In a project I am currently working on - which is just about to start with the construction phase - we are considering to use maven. I have been encountering maven in previous projects as well and based on these experiences i was quite sure I will use it on many others as well. However when i see the new roadmap description on maven site : Maven 2.0 is a complete rewrite. It will not be backwards compatible with any of the Maven 1.x releases, i am having doubts on what exactly should we do right now. To take off with the current release (1.0.2) and wait for a complete rewrite of our build scripts? How complete will that rewrite actually have to be? All what the explanation in the roadmap leaves us with is a bit of hope that attempts will be made to stay backward compatible in the new 2.0 release. What about the conceptual approach, how many things can we expect to be different, new or completely dissapear (multiproject, repository, ...goals)? Could someone point me to a document/person that can give a bit more of vision/explanation concerning these issues? What would you suggest to a project that is just about to jump into maven? Thanks. -Sejo - 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 roadmap - should i stay or should i go
OK, that is usually simple stuff anyway. Thanks for the relief... Steve On Thu, 2005-24-03 at 14:47 +0100, Nicolas Chalumeau wrote: All old plugin in jelly will be suported. As far I know the trouble will be with all the goal you have in your maven.xml as (I am maybe wrong) this file not be use in M2 Nicolas On Thu, 24 Mar 2005 08:39:49 -0500, Steve Molloy [EMAIL PROTECTED] wrote: Huh... Exactly how much trouble are we talking about to switch custom plugins and such??? Is Jelly replaced? And if so, with what and why? Does it mean all the custom stuff I'm currently implementing will be thrown out if I upgrade to 2.x when it comes out? I'd like my stuff to be in production for more than a couple of months... Steve On Thu, 2005-24-03 at 19:05 +1100, Brett Porter wrote: Vincent has pretty well summed it up. I will try to clarify the document. Though the basic concepts are the same, Maven 2.x is really quite different, and it will require some work to move a project over to it. How much depends on how heavily you customise your Maven 1.x project - if you stick to the defaults and don't use Jelly, then it should be quite simple. Maven 1.x will still be developed until Maven 2.x is production ready (which is not going to be until later this year). - Brett On Thu, 24 Mar 2005 08:44:12 +0100, Vincent Massol [EMAIL PROTECTED] wrote: Hi Sejo, I'd personally go ahead with Maven 1.0.2. There should be a Maven 1.1 version before this summer too with several components from Maven2 backported. I believe the Maven2 team will make it as easy as possible for existing Maven users to switch to Maven2. Most of the Maven1 concepts will stay but will be implemented differently (new POM version for example). I'll let the Maven2 team comment further on details. -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: jeudi 24 mars 2005 08:22 To: Maven Users List Subject: maven roadmap - should i stay or should i go Hi all, In a project I am currently working on - which is just about to start with the construction phase - we are considering to use maven. I have been encountering maven in previous projects as well and based on these experiences i was quite sure I will use it on many others as well. However when i see the new roadmap description on maven site : Maven 2.0 is a complete rewrite. It will not be backwards compatible with any of the Maven 1.x releases, i am having doubts on what exactly should we do right now. To take off with the current release (1.0.2) and wait for a complete rewrite of our build scripts? How complete will that rewrite actually have to be? All what the explanation in the roadmap leaves us with is a bit of hope that attempts will be made to stay backward compatible in the new 2.0 release. What about the conceptual approach, how many things can we expect to be different, new or completely dissapear (multiproject, repository, ...goals)? Could someone point me to a document/person that can give a bit more of vision/explanation concerning these issues? What would you suggest to a project that is just about to jump into maven? Thanks. -Sejo - 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]
Args in goals
Hi,
Does anyone know if there are plans to allow passing arguments when calling goals? For instance, I have to run the same goal for each item in a list. It would be nice to be able to pass the item as argument and get some result back, similar to a jelly invoke call... Something like:
j:forEach var=curItem items=${myList}
attainGoal name=myGoal var=theResult
arg type=java.lang.Object value=${curItem}/
/attainGoal
echoCurrent item: ${theResult}/echo
/j:forEach
...
goal name=myGoal returns=java.lang.String
param type=java.lang.Object name=theItem/
j:invoke on=theItem method=toString var=return/
/goal
But more useful...
Thanks,
Steve
RE: Maven systemscope
Try this:
j:set var=test value=true/
echoShould work/echo
j:if test=${test}
echoTest is true.../echo
/j:if
j:set var=test value=false/
echoShould not.../echo
j:if test=${test}
echoTest is true.../echo
/j:if
echoDone.../echo
You'll get:
[echo] Should work
[echo] Test is true...
[echo] Should not...
[echo] Done...
Steve
On Fri, 2005-11-03 at 16:38 +0100, Deblauwe, Wim wrote:
nope, it does not print any of the possibilities in that case. The brackets
needs to be around the testcase.
If you have this:
j:if test=${passvar == 'true'}
echopassvar was true/echo
/j:if
and you type: maven -Dpassvar=true test-test
then passvar was true is printed out.
If you use:
j:if test=${passvar} == 'true'
echopassvar was true/echo
/j:if
Then nothing is printed out.
So, guess I still got a problem :(
BTW: Is there somewhere a good tutorial on jelly? I already searched the
offical site, but I found it very lacking.
regards,
Wim
-Original Message-
From: Marc-Andre Blain [mailto:[EMAIL PROTECTED]
Sent: vrijdag 11 maart 2005 16:32
To: Maven Users List
Subject: RE: Maven systemscope
Maybe you should try the following:
j:if test=${testing.var} == 'true'
echo${testing.var} is true/echo
/j:if
j:if test=${testing.var} != 'true'
echo'${testing.var}' is not true/echo
/j:if
The brackets should delimit your variable, not the test case
regards,
Marc-Andre
-Original Message-
From: Deblauwe, Wim [mailto:[EMAIL PROTECTED]
Sent: Friday, March 11, 2005 10:28 AM
To: 'Maven Users List'
Subject: RE: Maven systemscope
thank you for your time, but I still got a last question on checking the
variable. Consider this:
goal name=test-test
echo${systemScope.setProperty(${pom.groupId}.${pom.artifactId}.buildstart
ed,'true')}/echo
echo${pom.groupId}/echo
echo${pom.artifactId}/echo
echo${pom.groupId}.${pom.artifactId}.buildstarted/echo
echosystemScope[${pom.groupId}.${pom.artifactId}.buildstarted] =
${systemScope[${pom.groupId}.${pom.artifactId}.buildstarted]}/echo
j:set var=testing.var
value='${systemScope[${pom.groupId}.${pom.artifactId}.buildstarted]}'/
echo${testing.var}/echo
j:if test=${testing.var == 'true'}
echo${testing.var} is true/echo
/j:if
j:if test=${testing.var != 'true'}
echo'${testing.var}' is not true/echo
/j:if
/goal
This is the output I get:
test-test:
[echo]
[echo] multiproject-root
[echo] multiproject-root-project
[echo] multiproject-root.multiproject-root-project.buildstarted
[echo]
systemScope[multiproject-root.multiproject-root-project.buildstarted] =
true
[echo] true
[echo] 'true' is not true
Why is true not true??
regards,
Wim
-Original Message-
From: Marc-Andre Blain [mailto:[EMAIL PROTECTED]
Sent: donderdag 10 maart 2005 15:43
To: Maven Users List
Subject: RE: Maven systemscope
I tried the following and it returns me 'true'
goal name=test-test
echo${systemScope.setProperty(${pom.groupId}.${pom.artifactId}.buildstart
ed,'true')}/echo
echo${pom.groupId}/echo
echo${pom.artifactId}/echo
echo${pom.groupId}.${pom.artifactId}.buildstarted/echo
echosystemScope[${pom.groupId}.${pom.artifactId}.buildstarted] =
${systemScope[${pom.groupId}.${pom.artifactId}.buildstarted]}/echo
/goal
Thanks !
Marc-Andre
-Original Message-
From: Deblauwe, Wim [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 10, 2005 9:02 AM
To: 'Maven Users List'
Subject: RE: Maven systemscope
Does not seem to work..
I have this:
goal name=wim:testing
${systemScope.setProperty(${pom.groupId}.${pom.artifactId}.buildstarted,'t
rue')}
ant:echo${systemScope}/ant:echo
/goal
When I look though the echo, it states:
${pom.groupId}.${pom.artifactId}.buildstarted=true
so, not expanded unfortunatly...
-Original Message-
From: Marc-Andre Blain [mailto:[EMAIL PROTECTED]
Sent: donderdag 10 maart 2005 14:58
To: Maven Users List
Subject: RE: Maven systemscope
You just need to insert it in double quotes
${systemScope.setProperty(${pom.groupId}.${pom.artifactId}.buildstarted,'t
rue')}
Regards,
Marc-Andre
-Original Message-
From: Deblauwe, Wim [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 10, 2005 8:55 AM
To: Maven Users List (E-mail)
Subject: Maven systemscope
Hi,
I would like to add the following to the systemscope:
${systemScope.setProperty('${pom.groupId}.${pom.artifactId}.buildstarted','t
rue')}
This
Re: Generated sources
For eclipse, add something like this as a postGoal:
j:file name=${basedir}/.classpathNew
classpath
jxml:parse var=theDoc
xml=file://${basedir}/.classpath/
jxml:forEach var=entry
select=$theDoc/classpath/classpathentry
jxml:copyOf select=$entry/
/jxml:forEach
jxml:element name=classpathentry
jxml:attribute
name=kindsrc/jxml:attribute
jxml:attribute
name=exclude/jxml:attribute
jxml:attribute
name=pathtarget/axis/src/jxml:attribute
/jxml:element
/classpath
/j:file
delete file=${basedir}/.classpath/
move file=${basedir}/.classpathNew
toFile=${basedir}/.classpath/
For javadoc, I think a preGoal looking like this should work:
path id=ejbdoclet.test.compile.src.set
location=${maven.xdoclet.ejbdoclet.destDir}/
maven:addPath id=maven.test.compile.src.set
refid=ejbdoclet.test.compile.src.set/
Of course, you'll need to adjust a bit to fit your stuff...
Enjoy!
Steve
On Tue, 2005-01-03 at 15:14 +0100, Guillaume Lederrey wrote:
Hi !
Maven is a great tool ! I dont know how i could do without it !
Still, I'm a bit of a beginner and there are a few point I couldnt find in
the docs (but I might be a bit too blind ...). I have projects with a lot of
generated sources (from AndroMDA). I'd like the javadoc to be compiled for
those src as well and have them added to the eclipse classpath with maven
eclipse:generate-classpath. It's probably just a fairly easy property to
set, but I could not find it ...
Any help ?
Thanks
Guillaume Lederrey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiple src directories ?
Had a similar issue to use code generated with Axis... I created a
postGoal in maven.xml:
postGoal name=eclipse:generate-classpath
attainGoal name=generateAxis/
attainGoal name=addAxisPath/
/postGoal
goal name=addAxisPath
j:file name=${basedir}/.classpathNew
classpath
jxml:parse var=theDoc
xml=file://${basedir}/.classpath/
jxml:forEach var=entry
select=$theDoc/classpath/classpathentry
jxml:copyOf select=$entry/
/jxml:forEach
jxml:element name=classpathentry
jxml:attribute
name=kindsrc/jxml:attribute
jxml:attribute
name=exclude/jxml:attribute
jxml:attribute
name=pathtarget/axis/src/jxml:attribute
/jxml:element
/classpath
/j:file
delete file=${basedir}/.classpath/
move file=${basedir}/.classpathNew
toFile=${basedir}/.classpath/
/goal
Enjoy!
Steve
On Thu, 2005-10-02 at 18:02 -0500, Joseph M. Ferner wrote:
I'm having a similar problem with JavaCC. I found the same entry in the FAQ
about adding additional source directories but, the eclipse plug-in doesn't
add the second source directory to the project. Are there any solutions to
this problem? Could the eclipse plug-in possibly run a java:compile and
extract the source directories from there?
-Original Message-
From: Mark D. Hansen [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 10, 2005 4:57 PM
To: Maven Users List
Subject: RE: multiple src directories ?
oops, sorry to bug you good people. i just found this in the FAQ:
http://maven.apache.org/faq.html#multiple-source-directories
-Original Message-
From: Mark D. Hansen [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 10, 2005 4:55 PM
To: Maven User (E-mail)
Subject: multiple src directories ?
another newbie question:
I would like to compile from 2 src directories, like this (in
my project.xml)
build
sourceDirectorysrc/java/sourceDirectory
sourceDirectorytarget/work/java/sourceDirectory
...
/build
It doesn't seem to work that way. The idea here is that I am
using a tool (JAXB XJC) to generate some source from an XSD -
and I don't want to copy that into the regular src directory
(that is a no, no since you can screw up your src if you are
sloppy). With Ant, I can specify multiple src directories.
How is this done in maven?
Thanks!
-- Mark
-
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 plugin
I think what you're looking for is the jelly useBean and invoke tags...
http://jakarta.apache.org/commons/jelly/tags.html
Steve
On Thu, 2005-03-02 at 11:39 +, HEAD-RAPSON, David wrote:
Hi,
I wonder if someone can help me. It's regarding a new maven plugin I'm
writing.
I'm using Maven and Jelly to execute a Java command as part of our build
process. Following that I wish to execute an ant command, but I need an
argument from the java. Ideally I'd like to know how to return a value from
a call to a defined java class. I've written the java class and its being
called correctly but I've no idea how to use the return value.
Here's the method spec:
public class Release {
public String makeRelease() {}
...
}
And I'm using the following in my plugin.jelly to call it.
goal name=bupa:make-release
j:jelly xmlns:j=jelly:core xmlns:define=jelly:define
xmlns:release=releaseTagLib
define:taglib uri=releaseTagLib
define:jellybean name=rel method=makeRelease
className=com.bupa.maven.plugin.release.Release/
/define:taglib
release:rel artifactId=${pom.artifactId}
currentVersion=${pom.currentVersion} dependencies=${pom.dependencies}
pomExtension=${pom.extend}/
/j:jelly
!- I want to call the ant method here with an argument returned
from the Java method--
/goal
Can anyone help at all?
Thanks in advance
Dave
Visit http://www.bupa.com or call 0800 00 10 10 and find out what BUPA can do
for you.
BUPA, the health and care people
BUPA House 15-19 Bloomsbury Way London WC1A 2BA
Internet communications are not secure and therefore BUPA does
not accept legal responsibility for the contents of this message. Any
views or opinions presented are solely those of the author and do
not necessarily represent those of BUPA.
BUPA Insurance Limited, BUPA Health Assurance Limited, BUPA Insurance
Services Limited and Goldsborough Estates Limited are authorised and
regulated by the Financial Services Authority
Re: is there a way to force maven to always download a dependency?
The problem is when you do not have any control on the jars you rely on... I had the same problem, with projects depending on jars which were changing but were not tagged with any version. What I ended up doing is host them locally, renaming each one by adding -SNAPSHOT... Not very clean, but it works... Steve On Wed, 2005-02-02 at 12:54 -0500, Eric Giguere wrote: Hi No, cannot. But I would suggest to version all your jars and maybe remove the versions at deployment if it is an issue. We are using this technique and the jar compatibility nightmare (jars in cvs, versions clashing, etc) ended and never came back! HTH. Eric. [EMAIL PROTECTED] wrote: What if some jar files are not versioned (and maybe will never be versioned). Is there a way to force Maven to always go to the remote repositories to resolve dependencies? I've tried SNAPSHOT, but that does not reload a dependency every time a build is executed. Thanks for your help. Tom This message is intended for the recipient only and is not meant to be forwarded or distributed in any other format. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument, or security, or as an official confirmation of any transaction. Putnam does not accept purchase or redemptions of securities, instructions, or authorizations that are sent via e-mail. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of Putnam, LLC (DBA Putnam Investments) and its subsidiaries and affiliates. If you are not the intended recipient of this e-mail, please delete the e-mail. - 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: How to return/stop a goal in jelly script?
Returning in the middle of a goal is not a good idea anyways. Why don't you put the rest of the goal in a condition instead? Steve Molloy On Wed, 2005-01-26 at 10:45 +1100, Dion Gillard wrote: There's no 'stop' tag to stop the current goal for Maven. On Tue, 25 Jan 2005 12:23:10 -0600, Guo, Jiaqi [EMAIL PROTECTED] wrote: In a goal definition in plugin.jelly, can I call something like return value=0 / or attainGoal name=build:return / to return (stop) current goal? Thanks Jiaqi http://www.cyclopsgroup.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Duplicate project dependenices
I think there's room for discussion on this and not everyone will give you the same answer. The way I have done it here is that I have the same folder structure in CVS as my project hierarchy. That is, if Project B and C are children of A and D is child of B, I get: A: B: D: C: All projects except A extend the parent one. Then you checkout A and get everything configured. The trouble part usually comes when people want to use it in Eclipse, which we also do. The way I got around that problem is checking out module A in a separate workspace, run eclipse on all relevant subprojects (I wrote a small plugin to navigate through the hierarchy and only run eclipse goal on projects which do not have child projects...). Then, from your real workspace, you can use the Eclipse multi-project import plugin pointing to the workspace where A is and you'll see all subprojects and be able to work on them separately (including checking in and out since the CVS info is still there...). Now as I said, you might get a different answer from someone else... Steve Molloy On Thu, 2005-01-13 at 11:04 -0800, Todd Huss wrote: Thanks Steve! In your experience, is it better to have the parent project as a separate project all-together or include it? For example I tried it both ways and both approaches work technically: Mydata project.xml (extends conf/project-dependencies.xml) conf/project-dependencies.xml (hibernate dependency declared) Myweb project.xml (extends Mydata/conf/project-dependencies.xml) Or: Mywebdata project.xml (hibernate dependency) Mydata project.xml (extends Mywebdata/project.xml) Myweb project.xml (extends Mywebdata/project.xml) The downside I see with the latter approach is that a developer then has to checkout 3 CVS modules where one module basically has one file in it. Also if I later created a Mywebservices project that depends on Mydata it would then need to extend Mywebdata/project.xml as well for it to get the hibernate dependency. The first approach feels a touch kludgy though because I had to put project-dependencies.xml in a sub-directory so that projects extending it did not also inherit Mydata/maven.xml. I don't have a lot of experience with Maven yet though so I'm hoping other people have run into this and can share their experiences! Thanks, Todd -Original Message- From: Steve Molloy [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 10:39 AM To: Maven Users List Subject: Re: Duplicate project dependenices Make a parent project with hibernate dependency so you can use inheritance... Steve Molloy On Thu, 2005-01-13 at 10:29 -0800, Todd Huss wrote: I have a mydata project which publishes mydata.jar to my maven repository when I do maven jar:install. mydata.jar also requires hibernate.jar to be of any use to other projects. My myweb project creates myweb.war which includes mydata.jar through a dependency. However, I'm currently specifying the dependency on hibernate.jar in both myweb/project.xml and mydata/project.xml which isn't very elegant. Is there a way in myweb/project.xml to have it include all of mydata.jar's dependencies in the war without having duplicate dependency statements in both projects? Thanks, Todd - 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: altering war.bundle property at maven runtime
Wouldn't it be easier to remove the war.bundle property during development and putting it back later if you need it? Worst case, adding a copy to put it in your WEB-INF/lib before building a WAR also seems more straight-forward...
Steve Molloy
---BeginMessage---
Here the gist:
For various reasons, during development of a web application I use
tomcat's cross context feature. This means that specific jar files need
to be in tomcat's shared lib and not in the WEB-INF/lib directory. I am
trying to write a preGoal to set the war.bundle property to false on a
particular dependency during development.
What I have so far is:
j:forEach var=lib items=${pom.artifacts}
j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('war.bundle')=='true' and
dep.artifactId=='bms'}
j:expr value=${dep.setProperty('war.bundle','false')} /
ant:echoFound bms/ant:echo
/j:if
/j:forEach
The j:expr line does not work and I'm not sure how one would do this.
Thanks,
-Trav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---End Message---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating eclipse .classpath files
The eclipse plugin generates both .project and .classpath for the project you run it on. If you run it on the master project of a multiproject tree, you get the dependencies of the master project added to your .classpath, ie nothing. You shouldn't run it on your master project anyways as it will be difficult to use the resulting eclipse project, I'm guessing you don't get you source paths correct either do you? The best way is to run it against all subprojects, and use the subprojects in eclipse (you can use the multiproject import tool if you have many subprojects). Steve Molloy On Tue, 2004-12-21 at 12:05 +0100, Claudius Spellmann wrote: Hi, Is it actually possible to generate eclipse classpath files in maven like the .project files ??? When I use the eclipse plugin maven is generating an empty classpath file and when i fiddle around with the multiproject plugin maven is generating multiple classpath files for each subproject. But I need one general classpath file that contains all the classpath entries. Is it actually possible or has anybody done this before ? thanks Claudius - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Importing Multiple Projects into eclipse
There is a plugin to import multiple projects at once (http://eclipse-tools.sourceforge.net/projecttransfer/). Steve Molloy -Original Message- From: Eric Wood [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 2:30 PM To: Maven Users List Subject: Importing Multiple Projects into eclipse Hi, I'm using a multi project goal to generate eclipse project files for a bunch of projects at once. Does anyone know if there is a way to import multiple projects into eclipse without having to select one project at a time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trying to create developer group plugin
The one thing you can do is use plugin:deploy and plugin:download on the users' machines. It won't run automatically (Unless you use CruiseControl or something similar to run it...), but at least you won't have to unjar and do everything yourself... Steve Molloy -Original Message- From: Eric Black [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 3:01 PM To: Maven Users List Cc: Maven Users List Subject: Re: Trying to create developer group plugin Maven Users List [EMAIL PROTECTED] on Wednesday, December 8, 2004 at 2:58 PM + wrote: If your newly published jar can be refered by another maven project (with a dependency entry in project.xml) and that the developpers build this project, the file will get automatically downloaded from the remote repo. I thought about that, but I couldn't think of how to call the goal. What I'm thinking of now is to download the jar as you said, unjar it, and install it for anyone who's building the project. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SCM and Multiproject plugins
I simply use the same structure in CVS and the Maven build. This way you only run the scm:update-project on the master project, which module contains all sub-projects... Steve Molloy -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:16 AM To: Maven Users List Subject: RE: SCM and Multiproject plugins I do this in my projects by doing this: maven multiproject:goal -Dgoal=scm:update-project -Original Message- From: Poppe, Troy [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 9:11 AM To: Maven Users List Subject: SCM and Multiproject plugins Is there a way to get the SCM and multiproject plugins to play together such that if I do something like: maven scm:update-project OR maven multiproject:scm-update-project That Maven would update the modules for all of my sub-projects? T - 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: SCM and Multiproject plugins
I'm also using Eclipse. What you want to do is build the structure I
described in CVS, then checkout the whole project in a workspace. On the
projects you are interested in, run the eclipse goal. Then switch
workspace and import the configured projects.
To ease the process, I have a plugin to configure all subprojects that
have no sub-projects themselves, and then I import using the Eclipse
multi-project import plugin... The multiEclipse plugin I have is pretty
simple:
goal name=multiEclipse
maven:reactor
basedir=${maven.multiEclipse.basedir}
banner=Gathering project list
includes=${maven.multiEclipse.includes}
excludes=${maven.multiEclipse.excludes}
postProcessing=true
collectOnly=true
collectionVar=multiprojects
ignoreFailures=${maven.multiEclipse.ignoreFailures}
/
j:if test=${multiprojects.isEmpty()}
attainGoal name=eclipse/
/j:if
j:if test=${!multiprojects.isEmpty()}
maven:reactor
basedir=${maven.multiEclipse.basedir}
banner=Executing ${goal}
projectList=${multiprojects}
goals=multiEclipse
ignoreFailures=${maven.multiEclipse.ignoreFailures}
/
/j:if
/goal
This way, you have 1 set of files containing everything, but can still
work on individual subprojects in Eclipse.
Hope it helps!
Steve Molloy
-Original Message-
From: Poppe, Troy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 07, 2004 10:40 AM
To: 'Maven Users List'
Subject: RE: SCM and Multiproject plugins
Unfortunately, I am using Eclipse and there's a bit of a problem with
project
structure. (More detailed info than I can explain is in the Maven
wiki.) So I
don't think I can do what you are suggesting... Unless someone has an
alternative
structure to appease eclipse.
T
-Original Message-
From: Steve Molloy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 07, 2004 10:37 AM
To: Maven Users List
Subject: RE: SCM and Multiproject plugins
I simply use the same structure in CVS and the Maven build. This way you
only run
the scm:update-project on the master project, which module contains all
sub-projects...
Steve Molloy
-Original Message-
From: Ryan Sonnek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 07, 2004 10:16 AM
To: Maven Users List
Subject: RE: SCM and Multiproject plugins
I do this in my projects by doing this:
maven multiproject:goal -Dgoal=scm:update-project
-Original Message-
From: Poppe, Troy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 07, 2004 9:11 AM
To: Maven Users List
Subject: SCM and Multiproject plugins
Is there a way to get the SCM and multiproject plugins to play together
such that
if I do something like:
maven scm:update-project
OR
maven multiproject:scm-update-project
That Maven would update the modules for all of my sub-projects?
T
-
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: Dynamically modifing the ressources
Try adding scope=parent to your j:set.
Steve Molloy
-Original Message-
From: Charles-Alexandre Sabourdin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 24, 2004 10:56 AM
To: Maven Users List
Subject: Re: Dynamically modifing the ressources
it it not woking correctly.
What I am tried was to set in
project.xml
directorysrc/conf${configDir}/directory
in project.properties
configDir=/default
and in my maven.xml I creat the following goal :
goal name=exemplebean:jar description=set configuration file A
j:set var=configDir value=/configA/
echo set configuration directory : ${configDir}/echo
attainGoal name=echo-value/
attainGoal name=jar:jar/
/goal
unfortunatly it does not works.
Le mardi 23 Novembre 2004 20:30, Brett Porter a écrit :
in the resources, set it to something like:
src/conf/project${foo}, then set foo to A or B.
- Brett
On Tue, 23 Nov 2004 12:47:55 +0100, Charles-Alexandre Sabourdin
[EMAIL PROTECTED] wrote:
Hi,
I feel that this must have been discuss somewhere but I could not figure
it out.
The basic idea is to have 2 directory /src/conf/projetA
/src/conf/projetB. I would like to set maven goals to use a specific
directory.
I llok aroud and found :
[echo] $ {pom.build.resources}:
[[dir =
/home/sabourdin/Documents/projet/exemplebean/src/conf/projetA]] but I did
not find how to modify this propertie :(
--
Charles-Alexandre
SABOURDIN
-
-
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]
--
Charles-Alexandre
SABOURDIN
-
-
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: Grouping related projects
I came across the same problem and ended up writing a custom goal (actually a
simple plugin because it's used in more then 1 project) which I run as preGoal
to the standard java:jar-resources. It simply unjars the dependencies having
the jar.bundle property set to true and then the jar goal picks up the
classes and include them all in a standard jar. Note that this should only be
used internally and you should only be tagging YOUR OWN jars to be included...
Here's the goal I have, as you might see, it is inspired by the war plugin
and the war.bundle property:
goal name=prepareBundle
j:forEach var=lib items=${pom.artifacts}
j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('jar.bundle')=='true'}
j:if test=${dep.type =='jar'}
unjar dest=${maven.build.dest} src=${lib.path}/
/j:if
/j:if
/j:forEach
/goal
Steve Molloy
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 18, 2004 3:55 AM
To: Maven Users List
Subject: Re: Grouping related projects
this is definitely the right approach, but be aware uberjar is a JAR
of JARs, not jar of all classes. if you want a JAR of all classes,
that's something you will need to aggregate yourself at this point.
Cheers,
Brett
On Thu, 18 Nov 2004 09:50:07 +0100,
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Use the multiproject with a directory structure like
/root
/common-prj1
/common-prj2
...
/common-all
common-prj* are maven.multiproject.type=jar
common-all is maven.multiproject.type=uberjar and have all the
common-prj* in his dependancies
On the root dir using maven multiproject:install will build
common-prj*.jar and the common-all.jar who contains all the common-prj*
classes
Nicolas,
Duncan Krebs [EMAIL PROTECTED]
18/11/2004 03:34
Veuillez répondre à Maven Users List
Pour : Maven UserList [EMAIL PROTECTED]
cc :
Objet : Grouping related projects
Hi,
I'm breaking my development down into really small maven projects and I'm
trying to figure out what the options are if I want to group them
together. For example, say I have 5 separate projects that all start with
mycompany.commons that I'd like to distribute as one final versioned jar
but also want to maintain their own separate versions. Would this mean
creating a maven project to represent that jar? If that's the case then
would the five separate project folders be sub directories of the project
that represents the jar? Or am I totally out of it? thanks. - Duncan
-
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: http://www.ibiblio.org/maven/ seens to be dead or very slow
Here's the list I received last time. BTW, this should be added at least in the docs, if not in the default config... # http://mirrors.sunsite.dk/maven/ # http://ftp.up.ac.za/pub/linux/maven/ # http://download.au.kde.org/pub/maven/ # http://public.planetmirror.com/pub/maven/ # http://public.www.planetmirror.com/pub/maven/ # http://smokeping.planetmirror.com/pub/maven/ # http://horde.planetmirror.com/pub/maven/ # http://curl.planetmirror.com/pub/maven/ # http://python.planetmirror.com/pub/maven/ Steve Molloy -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Saturday, October 23, 2004 5:43 AM To: Maven Users List Subject: Re: http://www.ibiblio.org/maven/ seens to be dead or very slow yes, same for me. search the archives - someone brought up mirrors the other day. I use http://planetmirror.com/pub/maven in Australia. - Brett On Sat, 23 Oct 2004 11:35:13 +0200, Andreas Ernst [EMAIL PROTECTED] wrote: Hi, i try to test maven, but primary repository ibiblio.org seens to be dead or is very slow. With maven -Dpackage=de.ae-online.test test i get connection refused. Is there any secondary repository avilable? thanks Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject recursive nesting problem
Why are projectA and projectB not under the buildRoot (or the top-level project.xml under buildDir...)? If you had: BuildDir | +-buildRoot | +-projectA | +-projectB You wouldn't need to set the maven.multiproject properties and the sites will be generated only once per project, I think the basedir pointing to ../ is causing the problem. Also, if you want to have more levels, say projectA.1 under projectA, you can add: maven.multiproject.site.goals=multiproject Hope it helps, Steve Molloy -Original Message- From: Robert Hernik [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 11:04 AM To: Maven Users List Subject: multiproject recursive nesting problem Hello, I am having some trouble getting the maven multiproject:site generation to behave how I would like, and I would appreciate any help. My project layout: BuildDir | +-buildRoot / project.properties | +-projectA | +-projectB My project layout has a buildRoot that is a dummy project containing project.properties (plus a maven.xml and project.xml). builRoot has no source but is the 'parent' dir for the multiproject site generation even though it is at the same level in the dir structure. I am using this flat structure as the projects are coming from WSAD (Eclipse). project.properties contains the following entries for multiproject properties: maven.multiproject.basedir=../ maven.multiproject.excludes=buildroot/project.xml maven.multiproject.includes=projectA/project.xml,projectB/project.xml When I run maven multiproject:site in the buildRoot dir I get the following generated in my html directory: Docs | +-multiproject | +-projectA | +-projectB This is precisely what I want, and the generated project site appears OK in this case. However, when I drill down into projectA and projectB the following has happened: Docs | +-multiproject | +-projectA | | | +-multiproject | | | +-projectA | | +-projectB | +-multiproject | +-projectA | | | +-multiproject | | | +-projectA | +-projectB It appears there is some kind of recursion taking place in my multiproject generation. Has anybody got an idea how I can stop this happening/what is wrong in my properties? When I add a few more projects the whole site generation falls over when the nested paths become too long! Thanks for any help, Rob. This email and any files transmitted with it contain information that may be confidential or privileged, and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient any disclosure, copying, distribution or use of the information is prohibited. If you have received this email in error, please notify me by return email immediately. Any opinions expressed are those of the author, not of Morpheus Limited. This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multiproject recursive nesting problem
For Eclipse, I know I had the same problem, which I solved by writing a
simple plugin (it could be a goal in your root maven.xml if you only
have 1 project, I have many), which basically goes through each
subproject and runs the eclipse goal only if it doesn't have any
subproject, which in my case (and I imagine most cases) means it has no
sources. Then I use the multi-project import/export Eclipse plugin to
import the subprojects into Eclipse.
But if your stuff already works, I guess you don't really need this info
now do you? :-) Here's the goal anyway just in case...
goal name=multiEclipse
maven:reactor
basedir=${maven.multiEclipse.basedir}
banner=Gathering project list
includes=${maven.multiEclipse.includes}
excludes=${maven.multiEclipse.excludes}
postProcessing=true
collectOnly=true
collectionVar=multiprojects
ignoreFailures=${maven.multiEclipse.ignoreFailures}
/
j:if test=${multiprojects.isEmpty()}
attainGoal name=eclipse/
/j:if
j:if test=${!multiprojects.isEmpty()}
maven:reactor
basedir=${maven.multiEclipse.basedir}
banner=Executing ${goal}
projectList=${multiprojects}
goals=multiEclipse
ignoreFailures=${maven.multiEclipse.ignoreFailures}
/
/j:if
/goal
Steve Molloy
-Original Message-
From: Robert Hernik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 12:20 PM
To: Maven Users List
Subject: RE: multiproject recursive nesting problem
I'm using this flat structure to keep the same hierarchy as we have in
our Eclipse development environment, so I'd prefer to keep it if
possible.
I think I have found the solution though after your comments prompted
(yet another) re-read of the multiproject documentation.
My project.properties in the buildRoot dir also contains an entry for
the docs directory:
maven.docs.dest=F:/path/to/docs
The multiproject documentation says:
At the completion of the multiproject:site goal, each project's
generated site is copied into the appropriate directory. e.g. if
WebProject1 and JarProject2 are the names of projects processed via
multiproject:site, the project that is executing multiproject:site will
have the generated sites from WebProject1/target/docs and
JarProject2/target/docs copied into target/docs/multiproject/WebProject1
and target/docs/multiproject/JarProject2 respectively.
As the project.properties for my projectA and projectB did not
explicitly define their own maven.docs.dest I think they were using the
buildRoot's maven.docs.dest path, and because of this I was getting them
copied within each other.
Explicitly setting a unique maven.docs.dest in the project.properties of
each sub-project appears to have fixed this!
Thanks for helping with my question.
Cheers,
Rob.
This email and any files transmitted with it contain information that
may be
confidential or privileged, and are intended solely for the use of the
individual or entity to whom they are addressed. If you are not the
intended
recipient any disclosure, copying, distribution or use of the
information is
prohibited. If you have received this email in error, please notify me
by
return email immediately. Any opinions expressed are those of the
author,
not of Morpheus Limited.
This message has been checked for all known viruses by UUNET delivered
through the MessageLabs Virus Control Centre.
-
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]
Ibiblio repository
Is anyone else having recurring problems accessing the remote repository on Ibiblio? For example, it's been about an hour now that I've been trying to get 2 artifacts from it to be able to run a native goal, but I keep getting Connection timed out errors. Wouldn't it make sense to have the repository mirrored somewhere so that if Ibiblio has a problem? Even if the mirror was slower, at least people could continue to work. I know I can have a hard time explaining a manager why I can't setup a developer's machine because the Ibiblio server is not responding... Steve Molloy mailto:[EMAIL PROTECTED]
RE: Ibiblio repository
Great! Thanks! Steve Molloy -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 11:12 AM To: 'Maven Users List' Subject: RE: Ibiblio repository Try this list (each is sync'd with ibiblio as far as I've seen): # http://mirrors.sunsite.dk/maven/ # http://ftp.up.ac.za/pub/linux/maven/ # http://download.au.kde.org/pub/maven/ # http://public.planetmirror.com/pub/maven/ # http://public.www.planetmirror.com/pub/maven/ # http://smokeping.planetmirror.com/pub/maven/ # http://horde.planetmirror.com/pub/maven/ # http://curl.planetmirror.com/pub/maven/ # http://python.planetmirror.com/pub/maven/ With regards, Martijn -Oorspronkelijk bericht- Van: Steve Molloy [mailto:[EMAIL PROTECTED] Verzonden: maandag 18 oktober 2004 17:10 Aan: [EMAIL PROTECTED] Onderwerp: Ibiblio repository Is anyone else having recurring problems accessing the remote repository on Ibiblio? For example, it's been about an hour now that I've been trying to get 2 artifacts from it to be able to run a native goal, but I keep getting Connection timed out errors. Wouldn't it make sense to have the repository mirrored somewhere so that if Ibiblio has a problem? Even if the mirror was slower, at least people could continue to work. I know I can have a hard time explaining a manager why I can't setup a developer's machine because the Ibiblio server is not responding... Steve Molloy 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]
