Right. It's still not entirely clear to me what the difference is between this and something a plugin could fire off, but I might not have my thinking hat on today.
It still seems strange to me that we are re-inventing ways to validate pieces of XML when namespaces already exist for that purpose, too. Anyway, I'd recommend either starting a separate thread or putting a proposal in the wiki to make sure it doesn't get lost. Cheers, Brett Jesse McConnell wrote: > sorry on the wrapping, an artifact of the convoluted way I had to move it > around to get gmail to actually send it > > 1) it was related to custom in that it is basically alluding to a proposel > to have a structured mechanism of inserting other models into the pom and > having maven be able discover the implementing model dependency and perhaps > swizzle it all into objects automagically...what jason was talking about in > regards to his usage of the custom tag (here and on irc) made me think that > this would be a pretty natural extension of it...could be a new element > though > > 2) sorry, overrode <modules> there...so no, completely different type of > module, more like plugin.. > > again, sorry for the wrapping, I ended up having to cut and paste it over to > my windows box since my mac kept not being able to resolve google mail..very > odd :) > > jesse > > On 4/1/06, Brett Porter <[EMAIL PROTECTED]> wrote: >> Jesse, >> >> You've lost me a bit with this (and with the wrapping I found it really >> hard to read :) >> >> 1) is this related to the custom discussion or is this just a new >> element you'd like to add (if the latter, I think it deserves a new >> thread) >> >> 2) is this related to the current <modules> tag, or something different? >> >> Thanks, >> Brett >> >> Jesse McConnell wrote: >>> I was thinking about this a bit.. >>> >>> what about adding something like >>> >>> <modules> >>> <module> >>> <source> >>> <artifactId>runtime-model</artifactId> >>> <groupId>org.codehaus.mojo.plugin</groupId> >>> <version>1.0-SNAPSHOT</version> >>> </source> >>> <model> >>> <runtimes> >>> <runtime> >>> .... >>> </runtime> >>> </runtimes> >>> </model> >>> </module> >>> </modules> >>> >>> where we can logically embed the particular types of extensions to the >> pom >>> that >>> we want. >>> >>> I was thinking about picking up my runtime work and furthering the idea >> of >>> usin >>> g it as a program launching framework and it would be pretty spiffy if >> we >>> could >>> embed arbitary chunks into the pom that maven facilitates the passing of >> the >>> <cu >>> stom> tag into another modello model...the <source> would point to the >> place >>> tha >>> t the model could be pulled from and the <model> the container element >> for >>> the a >>> ctual model that would be created. >>> >>> maybe something like this is already slated for 2.1, haven't checked up >> on >>> it, b >>> ut I rather like the jist of it. >>> >>> Why not just do it as a plugin? >>> >>> well, for the runtime launching my thought was that a project that >> wanted to >>> be >>> able to be started from some general wrapper script called mvnrun could >>> declare >>> the specifics in the runtime model for things like linkage of some id to >> a >>> main >>> method in the program. The stuff could be in the repository and an >> indexing >>> pro >>> cess could exist that could comb through all the poms in the local repo >> and >>> inde >>> x the id's so >>> >>> mvnrun squirrel >>> >>> would know to start up the squirrel program. And if a more global index >>> existed >>> then it would know that it needed to go hit ibibilo and grab the root >>> squirrel >>> program and all of the dependencies, kinda making a java equivalent to >>> apt-get.. >>> And I don't see that kinda functionality being the purpose of a maven >>> plugin, >>> but I see it a natural extension for the maven pom since the pom >> metadata >>> alread >>> y tracks all of the dependencies needed to run. Could be very nice to >> just >>> add >>> in a simple module to the pom that enabled this sort of behavior. >>> >>> anyway, that is my use case... >>> >>> jesse >>> >>> >>> On 3/31/06, Brett Porter <[EMAIL PROTECTED]> wrote: >>>> +1. Strict parsing is only on for projects you build, its off for poms >>>> in the repository. >>>> >>>> This should be a change on trunk only, and the model version should be >>>> changed to 4.1.0, right? We need to now start looking into dealing with >>>> projects differently based on the model version. >>>> >>>> Given that this is a model change - why not add categories and tags to >>>> the POM itself? >>>> >>>> - Brett >>>> >>>> Jason van Zyl wrote: >>>>> John Casey wrote: >>>>>> so, how do you gain access to the custom section? Would you have to >>>>>> re-parse the whole pom? Also, would <custom/> be subject to any sort >>>>>> of inheritance, or would it simply be invisible to the project >> builder? >>>>> After some more chatting in IRC I think that if a <custom/> element >> was >>>>> added to the MDO then the strict parsing can be left on. Essentially >> the >>>>> <custom/> element would be processed like a plug-in configuration. >> That >>>>> would probably make more sense and be safer. >>>>> >>>>>> -john >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> -- >>> jesse mcconnell >>> jesseDOTmcconnellATgmailDOTcom >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > jesse mcconnell > jesseDOTmcconnellATgmailDOTcom > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
