Re: how can i compile jsps
I am getting some errors if wite the goal like this
goal name=precompile-jsp description=Precompile all JSPs into java classes,
and then into classes prereqs=war:load,java:compile
ant:mkdir dir=${maven.build.dir}/jspc/
ant:mkdir dir=${maven.build.dir}/jspc-processed/
ant:mkdir dir=${maven.build.dir}/jspc-classes/
ant:path id=jspc.classpath
ant:pathelement
location=E:/toolkit/eclipse/plugins/org.eclipse.tomcat_4.0.3/jasper-runtime.jar/
ant:pathelement
location=C:/JBuilderX/thirdparty/jakarta-tomcat-4.0.6-LE-jdk14/lib/jasper-compiler.jar/
ant:pathelement
location=E:/toolkit/eclipse/plugins/org.eclipse.tomcat_4.0.3/servlet.jar/
ant:path refid=maven.dependency.classpath/
ant:pathelement path=${maven.build.dest}/
/ant:path
ant:taskdef name=jasper2 classname=org.apache.jasper.JspC
classpathref=jspc.classpath/
ant:jasper2
webXmlFragment=${maven.build.dir}/web-fragment.xml
package=${pom.package}.jsp.${pom.artifactId}
outputDir=${maven.build.dir}/jspc
srcdir=${maven.war.src}
uriroot=${maven.war.src}
uribase=/${pom.artifactId}
verbose=2/
ant:javac
srcdir=${maven.build.dir}/jspc
destdir=${maven.build.dest}
debug=${maven.compile.debug}
deprecation=${maven.compile.deprecation}
optimize=${maven.compile.optimize}
classpathref=jspc.classpath/
/goal
Errors:-
[taskdef] [ERROR] No public no-arg constructor in class
org.apache.jasper.JspC
BUILD FAILED
File.. D:\starteam\conformia\pcm\dev\scripts\maven\maven.xml
Element... ant:taskdef
Line.. 1002
Column 102
No public no-arg constructor in class org.apache.jasper.JspC
Total time: 4 seconds
Finished at: Tue Apr 26 12:09:30 GMT+05:30 2005
Jack Tang [EMAIL PROTECTED] wrote:Hi
How about ant jspc task?
http://ant.apache.org/manual/OptionalTasks/jspc.html
/Jack
On 4/26/05, rajas kumar
wrote:
Hai all,
I need help in compiling jsps before creating war file...can any body
tell me the way how to compile.
regs,
raja.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Using Maven's Castor Plugin
Hi, I am trying to use the Maven's castor plugin for source code generation based on xsd file. When I see the documentation it talks about only one goal castor:prepare-filesystem. It also talks about a tag called castor:generate but its not clear how do I use this tag into my project. Could someone please help me with this? Thanks in advance, Dinesh
RE: Scripting Maven 1.0 with BeanShell and Jython
Hi, I'm using BeanShell in my plugin, perhaps you can find something usefull if you look at the plugin.jelly http://olofsson.homeip.net/maven-ui-plugin-site/index.html Mvh Mattias Olofsson Software Developer, M. Sc. Physics XDIN AB Gustaf Werners gata 12 SE-421 32 Västra Frölunda Office: +46 (0)31 725 10 92 mail: [EMAIL PROTECTED] This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, please notify us immediately; you should not copy it or use it for any purpose, nor disclose its contents to any other person. -Original Message- From: M. Sean Gilligan [mailto:[EMAIL PROTECTED] Sent: den 26 april 2005 02:47 To: Maven Users List Subject: Scripting Maven 1.0 with BeanShell and Jython I've been able to get BeanShell and Jython to work and documented what I did on this page: http://www.msgilligan.com/maven-scripting.html I'd still like to be able to do the following: 1) Use the ant:script tag rather than Jelly tags (for consistency) 2) Be able to read and write properties from the scripts 3) Be able to use Groovy I'll probably use BeanShell until Groovy is supported, but would if anyone knows how to read or write maven properties from the script that would be great. -- Sean -- --- M. Sean Gilligan: 831-466-9788 x11 vBlog Central : http://www.vblogcentral.com --- - 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: Using Maven's Castor Plugin
Hello Dinesh,
You'll have to:
- create a maven.xml (if you don't have already one).
- define a new goal a bit like that:
goal name=my:castor
attainGoal name=castor:prepare-filesystem/
castor:generate schema=${basedir}/xsd/some.xsd
package=com.foo.bar types=j2/
/goal
- call that goal before java:compile with:
preGoal name=java:compile
attainGoal name=ae6-web:castor/
/preGoal
- you may have to use the castorbuilder.properties file to make some
namespace/package mappins if you don't use the package attribute
(especially if you have some more complex multi-file xsd system)
And you should be done!
Guillaume
On 26/04/05, Dinesh Pandey [EMAIL PROTECTED] wrote:
Hi,
I am trying to use the Maven's castor plugin for source code generation
based on xsd file.
When I see the documentation it talks about only one goal
castor:prepare-filesystem.
It also talks about a tag called castor:generate but its not clear how do I
use this tag into my project.
Could someone please help me with this?
Thanks in advance,
Dinesh
--
Guillaume Laforge
http://glaforge.free.fr/weblog/?catid=2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven's Castor Plugin
Hi Guillaume,
I tried the exact same thing but I get the following error:
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
Fatal Error [line 3, row 87]: The prefix castor for element
castor:generate
is not bound.
org.apache.maven.MavenException: Error parsing plugin script
at
org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.j
ava:165)
at
org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.j
ava:177)
at
org.apache.maven.plugin.PluginManager.readMavenXml(PluginManager.java
:514)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
580)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
--- Nested Exception ---
org.xml.sax.SAXParseException: The prefix castor for element
castor:generate
is not bound.
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at
org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.j
ava:157)
at
org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.j
ava:177)
at
org.apache.maven.plugin.PluginManager.readMavenXml(PluginManager.java
:514)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
580)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)
You have encountered an unknown error running Maven. Please help us to
correct
this problem by following these simple steps:
- read the Maven FAQ at http://maven.apache.org/faq.html
- run the same command again with the '-e' parameter, eg maven -e jar
- search the maven-user archives for the error at
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
.org
- post the output of maven -e to JIRA at
http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up
first)
- run 'maven --info' and post the output as the environment to the bug above
Total time: 1 seconds
Finished at: Tue Apr 26 15:37:47 IST 2005
Thanks and regards,
Dinesh
-Original Message-
From: Guillaume Laforge [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 26, 2005 3:33 PM
To: Maven Users List
Subject: Re: Using Maven's Castor Plugin
Hello Dinesh,
You'll have to:
- create a maven.xml (if you don't have already one).
- define a new goal a bit like that:
goal name=my:castor
attainGoal name=castor:prepare-filesystem/
castor:generate schema=${basedir}/xsd/some.xsd
package=com.foo.bar types=j2/
/goal
- call that goal before java:compile with:
preGoal name=java:compile
attainGoal name=ae6-web:castor/
/preGoal
- you may have to use the castorbuilder.properties file to make some
namespace/package mappins if you don't use the package attribute
(especially if you have some more complex multi-file xsd system)
And you should be done!
Guillaume
On 26/04/05, Dinesh Pandey [EMAIL PROTECTED] wrote:
Hi,
I am trying to use the Maven's castor plugin for source code generation
based on xsd file.
When I see the documentation it talks about only one goal
castor:prepare-filesystem.
It also talks about a tag called castor:generate but its not clear how do
I
use this tag into my project.
Could someone please help me with this?
Thanks in advance,
Dinesh
--
Guillaume Laforge
http://glaforge.free.fr/weblog/?catid=2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
RE: ant:script tag and ANY SCRIPTING LANGUAGE
On Mon, 25 Apr 2005, M. Sean Gilligan wrote: If it's ant 1.6 or higher only, Ant 1.6.1 added built-in support for Groovy, but the script tag exists in Ant 1.5.3 and should work with JavaScript and/or BeanShell directly. Well, if it exists it should work. Try a basic build.xml using ant 1.5.3 and if that works those tags should work in maven.xml too.. you'd have to either use maven 1.1 I'd like to wait for a (beta) release before attempting Maven 1.1. Any hints as to when there might be a release? A developer will have to answer this.. I've used it and found the stability depending on the day you do a checkout.. So I understand you wanting to wait ;) or replace all ant-jar's in mavens lib/ directory with the 1.6 versions.. I don't think you can just replace the ant jars in Maven's lib with 1.6 versions -- have you done it? I've done it, works perfectly. :) I think this way you can get maven.xml to be run using ant 1.6. However, when a plugin explicitly refers to ant 1.5.3, that plugin gets run using that ant version, so you might also want to overwrite the jars in the local repository with the 1.6 versions (renaming them to 1.5). I know it's not the preferred way to go, but if you don't want to wait for maven 1.1 and you HAVE to use ant 1.6 features in maven.xml, this certainly works (at least for me - could be you get a NoClassDefFoundError or NoSuchMethodException or something when you use an obscure tag, but it's easy to revert..) I'm definitely willing to settle for BeanShell (or JavaScript if someone can tell me how to make it work. You might want to check out scripting support for Jelly. The scripting language is pluggable (defaults to Jexl), so you might be able to find a JavaScript language plugin for Jelly. -- Kenney -- Sean I have 5 scripting languages working in ANT, but cut-and-paste to maven doesn't work. I can't get the ant:script tag to work in Maven 1.0.2 with any language. If you can get one script language to work, it shouldn't be a big leap to get other ones working too. Especially since maven will do anything ant can do. If it's not working in maven, try writing it in ant first. Once you've worked out the problem in ant, it's usually little more than a cut-and-paste job to get it into maven. Adam -Original Message- From: M. Sean Gilligan [mailto:[EMAIL PROTECTED] Sent: 24 April 2005 23:03 To: users@maven.apache.org Subject: ant:script tag and Groovy Hello Maven Mavens: Using ant 1.6.1, I can use the ant script tag to run short scripts in JavaScript, Groovy, Jython, and Beanshell. (as long as the right jars are in my ant/lib directory...) I'd like to be able to do this in a maven.xml file under Maven 1.0.2. Is this possible? My first choice would be Groovy (or perhaps Beanshell) as I don't want to learn Python, and am not sure JavaScript gives me the file access that I need. (I know Groovy has its warts, but it works fairly well for me in short scripts.) I've thrashed around a bit and can't seem to get any language to work in the ant:script tag. I did manage to get the following to work: jython:script print This is a jython script print My Maven POM's name is, pom.getName() print If the POM has a name, then the context passing is working /jython:script After putting xmlns:jython=jelly:jython in the root project tag and the (correct?) jar files in Maven's path. I've looked in the maven site, the mailing lists, and done Google searches, and can't find any documentation or examples of how to do this. I thrashed around for far too long with the only progress being the jython:script test code above. I there a way to do this in Maven 1.0.2? Is it documented? If not, will Maven 1.1 (with ant 1.6.x) make it easier? Thanks, Sean -- --- M. Sean Gilligan: 831-466-9788 x11 vBlog Central : http://www.vblogcentral.com --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Maven2 ant tasks
Hi This looks like a great feature, but I'm having some problems getting it to work. I'm getting this message: *** CHECKSUM MISMATCH - currently disabled fail due to bad repository checksums *** with pretty much every dependency (all the commons-xxx packages, for example). Also, it fails when there is no pom.xml (javassist, commons-codec and many others). Any ideas? Can I disable md5 checking (assuming I would want to, of course...)? Thanks John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 ant tasks
*** CHECKSUM MISMATCH - currently disabled fail due to bad repository checksums *** This is just a warning, and can be ignored for now (as you can see, it has been disabled due to bad data in the repository). Also, it fails when there is no pom.xml (javassist, commons-codec and many others). They should have been converted over - please give us a list of the ones that are causing your problems (or file them here http://jira.codehaus.org/browse/MEV) and we'll look into correcting them. I can see that commons-codec is definitely missing data.. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Continuum 1.0 Technology Preview Available
Excellent! this is something i've been personally looking forward to for a long time. I'm glad to see that it isn't vaporware. is there a public continuum instance up anywhere (codehaus?) where we can check it out without downloading and installing? -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 2:46 PM To: [EMAIL PROTECTED]; users@maven.apache.org; dev@maven.apache.org Subject: Maven Continuum 1.0 Technology Preview Available The Maven team is pleased to announce our Technology Preview for the Continuum 1.0 release. Continuum is the Maven project's Continuous integration tool. This release offers users both an advance look at what's in Continuum 1.0 and a head start in helping to shape the final Continuum release (currently slated for early August). Continuum 1.0 features includes: o Tight integration Maven 2.x o Support for Maven 1.x o Support for Ant o Support for shell scripts o Easy to use web interface o An XML-RPC interface for integration, automation and remoting o Easy to use command line shell interface using Python and the XML-RPC interface o Pluggable project registrars o Pluggable project build triggers o Pluggable notification schemes Please note, as a Technology Preview, this release is not intended for production use. We plan to have 2-3 alphas and 1-2 betas prior to posting the release candidates, which will be followed by the final release. We welcome any and all feedback and look forward to your comments! http://maven.apache.org/continuum http://maven.apache.org/continuum/download.html -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org you are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Maven Continuum 1.0 Technology Preview Available
On 4/27/05, Ryan Sonnek [EMAIL PROTECTED] wrote: Excellent! this is something i've been personally looking forward to for a long time. I'm glad to see that it isn't vaporware. is there a public continuum instance up anywhere (codehaus?) where we can check it out without downloading and installing? Not presently - we aim to have something in the next few weeks. It is very easy to install locally: untar and run ./bin/plexus.sh|bat, then tune in to http://localhost:8080/continuum/ (there is plenty more you can configure, which is in the docs). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Continuum 1.0 Technology Preview Available
Having some trouble running continuum when installed inside a path
containing spaces. I'm using cygwin and make the following changes to
bin/plexus.sh to get things running:
116c116
-classpath ${PLEXUS_HOME}/core/boot/classworlds-1.1-alpha-1.jar \
---
-classpath ${PLEXUS_HOME}/core/boot/classworlds-*.jar \
122c122
$MAIN_CLASS ${CONF}
---
$MAIN_CLASS ${CONF}
But get the following error during startup:
[INFO] Starting XML-RPC listener on port '8000'.
Error while deploying application
'continuum-plexus-application-1.0-alpha-1-application.jar'.
java.net.URISyntaxException: Illegal character in path at index 16:
file:/c:/Program
Files/continuum-1.0-alpha-1/apps/continuum-plexus-application-1.0-alpha-1-application.jar
Cheers,
Mark
On 4/26/05, Brett Porter [EMAIL PROTECTED] wrote:
On 4/27/05, Ryan Sonnek [EMAIL PROTECTED] wrote:
Excellent! this is something i've been personally looking forward to
for a long time. I'm glad to see that it isn't vaporware. is there a
public continuum instance up anywhere (codehaus?) where we can check it
out without downloading and installing?
Not presently - we aim to have something in the next few weeks. It is
very easy to install locally: untar and run ./bin/plexus.sh|bat, then
tune in to http://localhost:8080/continuum/ (there is plenty more you
can configure, which is in the docs).
Cheers,
Brett
-
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: ant:script tag and Groovy
Hello Sean, On 25/04/05, M. Sean Gilligan [EMAIL PROTECTED] wrote: [snip] My first choice would be Groovy (or perhaps Beanshell) as I don't want to learn Python, and am not sure JavaScript gives me the file access that I need. (I know Groovy has its warts, but it works fairly well for me in short scripts.) [snip] I managed to use Groovy scripts inside Maven with the Groovy Ant task which will be shipping in the next version of Groovy (it's currently in CVS head only). So if you want to use some Groovy code in your build, you'll have to build Groovy from sources, or wait for a few weeks the next release (jsr-02). I've had hard times trying to find a solution to acces the POM and other objects, but I've managed to find a very ugly workaround to make that possible: ?xml version=1.0 encoding=UTF-8? project default=groovy xmlns:ant=jelly:ant goal name=groovy ant:taskdef name=groovy classname=org.codehaus.groovy.ant.Groovy classpathref=maven.dependency.classpath/ ant:groovy def contextField = project.propsHandler.class.getDeclaredField(context) contextField.setAccessible(true) def context = contextField.get(project.propsHandler) println context.project.class /ant:groovy /goal /project Unfortunately, the GrantProject instance (here the variable project) has got a context which is private, and that I could only access through the setAccessible(true) magic. What a pain... I wonder why there's no getter on the context! That would be so much better! In my project.xml, I've added the dependency on groovy-all-.jar which I've added manually to my local repository (since the next version of Groovy is not yet out in the wild) : dependency groupIdgroovy/groupId artifactIdgroovy-all/artifactId version1.0-jsr-02-SNAPSHOT/version properties classloaderroot/classloader /properties /dependency And after that... that works. We could probably write a small Groovy Maven plugin for that, to simplify the dirty stuffs. Question to Maven developers: Why can't we access the context within the propsHandler of GrantProject? That would simplify the job :-) -- Guillaume Laforge http://glaforge.free.fr/weblog/?catid=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Continuum 1.0 Technology Preview Available
Thanks - I'm on Cygwin, but I hadn't tried spaces... can you file it
in JIRA by any chance?
also, there is a continuum-users@maven.apache.org list for additional
questions so that we don't flood the main Maven lists.
Cheers,
Brett
On 4/27/05, Mark Hobson [EMAIL PROTECTED] wrote:
Having some trouble running continuum when installed inside a path
containing spaces. I'm using cygwin and make the following changes to
bin/plexus.sh to get things running:
116c116
-classpath ${PLEXUS_HOME}/core/boot/classworlds-1.1-alpha-1.jar \
---
-classpath ${PLEXUS_HOME}/core/boot/classworlds-*.jar \
122c122
$MAIN_CLASS ${CONF}
---
$MAIN_CLASS ${CONF}
But get the following error during startup:
[INFO] Starting XML-RPC listener on port '8000'.
Error while deploying application
'continuum-plexus-application-1.0-alpha-1-application.jar'.
java.net.URISyntaxException: Illegal character in path at index 16:
file:/c:/Program
Files/continuum-1.0-alpha-1/apps/continuum-plexus-application-1.0-alpha-1-application.jar
Cheers,
Mark
On 4/26/05, Brett Porter [EMAIL PROTECTED] wrote:
On 4/27/05, Ryan Sonnek [EMAIL PROTECTED] wrote:
Excellent! this is something i've been personally looking forward to
for a long time. I'm glad to see that it isn't vaporware. is there a
public continuum instance up anywhere (codehaus?) where we can check it
out without downloading and installing?
Not presently - we aim to have something in the next few weeks. It is
very easy to install locally: untar and run ./bin/plexus.sh|bat, then
tune in to http://localhost:8080/continuum/ (there is plenty more you
can configure, which is in the docs).
Cheers,
Brett
-
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: Maven2 ant tasks
Hi, These are the problems I came across while setting up my current projects to use the tasks: 1. ant-optional has problems (can't decide if it belongs to the group ant or ant-optional). Actually, as a general question, would it not be better to have all the commons downloads in the group commons, rather than duplicating the actual library name (commons-logging/commons-logging)? 2. javassist 3.0 and commons-codec 1.3 have no pom.xml (and some others too, but I forgot to note them down) 3. mysql-connector-java has the wrong jar name (xx-stable-bin...) 4. commons-configuration has all kinds of problems, with the mockobjects:mockobjects... dependency and a lot of others besides - apparently secondary dependencies - I can't be bothered to list them all, there are just too many (in the end, I just hacked the local pom.xml to get rid of them). Is there any way of providing an 'at-least' definition? For example, I could specify that my project required at least version 2.2 of xerces, and maven/ant would make sure I had that version or later. It would be great to avoid having 73 versions of xerces in the local repository just because developers don't upgrade to the latest dot version in their pom (or in their projects). If project owners really think there will be compatibility problems, perhaps they could specify a general version (for example xerces-1.*, xerces-2.*) or a range (xerces-1.4:xerces-1.6). This might reduce the flood of downloads that seems to accompany every maven project I build. I don't want to be negative - I love this feature of maven and I am very happy that it is now available to us ant users. Best wishes John -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 3:17 PM To: Maven Users List Subject: Re: Maven2 ant tasks *** CHECKSUM MISMATCH - currently disabled fail due to bad repository checksums *** This is just a warning, and can be ignored for now (as you can see, it has been disabled due to bad data in the repository). Also, it fails when there is no pom.xml (javassist, commons-codec and many others). They should have been converted over - please give us a list of the ones that are causing your problems (or file them here http://jira.codehaus.org/browse/MEV) and we'll look into correcting them. I can see that commons-codec is definitely missing data.. Cheers, Brett - 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: Maven2 ant tasks
1. ant-optional has problems (can't decide if it belongs to the group ant or ant-optional). group is ant, artifact id is ant-optional. Actually, as a general question, would it not be better to have all the commons downloads in the group commons, rather than duplicating the actual library name (commons-logging/commons-logging)? Definitely, but this is a historical issue. We will now be working with projects to improve the quality of their exported metadata and try and introduce some consistency. 2. javassist 3.0 and commons-codec 1.3 have no pom.xml (and some others too, but I forgot to note them down) I'm working on commons-codec now. I'll note the others down. 4. commons-configuration has all kinds of problems, with the mockobjects:mockobjects... dependency and a lot of others besides - apparently secondary dependencies - I can't be bothered to list them all, there are just too many (in the end, I just hacked the local pom.xml to get rid of them). Right, I've already spoken to them about that and it seems we may need to just hack the POM in our copy as well for the moment. Is there any way of providing an 'at-least' definition? For example, I could specify that my project required at least version 2.2 of xerces, and maven/ant would make sure I had that version or later. It would be great to avoid having 73 versions of xerces in the local repository just because developers don't upgrade to the latest dot version in their pom (or in their projects). If project owners really think there will be compatibility problems, perhaps they could specify a general version (for example xerces-1.*, xerces-2.*) or a range (xerces-1.4:xerces-1.6). This might reduce the flood of downloads that seems to accompany every maven project I build. We are planning that feature for the June release at the moment. I don't want to be negative - I love this feature of maven and I am very happy that it is now available to us ant users. No problem. I realise our docs also don't explain things for non-Maven users very well, so thanks for the feedback. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using local dependencies
Hi, I'm building a project using SNAPSHOT dependencies. Those are downloaded at every build which is fine because I always want the last version. But the problem is that the remote server is often down so when it's the case I'd like to build my project using local copies of those dependencies, because when it tries to download them it slows down the build process. Is there a command line option to do so with Maven 1 ? Thx in advance -- Sebastien ARBOGAST - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
usage: plexus plexus.xml
Just downloaded zip file. Unpacked per instructions, and when I try to execute plexus.bat from the command line, I get the message: usage: plexus plexus.xml TIA Bryce
Re: Using local dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 have you tried offline mode? just use the '-o' (no quotes) command-line switch... - -john Sebastien Arbogast wrote: Hi, I'm building a project using SNAPSHOT dependencies. Those are downloaded at every build which is fine because I always want the last version. But the problem is that the remote server is often down so when it's the case I'd like to build my project using local copies of those dependencies, because when it tries to download them it slows down the build process. Is there a command line option to do so with Maven 1 ? Thx in advance -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCboqkK3h2CZwO/4URAnM6AJwIpMr3wwBrzClbs6ZQL4NjKn0RzwCgmObp V5c7ud/L1MJOao6vH3eQdGk= =ULFg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using local dependencies
No I hadn't tried yet bu it's exactly what I was looking for. Thank you very much. On 4/26/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 have you tried offline mode? just use the '-o' (no quotes) command-line switch... - -john Sebastien Arbogast wrote: Hi, I'm building a project using SNAPSHOT dependencies. Those are downloaded at every build which is fine because I always want the last version. But the problem is that the remote server is often down so when it's the case I'd like to build my project using local copies of those dependencies, because when it tries to download them it slows down the build process. Is there a command line option to do so with Maven 1 ? Thx in advance -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCboqkK3h2CZwO/4URAnM6AJwIpMr3wwBrzClbs6ZQL4NjKn0RzwCgmObp V5c7ud/L1MJOao6vH3eQdGk= =ULFg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sebastien ARBOGAST - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] POM inheritance
Hi all, I have a question about which elements of the POM are inherited by derived POM's. In my parent POM I have a build section which specifies the source directory and some parameters for the java compiler: build sourceDirectorysrc/sourceDirectory plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version1.0-alpha-2-SNAPSHOT/version configuration source1.5/source target1.5/target /configuration /plugin /plugins /build In a derived POM, the source directoriy is different, so a new build section is specified: build sourceDirectorymodule/src/sourceDirectory /build The overridden source directory is effectuated in this second POM, but it appears that the java compiler settings have disappeared (it starts e.g. complaining about JDK 1.4 features like assertions). If I do not specify a build section in the derived POM, the settings of the base POM are inherited. It appears that the build section is (completely) inherited if it is not present in the derived POM, but if a build section is specified in the derived POM, everything from the base POM is thrown away and only the settings of the derived POM are used. Is this correct? Thanks in advance. Peter van de Hoef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
Okay, I have added the issue: http://jira.codehaus.org/browse/MNG-357 Thanks for your time! - Peter John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's entirely possible that our inheritance mechanism isn't completely right on this...can you please file a JIRA issue, and I'll look at it when I have some slack time. Thanks, - -john Peter van de Hoef wrote: Hi all, I have a question about which elements of the POM are inherited by derived POM's. In my parent POM I have a build section which specifies the source directory and some parameters for the java compiler: build sourceDirectorysrc/sourceDirectory plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version1.0-alpha-2-SNAPSHOT/version configuration source1.5/source target1.5/target /configuration /plugin /plugins /build In a derived POM, the source directoriy is different, so a new build section is specified: build sourceDirectorymodule/src/sourceDirectory /build The overridden source directory is effectuated in this second POM, but it appears that the java compiler settings have disappeared (it starts e.g. complaining about JDK 1.4 features like assertions). If I do not specify a build section in the derived POM, the settings of the base POM are inherited. It appears that the build section is (completely) inherited if it is not present in the derived POM, but if a build section is specified in the derived POM, everything from the base POM is thrown away and only the settings of the derived POM are used. Is this correct? Thanks in advance. Peter van de Hoef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbpDFK3h2CZwO/4URAiSnAJ9PEOiV+B3sG8oLg7dYQb/v8eSYHgCfYYdi jEQmZWa6JwLyEDZhSoYiw3E= =gP0+ -END PGP SIGNATURE- - 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]
My own repo is consulted for parent POM's but for plugins
Hi all, I have the following situation. A parent POM (parent) a child POM (child) and a plugin (plugin). The child inherits from the parent and uses the plugin like: artifactIdchild/artifactId ... parent artifactIdparent/artifactId ... /parent build plugins plugin artifactIdplugin/artifactId ... /plugin /plugins /build repositories repository idmy_own_repo/id ... /repository /repositories Furthermore I have my own remote repository (my_own_repo) to which these artifacts have sucessfully been deployed. This repository is declared in the child POM. Now, when I remove all three artifacts from the local repository and try to (re)build the child, the parent is automatically downloaded from the remote repository but the plugin not. It seems that plugins are only downloaded from the Maven repository and not from user defined repo's. Other dependencies are correctly downloaded from the user repository. If I remove the plugins section from the build section and instead, declare a dependency on the plugin like: dependencies dependency artifactIdplugin/artifactId ... /dependency /dependencies then the plugin is downloaded correctly from my own repo. If the plugin is specified in both the dependencies and the plugins section, Maven will only consult the Maven repository. It appears that the plugins section has a higher priority than the dependencies section. Hope anybody can shed some light on this. Thanks in advance, Peter van de Hoef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote: Hi all, I have a question about which elements of the POM are inherited by derived POM's. The law on inheritance resides here: http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven- project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217sortdir=downview=log In my parent POM I have a build section which specifies the source directory and some parameters for the java compiler: build sourceDirectorysrc/sourceDirectory plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version1.0-alpha-2-SNAPSHOT/version configuration source1.5/source target1.5/target /configuration /plugin /plugins /build In a derived POM, the source directoriy is different, so a new build section is specified: build sourceDirectorymodule/src/sourceDirectory /build The overridden source directory is effectuated in this second POM, but it appears that the java compiler settings have disappeared (it starts e.g. complaining about JDK 1.4 features like assertions). If I do not specify a build section in the derived POM, the settings of the base POM are inherited. It appears that the build section is (completely) inherited if it is not present in the derived POM, but if a build section is specified in the derived POM, everything from the base POM is thrown away and only the settings of the derived POM are used. Is this correct? We selectively choose what to inherit and the configuration for the plug-ins are a little trickier because they free form configurations essentially. We need to do a more careful merge of the configurations but this might not work generally so if we need to allow the plugin to determine how a configuration should be inherited then we'll probably have to come up with some way to decide this using notations we have for plugins. Anyway, I see you posted a JIRA issue so we'll take a look at it. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Test-plugin versus jcoverage-plugin?
I am even now getting jcoverage to work with our many projects, and have run into this sort of issue a few times. So far, I've been able to get things to work, but it seems it's complaning about something different every time. What sorts of errors are you getting? ..David.. -Original Message- From: Darren Hartford [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 12:36 PM To: Maven Users List Subject: Test-plugin versus jcoverage-plugin? Hey all, Rather weird and obtuse problem. Running Maven 1.0.2 with maven-test-plugin 1.6.2 and maven-jcoverage-plugin 1.0.9 on Sun jdk 5.0. When running 'maven test' for some unit tests that I have (and known to work), everything runs fine. Running the junit-report plugin returns nice information for the site. However, when I run 'maven jcoverage', all the tests fail, and I can't get code-coverage report. What is happening? -D - 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] POM inheritance
Thanks for your reply.
Now I see why the complete build section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except plugins
/}
I understand that inheriting plugins is problematic, since Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete plugins section if it
is not specified in the child, just like you do with resources and
testResources?
That seems IMHO more in line with the situation where there is no
build section at all. In that way it is possible to 'tweak' the build
settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217sortdir=downview=log
In my parent POM I have a build section which specifies the source
directory and some parameters for the java compiler:
build
sourceDirectorysrc/sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version1.0-alpha-2-SNAPSHOT/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build
In a derived POM, the source directoriy is different, so a new build
section is specified:
build
sourceDirectorymodule/src/sourceDirectory
/build
The overridden source directory is effectuated in this second POM, but
it appears that the java compiler settings have disappeared (it starts
e.g. complaining about JDK 1.4 features like assertions). If I do not
specify a build section in the derived POM, the settings of the base
POM are inherited.
It appears that the build section is (completely) inherited if it is
not present in the derived POM, but if a build section is specified in
the derived POM, everything from the base POM is thrown away and only
the settings of the derived POM are used.
Is this correct?
We selectively choose what to inherit and the configuration for the
plug-ins are a little trickier because they free form configurations
essentially. We need to do a more careful merge of the configurations
but this might not work generally so if we need to allow the plugin to
determine how a configuration should be inherited then we'll probably
have to come up with some way to decide this using notations we have for
plugins. Anyway, I see you posted a JIRA issue so we'll take a look at
it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: My own repo is consulted for parent POM's but for plugins
Done. http://jira.codehaus.org/browse/MNG-358 Jason van Zyl wrote: On Tue, 2005-04-26 at 22:26 +0200, Peter van de Hoef wrote: Hi all, I have the following situation. A parent POM (parent) a child POM (child) and a plugin (plugin). The child inherits from the parent and uses the plugin like: Can you post a JIRA issue, we do have separate repositories set for downloading plug-ins so we'll need to fix the inheritance and default population for the plug-ins remote repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My own repo is consulted for parent POM's but for plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We actually have the repositories for plugin download specified separately in the pom, using the pluginRepositories/ stanza. It looks similar to (using your original example): pluginRepositories repository idmy_own_repo/id ... /repository /pluginRepositories If this doesn't take care of the problem, let me know. Cheers, - -john Peter van de Hoef wrote: Done. http://jira.codehaus.org/browse/MNG-358 Jason van Zyl wrote: On Tue, 2005-04-26 at 22:26 +0200, Peter van de Hoef wrote: Hi all, I have the following situation. A parent POM (parent) a child POM (child) and a plugin (plugin). The child inherits from the parent and uses the plugin like: Can you post a JIRA issue, we do have separate repositories set for downloading plug-ins so we'll need to fix the inheritance and default population for the plug-ins remote repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbrrMK3h2CZwO/4URAuKwAJ9N9SkXbLKzoNxY1fqVCFIe5oK/YACdEr7S az35RKlDQZuPAQCCCNhRxBs= =m8Ar -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, I forgot all about the design decisions surrounding this... :)
Actually, our original decision was to disallow inheritance of any
plugin configuration, since plugin configuration can (and usually will)
modify the build lifecycle for that project. In light of this, inherited
plugin configuration could lead to somewhat counter-intuitive build
behavior.
We have a pluginManagement/ section of the POM for common
configuration of plugins for use within a typical multiproject-style
setup. It would be used like this:
parent-pom.xml
- ---
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugin/groupId
artifactIdmaven-something-plugin/artifactId
version1.4/version
configuration
someParamsomeValue/someParam
/configuration
/plugin
/plugins
/pluginManagement
...
- ---
child-pom.xml
- ---
...
parent
groupIdtest/groupId !-- Pretend that all of
artifactIdtest-root/artifactId| this resolves to the
version1.0/version| parent-pom.xml above --
/parent
...
build
plugins
plugin
groupIdorg.apache.maven.plugin/groupId !-- groupId,
artifactIdmaven-something-plugin/artifactId | artifactId
/plugin | enough here.
--
/build
...
- ---
If you need to override some setting from the pluginManagement section,
just specify it locally; more local specification in an inheritance
hierarchy wins.
Will this solve your problem?
HTH,
john
Peter van de Hoef wrote:
Thanks for your reply.
Now I see why the complete build section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except plugins
/}
I understand that inheriting plugins is problematic, since Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete plugins section if it
is not specified in the child, just like you do with resources and
testResources?
That seems IMHO more in line with the situation where there is no
build section at all. In that way it is possible to 'tweak' the build
settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217sortdir=downview=log
In my parent POM I have a build section which specifies the source
directory and some parameters for the java compiler:
build
sourceDirectorysrc/sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version1.0-alpha-2-SNAPSHOT/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build
In a derived POM, the source directoriy is different, so a new
build section is specified:
build
sourceDirectorymodule/src/sourceDirectory
/build
The overridden source directory is effectuated in this second POM,
but it appears that the java compiler settings have disappeared (it
starts e.g. complaining about JDK 1.4 features like assertions). If I
do not specify a build section in the derived POM, the settings of
the base POM are inherited.
It appears that the build section is (completely) inherited if it
is not present in the derived POM, but if a build section is
specified in the derived POM, everything from the base POM is thrown
away and only the settings of the derived POM are used.
Is this correct?
We selectively choose what to inherit and the configuration for the
plug-ins are a little trickier because they free form configurations
essentially. We need to do a more careful merge of the configurations
but this might not work generally so if we need to allow the plugin to
determine how a configuration should be inherited then we'll probably
have to come up with some way to decide this using notations we have for
plugins. Anyway, I see you posted a JIRA issue so we'll take a look at
it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: My own repo is consulted for parent POM's but for plugins
On Tue, 2005-04-26 at 18:03 -0400, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We actually have the repositories for plugin download specified separately in the pom, using the pluginRepositories/ stanza. It looks similar to (using your original example): pluginRepositories repository idmy_own_repo/id ... /repository /pluginRepositories If this doesn't take care of the problem, let me know. Sure, but maybe it would be nice to default the plug-in repositories to the standard repository settings if nothing exists for the plug-in repo settings. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My own repo is consulted for parent POM's but for plugins
Yes, it works! It appears, by the way, that the child of pluginRepositories is pluginRepository instead of repository. Thank you very much for your help. - Peter John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We actually have the repositories for plugin download specified separately in the pom, using the pluginRepositories/ stanza. It looks similar to (using your original example): pluginRepositories repository idmy_own_repo/id ... /repository /pluginRepositories If this doesn't take care of the problem, let me know. Cheers, - -john Peter van de Hoef wrote: Done. http://jira.codehaus.org/browse/MNG-358 Jason van Zyl wrote: On Tue, 2005-04-26 at 22:26 +0200, Peter van de Hoef wrote: Hi all, I have the following situation. A parent POM (parent) a child POM (child) and a plugin (plugin). The child inherits from the parent and uses the plugin like: Can you post a JIRA issue, we do have separate repositories set for downloading plug-ins so we'll need to fix the inheritance and default population for the plug-ins remote repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbrrMK3h2CZwO/4URAuKwAJ9N9SkXbLKzoNxY1fqVCFIe5oK/YACdEr7S az35RKlDQZuPAQCCCNhRxBs= =m8Ar -END PGP SIGNATURE- - 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] Multiproject Dependecies
Well I can't vote twice ;-) but I'd love to hear any comments about how to work with eclipse. Come on some of you maven developers guys secretly use eclipse sometimes right ? Thanks, jmp -Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 7:37 AM To: Maven Users List Subject: Re: [m2] Multiproject Dependecies I'm stuck with the same usecase (flat project layout). I filed this as jira issue as http://jira.codehaus.org/browse/MNG-359 since I have not seen anymore info on the mailing list. Brett Porter wrote: You are (mostly) correct. The ordering is currently by dependencies, then alphabetical. It should be in the following order: - dependencies - parent relationships - module ordering We haven't noticed, as we consider the best practice to be that the parent you extend is always the directory one level up. Nevertheless, I will file this in JIRA. - Brett What is the suggested best practice for those of us who have to live with eclipse's insistence of flat directory structure, but also want to continue to use multiproject. This was easy to do in M1 Thanks for any suggestions (and any JIRA issues I can vote on ;-) Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] POM inheritance
As this *VITAL* information flies by on the mailing list, is there anyone
updating the docs.
I'd be happy to work up some of it into confluence or some such if that will
help
Matthew
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 27, 2005 8:14 AM
To: Maven Users List
Subject: Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, I forgot all about the design decisions surrounding this... :)
Actually, our original decision was to disallow inheritance
of any plugin configuration, since plugin configuration can
(and usually will) modify the build lifecycle for that
project. In light of this, inherited plugin configuration
could lead to somewhat counter-intuitive build behavior.
We have a pluginManagement/ section of the POM for common
configuration of plugins for use within a typical
multiproject-style setup. It would be used like this:
parent-pom.xml
- ---
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugin/groupId
artifactIdmaven-something-plugin/artifactId
version1.4/version
configuration
someParamsomeValue/someParam
/configuration
/plugin
/plugins
/pluginManagement
...
- ---
child-pom.xml
- ---
...
parent
groupIdtest/groupId !-- Pretend that all of
artifactIdtest-root/artifactId| this resolves to the
version1.0/version| parent-pom.xml above --
/parent
...
build
plugins
plugin
groupIdorg.apache.maven.plugin/groupId !-- groupId,
artifactIdmaven-something-plugin/artifactId | artifactId
/plugin |
enough here.
--
/build
...
- ---
If you need to override some setting from the
pluginManagement section, just specify it locally; more local
specification in an inheritance hierarchy wins.
Will this solve your problem?
HTH,
john
Peter van de Hoef wrote:
Thanks for your reply.
Now I see why the complete build section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except plugins
/}
I understand that inheriting plugins is problematic, since
Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete plugins
section if
it is not specified in the child, just like you do with resources
and testResources?
That seems IMHO more in line with the situation where there is no
build section at all. In that way it is possible to 'tweak' the
build settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are
inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultMod
elInheritanceAssembler.java?rev=164217sortdir=downview=log
In my parent POM I have a build section which specifies
the source
directory and some parameters for the java compiler:
build
sourceDirectorysrc/sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version1.0-alpha-2-SNAPSHOT/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build
In a derived POM, the source directoriy is different, so a new
build section is specified:
build
sourceDirectorymodule/src/sourceDirectory
/build
The overridden source directory is effectuated in this
second POM,
but it appears that the java compiler settings have
disappeared (it
starts e.g. complaining about JDK 1.4 features like
assertions). If
I do not specify a build section in the derived POM,
the settings
of the base POM are inherited.
It appears that the build section is (completely)
inherited if it
is not present in the derived POM, but if a build section is
specified in the derived POM, everything from the base
POM is thrown
away and only the settings of the derived POM are used.
Is this correct?
We selectively choose what to inherit and the
configuration for the
plug-ins are a little trickier because
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I actually am working on doco for the various management features. I
know this is vital, and it's not escaping in the confusion. The
documentation is coming, please bear with us. This is still pre-beta
software, after all...
- -john
J. Matthew Pryor wrote:
As this *VITAL* information flies by on the mailing list, is there anyone
updating the docs.
I'd be happy to work up some of it into confluence or some such if that will
help
Matthew
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 27, 2005 8:14 AM
To: Maven Users List
Subject: Re: [m2] POM inheritance
Sorry, I forgot all about the design decisions surrounding this... :)
Actually, our original decision was to disallow inheritance
of any plugin configuration, since plugin configuration can
(and usually will) modify the build lifecycle for that
project. In light of this, inherited plugin configuration
could lead to somewhat counter-intuitive build behavior.
We have a pluginManagement/ section of the POM for common
configuration of plugins for use within a typical
multiproject-style setup. It would be used like this:
parent-pom.xml
---
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugin/groupId
artifactIdmaven-something-plugin/artifactId
version1.4/version
configuration
someParamsomeValue/someParam
/configuration
/plugin
/plugins
/pluginManagement
...
---
child-pom.xml
---
...
parent
groupIdtest/groupId !-- Pretend that all of
artifactIdtest-root/artifactId| this resolves to the
version1.0/version| parent-pom.xml above --
/parent
...
build
plugins
plugin
groupIdorg.apache.maven.plugin/groupId !-- groupId,
artifactIdmaven-something-plugin/artifactId | artifactId
/plugin |
enough here.
--
/build
...
---
If you need to override some setting from the
pluginManagement section, just specify it locally; more local
specification in an inheritance hierarchy wins.
Will this solve your problem?
HTH,
john
Peter van de Hoef wrote:
Thanks for your reply.
Now I see why the complete build section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except plugins
/}
I understand that inheriting plugins is problematic, since
Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete plugins
section if
it is not specified in the child, just like you do with resources
and testResources?
That seems IMHO more in line with the situation where there is no
build section at all. In that way it is possible to 'tweak' the
build settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are
inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultMod
elInheritanceAssembler.java?rev=164217sortdir=downview=log
In my parent POM I have a build section which specifies
the source
directory and some parameters for the java compiler:
build
sourceDirectorysrc/sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version1.0-alpha-2-SNAPSHOT/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build
In a derived POM, the source directoriy is different, so a new
build section is specified:
build
sourceDirectorymodule/src/sourceDirectory
/build
The overridden source directory is effectuated in this
second POM,
but it appears that the java compiler settings have
disappeared (it
starts e.g. complaining about JDK 1.4 features like
assertions). If
I do not specify a build section in the derived POM,
the settings
of the base POM are inherited.
It appears that the build section is (completely)
inherited if it
is not present in the derived POM, but if a build section is
specified in the derived POM, everything from the base
POM is thrown
away and only the settings of
RE: [m2] POM inheritance
I actually am working on doco for the various management features. I know this is vital, and it's not escaping in the confusion. The documentation is coming, please bear with us. This is still pre-beta software, after all... Totally understood, hence the offer of help. I very much appreciate that you guys are doing a stellar job here. Being practical, out in the wild is out in the wild and no amount of hand waving and beta-warning will prevent some people from forming impressions. I think it is fair to say that the importance of great documentation can't be over-estimated so I'd be happy to help out anywhere it might be needed. Imagine beta-software with release quality docs ;-) Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've started writing a large-project management overview, and I'm queued up on the managedDependencies doc (I have a blog entry waiting to go out for when it's done ;) Beyond that, pleased to have the help! - -john Brett Porter wrote: Being practical, out in the wild is out in the wild and no amount of hand waving and beta-warning will prevent some people from forming impressions. I think it is fair to say that the importance of great documentation can't be over-estimated so I'd be happy to help out anywhere it might be needed. We'll take you up on that - thanks for the offer. http://maven.apache.org/maven2/docs-required.html Just let us know what you'd like to work on so we make sure we aren't conflicting. John, have you started on the management doco already? Imagine beta-software with release quality docs ;-) Sure - we've made a commitment to work on that. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbtFhK3h2CZwO/4URAjEiAJ44+WkP0cmlvXGHA9bmM0a7lJ8SEQCfaPhe 2yeRuUS3fypHL0uNsL7BXms= =ef31 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
Tell me when we should take this off-list, but are: # plugin management # plugin configuration safe areas to work? That is the basic topic we were discussing. Also what format should I work in? Cheers, jmp --- John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've started writing a large-project management overview, and I'm queued up on the managedDependencies doc (I have a blog entry waiting to go out for when it's done ;) Beyond that, pleased to have the help! - -john Brett Porter wrote: Being practical, out in the wild is out in the wild and no amount of hand waving and beta-warning will prevent some people from forming impressions. I think it is fair to say that the importance of great documentation can't be over-estimated so I'd be happy to help out anywhere it might be needed. We'll take you up on that - thanks for the offer. http://maven.apache.org/maven2/docs-required.html Just let us know what you'd like to work on so we make sure we aren't conflicting. John, have you started on the management doco already? Imagine beta-software with release quality docs ;-) Sure - we've made a commitment to work on that. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbtFhK3h2CZwO/4URAjEiAJ44+WkP0cmlvXGHA9bmM0a7lJ8SEQCfaPhe 2yeRuUS3fypHL0uNsL7BXms= =ef31 -END PGP SIGNATURE- - 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] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think those are perfect places to start, and we're working in xdoc. dunno if you're familiar with that from m1, but it's a modified version of html with some shorthands for document layout...let me know if you have questions. Brett, any other thoughts? - -john J. Matthew Pryor wrote: Tell me when we should take this off-list, but are: # plugin management # plugin configuration safe areas to work? That is the basic topic we were discussing. Also what format should I work in? Cheers, jmp --- John Casey [EMAIL PROTECTED] wrote: I've started writing a large-project management overview, and I'm queued up on the managedDependencies doc (I have a blog entry waiting to go out for when it's done ;) Beyond that, pleased to have the help! -john Brett Porter wrote: Being practical, out in the wild is out in the wild and no amount of hand waving and beta-warning will prevent some people from forming impressions. I think it is fair to say that the importance of great documentation can't be over-estimated so I'd be happy to help out anywhere it might be needed. We'll take you up on that - thanks for the offer. http://maven.apache.org/maven2/docs-required.html Just let us know what you'd like to work on so we make sure we aren't conflicting. John, have you started on the management doco already? Imagine beta-software with release quality docs ;-) Sure - we've made a commitment to work on that. - Brett - 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbwsvK3h2CZwO/4URAkrgAJ49L/pG8BG/iwYZjIC0AYhrsLzluQCfeYsz jBr1m6EGfq+qUjxEXLBvY6U= =hIRH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 ant tasks
commons-codec is fixed. On 4/27/05, Brett Porter [EMAIL PROTECTED] wrote: 1. ant-optional has problems (can't decide if it belongs to the group ant or ant-optional). group is ant, artifact id is ant-optional. Actually, as a general question, would it not be better to have all the commons downloads in the group commons, rather than duplicating the actual library name (commons-logging/commons-logging)? Definitely, but this is a historical issue. We will now be working with projects to improve the quality of their exported metadata and try and introduce some consistency. 2. javassist 3.0 and commons-codec 1.3 have no pom.xml (and some others too, but I forgot to note them down) I'm working on commons-codec now. I'll note the others down. 4. commons-configuration has all kinds of problems, with the mockobjects:mockobjects... dependency and a lot of others besides - apparently secondary dependencies - I can't be bothered to list them all, there are just too many (in the end, I just hacked the local pom.xml to get rid of them). Right, I've already spoken to them about that and it seems we may need to just hack the POM in our copy as well for the moment. Is there any way of providing an 'at-least' definition? For example, I could specify that my project required at least version 2.2 of xerces, and maven/ant would make sure I had that version or later. It would be great to avoid having 73 versions of xerces in the local repository just because developers don't upgrade to the latest dot version in their pom (or in their projects). If project owners really think there will be compatibility problems, perhaps they could specify a general version (for example xerces-1.*, xerces-2.*) or a range (xerces-1.4:xerces-1.6). This might reduce the flood of downloads that seems to accompany every maven project I build. We are planning that feature for the June release at the moment. I don't want to be negative - I love this feature of maven and I am very happy that it is now available to us ant users. No problem. I realise our docs also don't explain things for non-Maven users very well, so thanks for the feedback. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven's Castor Plugin
I am still getting this issue. Could anyone please help me? Thanks, Dinesh Pandey, -Original Message- From: Guillaume Laforge [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 4:31 PM To: Maven Users List Subject: Re: Using Maven's Castor Plugin You'll have to specify the castor namespace: project xmlns:castor=castor ... And add some dependencies as well, such as castor, xerces, and a few commons-xxx. I don't know them by heart. Guillaume On 26/04/05, Dinesh Pandey [EMAIL PROTECTED] wrote: Hi Guillaume, I tried the exact same thing but I get the following error: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 Fatal Error [line 3, row 87]: The prefix castor for element castor:generate is not bound. -- Guillaume Laforge http://glaforge.free.fr/weblog/?catid=2 - 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]
