Could not download ... pom.xml
When I try to add a maven 2 project I get ... Could not download file:/tmp/summit-1/andromda/pom.xml: /tmp/summit-1/andromda/pom.xml (No such file or directory) Check the logs for more details. * Could not download file:/tmp/summit-1/andromdapp/pom.xml: /tmp/summit-1/andromdapp/pom.xml (No such file or directory) Check the logs for more details. This carries on for all the poms in the project. Why does it carry on when this is a fatal error? The logs dont provide any more information. I can see that temp files have been created in /tmp but not directory summit-1. I tried creating that directory but still the same problem. Any suggestions? -- Regards Martin West http://www.objectgizmos.com 07879 680 096
Re: [m2] maven-ear-plugin: why is the includeInApplicationXml set to false by default ?
On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: Thanks, I've been living a lye! Why God! Why! in the theme of Joey from Friends when he celebrates his birthday I had the same feelings a while ago ;-) Anyway, I am not against implementing some defaults in the plugin. Something like: * defaultJavaBundleDir (already exists) * defaultIncludeInApplicationXmlForJava ... Let me know what you guys think about it. Cheers, Stéphane -- .::You're welcome ::.
Does project a include project b in the classpath if they are both part of a multi project?
Hi I'm working with maven2 and using eclipse I have a war project and a jar project. when i am using the maven-eclipse plugin and have stated that my war project has a dependency on my jar project. I do not see the jar in my list of project dependencies. in the ide. This seems to cause a problem with my integration of the jetty plugin as well because it cannot find any of my classes in the jar project when i'm running jetty6. The packaged war however works as expected. does anyone have a clue how to fix it or have a work around for it? regards Rolf
RE: [m2.0.1] Clover JDK 1.5
Hi Wim, Yes I think you need to build the plugin from source. The plugin requires Maven 2.0.1 which is why it has not been released so far. Now that 2.0.1 is out we should release it. Thanks -Vincent -Original Message- From: Wim Deblauwe [mailto:[EMAIL PROTECTED] Sent: mercredi 14 décembre 2005 11:23 To: Maven Users List Subject: [m2.0.1] Clover JDK 1.5 Hi, I tried to include the clover report running 'mvn site', but it fails stating that it does not know 'enum'. I added jdk1.5/jdk in the configuration of the plugin, but it does not work. Do I need to build from source to have this or is there a build available somewhere? I tried running 'mvn -U site' (and even have the snapshot repository of codehaus in my list), but no update of the clover plugin happend. regards, Wim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to make pom.xml simpler?
-1 I agree with Brett. This is a matter of taste. My taste goes towards the existing solution. Writing everything on a single line may even become less readable. Have you ever tried to read an Eclipse .classpath file? You can hardly say that's more readeable. I also think that mixing attributes with elements is in this case a bad idea and would hurt overall consistency. On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: If your sole concern is the number of lines one must type, it is certainly an option to have meta-pom.xml be in the format you find most comfortable, then xslt it into the more verbose m2 pom.xml. This argument of attributes versus elements has existed since the dawn of [xml] time. I am not trying to argue one way or the other, but since m1 pom used the more verbose syntax, it eases the transition. My USD$0.02, -- /v\atthew - In fact people should develop a plugin that maps the simplified and verbose schemas on the fly :) The advantage of using namespaces is that you can create a your tag and map it to the verbose tag from the official pom. That's the way I've seen the spring guys use it for now but the advantage that I see is that in could be much easier to extend the pom and it would be more type safe My 0.02MKD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to make pom.xml simpler?
A simple XSLT stylesheet would do the job there. You don't need maven to support this format. On 12/17/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: -1 I agree with Brett. This is a matter of taste. My taste goes towards the existing solution. Writing everything on a single line may even become less readable. Have you ever tried to read an Eclipse .classpath file? You can hardly say that's more readeable. I also think that mixing attributes with elements is in this case a bad idea and would hurt overall consistency. On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: If your sole concern is the number of lines one must type, it is certainly an option to have meta-pom.xml be in the format you find most comfortable, then xslt it into the more verbose m2 pom.xml. This argument of attributes versus elements has existed since the dawn of [xml] time. I am not trying to argue one way or the other, but since m1 pom used the more verbose syntax, it eases the transition. My USD$0.02, -- /v\atthew - In fact people should develop a plugin that maps the simplified and verbose schemas on the fly :) The advantage of using namespaces is that you can create a your tag and map it to the verbose tag from the official pom. That's the way I've seen the spring guys use it for now but the advantage that I see is that in could be much easier to extend the pom and it would be more type safe My 0.02MKD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to make pom.xml simpler?
We all agree that it is really a matter of taste. That's precisely why Maven *should* support another theme. I definitly agree that whether attributes are more readable or not is arguable (at best) - but why not keep both camps happy? :) (if the costs are reasonable of course) On 12/17/05, Alexandre Poitras [EMAIL PROTECTED] wrote: A simple XSLT stylesheet would do the job there. You don't need maven to support this format. On 12/17/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: -1 I agree with Brett. This is a matter of taste. My taste goes towards the existing solution. Writing everything on a single line may even become less readable. Have you ever tried to read an Eclipse .classpath file? You can hardly say that's more readeable. I also think that mixing attributes with elements is in this case a bad idea and would hurt overall consistency. On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: If your sole concern is the number of lines one must type, it is certainly an option to have meta-pom.xml be in the format you find most comfortable, then xslt it into the more verbose m2 pom.xml. This argument of attributes versus elements has existed since the dawn of [xml] time. I am not trying to argue one way or the other, but since m1 pom used the more verbose syntax, it eases the transition. My USD$0.02, -- /v\atthew - In fact people should develop a plugin that maps the simplified and verbose schemas on the fly :) The advantage of using namespaces is that you can create a your tag and map it to the verbose tag from the official pom. That's the way I've seen the spring guys use it for now but the advantage that I see is that in could be much easier to extend the pom and it would be more type safe My 0.02MKD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, _ Arik Kfir[EMAIL PROTECTED]
Re: [m2] maven-ear-plugin: why is the includeInApplicationXml set to false by default ?
That would be a very welcome addition indeed. On 12/17/05, Stephane Nicoll [EMAIL PROTECTED] wrote: On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: Thanks, I've been living a lye! Why God! Why! in the theme of Joey from Friends when he celebrates his birthday I had the same feelings a while ago ;-) Anyway, I am not against implementing some defaults in the plugin. Something like: * defaultJavaBundleDir (already exists) * defaultIncludeInApplicationXmlForJava ... Let me know what you guys think about it. Cheers, Stéphane -- .::You're welcome ::. -- Regards, _ Arik Kfir[EMAIL PROTECTED]
[M2] Release changes for maven 2.0.1
Where can I find the release notes and release changes for the new version? Thanks Heiko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVN checkout problems
Hi, I 've been trying to checkout the maven 2 plugins and the mojo project, on both I get a 301: $ svn co http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/ maven2-plugins svn: PROPFIND request failed on '/viewcvs.cgi/maven/plugins/trunk' svn: PROPFIND of '/viewcvs.cgi/maven/plugins/trunk': 301 Moved (http://svn.apache.org) Am I doing something wrong? I 'd start porting the izpack plugin to m2. Thanks for any and all help, Geoffrey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN checkout problems
Partially my mistake On m2 plugin I used the viewcgi url... On mojo I had to use: svn checkout svn://svn.codehaus.org/mojo/scm/trunk/mojo With kind regards, Geoffrey Geoffrey wrote: Hi, I 've been trying to checkout the maven 2 plugins and the mojo project, on both I get a 301: $ svn co http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/ maven2-plugins svn: PROPFIND request failed on '/viewcvs.cgi/maven/plugins/trunk' svn: PROPFIND of '/viewcvs.cgi/maven/plugins/trunk': 301 Moved (http://svn.apache.org) Am I doing something wrong? I 'd start porting the izpack plugin to m2. Thanks for any and all help, Geoffrey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Does project a include project b in the classpath if they are both part of a multi
I have included the M2_REPO variable and all my other dependencies appear as normally in my classpath structure when i looked in the folder in the repository containing the jar it is there. as i expected because the war file has the jar included Regards Rolf On 12/17/05, Allan Ramirez [EMAIL PROTECTED] wrote: Hi Rolf, Have you specified the M2_REPO classpath variable in eclipse? as stated in http://maven.apache.org/guides/mini/guide-ide-eclipse.html regards, -allan Rolf Strijdhorst wrote: Hi I'm working with maven2 and using eclipse I have a war project and a jar project. when i am using the maven-eclipse plugin and have stated that my war project has a dependency on my jar project. I do not see the jar in my list of project dependencies. in the ide. This seems to cause a problem with my integration of the jetty plugin as well because it cannot find any of my classes in the jar project when i'm running jetty6. The packaged war however works as expected. does anyone have a clue how to fix it or have a work around for it? thanx Rolf No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.13/200 - Release Date: 12/14/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly dependencies
We are trying to use Maven 2 to manage our projects. So far, we have osesm-lib (which contains libs that I think all of our projects might use), and osesm-webappA and osesm-webappB (which use osesm-lib for things like db access and constant lookups). I want to deploy osesm-webappA and osesm-webappB to my servlet container. I want to use create a jar of dependencies so it will be easier to maintain these in the future. Can I create multiple assemblies? I don't want osesm-webappA and osesm-webappB to contain any of the dependencies that osesm-lib has. I noted in the assembly descriptor file, you can use excludes. Is there a way to exclude everything a dependency may bring over without explicitly excluding each item in each assembly descriptor file?
Re: Assembly dependencies
On 12/17/05, Bryan Liles [EMAIL PROTECTED] wrote: what you need is maven-jarjar-plugin for m2 which is not available yet. This plugin combines a bunch of jar files into one. However, those jars must be appear in plugin's configuration not in the dependencies list so that transitive dependency is completely disable. some of the work already started by Brian Fox http://jira.codehaus.org/browse/MOJO-173 -Dan We are trying to use Maven 2 to manage our projects. So far, we have osesm-lib (which contains libs that I think all of our projects might use), and osesm-webappA and osesm-webappB (which use osesm-lib for things like db access and constant lookups). I want to deploy osesm-webappA and osesm-webappB to my servlet container. I want to use create a jar of dependencies so it will be easier to maintain these in the future. Can I create multiple assemblies? I don't want osesm-webappA and osesm-webappB to contain any of the dependencies that osesm-lib has. I noted in the assembly descriptor file, you can use excludes. Is there a way to exclude everything a dependency may bring over without explicitly excluding each item in each assembly descriptor file?
RE: Assembly dependencies
This project will hopefully be in the sandbox within the next couple of days. -Original Message- From: dan tran [mailto:[EMAIL PROTECTED] Sent: Saturday, December 17, 2005 11:57 AM To: Maven Users List Subject: Re: Assembly dependencies On 12/17/05, Bryan Liles [EMAIL PROTECTED] wrote: what you need is maven-jarjar-plugin for m2 which is not available yet. This plugin combines a bunch of jar files into one. However, those jars must be appear in plugin's configuration not in the dependencies list so that transitive dependency is completely disable. some of the work already started by Brian Fox http://jira.codehaus.org/browse/MOJO-173 -Dan We are trying to use Maven 2 to manage our projects. So far, we have osesm-lib (which contains libs that I think all of our projects might use), and osesm-webappA and osesm-webappB (which use osesm-lib for things like db access and constant lookups). I want to deploy osesm-webappA and osesm-webappB to my servlet container. I want to use create a jar of dependencies so it will be easier to maintain these in the future. Can I create multiple assemblies? I don't want osesm-webappA and osesm-webappB to contain any of the dependencies that osesm-lib has. I noted in the assembly descriptor file, you can use excludes. Is there a way to exclude everything a dependency may bring over without explicitly excluding each item in each assembly descriptor file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to make pom.xml simpler?
That's a good pointquestion is: Is readability of pom.xml a good-enough feature? (which brings us back to a matter of taste hehehee) On 12/17/05, Brian E. Fox [EMAIL PROTECTED] wrote: why not keep both camps happy? :) I would personally have them spend time on bugs fixes and new functional features than rewrite something that is a matter of taste. -Original Message- From: Arik Kfir [mailto:[EMAIL PROTECTED] Sent: Saturday, December 17, 2005 7:30 AM To: Maven Users List Subject: Re: Is it possible to make pom.xml simpler? We all agree that it is really a matter of taste. That's precisely why Maven *should* support another theme. I definitly agree that whether attributes are more readable or not is arguable (at best) - but why not keep both camps happy? :) (if the costs are reasonable of course) On 12/17/05, Alexandre Poitras [EMAIL PROTECTED] wrote: A simple XSLT stylesheet would do the job there. You don't need maven to support this format. On 12/17/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: -1 I agree with Brett. This is a matter of taste. My taste goes towards the existing solution. Writing everything on a single line may even become less readable. Have you ever tried to read an Eclipse .classpath file? You can hardly say that's more readeable. I also think that mixing attributes with elements is in this case a bad idea and would hurt overall consistency. On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: If your sole concern is the number of lines one must type, it is certainly an option to have meta-pom.xml be in the format you find most comfortable, then xslt it into the more verbose m2 pom.xml. This argument of attributes versus elements has existed since the dawn of [xml] time. I am not trying to argue one way or the other, but since m1 pom used the more verbose syntax, it eases the transition. My USD$0.02, -- /v\atthew - In fact people should develop a plugin that maps the simplified and verbose schemas on the fly :) The advantage of using namespaces is that you can create a your tag and map it to the verbose tag from the official pom. That's the way I've seen the spring guys use it for now but the advantage that I see is that in could be much easier to extend the pom and it would be more type safe My 0.02MKD -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, _ Arik Kfir[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, _ Arik Kfir[EMAIL PROTECTED]
Re: Is it possible to make pom.xml simpler?
-0
Support for both should be out of the question. Double the documentation,
double the confusion, double the possibility for error proneness.
Readability is very important. I've never been a big fan of the less lines
argument. Sure:
if(a!=null){a+= label;System,out.println(a);}
may be less lines than:
if ( a!=null )
{
a += label;
System,out.println( a );
}
However, I'd rather maintain the second than the first. Since maintinence of
code (and, by extension, the POM) is a larger percentage of the development
lifecycle than the initial writing, that is the more important piece to
pander too.
I'm all for removing some of the verbosity of the POM. I kind of like the
idgroupId/artifactId/id syntax. But that's a far cry from cramming
everything onto a single, unreadable ( hyperbole :) ), line.
Eric
On 12/17/05, Arik Kfir [EMAIL PROTECTED] wrote:
That's a good pointquestion is: Is readability of pom.xml a
good-enough feature? (which brings us back to a matter of taste
hehehee)
On 12/17/05, Brian E. Fox [EMAIL PROTECTED] wrote:
why not keep both camps happy? :)
I would personally have them spend time on bugs fixes and new functional
features than rewrite something that is a matter of taste.
-Original Message-
From: Arik Kfir [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 17, 2005 7:30 AM
To: Maven Users List
Subject: Re: Is it possible to make pom.xml simpler?
We all agree that it is really a matter of taste. That's precisely why
Maven *should* support another theme.
I definitly agree that whether attributes are more readable or not is
arguable (at best) - but why not keep both camps happy? :) (if the costs
are reasonable of course)
On 12/17/05, Alexandre Poitras [EMAIL PROTECTED] wrote:
A simple XSLT stylesheet would do the job there. You don't need maven
to support this format.
On 12/17/05, Thomas Van de Velde [EMAIL PROTECTED] wrote:
-1
I agree with Brett. This is a matter of taste. My taste goes
towards the existing solution. Writing everything on a single line
may even become less readable. Have you ever tried to read an
Eclipse .classpath file? You can hardly say that's more readeable.
I also think that mixing attributes with elements is in this case a
bad idea and would hurt overall consistency.
On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote:
If your sole concern is the number of lines one must type, it is
certainly an option to have meta-pom.xml be in the format you
find most comfortable, then xslt it into the more verbose m2
pom.xml.
This argument of attributes versus elements has existed since the
dawn of [xml] time. I am not trying to argue one way or the
other, but since
m1 pom used the more verbose syntax, it eases the transition.
My USD$0.02,
-- /v\atthew
-
In fact people should develop a plugin that maps the simplified
and verbose schemas on the fly :) The advantage of using
namespaces is that you can create a your tag and map it to the
verbose tag from the official pom.
That's the way I've seen the spring guys use it for now but the
advantage that I see is that in could be much easier to extend the
pom and it would be more type safe
My 0.02MKD
--
--- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexandre Poitras
Québec, Canada
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
_
Arik Kfir[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
_
Arik Kfir[EMAIL PROTECTED]
Re: SVN checkout problems
http://svn.apache.org/repos/asf/maven/plugins/trunk/ On 12/17/05, Geoffrey [EMAIL PROTECTED] wrote: Hi, I 've been trying to checkout the maven 2 plugins and the mojo project, on both I get a 301: $ svn co http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/ maven2-plugins svn: PROPFIND request failed on '/viewcvs.cgi/maven/plugins/trunk' svn: PROPFIND of '/viewcvs.cgi/maven/plugins/trunk': 301 Moved (http://svn.apache.org) Am I doing something wrong? I 'd start porting the izpack plugin to m2. Thanks for any and all help, Geoffrey - 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: [M2] Release changes for maven 2.0.1
Here is the page that is generated by JIRA: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=12000 On 12/17/05, puschteblume [EMAIL PROTECTED] wrote: Where can I find the release notes and release changes for the new version? Thanks Heiko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Download of Plugins does not start
Hello, it's the first time I try to using maven 2. I've downloaded and made some changes in settings.xml: localRepository/usr/local/maven_repository/localRepository mirrors mirror idplanetmirror/id nameAustralian Mirror of http://repo1.maven.org/maven2//name urlhttp://public.planetmirror.com/maven2//url mirrorOfcentral/mirrorOf /mirror mirror idIBiblio/id nameIBiblio Repository/name urlhttp://www.ibiblio.org/maven2//url mirrorOfcentral/mirrorOf /mirror /mirrors now I'm trying to create my first project with mvn archetype:create - DgroupId=com.mycompany.app -DartifactId=my-app But if I start this command I receive the following Exception: The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exist or no valid version could be found. I think first it should start the download for some plugins? I'm not behind a proxy. Thanks Mike
Re: [m2] Adding surefire-report = Infinite loop
I think it requires maven 2.0.1 - that infinite loop bug was supposed to be fixed then. - Brett On 12/17/05, Allan Ramirez [EMAIL PROTECTED] wrote: Hi Sri, There is no attached file in your mail :) -allan Sri Sankaran wrote: Attached is the output of a run with the -X option. Other than seeing the same steps repeating, I don't see the *cause* of the problem. Sri -Original Message- From: Allan Ramirez [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 3:53 AM To: Maven Users List Subject: Re: [m2] Adding surefire-report = Infinite loop I cant replicate this issue. It is working in my copy. Can you paste the log with -X arguement? -allan Sri Sankaran wrote: I wanted to run the surefire-report:report goal as part of the test phase. So, I add the following to my pom plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdsurefire-report-maven-plugin/artifactId version2.0-beta-1/version executions execution phasetest/phase goalsgoalreport/goal/goals /execution /executions /plugin /plugins This results in an infinite loop of the test:test goal. What am I doing wrong? Sri - 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] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.13/200 - Release Date: 12/14/2005 - 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: [m2] clean plugin needs dependant plugins?
Please create a new one (and don't clone the existing one). I think this is related to the addition of a clean lifecycle. I'm not sure what the best answer to this is. - Brett On 12/17/05, Chad Brandon [EMAIL PROTECTED] wrote: Thanks Edwin, Yeah it appears that any plugins that are in my pom.xml need to be downloaded before clean can work, otherwise it fails with unsatisfied dependencies (for example, I can't clean our distribution until the rest of the plugins of our build are installed). I'll reopen the issue. Chad Edwin Punzalan wrote: According to jira, this has been fixed in 2.0-alpha-3, if you're sure that its not working again, you can reopen http://jira.codehaus.org/browse/MNG-489 Chad Brandon wrote: Hi, Is there any reason why the clean plugin needs to have dependent plugins downloaded before it can do its thing? It would be nice if it ignored all dependencies (including plugins). Thanks, Chad - 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: [m2] release plugin problems
Hello, Has anyone found a solution to this problem yet? I'm getting the same error message using subversion 1.2.3 on cygwin with maven 2.0.1 and release plugin version 2.0 beta 3. Jurgen I tried running the command 'svn cp . ../tags/0.4' and that gave the same error message. I'm starting to think it may be a problem with svn. I ran 'svn cp /full/path/to/trunk ../tags/0.4' and that worked without a problem. Rich Richard Wallace wrote: I tried setting the tagBase via the -DtagBase option, but that didn't seem to make a difference. Arik Kfir wrote: Hi, Make sure you define the following in your pom.xml: build plugins plugin artifactIdmaven-release-plugin/artifactId configuration tagBasehttp://www.mysvnserver.com/myproject/tags/tagBase /configuration /plugin /plugins /build This tells the release plugin where to place tagged sources (see svn docs for info how tagging in svn). cheers, Arik. On 11/15/05, Richard Wallace [EMAIL PROTECTED] wrote: I'm trying to use the release plugin to do a release of my project. I'm using subversion 1.2.3 and everything proceeds to the point where m2 tries to do the svn copy but svn kicks back the following error message: svn: Cannot copy path '.' into its own child '../tags/0.3' I was able to do releases with the m1 plugin, but this is the first time I've tried with m2. Any ideas? Thanks, Rich - 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: Is it possible to make pom.xml simpler?
Don't confuse shorter with more readable. I don't mind going for
the idmygroup/myartiact/id instead of attributes. I just wanted
to note that the existing syntax is (perhaps) *too* verbose...
I definitly agree with your example, and maintainance takes priority
over number-of-source-lines...but when you reach 20..30 dependencies,
things get messy... Some might argue that having 20 dependencies might
indicate a hidden problem, but even with 10 dependencies, combined
with a real-world build and plugins section, you get a pretty big
POM...
Anyway, just my 2cents ;-)
On 12/17/05, Eric Redmond [EMAIL PROTECTED] wrote:
-0
Support for both should be out of the question. Double the documentation,
double the confusion, double the possibility for error proneness.
Readability is very important. I've never been a big fan of the less lines
argument. Sure:
if(a!=null){a+= label;System,out.println(a);}
may be less lines than:
if ( a!=null )
{
a += label;
System,out.println( a );
}
However, I'd rather maintain the second than the first. Since maintinence of
code (and, by extension, the POM) is a larger percentage of the development
lifecycle than the initial writing, that is the more important piece to
pander too.
I'm all for removing some of the verbosity of the POM. I kind of like the
idgroupId/artifactId/id syntax. But that's a far cry from cramming
everything onto a single, unreadable ( hyperbole :) ), line.
Eric
On 12/17/05, Arik Kfir [EMAIL PROTECTED] wrote:
That's a good pointquestion is: Is readability of pom.xml a
good-enough feature? (which brings us back to a matter of taste
hehehee)
On 12/17/05, Brian E. Fox [EMAIL PROTECTED] wrote:
why not keep both camps happy? :)
I would personally have them spend time on bugs fixes and new functional
features than rewrite something that is a matter of taste.
-Original Message-
From: Arik Kfir [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 17, 2005 7:30 AM
To: Maven Users List
Subject: Re: Is it possible to make pom.xml simpler?
We all agree that it is really a matter of taste. That's precisely why
Maven *should* support another theme.
I definitly agree that whether attributes are more readable or not is
arguable (at best) - but why not keep both camps happy? :) (if the costs
are reasonable of course)
On 12/17/05, Alexandre Poitras [EMAIL PROTECTED] wrote:
A simple XSLT stylesheet would do the job there. You don't need maven
to support this format.
On 12/17/05, Thomas Van de Velde [EMAIL PROTECTED] wrote:
-1
I agree with Brett. This is a matter of taste. My taste goes
towards the existing solution. Writing everything on a single line
may even become less readable. Have you ever tried to read an
Eclipse .classpath file? You can hardly say that's more readeable.
I also think that mixing attributes with elements is in this case a
bad idea and would hurt overall consistency.
On 12/17/05, Srepfler Srgjan [EMAIL PROTECTED] wrote:
If your sole concern is the number of lines one must type, it is
certainly an option to have meta-pom.xml be in the format you
find most comfortable, then xslt it into the more verbose m2
pom.xml.
This argument of attributes versus elements has existed since the
dawn of [xml] time. I am not trying to argue one way or the
other, but since
m1 pom used the more verbose syntax, it eases the transition.
My USD$0.02,
-- /v\atthew
-
In fact people should develop a plugin that maps the simplified
and verbose schemas on the fly :) The advantage of using
namespaces is that you can create a your tag and map it to the
verbose tag from the official pom.
That's the way I've seen the spring guys use it for now but the
advantage that I see is that in could be much easier to extend the
pom and it would be more type safe
My 0.02MKD
--
--- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexandre Poitras
Québec, Canada
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
_
Arik Kfir[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
[m2] finalName ${version} being picked up from System properties?
Hi,
I'm using maven 2.0.1 for AndroMDA's build (its a fairly large
multiproject build).
It appears that if I have a version property in my System properties,
it sometimes gets picked up and used for the version of my project when
creating the final name (during pom interpolation I'm assuming). I
then get an unresolved dependency error because of course the version is
not the one defined as the version in my pom.xml. Is this a know issue
and shouldn't information in the pom take precedence over System
properties? I'm assuming this call in DefaultMavenProjectBuilder is the
culprit (since this context is then passed to the
RegexBasedModelInterpolator for use in project interpolation) :
// TODO: Clean this up...we're using this to 'jump' the
interpolation step for model properties not expressed in XML.
// [BP] - Can this above comment be explained?
// We don't need all the project methods that are added over
those in the model, but we do need basedir
Map context = new HashMap( System.getProperties() );
I also have a similar issue with ${basedir}, the value that sometimes
gets picked up, is the value for the previous project (which of course
breaks the build), I resorted to using ${pom.basedir} which seems to fix
things. I've tried using ${pom.version} instead of ${version} to
fix my issue with the wrong version, however it doesn't help because it
looks like the DefaultModelInheritanceAssembler sets the final name as
${artifactId}-${version} (I put some debug in that code to see what
was being set). For now I've put a hack in one of my m2 plugins to
remove the version System property (not sure where its coming from
really) so that I can get past this, but of course this isn't the best
solution :)
Thanks,
Chad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Source packages for acegisecurity
Is there a source package for acegi security? Can it be added to the repository? Thanks Srgjan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source packages for acegisecurity
You can create an upload bundle, with what it is currently in the repo + sources and specify that you only want the sources http://maven.apache.org/guides/mini/guide-ibiblio-upload.html On 12/18/05, Srepfler Srgjan [EMAIL PROTECTED] wrote: Is there a source package for acegi security? Can it be added to the repository? Thanks Srgjan - 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: [m2] Adding surefire-report = Infinite loop
Tried with Maven 2.0.1 -- no improvement :( I tried to reply to Allan's last email on this thread by confirming that I had indeed attached the mvn -X output as he had instructed and that it had got stripped somewhere in transit. So, I tried to embed the output in the email in addition to attaching it again with a txt extension. That blew up in my face 'cos it caused the email to exceed the size restriction. So, I'll send it again now -- this time only as an attachment (mvn.txt). It was generated using Maven 2.0.1. Sri -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Saturday, December 17, 2005 4:30 PM To: Maven Users List Subject: Re: [m2] Adding surefire-report = Infinite loop I think it requires maven 2.0.1 - that infinite loop bug was supposed to be fixed then. - Brett On 12/17/05, Allan Ramirez [EMAIL PROTECTED] wrote: Hi Sri, There is no attached file in your mail :) -allan Sri Sankaran wrote: Attached is the output of a run with the -X option. Other than seeing the same steps repeating, I don't see the *cause* of the problem. Sri -Original Message- From: Allan Ramirez [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 3:53 AM To: Maven Users List Subject: Re: [m2] Adding surefire-report = Infinite loop I cant replicate this issue. It is working in my copy. Can you paste the log with -X arguement? -allan Sri Sankaran wrote: I wanted to run the surefire-report:report goal as part of the test phase. So, I add the following to my pom plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdsurefire-report-maven-plugin/artifactId version2.0-beta-1/version executions execution phasetest/phase goalsgoalreport/goal/goals /execution /executions /plugin /plugins This results in an infinite loop of the test:test goal. What am I doing wrong? Sri --- -- 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] - --- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.13/200 - Release Date: 12/14/2005 - 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] + Error stacktraces are turned on. [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settings\srsank\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'c:\.devtools\maven-2.0\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [test] [INFO] [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-resources-plugin:maven-plugin:2.1 [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-compiler-plugin:maven-plugin:2.0 [DEBUG] maven-surefire-plugin: resolved to version 2.0 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-surefire-plugin:maven-plugin:2.0 [DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-model:jar:2.0 [DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: null:maven-project:jar:2.0 [DEBUG] org.apache.maven:maven-project:jar:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for
