You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@zenior.no> on 2014/12/05 16:36:46 UTC
Re: Maven assembly plugin : includeBaseDirectory not correctly used
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 <je...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <he...@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 <he...@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
>> >
>> > <kr...@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 <he...@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
>> >> >>>
>> >> >>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>> >> >>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>
>> >> >>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <kr...@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 <he...@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 <he...@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
>>>>>
>>>>> <kr...@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 <he...@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
>>>>>>>>>
>>>>>>>>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by 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 <kr...@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 <he...@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 <he...@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
>>>>
>>>> <kr...@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 <he...@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
>>>>>>>>
>>>>>>>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <he...@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 <he...@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
>> >
>> > <kr...@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 <he...@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
>> >> >>>
>> >> >>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>> >> >>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>
>> >> >>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Hervé BOUTEMY <he...@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 <he...@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
> >
> > <kr...@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 <he...@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
> >> >>>
> >> >>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
> >> >>> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <he...@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
> <kr...@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 <he...@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
>> >>>
>> >>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>> >>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Hervé BOUTEMY <he...@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
<kr...@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 <he...@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
> >>>
> >>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
> >>> > For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <kr...@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 <he...@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
>>>
>>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Kristian Rosenvold <kr...@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 <he...@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
>>
>> <kr...@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 <je...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Hervé BOUTEMY <he...@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
>
> <kr...@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 <je...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven assembly plugin : includeBaseDirectory not correctly used
Posted by Robert Scholte <rf...@apache.org>.
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
<kr...@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 <je...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org