Re: Incorporating VPP code into cgen

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon May 23 2005 - 17:19:10 EDT

  • Next message: Mike Kienenberger: "Re: Incorporating VPP code into cgen"

    So it looks like we should use full binary vpp.jar.

    A question - will the current default generation option still be available
    without VPP, or is it an all or nothing deal?

    Andrus

    > On May 23, 2005, at 4:47 PM, Mike Kienenberger wrote:
    >> Andrus Adamchik <andru..bjectstyle.org> wrote:
    >>
    >>> I'd say if we have to do that, we should create our own classes and
    >>> paste
    >>> the code there under ObjectStyle license, and put the VPP license
    >>> in our
    >>> third party liceses directory under docs.
    >>>
    >>> My reasoning is that if we have a Java class under our source tree,
    >>> it is
    >>> a part of Cayenne and we will be maintaining it. Otherwise it
    >>> should be
    >>> imported as a binary jar.
    >>>
    >>> BTW, how many Java classes from VPP are you planning to import,
    >>>
    >>
    >> I'm still trying to determine how many I'm going to import :) I'd
    >> actually
    >> prefer to import it as a binary jar, but I'd be concerned about the
    >> additional configuration needed to get the cgen task defined. On
    >> the other
    >> hand, perhaps that's not an issue now that we're using antlib.xml.
    >> I'm also
    >> not yet sure how easy it will be to override any vpp logic we're not
    >> interested in.
    >
    > To use classes from the VPP binary, I think all you'd need to do is
    > put it's JAR in the classpath used to define Cayenne Ant tasks, so it
    > shouldn't be too big of a deal. I haven't looked under the covers of
    > VPP in a long while, but if it has the classes broken out in a
    > reusable fashion then using it's JAR directly seems the best way to go
    > with this.
    >
    >> The first two items are the ones I need.
    >>
    >> 1) ability to add velocity context attributes by class ("velocity
    >> tool"
    >> instance).
    >> 2) ability to add velocity context attributes via a property or
    >> property
    >> file.
    >>
    >> Example:
    >>
    >> <vppconfig id="vppconfig0" >
    >> <context>
    >> <property key="foo" value="bar" />
    >> <property file="some.properties" />
    >> <tool key="mytool" className="foo.bar.MyTool" />
    >> </context>
    >> </vppconfig>
    >
    > Ain't VPP great?! :)
    >
    >> The others that we could get "for free" would be (in my order of
    >> perceived
    >> importance),
    >>
    >> 3) ability to specify the resource loader (for Erik's #parse classpath
    >> request)
    >
    > I'm honored!
    >
    >> 4) ability to specify a velocity macro library
    >> 5) ability to log all velocity messages to the ant logger (default
    >> configuration for the runtime.log.logsystem engine property).
    >> 6) ability to configure all of these options as a standalone ant
    >> vppconfig
    >> element so it can be shared between tasks.
    >> 7) ability to add an event handler
    >> 8) ability to specify other velocity engine properties.
    >> 9) reference to hash table of all ant properties and to the ant
    >> project
    >> object.
    >> 10) conformance to the vpp ant api.
    >
    > I *heart* VPP.
    >
    > Erik



    This archive was generated by hypermail 2.0.0 : Mon May 23 2005 - 17:19:12 EDT