Re: properties in maven-remote-resources-plugin

[Delany]

Solved. The remote project was packaging type pom.

Perhaps a mention of this could be added to the documentation?

Thanks,
Delany

On Fri, 9 Apr 2021 at 14:14, Delany  wrote:

> Hi. I'm able to use the maven-remote-resources-plugin when the source
> project is included in the reactor, but not when I'm just building the
> destination project.
>
> So for example `mvn clean install -pl :commondb,:credmanagementdb` yields
>
> [INFO] --- maven-remote-resources-plugin:1.7.0:bundle (default) @ commondb
> ---
> [INFO] Writing META-INF/maven/remote-resources.xml descriptor with 28
> entries
>
> and then
>
> [INFO] --- maven-remote-resources-plugin:1.7.0:process
> (unbundle-commondb-resources) @ credmanagementdb ---
> [INFO] Preparing remote bundle dbs:commondb:4.5.3.0
> [INFO] Copying 28 resources from 1 bundle.
>
> But if I say `mvn clean install -pl :credmanagementdb`, I get
>
> [INFO] --- maven-remote-resources-plugin:1.7.0:process
> (unbundle-commondb-resources) @ credmanagementdb ---
> [INFO] Preparing remote bundle dbs:commondb:4.5.3.0
> [INFO] Copying 0 resource from 0 bundle.
>
> I obviously always want these remote resources included whether I build
> individually or in a reactor. How can I get that?
>
> Thanks,
>
>
> On Tue, 9 Mar 2021 at 10:43, Delany  wrote:
>
>> Ok, no images thank you.
>> So I was barking up the wrong tree using the properties tag in the
>> plugin. I still don't know what I did wrong, but it works now.
>>
>> Now there's another issue. If I bundle resources in a
>> *descriptorgenerator* directory, the process goal will create an empty
>> maven-shared-archive-resources/descriptorgenerator directory. Why is it
>> filtering on this name?
>>
>> Thanks,
>>
>>
>> On Sun, 28 Feb 2021 at 12:23, Hervé BOUTEMY 
>> wrote:
>>
>>> please try to write:
>>>
>>>   
>>> 1.12
>>>   
>>>
>>> in you pom.xml = it defines a custom property with the value you want
>>>
>>> this will permit
>>> "dbs:commondb:${dep.dbs.commondb}" to get
>>> the value replaced
>>>
>>> Notice that images are removed, then we don't understand what you're
>>> trying to show
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le samedi 27 février 2021, 08:03:33 CET Delany a écrit :
>>> > I didn't want to give you all the context, because that complicates the
>>> > problem which I carefully worded in the initial email:
>>> >
>>> > "I don't want to hardcode the version number of the remote project into
>>> > this plugin config, so I've used a property made available in a parent
>>> pom."
>>> >
>>> > The fact that I don't use that version number property in the project
>>> that
>>> > bundles the remote resources is immaterial. The problem is that the
>>> process
>>> > goal in this receiving project will recognize one property
>>> > "project.version" and not another "dep.dbs.commondb". It does that
>>> because
>>> > project.version is one of the default properties the plugin passes
>>> through
>>> > to its templating logic, I quote
>>> >
>>> > "Additional properties to be passed to Velocity. Several properties are
>>> > automatically added:"
>>> >
>>> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo
>>> .
>>> > html#properties
>>> >
>>> > So has anyone ever successfully passed through a non-default property?
>>> Or
>>> > is this dead code no one ever uses.
>>> > The example given here
>>> > <
>>> https://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sha
>>> > ring-resources.html> demonstrates using the project.version property.
>>> But
>>> > you don't need to use the properties tag for that. There are no
>>> examples
>>> > showing the use of the properties tag of this goal.
>>> >
>>> > [image: image.png]
>>> >
>>> > The link at the bottom is to some generic javadoc about properties,
>>> and it
>>> > happens to be dead.
>>> >
>>> > Thanks,
>>> >
>>> > On Sat, 27 Feb 2021 at 05:47, Anthony Whitford 
>>> wrote:
>>> > > I’m honestly unclear on your precise scenario.
>>> > > 1.  If you are expecting a dependency to have a pom with a variable
>>> in it,
>>> > > that then you would specify before using it, then Maven doesn’t work
>>> that
>>> > > way.  (And if you think about it, it creates a chicken-egg problem.)
>>> > > 2.  If you are expecting to use a pom property from a dependency,
>>> then you
>>> > > can’t do that either.  (And if you think about it, that could be
>>> dangerous
>>> > > because children properties could collide or interfere with your
>>> own.)
>>> > >
>>> > > Note that you can declare a dependency/plugin and override a
>>> dependency —
>>> > > sometimes that is useful.
>>> > >
>>> > > I highly recommend  `mvn help:effective-pom` to see exactly what a
>>> > > project’s pom results look like; it can be insightful.
>>> > >
>>> > > You can also use  `mvn help:evaluate` to see the value of
>>> expressions.
>>> > >
>>> > > This is also a good reference:
>>> > >
>>> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
>>> > > roperties.html <
>>> > >
>>> https://books.s

