Re: eogenerator builder

From: Greg (ghuland..ramedphotographics.com)
Date: Mon Sep 26 2005 - 20:31:26 EDT

  • Next message: Greg: "Saving Api Files"

    Thanks Mike. I never thought to look in Preferences, only Project
    properties.

    All working now.

    Greg.

    On 27/09/2005, at 9:46 AM, Mike Schrag wrote:

    > You specify the /usr/local/bin/eogenerator part in the WOLips
    > preferences pane and the rest on the WOLips project properties pane.
    >
    > I'm using the same code to launch external builder calls, so i /
    > think/ the same vars should work. However, the working directory
    > is explicitly set to the be the project location, so you don't
    > really need to specify that.
    >
    > So in your case, your EOGenerator args would be:
    >
    > -model LightBox.eomodeld -javaTemplate java-class.eotemplate -
    > subclassJavaTemplate java-subclass.eotemplate -destination src/au/
    > com/shoebox/businesslogic/core -subclassDestination src/au/com/
    > shoebox/businesslogic/
    >
    > Then do a clean build or touch one of the files inside the eomodeld
    > folder and it should regenerate.
    >
    > ms
    >
    > On Sep 26, 2005, at 7:28 PM, Greg wrote:
    >
    >> Do we have to specify the complete command line with no eclipse
    >> variables?
    >>
    >> /usr/local/bin/eogenerator -java -model ${project_loc}/
    >> LightBox.eomodeld -javaTemplate ${project_loc}/java-
    >> class.eotemplate -subclassJavaTemplate ${project_loc}/java-
    >> subclass.eotemplate -destination ${project_loc}/src/au/com/shoebox/
    >> businesslogic/core -subclassDestination ${project_loc}/src/au/com/
    >> shoebox/businesslogic/
    >>
    >> Having the above does not seem to do anything when I change my
    >> model. What would be great, I know this is asking a lot, but have
    >> a variable named ${EOModel} so the builder can substitute in the
    >> model path when there are multiple models in the project. And the
    >> other thing would be for it to determine the destination paths
    >> based on the package name in the model, though this one would be a
    >> bit trickier and maybe easier to implement by customising
    >> eogenerator so that you could use the -destination switch as the
    >> root folder and then have another switch -placeInPackage or
    >> something similar so for each entity it placed it into the correct
    >> folder. If people want this I would be more than happy to modify
    >> eogenerator to handle this.
    >>
    >> Greg
    >>
    >> On 27/09/2005, at 3:47 AM, Mike Schrag wrote:
    >>
    >>
    >>> I was afraid someone was going to ask that :) Right now you
    >>> can't ... I was thinking this should be properties attached to a
    >>> particular eomodel instead of a project-level setting like it is
    >>> now, I just wanted to get this change in to see if it worked at
    >>> all before taking it further.
    >>>
    >>> ms
    >>>
    >>> On Sep 26, 2005, at 1:37 PM, Brendan Duddridge wrote:
    >>>
    >>>
    >>>
    >>>> Hi Mike,
    >>>>
    >>>> How do you set up multiple model files with different refModels
    >>>> with just a single EOGenerator args field in WOLips? Typically,
    >>>> we would use an external launch builder configuration for each
    >>>> EOModel. Each model could possibly have a couple of different
    >>>> refModels that it relies upon for cross-model relationships.
    >>>>
    >>>> Thanks,
    >>>>
    >>>> ___________________________________________________________________
    >>>> _
    >>>> Brendan Duddridge | CTO | 403-277-5591 x24 |
    >>>> brenda..lickspace.com
    >>>>
    >>>> ClickSpace Interactive Inc.
    >>>> Suite L100, 239 - 10th Ave. SE
    >>>> Calgary, AB T2G 0V9
    >>>>
    >>>> http://www.clickspace.com
    >>>>
    >>>> On Sep 26, 2005, at 10:30 AM, Mike Schrag wrote:
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>> Too late, it's already checked in :) But you can just choose
    >>>>> not to use it by not filling in an eogenerator path or
    >>>>> eogenerator args on your project. I personally find it to be
    >>>>> really handy just in the short time it has existed. As far as
    >>>>> auto-running, I've never had eogenerator cause problems for me
    >>>>> with the code it generates. And it was always the case that i
    >>>>> would just manually run code generation every time i made a
    >>>>> change to the model, anyway. So at least for my workflow, it
    >>>>> only makes development quicker. But then I detest having to
    >>>>> use ant build files from inside of eclipse for anything other
    >>>>> than deployment, so I may be biased :)
    >>>>>
    >>>>> On Sep 26, 2005, at 12:21 PM, Ian McDougall wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>> Personally, I don't believe the incremental builder should do
    >>>>>> any code generation. Plus, code generation from eomodeler has
    >>>>>> always been a manual process, and should probably continue to
    >>>>>> be so.
    >>>>>>
    >>>>>> It would be nice, however, to have a wizard that generates
    >>>>>> entity class pairs from the UI with the ability to specify/
    >>>>>> edit templates. At the very least it could generate an ant
    >>>>>> build file.
    >>>>>>
    >>>>>> _ _
    >>>>>> Ian
    >>>>>>
    >>>>>> On Sep 25, 2005, at 3:20 PM, Mike Schrag wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>> So I'm toying with the idea of an incremental builder that
    >>>>>>> calls eogenerator when eomodels get updated ... My question
    >>>>>>> is whether people would rather have just a text field where
    >>>>>>> they can put in the commandline or should i automagically
    >>>>>>> find all the prototype models and call eogenerator on each of
    >>>>>>> the eomodels in your project? Or would people rather not
    >>>>>>> have this at all?
    >>>>>>>
    >>>>>>> ms
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>
    >>>
    >>>
    >>
    >>
    >



    This archive was generated by hypermail 2.0.0 : Mon Sep 26 2005 - 20:32:11 EDT