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