Re: properties in maven-remote-resources-plugin

[Delany]

Hi. I'm able to use the maven-remote-resources-plugin when the source
project is included in the reactor, but not when I'm just building the
destination project.

So for example `mvn clean install -pl :commondb,:credmanagementdb` yields

[INFO] --- maven-remote-resources-plugin:1.7.0:bundle (default) @ commondb
---
[INFO] Writing META-INF/maven/remote-resources.xml descriptor with 28
entries

and then

[INFO] --- maven-remote-resources-plugin:1.7.0:process
(unbundle-commondb-resources) @ credmanagementdb ---
[INFO] Preparing remote bundle dbs:commondb:4.5.3.0
[INFO] Copying 28 resources from 1 bundle.

But if I say `mvn clean install -pl :credmanagementdb`, I get

[INFO] --- maven-remote-resources-plugin:1.7.0:process
(unbundle-commondb-resources) @ credmanagementdb ---
[INFO] Preparing remote bundle dbs:commondb:4.5.3.0
[INFO] Copying 0 resource from 0 bundle.

I obviously always want these remote resources included whether I build
individually or in a reactor. How can I get that?

Thanks,


On Tue, 9 Mar 2021 at 10:43, Delany  wrote:

> Ok, no images thank you.
> So I was barking up the wrong tree using the properties tag in the plugin.
> I still don't know what I did wrong, but it works now.
>
> Now there's another issue. If I bundle resources in a
> *descriptorgenerator* directory, the process goal will create an empty
> maven-shared-archive-resources/descriptorgenerator directory. Why is it
> filtering on this name?
>
> Thanks,
>
>
> On Sun, 28 Feb 2021 at 12:23, Hervé BOUTEMY  wrote:
>
>> please try to write:
>>
>>   
>> 1.12
>>   
>>
>> in you pom.xml = it defines a custom property with the value you want
>>
>> this will permit
>> "dbs:commondb:${dep.dbs.commondb}" to get
>> the value replaced
>>
>> Notice that images are removed, then we don't understand what you're
>> trying to show
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 27 février 2021, 08:03:33 CET Delany a écrit :
>> > I didn't want to give you all the context, because that complicates the
>> > problem which I carefully worded in the initial email:
>> >
>> > "I don't want to hardcode the version number of the remote project into
>> > this plugin config, so I've used a property made available in a parent
>> pom."
>> >
>> > The fact that I don't use that version number property in the project
>> that
>> > bundles the remote resources is immaterial. The problem is that the
>> process
>> > goal in this receiving project will recognize one property
>> > "project.version" and not another "dep.dbs.commondb". It does that
>> because
>> > project.version is one of the default properties the plugin passes
>> through
>> > to its templating logic, I quote
>> >
>> > "Additional properties to be passed to Velocity. Several properties are
>> > automatically added:"
>> >
>> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo
>> .
>> > html#properties
>> >
>> > So has anyone ever successfully passed through a non-default property?
>> Or
>> > is this dead code no one ever uses.
>> > The example given here
>> > <
>> https://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sha
>> > ring-resources.html> demonstrates using the project.version property.
>> But
>> > you don't need to use the properties tag for that. There are no examples
>> > showing the use of the properties tag of this goal.
>> >
>> > [image: image.png]
>> >
>> > The link at the bottom is to some generic javadoc about properties, and
>> it
>> > happens to be dead.
>> >
>> > Thanks,
>> >
>> > On Sat, 27 Feb 2021 at 05:47, Anthony Whitford 
>> wrote:
>> > > I’m honestly unclear on your precise scenario.
>> > > 1.  If you are expecting a dependency to have a pom with a variable
>> in it,
>> > > that then you would specify before using it, then Maven doesn’t work
>> that
>> > > way.  (And if you think about it, it creates a chicken-egg problem.)
>> > > 2.  If you are expecting to use a pom property from a dependency,
>> then you
>> > > can’t do that either.  (And if you think about it, that could be
>> dangerous
>> > > because children properties could collide or interfere with your own.)
>> > >
>> > > Note that you can declare a dependency/plugin and override a
>> dependency —
>> > > sometimes that is useful.
>> > >
>> > > I highly recommend  `mvn help:effective-pom` to see exactly what a
>> > > project’s pom results look like; it can be insightful.
>> > >
>> > > You can also use  `mvn help:evaluate` to see the value of expressions.
>> > >
>> > > This is also a good reference:
>> > >
>> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
>> > > roperties.html <
>> > >
>> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
>> > > roperties.html
>> > >
>> > >
>> > > Hope this helps,
>> > >
>> > > Anthony
>> > >
>> > > > On Feb 23, 2021, at 11:32 PM, Delany 
>> wrote:
>> > > >
>> > > > Thanks I know how to use properties, but this plugin doesn't, it
>> seems.
>> > >
>> > > It has some special way of importing them

