first-timer build error
Hi, I am trying to build maven from cvs, and am receiving compile errors during the first phase of the compiling. I am using the ant -f build-bootstrap.xml command. The compilation error is the following; [javac] E:\sandbox\maven\src\java\org\apache\maven\DefaultProjectMarshaller.java :72: package org.xmlpull.v1 does not exist [javac] import org.xmlpull.v1.XmlPullParserFactory; I am using ant 1.6.0 and 1.6.1. Can you please suggest what this error may be? Thank you in advance. With kind regards, Mathew Kuppe
Re: first-timer build error
You must use MAVEN_1.0_BRANCH in cvs. The HEAD isn't for users for the moment. The 1.0 branch is the future rc2 that will be release in few days. Emmanuel - Original Message - From: Mathew Kuppe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 13, 2004 11:15 AM Subject: first-timer build error Hi, I am trying to build maven from cvs, and am receiving compile errors during the first phase of the compiling. I am using the ant -f build-bootstrap.xml command. The compilation error is the following; [javac] E:\sandbox\maven\src\java\org\apache\maven\DefaultProjectMarshaller.java :72: package org.xmlpull.v1 does not exist [javac] import org.xmlpull.v1.XmlPullParserFactory; I am using ant 1.6.0 and 1.6.1. Can you please suggest what this error may be? Thank you in advance. With kind regards, Mathew Kuppe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
customizing the properties in maven.xml
Hi, how can I set properties, that can normally be found in the project.properties file, dynamically? The background of the question is, that I would like to build to ejb archives, but with different ejb-jar.xml files in it. The project_xxx.xml files are all in the same directory, so they share the same project.properties file, which makes it unusable for that purpose. Specifically, the maven.ejb.src has to be set in the maven-ejb-plugin. What I tried so far is to use the j:set element in the maven.xml file, but I could not really find the documentation on how to use that, and where it should be placed correctly. Is this documented somewhere? If yes, I'd be happy to get a pointer to the documentation. If not, could you please explain to me how to do it, or which information you need from me to understand my problem better? Thanks a lot, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency to a plugin
Hello, i have 3 modules A: produces a jar B: uses the A.jar to build a maven plugin C: needs the B plugin How can a setup the dependency in C ??? Thanks Jens Zastrow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: aspectwerkz plugin
On Thu, 2004-02-12 at 18:31, Chad Woolley wrote: Jason van Zyl wrote: Personally, I think AOP where aspects are definted with XML is not a very good idea. You completely lose the power of the compiler and you are left to find your mistakes at runtime. And XML is just cumbersome and there is no way you could even come close with XML, to the power of the syntax AspectJ provides. Wes Isberg had a pretty good summary of some of the potential pitfalls of using XML in conjunction with AOP, I'll see if I can dig it up. Sorry, I can't resist putting in my off-topic $.02. First, the claim that XML-defined aspects can only be caught at runtime is incorrect. AspectWerkz, with XML definined aspects, can use the post-compiler approach just like AspectJ and report all compilation failures then. Not all tools have this, but I'm sure they all will catch up eventually. Also, I totally agree with your point that aspects can often be misused when a plain-java approach would be much more understandable and straightforward. AspectJ is definitely more mature and powerful. It does currently support some features that AspectWerkz does not (but the AspectWerkz developers are steadily working to address these shortcomings). AspectJ is also, IMHO, very hard to learn. I'm not ashamed to admit that the the AspectJ custom definition syntax often makes my head hurt when I try to understand it. Of course this is just a learning curve issue, but there is a lot of complex stuff to learn. AspectWerkz, in contrast, is much easier to learn. The XML definition syntax is much closer to something that can be read and understood by your average human. The arguments against coding in XML are all valid, but it's definitely much more understandable than the AspectJ syntax. I guess that's a matter of opinion. I don't you have to be smart to understand the AspectJ as I know of many places where AspectJ is in production and used by normal Joe programmers. It certainly is a personal preference but the AspectJ team not focused on making AspectJ powerful but a great effort was made to try and make it comprehensible. Maybe this effort hasn't been entirely successful but I think in years to come people will see AspectJ might be a little ahead of its time. I think tools like AspectWerkz are great because it does help the adoption of AOP which I think is great, but just as OO took a great number of years to be adopted and there too were present intermediary tools and practices that allowed developers to do things in plain C, for example, I believe that things akin to AspectWerkz are analagous and as people become more comfortable with AOP they will turn to the languages and tools which embody AOP semantics natively and for Java at least that's AspectJ. Also, in my experience, I think it is best to make your aspects as bare-bones as possible. In other words, refactor out all the logic that is not directly tied to the aspect into plain-java helper utility classes. These can then be directly unit tested without worrying about the complication of the aspect framework. I think this is a good general approach to make your aspects more understandable and manageable. Not thing stopping you from doing this in AspectJ. Lots of folks use the aspects as glue so to speak. It's a common practice amongst AspectJ'ers. Anyway, enough off-topic opinionated spew. But it's interesting, you have many good points and you speak from actually trying both tools so opinionated spew borne from experience is just fine with me :-) Thanks, Chad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: first-timer build error
On Fri, 2004-02-13 at 05:31, Emmanuel Venisse wrote: You must use MAVEN_1.0_BRANCH in cvs. The HEAD isn't for users for the moment. MAVEN-1_0-BRANCH is the name of the branch, which I mispelled the first three times trying to update :-) The 1.0 branch is the future rc2 that will be release in few days. Emmanuel - Original Message - From: Mathew Kuppe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 13, 2004 11:15 AM Subject: first-timer build error Hi, I am trying to build maven from cvs, and am receiving compile errors during the first phase of the compiling. I am using the ant -f build-bootstrap.xml command. The compilation error is the following; [javac] E:\sandbox\maven\src\java\org\apache\maven\DefaultProjectMarshaller.java :72: package org.xmlpull.v1 does not exist [javac] import org.xmlpull.v1.XmlPullParserFactory; I am using ant 1.6.0 and 1.6.1. Can you please suggest what this error may be? Thank you in advance. With kind regards, Mathew Kuppe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A Bug With war:install?
[EMAIL PROTECTED] wrote: Hi, I received an error message and nothing was copied to the below named directory everytime I try to use the goal, 'war:install'. It would be interesting to see what the error message is... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can I set the classpath for a plugin?
I'm working on a maven plugin for xmlbeans. I need to be able to specify for each use of the plugin which dependencies are in the classloader that loads the java class used by the plugin (which is included in the plugin) or what is in the thread context classloader (I think). Before I go off and spend hours investigating this I thought I'd ask if this is possible and how to do it. Many thanks, david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can I set the classpath for a plugin?
What about using the project.xml from the plugin? You can add dependencies via the dependencies subnode... Is this not adequate? -john -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 12:52 PM To: [EMAIL PROTECTED] Subject: Can I set the classpath for a plugin? I'm working on a maven plugin for xmlbeans. I need to be able to specify for each use of the plugin which dependencies are in the classloader that loads the java class used by the plugin (which is included in the plugin) or what is in the thread context classloader (I think). Before I go off and spend hours investigating this I thought I'd ask if this is possible and how to do it. Many thanks, david jencks - 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: Can I set the classpath for a plugin?
AFAIK this is not adequate. Each time I use the plugin I need different stuff on the classpath. Some background is that the xmlbeans schema compiler, each time it is called, makes sure everything referenced (recursively) from the schemas you tell it about can be processed by code. Anything you have already processed needs to be available in the schema compiler classloader or it will generate another copy. an example: module A has schema A, with no references. schema compiler compiles it fine. module B has schema B which references A. Unless the results from module A are available in the classloader for the schema compiler when compiling B, the schema compiler will generate duplicates for what id did for module A. thanks david jencks On Friday, February 13, 2004, at 09:49 AM, [EMAIL PROTECTED] wrote: What about using the project.xml from the plugin? You can add dependencies via the dependencies subnode... Is this not adequate? -john -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 12:52 PM To: [EMAIL PROTECTED] Subject: Can I set the classpath for a plugin? I'm working on a maven plugin for xmlbeans. I need to be able to specify for each use of the plugin which dependencies are in the classloader that loads the java class used by the plugin (which is included in the plugin) or what is in the thread context classloader (I think). Before I go off and spend hours investigating this I thought I'd ask if this is possible and how to do it. Many thanks, david jencks - 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: Can I set the classpath for a plugin?
Hi David
From your message, I'm not sure if this solution may apply but I'll
give it a try. You can, if you can use the Ant classpath element in your
plugin. If you need to refer to the classpath of the project
(dependencies for instance), you still can access it and insert those
entries in your new Ant classpath element using a call like :
...
ant:path id=project.class.path
pathelement location=${maven.build.dest}/
pathelement path=${plugin:getDependencyPath(groupId:artifactId)}/
/ant:path
...
Instead of using the complete depencies path, you can add some smart jelly code to pick what you need from the complete classpath of the whole project.
There is a good example of using multiple dependancy path to configure the classpath of an ant:java call in the AspectWerkz plugin jelly script.
Hope it helps
Eric.
David Jencks wrote:
I'm working on a maven plugin for xmlbeans. I need to be able to
specify for each use of the plugin which dependencies are in the
classloader that loads the java class used by the plugin (which is
included in the plugin) or what is in the thread context classloader
(I think).
Before I go off and spend hours investigating this I thought I'd ask
if this is possible and how to do it.
Many thanks,
david jencks
-
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]
ANT Namespace?
Hi, could someone tell me which namespace to add to call ANT tasks? Thanks in advance, -Conrad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT Namespace?
Hi xmlns:ant=jelly:ant But basically, I'm not even sure that you need this to call ant task in your maven.xml...just safer to use the namespace to prevent possibl name clashes with plugins. Eric. [EMAIL PROTECTED] wrote: Hi, could someone tell me which namespace to add to call ANT tasks? Thanks in advance, -Conrad - 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: A Bug With war:install?
BEGIN ERROR:
war:war:
[echo] Building WAR WebShop-App
[jar] Building jar: C:\workspace\webshop\WebShop-App\target\WebShop-App.war
[echo] [war:war] Renaming of WAR to include version number.
[move] Moving 1 files to C:\workspace\webshop\WebShop-App\target
BUILD FAILED
File.. file:/C:/Documents and Settings/CTaylor/.maven/plugins/maven-war-plug
in-1.4/
Element... artifact:install
Line.. 153
Column 27
Artifact file: 'c:\workspace\webshop\WebShop-App/target/WebShop-App.war' must ex
ist
Total time: 15 seconds
Finished at: Fri Feb 13 11:40:38 PST 2004
END ERROR:
Now, I have the following code within my 'maven.xml':
!-- Renaming of WAR to include version number --
postGoal name=war:war
echo[war:war] Renaming of WAR to include version number./echo
move file=${basedir}/target/${maven.war.final.name}
tofile=${basedir}/target/${maven.final.name}.war
/move
/postGoal
It creates the WebShop-App-0.9.8.war but war:install goal is expecting to copy
WebShop-App.war.
Thanks in advance,
-Conrad
[EMAIL PROTECTED] wrote:
Hi, I received an error message and nothing was copied to the below named directory
everytime I try to use the goal, 'war:install'.
It would be interesting to see what the error message is...
-
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]
Basic Maven Question - Dependencies
I've done some preliminary searching and reading of articles, docs, etc. regarding Maven and multiple-subprojects, but haven't been able to determine an answer to the following question: Assuming a project structure of: Project | |--A | |--B | |--C Where A depends upon B and C depends on A, the typical compile steps to build the entire project would be B-A-C. I've seen articles regarding the use of a reactor to provide a one-step method of making this compile happen for all subprojects. However, our project has a large number of modules and we'd like to build a subset of them for quicker testing purposes by running Maven from, for example, subproject A (should build and deploy only B and A, not C). This would prevent me from having to compile all modules to simply test a set of 3 modules and deploy an EAR with those components. Is this possible using typical Maven constructs? What would be required to accomplish this using Maven? My first thought is that each subproject A,B, and C would have its own project-level Maven files as well as the master one that lives at the top level. Is this the right approach? Anyone doing this? Any best practices suggested with larger projects? Best Regards, James
Re: Basic Maven Question - Dependencies
On Fri, 2004-02-13 at 13:58, James Higginbotham wrote: I've done some preliminary searching and reading of articles, docs, etc. regarding Maven and multiple-subprojects, but haven't been able to determine an answer to the following question: Assuming a project structure of: Project | |--A | |--B | |--C Where A depends upon B and C depends on A, the typical compile steps to build the entire project would be B-A-C. I've seen articles regarding the use of a reactor to provide a one-step method of making this compile happen for all subprojects. Yes. The multiproject plugin does this beautifully. However, our project has a large number of modules and we'd like to build a subset of them for quicker testing purposes by running Maven from, for example, subproject A (should build and deploy only B and A, not C). This would prevent me from having to compile all modules to simply test a set of 3 modules and deploy an EAR with those components. Is this possible using typical Maven constructs? Yes. What would be required to accomplish this using Maven? See below. My first thought is that each subproject A,B, and C would have its own project-level Maven files as well as the master one that lives at the top level. Is this the right approach? No, but close. You're correct that each subproject has its own project.xml. Each declares the dependencies for that subproject. If I remember correctly, one or more of the plugins don't like having subprojects stored in subdirectories of the current directory. When I set up our codebase to use multiproject, I set up the master project at the same level in the directory tree instead of at the top: (top level dir) | +-- master | +-- A | +-- B | +-- C The project.xml for A lists B as a dependency. The project.xml for C lists A as a dependency. The project.xml in master is about as simple as it can get without Maven complaining; most importantly, no dependencies are declared in it. Then you'll need to add to project.properties in master: maven.multiproject.basedir=.. maven.multiproject.includes=A/project.xml,B/project.xml,C/project.xml If you cd to master and run maven -Dgoal=... multiproject:goal (replacing ... with an appropriate goal), Maven should apply the goal to the subprojects in the appropriate order. Now, to be able to build a subset, create a directory at the same level as master: (top level dir) | +-- master | +-- subset | +-- A | +-- B | +-- C Copy project.xml and project.properties from master to subset. Edit project.xml as necessary. Edit maven.multiproject.includes in project.properties to list only the modules you want to include in this subset. Build as above. Hope this helps. -- Craig S. Cottingham [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic Maven Question - Dependencies
geronimo does something like this from the top level build. You can specify the list of modules you want to compile on the command line: maven -Dmodules=A,B,C rebuild geronimo actually has a 2 level approach that you can customize. you can also easily define targets with predefined lists of modules. david jencks On Friday, February 13, 2004, at 11:58 AM, James Higginbotham wrote: I've done some preliminary searching and reading of articles, docs, etc. regarding Maven and multiple-subprojects, but haven't been able to determine an answer to the following question: Assuming a project structure of: Project | |--A | |--B | |--C Where A depends upon B and C depends on A, the typical compile steps to build the entire project would be B-A-C. I've seen articles regarding the use of a reactor to provide a one-step method of making this compile happen for all subprojects. However, our project has a large number of modules and we'd like to build a subset of them for quicker testing purposes by running Maven from, for example, subproject A (should build and deploy only B and A, not C). This would prevent me from having to compile all modules to simply test a set of 3 modules and deploy an EAR with those components. Is this possible using typical Maven constructs? What would be required to accomplish this using Maven? My first thought is that each subproject A,B, and C would have its own project-level Maven files as well as the master one that lives at the top level. Is this the right approach? Anyone doing this? Any best practices suggested with larger projects? Best Regards, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I set the classpath for a plugin?
Hi Eric,
Thanks for the suggestion. Right now it does not seem to be applicable
to my situation since I am running xmlbeans in the same vm as maven, so
I think I need maven to set up the classloader for me before the plugin
is called. If there is no other way I may try the separate vm approach.
thanks
david jencks
On Friday, February 13, 2004, at 10:42 AM, Eric Giguere wrote:
Hi David
From your message, I'm not sure if this solution may apply but I'll
give it a try. You can, if you can use the Ant classpath element in
your plugin. If you need to refer to the classpath of the project
(dependencies for instance), you still can access it and insert
those entries in your new Ant classpath element using a call like :
...
ant:path id=project.class.path
pathelement location=${maven.build.dest}/
pathelement
path=${plugin:getDependencyPath(groupId:artifactId)}/
/ant:path
...
Instead of using the complete depencies path, you can add some smart
jelly code to pick what you need from the complete classpath of the
whole project.
There is a good example of using multiple dependancy path to configure
the classpath of an ant:java call in the AspectWerkz plugin jelly
script.
Hope it helps
Eric.
David Jencks wrote:
I'm working on a maven plugin for xmlbeans. I need to be able to
specify for each use of the plugin which dependencies are in the
classloader that loads the java class used by the plugin (which is
included in the plugin) or what is in the thread context classloader
(I think).
Before I go off and spend hours investigating this I thought I'd ask
if this is possible and how to do it.
Many thanks,
david jencks
-
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]
