Wouldn't it be easier to add interpolation with something like: Model model = MavenXpp3Reader.read(new MyFilterInputStream(inputStream));
Instead of adding interpolation into Modello? Swizzle has lots of nice filtering implementations: http://svn.codehaus.org/swizzle/trunk/swizzle-stream/src/main/java/org/codehaus/swizzle/stream/ On Dec 8, 2014, at 12:35 PM, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote: > I fixed interpolation in modello for Xpp3reader. > http://jira.codehaus.org/browse/MODELLO-290. Build 1.8.3-SNAPSHOT from > git if you want to test it. > > I'll play around with base class generation for a day or two before > releasing 1.8.3 (maybe 1.9) > > K > > > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io ---------------------------------------------------------
