I have been thinking about adding a "generateSuperclasses" option to modello that would actually put the generated classes in a subpackage "generated" and let the actual implementation be up to the client (so in this case I would implement the class org.apache.maven.plugin.assembly.model.Assembly which would extend the class org.apache.maven.plugin.assembly.model.generated.Assembly generated by modello. AssemblyXpp3Reader would instantiate org.apache.maven.plugin.assembly.model.Assembly). So I would have custom code in org.apache.maven.plugin.assembly.model.Assembly that could extend the generated code
Do you think this is feasible ? There is still the issue of the "boolean" datatype. Changing 30 booleans to strings leads to a huge and undesirable footprint in the code. Using custom-written subclasses could solve some of this (and a few other problems of code generation too!) If we were able to make modello classes extend regular classes, I think it would be easy to make a *Xpp3Reader that supports interpolation. Is there any way we could do this ? (Maybe make a modello-client module that can contain modello base classes ?) Kristian 2014-12-06 17:11 GMT+01:00 Hervé BOUTEMY <herve.bout...@free.fr>: > I don't think this is a good idea: in general, a modello generated model > doesn't support interpolation. > > but you're right: something should be done in case of a model with > interpolation support > > Regards, > > Hervé > > Le samedi 6 décembre 2014 12:28:20 Kristian Rosenvold a écrit : >> Reading my own suggestion: I was suggesting to change modello to >> always back boolean fields with strings. >> >> 2014-12-06 12:21 GMT+01:00 Kristian Rosenvold > <kristian.rosenv...@gmail.com>: >> > Looking at the implications of changing all the 30+ boolean fields of >> > the assembly plugin to String, I really start thinking "what is the >> > point of code generation". It looks to me like we should at least just >> > globally change the backing datatype of "boolean" to String, and >> > generate overloads setXXX(String stringValue), setXXX(boolean >> > booleanValue), String getXXX() and boolean isXXX(). That should work, >> > or not ? >> > >> > It's no secret I dislike code generation, but then again I have not >> > made a commitment to love everything in our code base :) >> > Alternately I think this would be a suitable point in time to just >> > sever the entire modello binding and move the generated classes to >> > src/main. >> > >> > Kristan >> > >> > 2014-12-05 21:48 GMT+01:00 Hervé BOUTEMY <herve.bout...@free.fr>: >> >> Robert beat me at it :) >> >> >> >> Regards, >> >> >> >> Hervé >> >> >> >> Le vendredi 5 décembre 2014 18:55:55 Robert Scholte a écrit : >> >>> Hi Kristian, >> >>> >> >>> AFIAK this is indeed the only way to solve this. >> >>> Visit http://maven.apache.org/ref/3.2.3/maven-model/maven.html and >> >>> search >> >>> for "Boolean". You'll find elements which are actually a Boolean, but >> >>> are >> >>> a String for technical reasons. e.g. make it possible to interpolate >> >>> them. >> >>> >> >>> Robert >> >>> >> >>> Op Fri, 05 Dec 2014 16:36:46 +0100 schreef Kristian Rosenvold >> >>> >> >>> <kristian.rosenv...@zenior.no>: >> >>> > You should create an issue at >> >>> > http://jira.codehaus.org/browse/MASSEMBLY >> >>> > >> >>> > >> >>> > Hervé/Others: >> >>> > >> >>> > Since the attachement made it through, I took a quick look. The >> >>> > problem is that the modello-generated assembly descriptor has a >> >>> > "boolean" type for this value. Since the assembly descriptor >> >>> > interpolation happens "after" the AssemblyXpp3Reader has done its job, >> >>> > the only solution I can think of is to change the datatype of this >> >>> > field to "string"; which would preserve the original expression long >> >>> > enough for the interpolator to get hold of it. Is there any other way >> >>> > ? >> >>> > >> >>> > (Hmm. I could interpolate the assembly descriptor as an xml string >> >>> > *before* feeding it to AssemblyXpp3Reader, does that make sense ?) >> >>> > >> >>> > Kristian >> >>> > >> >>> > 2014-12-05 15:46 GMT+01:00 Jean-Eric Cuendet <j...@jesc.ch>: >> >>> >> Hi, >> >>> >> >> >>> >> It's the first time I post a bug on a maven plugin. If that's the >> >>> >> wrong >> >>> >> way, >> >>> >> please let me know where to do it. I found the issue tracker but I'm >> >>> >> unable >> >>> >> to create new issue. >> >>> >> >> >>> >> My problem: >> >>> >> I use the assembly plugin, with the <includeBaseDirectory> tag in the >> >>> >> assembly.xml file. If I put a variable (${mine.includeBaseDirectory}) >> >>> >> in the >> >>> >> tag, it's not taken into account. >> >>> >> But if I use true or false, that fine. >> >>> >> >> >>> >> I have created a small project that shows the problem. It's attached. >> >>> >> >> >>> >> To reproduce: >> >>> >> - unzip the attachment >> >>> >> - cd maven-assembly-bug/ >> >>> >> - mvn clean install assembly:single >> >>> >> The file maven-assembly-bug-1.0.0-SNAPSHOT.tar.gz doesn't contain the >> >>> >> baseDir, while the variable used is set to true >> >>> >> >> >>> >> If you change the value in assembly.xml to true or false (instead of >> >>> >> using >> >>> >> the variable), that's worting fine. >> >>> >> >> >>> >> Any idea? >> >>> >> Thanks a lot. >> >>> >> >> >>> >> -- >> >>> >> Jean-Eric Cuendet >> >>> >> Le Pré des Buis 1 >> >>> >> CH - 1315 La Sarraz >> >>> >> >> >>> >> Blog: http://jesc.ch >> >>> >> LinkedIn: http://www.linkedin.com/profile/view?id=1456133 >> >>> >> FB: http://www.facebook.com/profile.php?id=100002135244701 >> >>> >> Mobile: +41 76 222 3343 >> >>> > >> >>> > --------------------------------------------------------------------- >> >>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >>> > For additional commands, e-mail: dev-h...@maven.apache.org >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
