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]
