The extension I added to Xpp3Reader is simple and is not coupled to any kind of specific external code and is just a general purpose extension point.
Swizzle looks cool. I'm not entirely convinced interpolation at the stream level will be entirely without a round of gotchas, various forms of xml related escaping being the first that come to mind. Certainly if someone wants to give it a shot and iron out the interesting bugs that will arise I'l be more than happy to try it. Field-level interpolation is safe. (And technically, extracting the interpolator enough to inject it in the proper place is the most significant change for the code base. Injecting "differently" is a minor change if it should ever come around) Kristian 2014-12-08 22:12 GMT+01:00 Jason van Zyl <ja...@takari.io>: > 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 > --------------------------------------------------------- > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