Re: properties in maven-remote-resources-plugin

[Delany]

Ok, no images thank you.
So I was barking up the wrong tree using the properties tag in the plugin.
I still don't know what I did wrong, but it works now.

Now there's another issue. If I bundle resources in a *descriptorgenerator*
directory, the process goal will create an empty
maven-shared-archive-resources/descriptorgenerator directory. Why is it
filtering on this name?

Thanks,


On Sun, 28 Feb 2021 at 12:23, Hervé BOUTEMY  wrote:

> please try to write:
>
>   
> 1.12
>   
>
> in you pom.xml = it defines a custom property with the value you want
>
> this will permit
> "dbs:commondb:${dep.dbs.commondb}" to get
> the value replaced
>
> Notice that images are removed, then we don't understand what you're
> trying to show
>
> Regards,
>
> Hervé
>
> Le samedi 27 février 2021, 08:03:33 CET Delany a écrit :
> > I didn't want to give you all the context, because that complicates the
> > problem which I carefully worded in the initial email:
> >
> > "I don't want to hardcode the version number of the remote project into
> > this plugin config, so I've used a property made available in a parent
> pom."
> >
> > The fact that I don't use that version number property in the project
> that
> > bundles the remote resources is immaterial. The problem is that the
> process
> > goal in this receiving project will recognize one property
> > "project.version" and not another "dep.dbs.commondb". It does that
> because
> > project.version is one of the default properties the plugin passes
> through
> > to its templating logic, I quote
> >
> > "Additional properties to be passed to Velocity. Several properties are
> > automatically added:"
> >
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo
> .
> > html#properties
> >
> > So has anyone ever successfully passed through a non-default property? Or
> > is this dead code no one ever uses.
> > The example given here
> > <
> https://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sha
> > ring-resources.html> demonstrates using the project.version property. But
> > you don't need to use the properties tag for that. There are no examples
> > showing the use of the properties tag of this goal.
> >
> > [image: image.png]
> >
> > The link at the bottom is to some generic javadoc about properties, and
> it
> > happens to be dead.
> >
> > Thanks,
> >
> > On Sat, 27 Feb 2021 at 05:47, Anthony Whitford 
> wrote:
> > > I’m honestly unclear on your precise scenario.
> > > 1.  If you are expecting a dependency to have a pom with a variable in
> it,
> > > that then you would specify before using it, then Maven doesn’t work
> that
> > > way.  (And if you think about it, it creates a chicken-egg problem.)
> > > 2.  If you are expecting to use a pom property from a dependency, then
> you
> > > can’t do that either.  (And if you think about it, that could be
> dangerous
> > > because children properties could collide or interfere with your own.)
> > >
> > > Note that you can declare a dependency/plugin and override a
> dependency —
> > > sometimes that is useful.
> > >
> > > I highly recommend  `mvn help:effective-pom` to see exactly what a
> > > project’s pom results look like; it can be insightful.
> > >
> > > You can also use  `mvn help:evaluate` to see the value of expressions.
> > >
> > > This is also a good reference:
> > >
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
> > > roperties.html <
> > >
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
> > > roperties.html
> > >
> > >
> > > Hope this helps,
> > >
> > > Anthony
> > >
> > > > On Feb 23, 2021, at 11:32 PM, Delany 
> wrote:
> > > >
> > > > Thanks I know how to use properties, but this plugin doesn't, it
> seems.
> > >
> > > It has some special way of importing them:
> > >
> > >
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-moj
> > > o.html <
> > >
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-moj
> > > o.html>
> > > > It can do this
> > >
> > >
> org.test:shared-resources:${project.version} > > le>>
> > > > But this is the version of this project, not the resource bundle
> > >
> > > org.test:shared-resources. Why would I ever do that? The plugin is
> > > assuming
> > > that all project modules in the reactor have the same version.
> > >
> > > > I need it to do this
> > >
> > >
> org.test:shared-resources:${shared-resources.version} > > ourceBundle>>
> > > > It looks like if I make commondb a dependency, I can use the projects
> > >
> > > property to access the version number. How do I do that?
> > >
> > > > Thanks,
> > > > Delany
> > > >
> > > >
> > > > On Tue, 23 Feb 2021 at 22:46, Anthony Whitford  > >
> > > > wrote:
> > > > The  tag is documented here:
> > >
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > > properties <
> > >
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > > prop

