I solved interpolation of boolean values (http://jira.codehaus.org/browse/MASSEMBLY-743) in modello 1.8.3 and r1644916.
I just though I'd like to add that the "new" solution with injection through the Xpp3Reader turned out to be a fair bit "simpler" than the old ObjectInterpolator strategy, it turned out to be a much more "natural" fit, since the interpolation target is 1:1 with the stuff being read, and there is no impedance mismatch. I seriously doubt that a stream-based approach will be better, since it basically introduces the same kind of impedance mismatch that I just removed again... Kristian 2014-12-07 12:22 GMT+01:00 Hervé BOUTEMY <herve.bout...@free.fr>: >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
