[EMAIL PROTECTED]: Re: Maven 2 (was Re: Maven 1.1)]
Brett's message from a while back which may be of interest to bill. There's more in this thread... LSD - Forwarded message from Brett Porter [EMAIL PROTECTED] - From: Brett Porter [EMAIL PROTECTED] Date: Wed, 16 Nov 2005 16:45:56 +1100 Subject: Re: Maven 2 (was Re: Maven 1.1) To: Gump code and data general@gump.apache.org Reply-To: Gump code and data general@gump.apache.org List-Id: Gump code and data general.gump.apache.org Ok, here's the opportunity for me to write the mail in my head. Aside from the non-existance of a gump machine right now, what is needed to use Maven 2, a) minimally b) ideally Because it has an even more online nature (plugins are not preinstalled), to use an installed version we'd again need to create a minimal local repository including those plugins, then use offline mode (-o), and ensure it can't get any internet access just to make sure. However, it should be pretty easy to step it up to the next level. Instead of a pre-installed repository, we can add a Gump artifact resolver. What I'd need to know is the best way to make that work. Can you verify that to resolve a JAR file in gump (assuming gump has already built it) I'd need to: * know the base working directory * know the location of the gump XML file * parse out project name and within that jar name * look in base/project_name/jar_name The resolver can also parse these files for depends. This would require knowing where everything is, so even better would be: * a list of directories creating gump descriptors * that all files in the descriptor are relative to that gump descriptor Is that how it is currently? We come back to the problem of aligning IDs. I think the best place to solve this is in the gump descriptors. Here is how I'd parse them out in order of preference: * GroupId: 1) project groupId= 2) module groupId= 3) module name= * Artifact ID: 1) jar artifactId= 2) jar id= 3) project artifactId= 4) project name= * Type: 1) jar type= / 2) jar / means jar 3) project type= / 4) how do you specify non-jar outputs? * Classifier: 1) jar classifier= / 2) project classifier= / 3) default is none If I start adding them, will it break anything? Now, the next issue comes when Gump3 parses multiple input formats. I don't want to duplicate information in Maven - can we get gump to pick a format and produce that as part of the build, regardless of its input? A POM would simplify things :) Ok, this would have a preinstalled Maven using some packaged plugins working offline without a manual repository setup. Next, to build Maven. We have a bootstrap that runs without any dependencies except Java that would produce the installation above - but it downloads the Maven dependencies on the way. We could have it resolve packaged versions of those by reusing the gump resolver. Alternatively, something we are doing so it can be packaged on unix is checking out the sources rather than relying on packaging, then building them, then building m2 (and those packages would later be rebuilt again using the new m2). Is that a better alternative to the above? - Brett On 11/16/05, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Nov 2005, Leo Simons [EMAIL PROTECTED] wrote: Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. Pluto's trunk has already jumped to Maven 2. We will need a maven2 builder, that's all. Stefan - 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] - End forwarded message - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
On 11/16/05, Leo Simons [EMAIL PROTECTED] wrote: I wrote an answer then deleted it. I got lost a little. Seperating concerns: -- support for maven2 in gump2 -- I'm not going to work on it Fine by me. I assume gump3 is not far off then? -- how to properly support maven2 in gump3 ... -- a python function or two to work with that xml (while in DOM form) and help transform it into the python object model gump uses I'll come back to this. project name=mvn module name=mvn/ depend name=maven2-bootstrap inherit=all/ mvn/ jar name=target/mvn.jar runtime=true/ /project This is oversimplified as a working Maven contains more than one jar and a few dependencies. But the bootstrap can be used to build that install in the first step and then the above could rebuild a new maven install after gump has built its dependencies. That was all discussed in my email. Ideally we can run mvn without using its shell scripts and just digest a command which starts with java, since that makes it easier to get things like the CLASSPATH right. There is no classpath. Maven starts with just classworlds, which constructs class loaders for different areas of the system. So its fine to run without the shell scripts, they don't do much except make it usable, but the behaviour won't change. In this case we don't have a local installation but one running straight from trunk (just like ant). As built above, sure. Now, if we need some special bits like some java code to replace the repository management, we would have something like project name=mvn-gump-java-helper module name=gump3/ depend name=ant inherit=all/ depend name=mvn-bootstrap inherit=all/ ant/ jar name=target/mvn-gump-java-helper.jar/ /project You've got Maven at this point, you can build with it :) This will just be one class, and was something I discussed in my prior email. Now, as far as repository management, downloading, dependency resolution, any of that is concerned, what we want to do in this mvn-gump-java-helper is simply disable as much of those bits of maven2 as possible. Yes, but you are going to have to go the other way around. It's a component that resolves artifacts and metadata. It doesn't get fed, it hunts. You can't use CLASSPATH. The helper will be the implementation that goes and finds things. I hope all that made sense. Now, moving on to the first implementation details LOL. Like there weren't any implementation details above :) Unfortunately, the assumptions above won't work. Maven needs to resolve JARs, and resolve dependencies via metadata. This means it has to be able to find the JARs (Seems easy enough), and the metadata - which means reading gump.xml/pom.xml/something-else.xml. In the part above where you create a gump object model, you will need to write that out in a form so that Maven (though the gump java helper) can digest it and get the proper ids and the dependencies. Is it possible for me to put ID mappings into the gump2/3 descriptor without breaking anything, or will we need to align them? -- how to bootstrap maven2 Downloading things from elsewhere is not a problem. The key bit is getting to a classpath when using maven to build stuff that contains only fresh built sources and none of the prepackaged bits (just like when you're bootstrapping GCC -- you download a binary GCC to build GCC, then you throw the binary away). If there is a procedure to get absolutely everything from source including all of mavens dependencies and build all of it properly (I really hope there is one now for maven 2) and dependably, lets use it. Currently, it downloads the bits that it depends on outside the Maven tree. I can change those to be checked out and built too. Key bit here is that what gump does for bootstrapping is the same as what the maven 2 people do for bootstrapping. It sounds like the one you use yourselves is the first option so lets roll with that. Ok, this part is fine. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
I missed a bit.. On Fri, Nov 18, 2005 at 10:27:53PM +1100, Brett Porter wrote: On 11/16/05, Leo Simons [EMAIL PROTECTED] wrote: I wrote an answer then deleted it. I got lost a little. Seperating concerns: -- support for maven2 in gump2 -- I'm not going to work on it Fine by me. I assume gump3 is not far off then? Heh, I wish :-). We don't have a working webapp nor do we have it sending out email. But there's a lot of the hard problems solved in there and for me its just a whole less painful to work with (I still get lost around the gump2 codebase all the time). I hope to find more time to hack on it. Its not far off in terms of man hours, I hope :-) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
On 11/18/05, Leo Simons [EMAIL PROTECTED] wrote: Bing! Light bulb went on in my head. Pull not push. I'm trying to think about an easy way to do the pull stuff, but that is probably all dependent on the mechanisms maven employs. I'm pretty sure I can do this. Both gump and maven 2 are neatly inversion of control. Both made the right decisions but this really makes things harder as there's a wrestle for control. I think I now also understand better why continuum is a real need in a maven 2 world -- its just natural to not try and to subvert the control that maven 2 implements. Right - it builds on top of it that fit that pattern. Why do you keep referring to a something.xml? Is it going to be a lot easier to have the maven jar resolver read a something.xml rather than do something else (like, I dunno, a database, or an XML/RPC interface, or ...)? Just checking -- I think there's more assumptions in my head that might need to get out. No, we can read from any number of sources, nothing has to be XML. Like what you are saying - we just need to end up with a Maven POM in Java (where you need to end up with your Gump object model). All I'm saying is that both Maven and Gump shouldn't have to implement the same mechanism to read all the formats gump digests (and as Maven pulls dependencies, it will need to get that information). If Gump intends to do this, all it needs to do is output a file from the gump object model and Maven can read just one format (and if it outputs a POM, even better :) Of course, Maven *could* do all this, but either that's doubling up, or putting Maven at the centre of Gump, neither of which seem desirable :) Gump3 will ignore everything it doesn't understand as long as its valid XML. I think gump2 does the same but I'm less sure -- just try :-) Will do. Hey Brett, are you going to be at ApacheCon and esp. the hackathon? I'd love to get some help digesting maven 2 internals! :-) Yep. See you there! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
On Fri, Nov 18, 2005 at 11:10:24PM +1100, Brett Porter wrote: Why do you keep referring to a something.xml? Is it going to be a lot easier to have the maven jar resolver read a something.xml rather than do something else (like, I dunno, a database, or an XML/RPC interface, or ...)? Just checking -- I think there's more assumptions in my head that might need to get out. No, we can read from any number of sources, nothing has to be XML. Like what you are saying - we just need to end up with a Maven POM in Java (where you need to end up with your Gump object model). All I'm saying is that both Maven and Gump shouldn't have to implement the same mechanism to read all the formats gump digests (and as Maven pulls dependencies, it will need to get that information). If Gump intends to do this, all it needs to do is output a file from the gump object model and Maven can read just one format (and if it outputs a POM, even better :) Of course, Maven *could* do all this, but either that's doubling up, or putting Maven at the centre of Gump, neither of which seem desirable :) Maven is in the center of the developers for a project (they type mvn and not gump) so what these people want to author is a POM. Gump should read that POM and understand it. Question: can gump get away with writing things like settings.xml and command line arguments and not touch any POM at all (eg maven just reads the normal pom.xml that's already there) yet change enough of maven's behaviour so that all the classworlds match up properly with the gump process? Maybe we should just try it and see how far we get. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
On 11/19/05, Leo Simons [EMAIL PROTECTED] wrote: Maven is in the center of the developers for a project (they type mvn and not gump) so what these people want to author is a POM. Gump should read that POM and understand it. Sorry, I probably didn't explain where I was coming from. Maven does transitive dependencies. Even when you take the versioning out of it, it still needs to traverse the projects to get the correct list. So this is fine as long as it hits Maven projects, but when it finds a dependency without a POM, then it needs to be able to parse whatever is given to figure out the dependencies of that. Maybe we should just try it and see how far we get. Yep, I think I can make an attempt at it. But for now, sleep. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
I wrote an answer then deleted it. I got lost a little. Seperating concerns: -- support for maven2 in gump2 -- I'm not going to work on it -- support for maven2 in gump3 -- pretty much like we did for maven1 + bootstrap -- doing it quickly -- not me -- doing it properly -- been thinking about that too So... -- how to properly support maven2 in gump3 Basically in the gump descriptors all we want to do is project name=pluto type=mvn href=http://svn.a.o/r/a/p/x/pom.xml/ and then gump fetches that xml file and merges it into the rest of the XML. We end up with lots of xml. Now we need -- a python function or two to work with that xml (while in DOM form) and help transform it into the python object model gump uses Then the gump engine at some point figures out it needs to boostrap mvn. The goal here is to use the actual bootstrap process used for mvn, I believe that involves an svn checkout followed by running a shell script followed by running a minimal mvn on itself. project name=mvn-bootstrap module name=mvn/ script name=bootstrap/ !-- .sh or .bat -- jar name=build/maven2-bootstrap.jar runtime=true/ /project project name=mvn module name=mvn/ depend name=maven2-bootstrap inherit=all/ mvn/ jar name=target/mvn.jar runtime=true/ /project eg, pretty much as we do for Ant. Next bit is -- a python plugin which can call Maven2 Ideally we can run mvn without using its shell scripts and just digest a command which starts with java, since that makes it easier to get things like the CLASSPATH right. In this case we don't have a local installation but one running straight from trunk (just like ant). Now, if we need some special bits like some java code to replace the repository management, we would have something like project name=mvn-gump-java-helper module name=gump3/ depend name=ant inherit=all/ depend name=mvn-bootstrap inherit=all/ ant/ jar name=target/mvn-gump-java-helper.jar/ /project project name=mvn !-- ... -- depend project=mvn-gump-java-helper runtime=true/ /project Now, as far as repository management, downloading, dependency resolution, any of that is concerned, what we want to do in this mvn-gump-java-helper is simply disable as much of those bits of maven2 as possible. Basically what we want to end up with is a gump-generated CLASSPATH (in some form) which maven just accepts as containing all the required dependencies. All those pom.xml files are still available and we can write bits of glue (in python) to expose info from them or for them up as much as needed. Eg Gump3 ends up doing something like for element in parsed.pom.xml.DOM: for (origname, replacement) in artifactmap: element.replaceall(origname, replacement) (...) CLASSPATH=$JAVA_HOME/tools.jar:$MVN_HOME/target/mvn.jar:$GUMP_HOME/target/mvn-gump-java-helper.jar: cd pluton/ java -cp $CLASSPATH org.apache.maven.Maven2.Main jar I hope all that made sense. Now, moving on to the first implementation details -- how to bootstrap maven2 On Wed, Nov 16, 2005 at 04:45:56PM +1100, Brett Porter wrote: Next, to build Maven. We have a bootstrap that runs without any dependencies except Java that would produce the installation above - but it downloads the Maven dependencies on the way. We could have it resolve packaged versions of those by reusing the gump resolver. Alternatively, something we are doing so it can be packaged on unix is checking out the sources rather than relying on packaging, then building them, then building m2 (and those packages would later be rebuilt again using the new m2). Is that a better alternative to the above? Downloading things from elsewhere is not a problem. The key bit is getting to a classpath when using maven to build stuff that contains only fresh built sources and none of the prepackaged bits (just like when you're bootstrapping GCC -- you download a binary GCC to build GCC, then you throw the binary away). If there is a procedure to get absolutely everything from source including all of mavens dependencies and build all of it properly (I really hope there is one now for maven 2) and dependably, lets use it. Key bit here is that what gump does for bootstrapping is the same as what the maven 2 people do for bootstrapping. It sounds like the one you use yourselves is the first option so lets roll with that. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
Brett Porter wrote: I don't know of them all, but I believe the following projects are on the way or considering it: Cocoon, Pluto, JetSpeed 2, Struts, Excalibur, Geronimo, Directory, Felix Add MyFaces (they are considering it) to the list (tobago is already maven2). Struts has an attempt somewhere in svn (just read that on the myfaces list). Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
On Tue, Nov 15, 2005 at 06:28:28AM +0100, Stefan Bodewig wrote: On Mon, 14 Nov 2005, Brett Porter [EMAIL PROTECTED] wrote: We actually started validating the project.xml files. Some people have a lot of random content in there that was previously silenty ignored. Maybe its worth considering them a failed build for the purposes of Gump so that they update it? If it wasn't the excalibur project, maybe. You may not have noticed it, but before I destroyed vmgump the only project still depending on the old Avalon codebase was James - since I don't find a replacement for meta-tools in Excalibur. All other dependencies, in particular commons-logging's dependency on framework and logkit have been migrated to the Excalibur maintained versions. I'm sure the james people would love to hear about the stuff that's keeping them depending on the old avalon codebase. Either we migrate that to excalibur or into james or they stop using it :-) On the other hand - unless Leo jumps in - I'm afraid that the Excalibur community doesn't care about Gump that much and we'd be left with a build tree that is only building around 50% or even less just because Maven started to validate the descriptors. Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. cheers, LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
On 11/16/05, Leo Simons [EMAIL PROTECTED] wrote: [snip] Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. cheers, LSD Just out of curiosity, what adoption of Maven 2 has there been @ Apache. In Jakarta I've seen very little. -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
On 11/16/05, Leo Simons [EMAIL PROTECTED] wrote: Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. In theory, Gump should be able to build and use Maven 2 very shortly. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
I don't know of them all, but I believe the following projects are on the way or considering it: Cocoon, Pluto, JetSpeed 2, Struts, Excalibur, Geronimo, Directory, Felix Those are the ones feeling pain points in their build that Maven solves. For the ones where it already just works, there is probably little reason to change. I want to get a good multiproject site/reporting solution together before proposing it as a parallel build in commons, but I think that there could be a lot of benefits there too. - Brett On 11/16/05, Dion Gillard [EMAIL PROTECTED] wrote: On 11/16/05, Leo Simons [EMAIL PROTECTED] wrote: [snip] Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. cheers, LSD Just out of curiosity, what adoption of Maven 2 has there been @ Apache. In Jakarta I've seen very little. -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2 (was Re: Maven 1.1)
On Tue, 15 Nov 2005, Leo Simons [EMAIL PROTECTED] wrote: Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. Pluto's trunk has already jumped to Maven 2. We will need a maven2 builder, that's all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (was Re: Maven 1.1)
Ok, here's the opportunity for me to write the mail in my head. Aside from the non-existance of a gump machine right now, what is needed to use Maven 2, a) minimally b) ideally Because it has an even more online nature (plugins are not preinstalled), to use an installed version we'd again need to create a minimal local repository including those plugins, then use offline mode (-o), and ensure it can't get any internet access just to make sure. However, it should be pretty easy to step it up to the next level. Instead of a pre-installed repository, we can add a Gump artifact resolver. What I'd need to know is the best way to make that work. Can you verify that to resolve a JAR file in gump (assuming gump has already built it) I'd need to: * know the base working directory * know the location of the gump XML file * parse out project name and within that jar name * look in base/project_name/jar_name The resolver can also parse these files for depends. This would require knowing where everything is, so even better would be: * a list of directories creating gump descriptors * that all files in the descriptor are relative to that gump descriptor Is that how it is currently? We come back to the problem of aligning IDs. I think the best place to solve this is in the gump descriptors. Here is how I'd parse them out in order of preference: * GroupId: 1) project groupId= 2) module groupId= 3) module name= * Artifact ID: 1) jar artifactId= 2) jar id= 3) project artifactId= 4) project name= * Type: 1) jar type= / 2) jar / means jar 3) project type= / 4) how do you specify non-jar outputs? * Classifier: 1) jar classifier= / 2) project classifier= / 3) default is none If I start adding them, will it break anything? Now, the next issue comes when Gump3 parses multiple input formats. I don't want to duplicate information in Maven - can we get gump to pick a format and produce that as part of the build, regardless of its input? A POM would simplify things :) Ok, this would have a preinstalled Maven using some packaged plugins working offline without a manual repository setup. Next, to build Maven. We have a bootstrap that runs without any dependencies except Java that would produce the installation above - but it downloads the Maven dependencies on the way. We could have it resolve packaged versions of those by reusing the gump resolver. Alternatively, something we are doing so it can be packaged on unix is checking out the sources rather than relying on packaging, then building them, then building m2 (and those packages would later be rebuilt again using the new m2). Is that a better alternative to the above? - Brett On 11/16/05, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Nov 2005, Leo Simons [EMAIL PROTECTED] wrote: Actually, someone's looking at changing the excalibur build to use maven 2. That pretty much means tree detoriation anyway. We're going to start seeing that all over apache as projects migrate to maven 2. Pluto's trunk has already jumped to Maven 2. We will need a maven2 builder, that's all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
On Mon, Nov 14, 2005 at 05:55:48AM +0100, Stefan Bodewig wrote: On Sun, 13 Nov 2005, Bill Barker [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The version of dom4j that Maven 1.0.2 uses is quite old - some prerelase of 1.4. Maybe we could upgrade to Maven 1.1? I just tried with Maven 1.1b2, and Maven chokes on the Excalibur project.xml long before getting to Struts. It looks like there isn't enough backwards compatibility in Maven to make it possible to upgrade the version that Gump is using. That's unfortunate. Thanks for checking. Heh. I'm sure maven would appreciate a bug report, so they can fix it :-) -LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
We probably need a compatibility option, but it's listed on the known incompatibility pages. We actually started validating the project.xml files. Some people have a lot of random content in there that was previously silenty ignored. Maybe its worth considering them a failed build for the purposes of Gump so that they update it? - Brett On 11/14/05, Leo Simons [EMAIL PROTECTED] wrote: On Mon, Nov 14, 2005 at 05:55:48AM +0100, Stefan Bodewig wrote: On Sun, 13 Nov 2005, Bill Barker [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The version of dom4j that Maven 1.0.2 uses is quite old - some prerelase of 1.4. Maybe we could upgrade to Maven 1.1? I just tried with Maven 1.1b2, and Maven chokes on the Excalibur project.xml long before getting to Struts. It looks like there isn't enough backwards compatibility in Maven to make it possible to upgrade the version that Gump is using. That's unfortunate. Thanks for checking. Heh. I'm sure maven would appreciate a bug report, so they can fix it :-) -LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
On Mon, Nov 14, 2005 at 09:53:01PM +1100, Brett Porter wrote: We probably need a compatibility option, but it's listed on the known incompatibility pages. Aw, that sucks as a concept! I thought maven1 was going to stay compatible and there'd be painfulness only once (maven1 - maven2)? We actually started validating the project.xml files. Some people have a lot of random content in there that was previously silenty ignored. Grr. Very useful, that was. I know I did stuff like jsd custom-metadata-here/ /jsd :-) Maybe its worth considering them a failed build for the purposes of Gump so that they update it? IMHO maven is broken and its behaviour should change. Validate XML if there is a reference to a DTD or a schema or a pomVersion bigger than X, otherwise preserve the old behavior. Or something. If maven is not going to change, then yes, that would make sense, but I think some people are not going to be very happy. cheers! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
On 11/14/05, Leo Simons [EMAIL PROTECTED] wrote: On Mon, Nov 14, 2005 at 09:53:01PM +1100, Brett Porter wrote: We probably need a compatibility option, but it's listed on the known incompatibility pages. Aw, that sucks as a concept! I thought maven1 was going to stay compatible and there'd be painfulness only once (maven1 - maven2)? Why is having to set a compat option painful? It's about getting better metadata - a lot of people make typos and don't realise it, and its hard to track down. There's nothing in there we set out to break existing builds with, but we did drop support for things that we said a long time ago were unsupported. IMHO maven is broken and its behaviour should change. Validate XML if there is a reference to a DTD or a schema or a pomVersion bigger than X, otherwise preserve the old behavior. Or something. There is a schema. It's optional to declare it. If maven is not going to change, then yes, that would make sense, but I think some people are not going to be very happy. Most people have been happy to change their pom, not realising the elements weren't being used before. If this is something you think is an issue, then by all means complain to the relevant list. On the gump side, I can't see why you wouldn't use the latest no matter how broken you think it is. Isn't that the point? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.1
On Mon, 14 Nov 2005, Brett Porter [EMAIL PROTECTED] wrote: We actually started validating the project.xml files. Some people have a lot of random content in there that was previously silenty ignored. Maybe its worth considering them a failed build for the purposes of Gump so that they update it? If it wasn't the excalibur project, maybe. You may not have noticed it, but before I destroyed vmgump the only project still depending on the old Avalon codebase was James - since I don't find a replacement for meta-tools in Excalibur. All other dependencies, in particular commons-logging's dependency on framework and logkit have been migrated to the Excalibur maintained versions. On the other hand - unless Leo jumps in - I'm afraid that the Excalibur community doesn't care about Gump that much and we'd be left with a build tree that is only building around 50% or even less just because Maven started to validate the descriptors. Breaking backwards compatibility, even with the best reasons, is very difficult to do and to get accepted. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 1.1 (was Re: svn commit: r330729 - /gump/metadata/project/struts.xml)
On Sun, 13 Nov 2005, Bill Barker [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The version of dom4j that Maven 1.0.2 uses is quite old - some prerelase of 1.4. Maybe we could upgrade to Maven 1.1? I just tried with Maven 1.1b2, and Maven chokes on the Excalibur project.xml long before getting to Struts. It looks like there isn't enough backwards compatibility in Maven to make it possible to upgrade the version that Gump is using. That's unfortunate. Thanks for checking. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