Re: properties in maven-remote-resources-plugin

[Hervé BOUTEMY]

please try to write:

  
1.12
  

in you pom.xml = it defines a custom property with the value you want

this will permit 
"dbs:commondb:${dep.dbs.commondb}" to get the 
value replaced

Notice that images are removed, then we don't understand what you're trying to 
show

Regards,

Hervé

Le samedi 27 février 2021, 08:03:33 CET Delany a écrit :
> I didn't want to give you all the context, because that complicates the
> problem which I carefully worded in the initial email:
> 
> "I don't want to hardcode the version number of the remote project into
> this plugin config, so I've used a property made available in a parent pom."
> 
> The fact that I don't use that version number property in the project that
> bundles the remote resources is immaterial. The problem is that the process
> goal in this receiving project will recognize one property
> "project.version" and not another "dep.dbs.commondb". It does that because
> project.version is one of the default properties the plugin passes through
> to its templating logic, I quote
> 
> "Additional properties to be passed to Velocity. Several properties are
> automatically added:"
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.
> html#properties
> 
> So has anyone ever successfully passed through a non-default property? Or
> is this dead code no one ever uses.
> The example given here
>  ring-resources.html> demonstrates using the project.version property. But
> you don't need to use the properties tag for that. There are no examples
> showing the use of the properties tag of this goal.
> 
> [image: image.png]
> 
> The link at the bottom is to some generic javadoc about properties, and it
> happens to be dead.
> 
> Thanks,
> 
> On Sat, 27 Feb 2021 at 05:47, Anthony Whitford  wrote:
> > I’m honestly unclear on your precise scenario.
> > 1.  If you are expecting a dependency to have a pom with a variable in it,
> > that then you would specify before using it, then Maven doesn’t work that
> > way.  (And if you think about it, it creates a chicken-egg problem.)
> > 2.  If you are expecting to use a pom property from a dependency, then you
> > can’t do that either.  (And if you think about it, that could be dangerous
> > because children properties could collide or interfere with your own.)
> > 
> > Note that you can declare a dependency/plugin and override a dependency —
> > sometimes that is useful.
> > 
> > I highly recommend  `mvn help:effective-pom` to see exactly what a
> > project’s pom results look like; it can be insightful.
> > 
> > You can also use  `mvn help:evaluate` to see the value of expressions.
> > 
> > This is also a good reference:
> > https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
> > roperties.html <
> > https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-p
> > roperties.html
> > 
> > 
> > Hope this helps,
> > 
> > Anthony
> > 
> > > On Feb 23, 2021, at 11:32 PM, Delany  wrote:
> > > 
> > > Thanks I know how to use properties, but this plugin doesn't, it seems.
> > 
> > It has some special way of importing them:
> > 
> > https://maven.apache.org/plugins/maven-remote-resources-plugin/process-moj
> > o.html <
> > https://maven.apache.org/plugins/maven-remote-resources-plugin/process-moj
> > o.html> 
> > > It can do this
> > 
> > org.test:shared-resources:${project.version} > le>> 
> > > But this is the version of this project, not the resource bundle
> > 
> > org.test:shared-resources. Why would I ever do that? The plugin is
> > assuming
> > that all project modules in the reactor have the same version.
> > 
> > > I need it to do this
> > 
> > org.test:shared-resources:${shared-resources.version} > ourceBundle>> 
> > > It looks like if I make commondb a dependency, I can use the projects
> > 
> > property to access the version number. How do I do that?
> > 
> > > Thanks,
> > > Delany
> > > 
> > > 
> > > On Tue, 23 Feb 2021 at 22:46, Anthony Whitford  > 
> > > wrote:
> > > The  tag is documented here:
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties <
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties> <
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties <
> > https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#
> > properties> 
> > > > On Feb 23, 2021, at 3:34 AM, Delany  > 
> > > wrote:
> > > > I don't want to hardcode the version number of the remote project into
> > 
> > this
> > 
> > > > plugin config, so I've used a property made available in a parent pom.
> > > > But it's not being resolved. What am I doing wrong?
> > > > 
> > > >  
> > > >  
> > > >maven-remote-resources-plugin
> > > >
> > > >
> > > >  
> > > >  
> > > >  

