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]
