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