Re: properties in maven-remote-resources-plugin

[Delany]

I didn't want to give you all the context, because that complicates the
problem which I carefully worded in the initial email:

"I don't want to hardcode the version number of the remote project into
this plugin config, so I've used a property made available in a parent pom."

The fact that I don't use that version number property in the project that
bundles the remote resources is immaterial. The problem is that the process
goal in this receiving project will recognize one property
"project.version" and not another "dep.dbs.commondb". It does that because
project.version is one of the default properties the plugin passes through
to its templating logic, I quote

"Additional properties to be passed to Velocity. Several properties are
automatically added:"
https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.html#properties

So has anyone ever successfully passed through a non-default property? Or
is this dead code no one ever uses.
The example given here

demonstrates using the project.version property. But you don't need to use
the properties tag for that. There are no examples showing the use of the
properties tag of this goal.

[image: image.png]

The link at the bottom is to some generic javadoc about properties, and it
happens to be dead.

Thanks,

On Sat, 27 Feb 2021 at 05:47, Anthony Whitford  wrote:

> I’m honestly unclear on your precise scenario.
> 1.  If you are expecting a dependency to have a pom with a variable in it,
> that then you would specify before using it, then Maven doesn’t work that
> way.  (And if you think about it, it creates a chicken-egg problem.)
> 2.  If you are expecting to use a pom property from a dependency, then you
> can’t do that either.  (And if you think about it, that could be dangerous
> because children properties could collide or interfere with your own.)
>
> Note that you can declare a dependency/plugin and override a dependency —
> sometimes that is useful.
>
> I highly recommend  `mvn help:effective-pom` to see exactly what a
> project’s pom results look like; it can be insightful.
>
> You can also use  `mvn help:evaluate` to see the value of expressions.
>
> This is also a good reference:
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> <
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
> >
>
> Hope this helps,
>
> Anthony
>
>
> > On Feb 23, 2021, at 11:32 PM, Delany  wrote:
> >
> > Thanks I know how to use properties, but this plugin doesn't, it seems.
> It has some special way of importing them:
> >
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.html
> <
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.html
> >
> >
> >
> >
> > It can do this
> >
> >
> org.test:shared-resources:${project.version}
> >
> > But this is the version of this project, not the resource bundle
> org.test:shared-resources. Why would I ever do that? The plugin is assuming
> that all project modules in the reactor have the same version.
> >
> > I need it to do this
> >
> >
> org.test:shared-resources:${shared-resources.version}
> >
> > It looks like if I make commondb a dependency, I can use the projects
> property to access the version number. How do I do that?
> >
> > Thanks,
> > Delany
> >
> >
> > On Tue, 23 Feb 2021 at 22:46, Anthony Whitford  > wrote:
> > The  tag is documented here:
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
> <
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties>
> <
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
> <
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
> >>
> >
> >
> > > On Feb 23, 2021, at 3:34 AM, Delany  > wrote:
> > >
> > > I don't want to hardcode the version number of the remote project into
> this
> > > plugin config, so I've used a property made available in a parent pom.
> > > But it's not being resolved. What am I doing wrong?
> > >
> > >  
> > >maven-remote-resources-plugin
> > >
> > >  
> > >process-remote-resources
> > >
> > >  process
> > >
> > >
> > >  
> > >
> > > dbs:commondb:${dep.dbs.commondb}
> > >  
> > >
> > >  
> > >
> > >  
> > >
> > > There's a mention of including a  tag that is a map, but
> Im not
> > > sure what that should look like.
> > >
> > >
> https://maven.apache.org/plugins/maven-remote-resources-plugin/usage.html
>  >
> > >
> > > Thanks,
> >
>
>

