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

Reply via email to