> 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.
this is pretty much entirely outside the purview of this thread, it was just
my usecase..so I'll just cease discussion on that and use jasons :)
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.
well, if we are turning off the strictness then we aren't really worried
about validation perse here...and from the irc discussions namespaces where
kinda referred to a 'goop' I believe :)
all I was trying to say was that I liked the <custom/> idea, and that a
natural extension to me seemed a way to perhaps formally embed other modello
based models into the <custom> tag and provide a way for maven to be able to
discover the implementing model Xpp3 reader and be able to explode it into
objects.
to use Jason's example above
<project>
<custom>
<models>
<model>
<implementation>
<artifactId>codething-model</artifactId>
<groupId> org.codehaus.codething</groupId>
<version>1.0-SNAPSHOT</version>
</implementation>
<configuration>
<categories>
<category>Build Tools<category>
</categories>
<tags>
<tag>Project Management</tag>
<tag>Build Management</tag>
</tags>
<downloadSite>http://maven.apache.org/download.html</downloadSite>
</configuration>
</model>
</models>
</custom>
</project>
so now maven can take the information in the <implementation> tags up above
and go get the implemention and swizzle the <configuration> into the
objects...
some process is going to have to go get the model xpp3 reader, so why not
formalize that process..
that is all I was referring to until my example usecase took over.
hope that is clearer :)
Anyway, I'd recommend either starting a separate thread or putting a
> proposal in the wiki to make sure it doesn't get lost.
the usecase part already exists somewhat under the runtime topic
jesse
> 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]
>
>
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