Re: properties in maven-remote-resources-plugin

[Anthony Whitford]

I’m honestly unclear on your precise scenario.
1.  If you are expecting a dependency to have a pom with a variable in it, that 
then you would specify before using it, then Maven doesn’t work that way.  (And 
if you think about it, it creates a chicken-egg problem.)
2.  If you are expecting to use a pom property from a dependency, then you 
can’t do that either.  (And if you think about it, that could be dangerous 
because children properties could collide or interfere with your own.)

Note that you can declare a dependency/plugin and override a dependency — 
sometimes that is useful.

I highly recommend  `mvn help:effective-pom` to see exactly what a project’s 
pom results look like; it can be insightful.

You can also use  `mvn help:evaluate` to see the value of expressions.

This is also a good reference:  
https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html
 


Hope this helps,

Anthony


> On Feb 23, 2021, at 11:32 PM, Delany  wrote:
> 
> Thanks I know how to use properties, but this plugin doesn't, it seems. It 
> has some special way of importing them:
> https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.html
>  
> 
> 
> 
> 
> It can do this
> 
> org.test:shared-resources:${project.version}
> 
> But this is the version of this project, not the resource bundle 
> org.test:shared-resources. Why would I ever do that? The plugin is assuming 
> that all project modules in the reactor have the same version.
> 
> I need it to do this
> 
> org.test:shared-resources:${shared-resources.version}
> 
> It looks like if I make commondb a dependency, I can use the projects 
> property to access the version number. How do I do that?
> 
> Thanks,
> Delany
> 
> 
> On Tue, 23 Feb 2021 at 22:46, Anthony Whitford  > wrote:
> The  tag is documented here: 
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
>  
> 
>  
>   
> >
> 
> 
> > On Feb 23, 2021, at 3:34 AM, Delany  > > wrote:
> > 
> > I don't want to hardcode the version number of the remote project into this
> > plugin config, so I've used a property made available in a parent pom.
> > But it's not being resolved. What am I doing wrong?
> > 
> >  
> >maven-remote-resources-plugin
> >
> >  
> >process-remote-resources
> >
> >  process
> >
> >
> >  
> > 
> > dbs:commondb:${dep.dbs.commondb}
> >  
> >
> >  
> >
> >  
> > 
> > There's a mention of including a  tag that is a map, but Im not
> > sure what that should look like.
> > 
> > https://maven.apache.org/plugins/maven-remote-resources-plugin/usage.html 
> > 
> > 
> > Thanks,
> 

