Ah ok. I guess we just need to add "This is an Ant counterpart of "xyz" goal of maven-cayenne-plugin described above." to each Ant task.
Andrus On Mar 19, 2013, at 6:48 PM, John Huss <[email protected]> wrote: > Well, I use Ant and that section isn't filled in. :-P > > I think it would be better to not mention regular expressions and just to > say something like: > > A comma-separated list of ObjEntity names to exclude from template > generation. Wildcards may be used to match multiple entities, for example, > 'Artist*'. > > > > On Tue, Mar 19, 2013 at 1:35 AM, Andrus Adamchik > <[email protected]>wrote: > >> I should've checked before answering :) Actually looking at 3.1 docs, it >> seems to be there, and very explicit: >> >> >> https://cayenne.apache.org/docs/3.1/cayenne-guide/including-cayenne-in-project.html#maven-projects >> >> "excludeEntities A comma-separated list of ObjEntity patterns >> (expressed as a perl5 regex) to exclude from template generation. By >> default none of the DataMap entities are excluded." >> >> "includeEntities A comma-separated list of ObjEntity patterns >> (expressed as a perl5 regex) to include from template generation. By >> default all DataMap entities are included." >> >> So where is it missing? >> >> (and we can update 3.0 docs as well) >> >> Andrus >> >> On Mar 19, 2013, at 12:15 AM, John Huss <[email protected]> wrote: >> >>> Well, surprise, it already works this way. I could have sworn I tried it >>> and it didn't work, but it does. Regular comma-separated names work >> fine. >>> Wildcards are optional but can be used it desired. >>> >>> So I guess this is more of an issue with the docs - the page >>> here<https://cayenne.apache.org/docs/3.0/cgen.html>doesn't say >>> comma-separated values are allowed or wildcards, but rather >>> regular expressions. This section is blank in the new docs, so whenever >> it >>> gets filled in it should be clarified and should include and example >> with a >>> comma separated list. I suppose I should make a JIRA issue. >>> >>> Thanks, >>> John >>> >>> >>> On Mon, Mar 18, 2013 at 1:40 PM, Andrus Adamchik <[email protected] >>> wrote: >>> >>>> I tend to agree. I also find regexp confusing in this situation. Yeah, >>>> let's deprecate it and replace with a differently named "include" and >>>> "exclude" properties. Maybe still allow a "*" to be used to match more >> than >>>> one entity? >>>> >>>> Andrus >>>> >>>> On Mar 14, 2013, at 7:49 PM, John Huss <[email protected]> wrote: >>>>> I've been using CGen for a bit and one confusing aspect of it to me was >>>> the >>>>> way you specific which entities to include for generation. I expected >> a >>>>> simple comma-separated list, but it requires a regular expression. You >>>> can >>>>> sort of make it work like a comma-separated list by using something >> like >>>>> this: >>>>> >>>>> includeEntities="Customer|Invoice" >>>>> >>>>> The problem is that if you have entites whose names contain these >>>>> substrings, they will also be included - so an entity named >> InvoiceDetail >>>>> will also be generated. You can avoid it by using this: >>>>> >>>>> includeEntities="Customer|^Invoice$" >>>>> >>>>> While the vertical bar instead of a comma is unintuitive, but passable, >>>>> requiring this syntax is not friendly. >>>>> >>>>> So my questions are: >>>>> >>>>> 1) Are people actually using the reg-ex here for useful, more complex >>>>> things? >>>>> 2) Would it be reasonable to add another mutually-exclusive property >> that >>>>> just takes a comma-separated list of entity names? >>>>> >>>>> John >>>> >>>> >> >>
