On Mon, 2002-02-25 at 12:37, Sam Ruby wrote:
 
> > All right. We'll start with this then:
> >
> > 
>http://cvs.apache.org/viewcvs/jakarta-turbine-maven/jakarta-turbine-maven.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
> >
> > This is produced by Maven, taking a Maven descriptor and converting it
> > to a Gump descriptor. So I have a couple issues I'd like to deal with.
> >
> > 1) How would you like these descriptors to arrive for use in Gump. I
> > would prefer not to mail in a patch, I would just like to be able to
> > push it somewhere for you to use. Or I could automatically check it in
> > to cvs. I haven't tried Tim Endres cvs client lib but I could give it a
> > shot. Thoughts?
> 
> I would prefer a process that bootstraps - i.e., build maven's
> dependencies.  Build maven.  Execute maven.  Incorporate the dependencies.
> Continue on.  I realize that some invention would be required to make this
> all work, but I am willing to do my half of the bargain.

I'm not sure I follow here: you want maven to build so that it can
generate the gump descriptor? Just want to make sure I understand.
 
> > 2) The other issue is the the way Gump embeds projects inside one
> > another. Currently Maven depends on GNU regexp (we're working on
> > removing it) and wanted to know if a project descriptor could be setup
> > this instead of embedding the project definition. The same issue is
> > present in the Turbine 2.x descriptor (webmacro, freemarker, helma
> > xmlrpc) So can I break out the embedded projects and make descriptors
> > for them that live on their own? So that they can be reused? I want to
> > add support back in for webmacro and freemarker in Turbine 3.x so I
> > would rather not define the project in each project. I assume I can just
> > break them out.
> 
> I don't follow.  Can you provide an example?

http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/jakarta-turbine-2.xml?rev=1.12&content-type=text/vnd.viewcvs-markup

If I were to create dependency on webmacro in turbine 3 I don't want to
replicate the project entry that is embedded the turbine 2 entry. If
that embedded entry becomes globally available that's unintuitive so I
would like to not be in the habit of embedding projects in one another.
I think if there is a new dependency introduced it should be made into a
descriptor of its own right off the bat.

> > If we can work this out then I will start sending you accurate
> > descriptors and we'll change the way Turbine generally behaves with
> > Gump.
> 
> Cool.
> 
> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to