Re: properties in maven-remote-resources-plugin

[Delany]

Thanks I know how to use properties, but this plugin doesn't, it seems. It
has some special way of importing them:
https://maven.apache.org/plugins/maven-remote-resources-plugin/process-mojo.html

[image: image.png]

It can do this

org.test:shared-resources:${project.version}

But this is the version of *this* project, not the resource bundle
org.test:shared-resources. Why would I ever do that? The plugin is assuming
that all project modules in the reactor have the same version.

I need it to do this

org.test:shared-resources:${shared-resources.version}

It looks like if I make commondb a dependency, I can use the *projects*
property to access the version number. How do I do that?

Thanks,
Delany


On Tue, 23 Feb 2021 at 22:46, Anthony Whitford  wrote:

> The  tag is documented here:
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
> <
> https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
> >
>
>
> > On Feb 23, 2021, at 3:34 AM, Delany  wrote:
> >
> > I don't want to hardcode the version number of the remote project into
> this
> > plugin config, so I've used a property made available in a parent pom.
> > But it's not being resolved. What am I doing wrong?
> >
> >  
> >maven-remote-resources-plugin
> >
> >  
> >process-remote-resources
> >
> >  process
> >
> >
> >  
> >
> > dbs:commondb:${dep.dbs.commondb}
> >  
> >
> >  
> >
> >  
> >
> > There's a mention of including a  tag that is a map, but Im
> not
> > sure what that should look like.
> >
> >
> https://maven.apache.org/plugins/maven-remote-resources-plugin/usage.html
> >
> > Thanks,
>
>

Re: properties in maven-remote-resources-plugin

[Anthony Whitford]

The  tag is documented here: 
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#properties
 



> On Feb 23, 2021, at 3:34 AM, Delany  wrote:
> 
> I don't want to hardcode the version number of the remote project into this
> plugin config, so I've used a property made available in a parent pom.
> But it's not being resolved. What am I doing wrong?
> 
>  
>maven-remote-resources-plugin
>
>  
>process-remote-resources
>
>  process
>
>
>  
> 
> dbs:commondb:${dep.dbs.commondb}
>  
>
>  
>
>  
> 
> There's a mention of including a  tag that is a map, but Im not
> sure what that should look like.
> 
> https://maven.apache.org/plugins/maven-remote-resources-plugin/usage.html
> 
> Thanks,

Re: properties in maven-remote-resources-plugin

[Delany]

Well I gave it my best shot

  
maven-remote-resources-plugin

  
process-remote-resources

  process


  
dbs:commondb:${bully}
  
  
3
  

  

  

It looks like the process goal has been abandoned and everyone is just
using maven-dependency-plugin's unpack-dependencies goal.


On Tue, 23 Feb 2021 at 13:34, Delany  wrote:

> I don't want to hardcode the version number of the remote project into
> this plugin config, so I've used a property made available in a parent pom.
> But it's not being resolved. What am I doing wrong?
>
>   
> maven-remote-resources-plugin
> 
>   
> process-remote-resources
> 
>   process
> 
> 
>   
>
> dbs:commondb:${dep.dbs.commondb}
>   
> 
>   
> 
>   
>
> There's a mention of including a  tag that is a map, but Im
> not sure what that should look like.
>
> https://maven.apache.org/plugins/maven-remote-resources-plugin/usage.html
>
> Thanks,
>