> Do you think this is feasible ? we maintain the generator, so anything is feasible if it's valid java :)
one hard part is to demonstrate the code you intend to generate before hacking the generator, because hacking the generator is always hard And I didn't really get the idea yet. > There is still the issue of the "boolean" datatype. notice the issue is in fact for any data type that is not String: interpolation requires to happen on String, and data type conversion has to to be done after interpolation which takes us to the demo before hacking the generator IMHO, we should create a little demo project with interpolation, let the code generate and hack generated code to show how interpolation support can be added Regards, Hervé Le samedi 6 décembre 2014 19:29:09 Kristian Rosenvold a écrit : > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
