Hello,

I think using the enforcer is generally possible, but I am looking for an
option I can configure in the parent POM. For requireProperty I would have
to have a list of all the properties used in the assembly descriptors
(which means i have to maintain 2 times).

My goal is to find mismatch automatically and early without additional
manual steps.

I havent seen somewhere a general maven concept about handling unexpanded
properties, so I think about providing patches to some specific components
(if it has a chance to be included?).

Greetings
Bernd
 Am 08.03.2014 09:57 schrieb "Mirko Friedenhagen" <mfriedenha...@gmail.com>:

> Bernd,
>
> what about using enforcer's requireProperty rule?
>
> Regards
> Mirko
> --
> Sent from my mobile
> On Mar 7, 2014 10:20 PM, "Bernd Eckenfels" <e...@zusammenkunft.net> wrote:
>
> > Hello,
> >
> > we use in a lot of projects special assembly descriptors, which
> > typically use the following pattern:
> >
> > <assembly
> > ...
> >     <id>distribution</id>
> >     <baseDirectory></baseDirectory>
> >     <files>
> >         <file>
> >
> > <outputDirectory>${dist.x}/${dist.base.software.lib}</outputDirectory>
> >             <source>${project.build.directory}/x.jar</source>
> >         </file>
> >     </files>
> > </assembly>
> >
> > We are currently cleaning up some POMs and there is a risk that some of
> > the properties are no longer defined. This produces ZIP files which
> > have directory or file names in there with unexpanded ${dist*} symbols
> > (file name not filters).
> >
> > Is it possible to make the assembly (archiver?) plugin (and
> > others) fail in a situation where ${} cannot be interpolated?
> >
> > The same would be nice for manifest headers in the maven archiver
> > (filter in this case)?
> >
> > Greetings
> > Bernd
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Reply via email to