[ http://jira.codehaus.org/browse/MNG-331?page=comments#action_40440 ] John Casey commented on MNG-331: --------------------------------
Regarding the first question: I don't see how a .mdo can extend anything meaningful, since it generates fields and methods for every <field/> element within a <class/>. This means that even if you were to extend some base class - say ProtoRepository, or something - you wouldn't be able to force the generated code to use the methods/fields in that super-class...it would duplicate the fields/methods in the subclass instead, and the xml parser bindings would use these new ones. Additionally, it doesn't really serve to reduce the size or duplication in the .mdo's. The other path would be to add some functionality that allowed one .mdo to import another .mdo, and use classes/interfaces/etc. defined in that second .mdo as an integral part of the first. This is not practically possible without using namespaces for each model, I don't think, since you have a separate parser per .mdo, and one doesn't know about the other, or when to delegate to the other. This *might* work if the importing model could add something to its parser telling it to construct a subparser of the imported type, and delegate to that subparser in certain cases. Otherwise, you're talking about straight import of the XML prior to code generation, which means duplicate classes in different packages, and the need to have conversion utilities a la o.a.m.profiles.ModelNormalizationUtils in maven-core. Regarding the second issue: I'll go update confluence now. > design profile and filtering solution > ------------------------------------- > > Key: MNG-331 > URL: http://jira.codehaus.org/browse/MNG-331 > Project: Maven 2 > Type: New Feature > Reporter: Brett Porter > Assignee: John Casey > Fix For: 2.0-alpha-3 > > > as discussed on the ML, need to be able to build different types of artifacts > for development by switching profiles (this can also be used to switch > deployment environments). > The final environment - QA or even earlier - should not be filtered > differently to production, but instead we swhould sort out a way to reprocess > the artifacts more predictably and suggest a best practice of externalising > all configuration so the artifact doesn't change at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
