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 <
>>> > >
>>> 

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 

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#
> > > 

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,
>

Re: Properties Files

[Greg Trasuk]

Converting projects to Maven is not always a direct process.

You might want to check out the document below.  It talks about a systematic 
approach to converting projects to Maven, based on the artifacts that are 
created.  

http://www.webagesolutions.com/knowledgebase/kb001-Converting-To-Maven.html 
http://www.webagesolutions.com/knowledgebase/kb001-Converting-To-Maven.html

Cheers,

Greg Trasuk

 On Aug 18, 2015, at 10:02 AM, aalok singhvi aaloksing...@gmail.com wrote:
 
 It's a migration of an ant project. It's java project. Presently ant gets
 build properties file on compile time.
 On Aug 18, 2015 9:56 AM, Ron Wheeler rwhee...@artifact-software.com
 wrote:
 
 What are you building?
 What language and technology stack?
 
 What are the properties files used for - run-time? If so, where do you
 want them to end up when you install your app?
 How are you installing it?
 
 Ron
 
 On 18/08/2015 7:02 AM, aalok singhvi wrote:
 
 Hello,
 
 I have a properties files. I have a multi modules project
 with 1 parent pom and approx 19 child modules. Where should
 i be putting the properties files which can be consumed by all
 the child modules.
 
 Thanks
 
 
 
 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: Properties Files

[Ron Wheeler]

What is their purpose now if you are not using Ant?

If these are properties for the build, they should be inside the parent 
POM as properties.


Ron

On 18/08/2015 10:02 AM, aalok singhvi wrote:

It's a migration of an ant project. It's java project. Presently ant gets
build properties file on compile time.
On Aug 18, 2015 9:56 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:


What are you building?
What language and technology stack?

What are the properties files used for - run-time? If so, where do you
want them to end up when you install your app?
How are you installing it?

Ron

On 18/08/2015 7:02 AM, aalok singhvi wrote:


Hello,

I have a properties files. I have a multi modules project
with 1 parent pom and approx 19 child modules. Where should
i be putting the properties files which can be consumed by all
the child modules.

Thanks



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties Files

[aalok singhvi]

It's a migration of an ant project. It's java project. Presently ant gets
build properties file on compile time.
On Aug 18, 2015 9:56 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 What are you building?
 What language and technology stack?

 What are the properties files used for - run-time? If so, where do you
 want them to end up when you install your app?
 How are you installing it?

 Ron

 On 18/08/2015 7:02 AM, aalok singhvi wrote:

 Hello,

 I have a properties files. I have a multi modules project
 with 1 parent pom and approx 19 child modules. Where should
 i be putting the properties files which can be consumed by all
 the child modules.

 Thanks



 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties Files

[Adrien Rivard]

Hi,

For build time use, the simplest way is to put directly properties in
pom.xml (parent or childs depending on how/where it is used).
See
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html ,
last part.


If you have lots of them it could eventually be externalized with the use
of a specific plugin, but I would'nt recommend that at first.
Most probably you will end up with differents properties for ant vs maven
build anyway.
See http://www.mojohaus.org/properties-maven-plugin/usage.html



On Tue, Aug 18, 2015 at 4:02 PM, aalok singhvi aaloksing...@gmail.com
wrote:

 It's a migration of an ant project. It's java project. Presently ant gets
 build properties file on compile time.
 On Aug 18, 2015 9:56 AM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

  What are you building?
  What language and technology stack?
 
  What are the properties files used for - run-time? If so, where do you
  want them to end up when you install your app?
  How are you installing it?
 
  Ron
 
  On 18/08/2015 7:02 AM, aalok singhvi wrote:
 
  Hello,
 
  I have a properties files. I have a multi modules project
  with 1 parent pom and approx 19 child modules. Where should
  i be putting the properties files which can be consumed by all
  the child modules.
 
  Thanks
 
 
 
  --
  Ron Wheeler
  President
  Artifact Software Inc
  email: rwhee...@artifact-software.com
  skype: ronaldmwheeler
  phone: 866-970-2435, ext 102
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 




-- 
Adrien Rivard

Re: Properties Files

[Ron Wheeler]

What are you building?
What language and technology stack?

What are the properties files used for - run-time? If so, where do you 
want them to end up when you install your app?

How are you installing it?

Ron

On 18/08/2015 7:02 AM, aalok singhvi wrote:

Hello,

I have a properties files. I have a multi modules project
with 1 parent pom and approx 19 child modules. Where should
i be putting the properties files which can be consumed by all
the child modules.

Thanks




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties that are not being resolved

[Stephen Connolly]

The File vs String types note is the relevant part IIRC... It's not just
file vs string though

On Tuesday, 25 March 2014, Henrik Østerlund Gram henrik.g...@gmail.com
wrote:

 Thanks for the link.  It was quite informative, but I'm again a little
 confused because it is stated in your explanation,
 the configuration sections will have mojo-injected properties evaluated,
 but that isn't the case in my example.  I was trying to have such
 properties evaluated in a envEntries element inside a configuration
 element for the ear plugin, but it would not work until I modified the
 plugin to do an extra substitution itself.

 Regards,
 Henrik Gram

 On Mon, Mar 24, 2014 at 10:38 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  Please read my answer to a similar question on Stack Overflow:
 
 
 http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
 
 
  On 23 March 2014 21:36, Henrik Østerlund Gram henrik.g...@gmail.com
  wrote:
 
   I stumbled over some rather strange behaviour regarding properties.  It
   seems properties generated by one plugin are not always resolved for
  other
   plugins and I can't figure out why.
  
   I use a plugin to make info about the git branch available in the
   properties so it can be passed to other plugins.  The particular plugin
   does not seem important, but I've included it here for sake of
   completeness:
  
   plugin
   groupIdcom.code54.mojo/groupId
   artifactIdbuildversion-plugin/artifactId
version1.0.3/version
   configuration
   tstamp_format.MM.dd HH:mm/tstamp_format
/configuration
   executions
   execution
goals
   goalset-properties/goal
   /goals
/execution
   /executions
   /plugin
  
   But when I referenced the properties set by the plugin in an env entry
  for
   the maven ear plugin, the properties were not resolved at all:
  
   envEntries
   env-entry
   descriptionMiddleware build information/description
env-entry-namejava:app/env/sw-version/env-entry-name
   env-entry-typejava.lang.String/env-entry-type
env-entry-value${build-commit} @ ${build-tstamp} built on
   ${maven.build.timestamp}/env-entry-value
   /env-entry
   /envEntries
  
   Just to be sure, I used the latest maven and tried both version 2.9 of
  the
   plugin and the latest from the repo with the same result.
  
   The only way I managed to fix this was to patch the maven-ear-plugin
   itself, adding the following code in
  GenerateApplicationXmlMojo.execute():
  
   // Fix env variable substitutions
   Properties props = project.getProperties();
   PlexusConfiguration[] entries = envEntries.getChildren();
   if (entries != null) {
   for (PlexusConfiguration entry : entries) {
   if (env-entry.equals(entry.getName())) {
   PlexusConfiguration[] envEntryChildren =
 entry.getChildren();
   if (envEntryChildren != null) {
   for (PlexusConfiguration envEntryChild :
  envEntryChildren)
   {
  
   envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
   props));
   }
   }
   }
   }
   }
  
   Then it worked just fine, but I don't understand why this is necessary.
   I
   thought whatever called the plugin was supposed to have done the
 variable
   substitution already.  So clearly the properties were present at the
 time
   of executing the plugin, but they werent being automaticly substituted.
  
   To add to the confusion, using ${project.version} in the
 env-entry-value
   was resolved just fine, but just not the properties coming from another
   plugin despite the plugins being run in the correct order.
  
   To further add to th



-- 
Sent from my phone

Re: properties that are not being resolved

[Baptiste Mathus]

Hi,
Out of curiosity, why don't you use the seemingly equivalent mojo
buildnumber maven plugin? May not be your issue, but may be the plugin
you're using doesn't create properties in the right way (no offense, just
trying to guess)?
My 2 cents
Le 23 mars 2014 22:37, Henrik Østerlund Gram henrik.g...@gmail.com a
écrit :

 I stumbled over some rather strange behaviour regarding properties.  It
 seems properties generated by one plugin are not always resolved for other
 plugins and I can't figure out why.

 I use a plugin to make info about the git branch available in the
 properties so it can be passed to other plugins.  The particular plugin
 does not seem important, but I've included it here for sake of
 completeness:

 plugin
 groupIdcom.code54.mojo/groupId
 artifactIdbuildversion-plugin/artifactId
  version1.0.3/version
 configuration
 tstamp_format.MM.dd HH:mm/tstamp_format
  /configuration
 executions
 execution
  goals
 goalset-properties/goal
 /goals
  /execution
 /executions
 /plugin

 But when I referenced the properties set by the plugin in an env entry for
 the maven ear plugin, the properties were not resolved at all:

 envEntries
 env-entry
 descriptionMiddleware build information/description
  env-entry-namejava:app/env/sw-version/env-entry-name
 env-entry-typejava.lang.String/env-entry-type
  env-entry-value${build-commit} @ ${build-tstamp} built on
 ${maven.build.timestamp}/env-entry-value
 /env-entry
 /envEntries

 Just to be sure, I used the latest maven and tried both version 2.9 of the
 plugin and the latest from the repo with the same result.

 The only way I managed to fix this was to patch the maven-ear-plugin
 itself, adding the following code in GenerateApplicationXmlMojo.execute():

 // Fix env variable substitutions
 Properties props = project.getProperties();
 PlexusConfiguration[] entries = envEntries.getChildren();
 if (entries != null) {
 for (PlexusConfiguration entry : entries) {
 if (env-entry.equals(entry.getName())) {
 PlexusConfiguration[] envEntryChildren = entry.getChildren();
 if (envEntryChildren != null) {
 for (PlexusConfiguration envEntryChild : envEntryChildren)
 {

 envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
 props));
 }
 }
 }
 }
 }

 Then it worked just fine, but I don't understand why this is necessary.  I
 thought whatever called the plugin was supposed to have done the variable
 substitution already.  So clearly the properties were present at the time
 of executing the plugin, but they werent being automaticly substituted.

 To add to the confusion, using ${project.version} in the env-entry-value
 was resolved just fine, but just not the properties coming from another
 plugin despite the plugins being run in the correct order.

 To further add to the confusion, I then used maven ant-run plugin, echoing
 the values of properties which worked just fine (!)

 While I solved the problem for me by making a locally patched version of
 the ear plugin, it's not really a solution I favour, so I hope someone can
 provide a better and more permanent fix.

 Regards,
 Henrik Gram

Re: properties that are not being resolved

[Henrik Østerlund Gram]

The one at
http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ?  It
states in the first couple of lines that it only works with subversion and
I'm using git.

Aside from that, I can't really see why it would make a difference; how
many ways are there to set properties?  I did establish that the properties
are indeed set as I can print them via the ant-run plugin and via the a
modified ear-plugin.



On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus bmat...@batmat.net wrote:

 Hi,
 Out of curiosity, why don't you use the seemingly equivalent mojo
 buildnumber maven plugin? May not be your issue, but may be the plugin
 you're using doesn't create properties in the right way (no offense, just
 trying to guess)?
 My 2 cents
 Le 23 mars 2014 22:37, Henrik Østerlund Gram henrik.g...@gmail.com a
 écrit :

  I stumbled over some rather strange behaviour regarding properties.  It
  seems properties generated by one plugin are not always resolved for
 other
  plugins and I can't figure out why.
 
  I use a plugin to make info about the git branch available in the
  properties so it can be passed to other plugins.  The particular plugin
  does not seem important, but I've included it here for sake of
  completeness:
 
  plugin
  groupIdcom.code54.mojo/groupId
  artifactIdbuildversion-plugin/artifactId
   version1.0.3/version
  configuration
  tstamp_format.MM.dd HH:mm/tstamp_format
   /configuration
  executions
  execution
   goals
  goalset-properties/goal
  /goals
   /execution
  /executions
  /plugin
 
  But when I referenced the properties set by the plugin in an env entry
 for
  the maven ear plugin, the properties were not resolved at all:
 
  envEntries
  env-entry
  descriptionMiddleware build information/description
   env-entry-namejava:app/env/sw-version/env-entry-name
  env-entry-typejava.lang.String/env-entry-type
   env-entry-value${build-commit} @ ${build-tstamp} built on
  ${maven.build.timestamp}/env-entry-value
  /env-entry
  /envEntries
 
  Just to be sure, I used the latest maven and tried both version 2.9 of
 the
  plugin and the latest from the repo with the same result.
 
  The only way I managed to fix this was to patch the maven-ear-plugin
  itself, adding the following code in
 GenerateApplicationXmlMojo.execute():
 
  // Fix env variable substitutions
  Properties props = project.getProperties();
  PlexusConfiguration[] entries = envEntries.getChildren();
  if (entries != null) {
  for (PlexusConfiguration entry : entries) {
  if (env-entry.equals(entry.getName())) {
  PlexusConfiguration[] envEntryChildren = entry.getChildren();
  if (envEntryChildren != null) {
  for (PlexusConfiguration envEntryChild :
 envEntryChildren)
  {
 
  envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
  props));
  }
  }
  }
  }
  }
 
  Then it worked just fine, but I don't understand why this is necessary.
  I
  thought whatever called the plugin was supposed to have done the variable
  substitution already.  So clearly the properties were present at the time
  of executing the plugin, but they werent being automaticly substituted.
 
  To add to the confusion, using ${project.version} in the env-entry-value
  was resolved just fine, but just not the properties coming from another
  plugin despite the plugins being run in the correct order.
 
  To further add to the confusion, I then used maven ant-run plugin,
 echoing
  the values of properties which worked just fine (!)
 
  While I solved the problem for me by making a locally patched version of
  the ear plugin, it's not really a solution I favour, so I hope someone
 can
  provide a better and more permanent fix.
 
  Regards,
  Henrik Gram
 

Re: properties that are not being resolved

[Anders Hammar]

It doesn't matter which plugin you use to set the property. What does
matter is when the property substitution takes place. It normally happens
in the very beginning of the Maven build when the pom is read, before the
build lifecycle is executed and way before your plugin is executed. So you
need the plugin (where you use the created property) to do an extra
property substition step as you describe in your code.

/Anders


On Mon, Mar 24, 2014 at 9:04 AM, Henrik Østerlund Gram 
henrik.g...@gmail.com wrote:

 The one at
 http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ?  It
 states in the first couple of lines that it only works with subversion and
 I'm using git.

 Aside from that, I can't really see why it would make a difference; how
 many ways are there to set properties?  I did establish that the properties
 are indeed set as I can print them via the ant-run plugin and via the a
 modified ear-plugin.



 On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus bmat...@batmat.net
 wrote:

  Hi,
  Out of curiosity, why don't you use the seemingly equivalent mojo
  buildnumber maven plugin? May not be your issue, but may be the plugin
  you're using doesn't create properties in the right way (no offense, just
  trying to guess)?
  My 2 cents
  Le 23 mars 2014 22:37, Henrik Østerlund Gram henrik.g...@gmail.com a
  écrit :
 
   I stumbled over some rather strange behaviour regarding properties.  It
   seems properties generated by one plugin are not always resolved for
  other
   plugins and I can't figure out why.
  
   I use a plugin to make info about the git branch available in the
   properties so it can be passed to other plugins.  The particular plugin
   does not seem important, but I've included it here for sake of
   completeness:
  
   plugin
   groupIdcom.code54.mojo/groupId
   artifactIdbuildversion-plugin/artifactId
version1.0.3/version
   configuration
   tstamp_format.MM.dd HH:mm/tstamp_format
/configuration
   executions
   execution
goals
   goalset-properties/goal
   /goals
/execution
   /executions
   /plugin
  
   But when I referenced the properties set by the plugin in an env entry
  for
   the maven ear plugin, the properties were not resolved at all:
  
   envEntries
   env-entry
   descriptionMiddleware build information/description
env-entry-namejava:app/env/sw-version/env-entry-name
   env-entry-typejava.lang.String/env-entry-type
env-entry-value${build-commit} @ ${build-tstamp} built on
   ${maven.build.timestamp}/env-entry-value
   /env-entry
   /envEntries
  
   Just to be sure, I used the latest maven and tried both version 2.9 of
  the
   plugin and the latest from the repo with the same result.
  
   The only way I managed to fix this was to patch the maven-ear-plugin
   itself, adding the following code in
  GenerateApplicationXmlMojo.execute():
  
   // Fix env variable substitutions
   Properties props = project.getProperties();
   PlexusConfiguration[] entries = envEntries.getChildren();
   if (entries != null) {
   for (PlexusConfiguration entry : entries) {
   if (env-entry.equals(entry.getName())) {
   PlexusConfiguration[] envEntryChildren =
 entry.getChildren();
   if (envEntryChildren != null) {
   for (PlexusConfiguration envEntryChild :
  envEntryChildren)
   {
  
   envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
   props));
   }
   }
   }
   }
   }
  
   Then it worked just fine, but I don't understand why this is necessary.
   I
   thought whatever called the plugin was supposed to have done the
 variable
   substitution already.  So clearly the properties were present at the
 time
   of executing the plugin, but they werent being automaticly substituted.
  
   To add to the confusion, using ${project.version} in the
 env-entry-value
   was resolved just fine, but just not the properties coming from another
   plugin despite the plugins being run in the correct order.
  
   To further add to the confusion, I then used maven ant-run plugin,
  echoing
   the values of properties which worked just fine (!)
  
   While I solved the problem for me by making a locally patched version
 of
   the ear plugin, it's not really a solution I favour, so I hope someone
  can
   provide a better and more permanent fix.
  
   Regards,
   Henrik Gram
  
 

Re: properties that are not being resolved

[Henrik Østerlund Gram]

Ok, I see.

Any chance of such a change making it into the official ear-plugin?  I
think it would be generally useful to be able to reference properties in
the env-entry values.  Could post a pull request if desired, but judging by
the months old ones at https://github.com/apache/maven-plugins/pulls it
doesn't appear those are being processed by anyone.  Is there another way
to suggest that change be implemented?

Regards,
Henrik Gram



On Mon, Mar 24, 2014 at 9:13 AM, Anders Hammar and...@hammar.net wrote:

 It doesn't matter which plugin you use to set the property. What does
 matter is when the property substitution takes place. It normally happens
 in the very beginning of the Maven build when the pom is read, before the
 build lifecycle is executed and way before your plugin is executed. So you
 need the plugin (where you use the created property) to do an extra
 property substition step as you describe in your code.

 /Anders


 On Mon, Mar 24, 2014 at 9:04 AM, Henrik Østerlund Gram 
 henrik.g...@gmail.com wrote:

  The one at
  http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ?  It
  states in the first couple of lines that it only works with subversion
 and
  I'm using git.
 
  Aside from that, I can't really see why it would make a difference; how
  many ways are there to set properties?  I did establish that the
 properties
  are indeed set as I can print them via the ant-run plugin and via the a
  modified ear-plugin.
 
 
 
  On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus bmat...@batmat.net
  wrote:
 
   Hi,
   Out of curiosity, why don't you use the seemingly equivalent mojo
   buildnumber maven plugin? May not be your issue, but may be the plugin
   you're using doesn't create properties in the right way (no offense,
 just
   trying to guess)?
   My 2 cents
   Le 23 mars 2014 22:37, Henrik Østerlund Gram henrik.g...@gmail.com
 a
   écrit :
  
I stumbled over some rather strange behaviour regarding properties.
  It
seems properties generated by one plugin are not always resolved for
   other
plugins and I can't figure out why.
   
I use a plugin to make info about the git branch available in the
properties so it can be passed to other plugins.  The particular
 plugin
does not seem important, but I've included it here for sake of
completeness:
   
plugin
groupIdcom.code54.mojo/groupId
artifactIdbuildversion-plugin/artifactId
 version1.0.3/version
configuration
tstamp_format.MM.dd HH:mm/tstamp_format
 /configuration
executions
execution
 goals
goalset-properties/goal
/goals
 /execution
/executions
/plugin
   
But when I referenced the properties set by the plugin in an env
 entry
   for
the maven ear plugin, the properties were not resolved at all:
   
envEntries
env-entry
descriptionMiddleware build information/description
 env-entry-namejava:app/env/sw-version/env-entry-name
env-entry-typejava.lang.String/env-entry-type
 env-entry-value${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}/env-entry-value
/env-entry
/envEntries
   
Just to be sure, I used the latest maven and tried both version 2.9
 of
   the
plugin and the latest from the repo with the same result.
   
The only way I managed to fix this was to patch the maven-ear-plugin
itself, adding the following code in
   GenerateApplicationXmlMojo.execute():
   
// Fix env variable substitutions
Properties props = project.getProperties();
PlexusConfiguration[] entries = envEntries.getChildren();
if (entries != null) {
for (PlexusConfiguration entry : entries) {
if (env-entry.equals(entry.getName())) {
PlexusConfiguration[] envEntryChildren =
  entry.getChildren();
if (envEntryChildren != null) {
for (PlexusConfiguration envEntryChild :
   envEntryChildren)
{
   
   
 envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
props));
}
}
}
}
}
   
Then it worked just fine, but I don't understand why this is
 necessary.
I
thought whatever called the plugin was supposed to have done the
  variable
substitution already.  So clearly the properties were present at the
  time
of executing the plugin, but they werent being automaticly
 substituted.
   
To add to the confusion, using ${project.version} in the
  env-entry-value
was resolved just fine, but just not the properties coming from
 another
plugin despite the plugins being run in the correct order.
   
To further add to the confusion, I then used maven ant-run plugin,
   echoing
the values of properties which worked just fine (!)
   
While I solved the problem for me by making a locally patched version
  of
the ear plugin, it's not really a solution I favour, so I hope
 someone
   can

Re: properties that are not being resolved

[Curtis Rueden]

Hi Henrik,

FYI, my projects use buildnumber-maven-plugin with git and it works great.
Probably the docs are just out of date.

Regards,
Curtis
On Mar 24, 2014 3:05 AM, Henrik Østerlund Gram henrik.g...@gmail.com
wrote:

 The one at
 http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ?  It
 states in the first couple of lines that it only works with subversion and
 I'm using git.

 Aside from that, I can't really see why it would make a difference; how
 many ways are there to set properties?  I did establish that the properties
 are indeed set as I can print them via the ant-run plugin and via the a
 modified ear-plugin.



 On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus bmat...@batmat.net
 wrote:

  Hi,
  Out of curiosity, why don't you use the seemingly equivalent mojo
  buildnumber maven plugin? May not be your issue, but may be the plugin
  you're using doesn't create properties in the right way (no offense, just
  trying to guess)?
  My 2 cents
  Le 23 mars 2014 22:37, Henrik Østerlund Gram henrik.g...@gmail.com a
  écrit :
 
   I stumbled over some rather strange behaviour regarding properties.  It
   seems properties generated by one plugin are not always resolved for
  other
   plugins and I can't figure out why.
  
   I use a plugin to make info about the git branch available in the
   properties so it can be passed to other plugins.  The particular plugin
   does not seem important, but I've included it here for sake of
   completeness:
  
   plugin
   groupIdcom.code54.mojo/groupId
   artifactIdbuildversion-plugin/artifactId
version1.0.3/version
   configuration
   tstamp_format.MM.dd HH:mm/tstamp_format
/configuration
   executions
   execution
goals
   goalset-properties/goal
   /goals
/execution
   /executions
   /plugin
  
   But when I referenced the properties set by the plugin in an env entry
  for
   the maven ear plugin, the properties were not resolved at all:
  
   envEntries
   env-entry
   descriptionMiddleware build information/description
env-entry-namejava:app/env/sw-version/env-entry-name
   env-entry-typejava.lang.String/env-entry-type
env-entry-value${build-commit} @ ${build-tstamp} built on
   ${maven.build.timestamp}/env-entry-value
   /env-entry
   /envEntries
  
   Just to be sure, I used the latest maven and tried both version 2.9 of
  the
   plugin and the latest from the repo with the same result.
  
   The only way I managed to fix this was to patch the maven-ear-plugin
   itself, adding the following code in
  GenerateApplicationXmlMojo.execute():
  
   // Fix env variable substitutions
   Properties props = project.getProperties();
   PlexusConfiguration[] entries = envEntries.getChildren();
   if (entries != null) {
   for (PlexusConfiguration entry : entries) {
   if (env-entry.equals(entry.getName())) {
   PlexusConfiguration[] envEntryChildren =
 entry.getChildren();
   if (envEntryChildren != null) {
   for (PlexusConfiguration envEntryChild :
  envEntryChildren)
   {
  
   envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
   props));
   }
   }
   }
   }
   }
  
   Then it worked just fine, but I don't understand why this is necessary.
   I
   thought whatever called the plugin was supposed to have done the
 variable
   substitution already.  So clearly the properties were present at the
 time
   of executing the plugin, but they werent being automaticly substituted.
  
   To add to the confusion, using ${project.version} in the
 env-entry-value
   was resolved just fine, but just not the properties coming from another
   plugin despite the plugins being run in the correct order.
  
   To further add to the confusion, I then used maven ant-run plugin,
  echoing
   the values of properties which worked just fine (!)
  
   While I solved the problem for me by making a locally patched version
 of
   the ear plugin, it's not really a solution I favour, so I hope someone
  can
   provide a better and more permanent fix.
  
   Regards,
   Henrik Gram
  
 

Re: properties that are not being resolved

[Karl Heinz Marbaise]

Hi,


 Hi Henrik,


FYI, my projects use buildnumber-maven-plugin with git and it works great.
Probably the docs are just out of date.


That looks like. I have created the following JIRA ticket for this.

https://jira.codehaus.org/browse/MBUILDNUM-119

If you have supplementals/infos etc. don't hesitate to add those 
information to the ticket...may be a good idea how to write the information.


Kind regards
Karl-Heinz Marbaise


Regards,
Curtis
On Mar 24, 2014 3:05 AM, Henrik Østerlund Gram henrik.g...@gmail.com
wrote:


The one at
http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ?  It
states in the first couple of lines that it only works with subversion and
I'm using git.

Aside from that, I can't really see why it would make a difference; how
many ways are there to set properties?  I did establish that the properties
are indeed set as I can print them via the ant-run plugin and via the a
modified ear-plugin.



On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus bmat...@batmat.net
wrote:


Hi,
Out of curiosity, why don't you use the seemingly equivalent mojo
buildnumber maven plugin? May not be your issue, but may be the plugin
you're using doesn't create properties in the right way (no offense, just
trying to guess)?
My 2 cents
Le 23 mars 2014 22:37, Henrik Østerlund Gram henrik.g...@gmail.com a
écrit :


I stumbled over some rather strange behaviour regarding properties.  It
seems properties generated by one plugin are not always resolved for

other

plugins and I can't figure out why.

I use a plugin to make info about the git branch available in the
properties so it can be passed to other plugins.  The particular plugin
does not seem important, but I've included it here for sake of
completeness:

plugin
groupIdcom.code54.mojo/groupId
artifactIdbuildversion-plugin/artifactId
  version1.0.3/version
configuration
tstamp_format.MM.dd HH:mm/tstamp_format
  /configuration
executions
execution
  goals
goalset-properties/goal
/goals
  /execution
/executions
/plugin

But when I referenced the properties set by the plugin in an env entry

for

the maven ear plugin, the properties were not resolved at all:

envEntries
env-entry
descriptionMiddleware build information/description
  env-entry-namejava:app/env/sw-version/env-entry-name
env-entry-typejava.lang.String/env-entry-type
  env-entry-value${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}/env-entry-value
/env-entry
/envEntries

Just to be sure, I used the latest maven and tried both version 2.9 of

the

plugin and the latest from the repo with the same result.

The only way I managed to fix this was to patch the maven-ear-plugin
itself, adding the following code in

GenerateApplicationXmlMojo.execute():


// Fix env variable substitutions
Properties props = project.getProperties();
PlexusConfiguration[] entries = envEntries.getChildren();
if (entries != null) {
 for (PlexusConfiguration entry : entries) {
 if (env-entry.equals(entry.getName())) {
 PlexusConfiguration[] envEntryChildren =

entry.getChildren();

 if (envEntryChildren != null) {
 for (PlexusConfiguration envEntryChild :

envEntryChildren)

{

envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
props));
 }
 }
 }
 }
}

Then it worked just fine, but I don't understand why this is necessary.

  I

thought whatever called the plugin was supposed to have done the

variable

substitution already.  So clearly the properties were present at the

time

of executing the plugin, but they werent being automaticly substituted.

To add to the confusion, using ${project.version} in the

env-entry-value

was resolved just fine, but just not the properties coming from another
plugin despite the plugins being run in the correct order.

To further add to the confusion, I then used maven ant-run plugin,

echoing

the values of properties which worked just fine (!)

While I solved the problem for me by making a locally patched version

of

the ear plugin, it's not really a solution I favour, so I hope someone

can

provide a better and more permanent fix.

Regards,
Henrik Gram







-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties that are not being resolved

[Stephen Connolly]

Please read my answer to a similar question on Stack Overflow:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072


On 23 March 2014 21:36, Henrik Østerlund Gram henrik.g...@gmail.com wrote:

 I stumbled over some rather strange behaviour regarding properties.  It
 seems properties generated by one plugin are not always resolved for other
 plugins and I can't figure out why.

 I use a plugin to make info about the git branch available in the
 properties so it can be passed to other plugins.  The particular plugin
 does not seem important, but I've included it here for sake of
 completeness:

 plugin
 groupIdcom.code54.mojo/groupId
 artifactIdbuildversion-plugin/artifactId
  version1.0.3/version
 configuration
 tstamp_format.MM.dd HH:mm/tstamp_format
  /configuration
 executions
 execution
  goals
 goalset-properties/goal
 /goals
  /execution
 /executions
 /plugin

 But when I referenced the properties set by the plugin in an env entry for
 the maven ear plugin, the properties were not resolved at all:

 envEntries
 env-entry
 descriptionMiddleware build information/description
  env-entry-namejava:app/env/sw-version/env-entry-name
 env-entry-typejava.lang.String/env-entry-type
  env-entry-value${build-commit} @ ${build-tstamp} built on
 ${maven.build.timestamp}/env-entry-value
 /env-entry
 /envEntries

 Just to be sure, I used the latest maven and tried both version 2.9 of the
 plugin and the latest from the repo with the same result.

 The only way I managed to fix this was to patch the maven-ear-plugin
 itself, adding the following code in GenerateApplicationXmlMojo.execute():

 // Fix env variable substitutions
 Properties props = project.getProperties();
 PlexusConfiguration[] entries = envEntries.getChildren();
 if (entries != null) {
 for (PlexusConfiguration entry : entries) {
 if (env-entry.equals(entry.getName())) {
 PlexusConfiguration[] envEntryChildren = entry.getChildren();
 if (envEntryChildren != null) {
 for (PlexusConfiguration envEntryChild : envEntryChildren)
 {

 envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
 props));
 }
 }
 }
 }
 }

 Then it worked just fine, but I don't understand why this is necessary.  I
 thought whatever called the plugin was supposed to have done the variable
 substitution already.  So clearly the properties were present at the time
 of executing the plugin, but they werent being automaticly substituted.

 To add to the confusion, using ${project.version} in the env-entry-value
 was resolved just fine, but just not the properties coming from another
 plugin despite the plugins being run in the correct order.

 To further add to the confusion, I then used maven ant-run plugin, echoing
 the values of properties which worked just fine (!)

 While I solved the problem for me by making a locally patched version of
 the ear plugin, it's not really a solution I favour, so I hope someone can
 provide a better and more permanent fix.

 Regards,
 Henrik Gram

Re: properties that are not being resolved

[Henrik Østerlund Gram]

Thanks for the link.  It was quite informative, but I'm again a little
confused because it is stated in your explanation,
the configuration sections will have mojo-injected properties evaluated,
but that isn't the case in my example.  I was trying to have such
properties evaluated in a envEntries element inside a configuration
element for the ear plugin, but it would not work until I modified the
plugin to do an extra substitution itself.

Regards,
Henrik Gram

On Mon, Mar 24, 2014 at 10:38 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Please read my answer to a similar question on Stack Overflow:

 http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072


 On 23 March 2014 21:36, Henrik Østerlund Gram henrik.g...@gmail.com
 wrote:

  I stumbled over some rather strange behaviour regarding properties.  It
  seems properties generated by one plugin are not always resolved for
 other
  plugins and I can't figure out why.
 
  I use a plugin to make info about the git branch available in the
  properties so it can be passed to other plugins.  The particular plugin
  does not seem important, but I've included it here for sake of
  completeness:
 
  plugin
  groupIdcom.code54.mojo/groupId
  artifactIdbuildversion-plugin/artifactId
   version1.0.3/version
  configuration
  tstamp_format.MM.dd HH:mm/tstamp_format
   /configuration
  executions
  execution
   goals
  goalset-properties/goal
  /goals
   /execution
  /executions
  /plugin
 
  But when I referenced the properties set by the plugin in an env entry
 for
  the maven ear plugin, the properties were not resolved at all:
 
  envEntries
  env-entry
  descriptionMiddleware build information/description
   env-entry-namejava:app/env/sw-version/env-entry-name
  env-entry-typejava.lang.String/env-entry-type
   env-entry-value${build-commit} @ ${build-tstamp} built on
  ${maven.build.timestamp}/env-entry-value
  /env-entry
  /envEntries
 
  Just to be sure, I used the latest maven and tried both version 2.9 of
 the
  plugin and the latest from the repo with the same result.
 
  The only way I managed to fix this was to patch the maven-ear-plugin
  itself, adding the following code in
 GenerateApplicationXmlMojo.execute():
 
  // Fix env variable substitutions
  Properties props = project.getProperties();
  PlexusConfiguration[] entries = envEntries.getChildren();
  if (entries != null) {
  for (PlexusConfiguration entry : entries) {
  if (env-entry.equals(entry.getName())) {
  PlexusConfiguration[] envEntryChildren = entry.getChildren();
  if (envEntryChildren != null) {
  for (PlexusConfiguration envEntryChild :
 envEntryChildren)
  {
 
  envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
  props));
  }
  }
  }
  }
  }
 
  Then it worked just fine, but I don't understand why this is necessary.
  I
  thought whatever called the plugin was supposed to have done the variable
  substitution already.  So clearly the properties were present at the time
  of executing the plugin, but they werent being automaticly substituted.
 
  To add to the confusion, using ${project.version} in the env-entry-value
  was resolved just fine, but just not the properties coming from another
  plugin despite the plugins being run in the correct order.
 
  To further add to the confusion, I then used maven ant-run plugin,
 echoing
  the values of properties which worked just fine (!)
 
  While I solved the problem for me by making a locally patched version of
  the ear plugin, it's not really a solution I favour, so I hope someone
 can
  provide a better and more permanent fix.
 
  Regards,
  Henrik Gram
 

Re: Properties within source code

[Anders Lindgren]

Hi Nick,

I think you missed the filtering part. I are supposed to enable the
filtering by filerteringtrue/filtering
See
http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

As you can see there, it also possible to put you variables in a
separate properties file.

Hopes it helps

/Anders

On Fri, 2012-11-16 at 22:53 +0100, Nick Cuneo (ncuneo) wrote:
 Hi,
 
  
 
 We are attempting to migrate our build environment from being very
 Ant-centric, to be Maven-centric.  We have a source file (Trace.java)
 that has a couple of variables that get set for debug/non-debug
 builds.  The code is as follows
 
 public boolean DEBUG = ${debug.enabled};
 
  
 
 Obviously this won’t compile as is, but with Ant we were able to
 replace that property at compile time so it would build the
 appropriate package.  I’m trying to get that same functionality with
 Maven… I’ve looked into trying to add the file as a resource and
 creating the property in the pom.xml.  I’ve also tried using the
 google-replace plugin, but that didn’t seem to work well either.  Am I
 just not doing it right?  I’m learning Maven as I go so I figured
 that’s a possibility.  I’ve tried doing searches on the subject with
 google and looking through maven documentation and it feels
 straightforward but just not working for me.
 
  
 
 Example from pom:
 
 properties
 
 debug.enabledtrue/debug.enabled
 
 /properties
 
 build
 
 …
 
 resources
 
 resource
 
 
 directory${basedir}/src/trace/directory
 
 includes
 
 
 includeTrace.java/include
 
 /includes
 
 /resource
 
 /resources
 
  
 
 I see in the log that it’s doing something with the file, maybe not
 what I was intending though:
 
 [INFO] Copying 1 resource
 
  
 
 Any help would be appreciative.
 
  
 
  
 
 Thanks,
 
  Nick
 
 Description:
 http://www.cisco.com/web/europe/images/email/signature/logo02.jpg
 
 
 Nicholas Cuneo
 Software Engineer
 SPVTG
 ncu...@cisco.com
 Phone: 1-714-434-2344
 Mobile: 1-949-243-4952
 
 
 
 
 
 3500 Hyland Ave
 Costa Mesa, CA
 United States
 Cisco.com
 
 Download
 vCardDescription:
 Virtual Card File
 
 
 
 
  
 
 Description: Think before you print.Think before you print.
 
 This email may contain confidential and privileged material for the
 sole use of the intended recipient. Any review, use, distribution or
 disclosure by others is strictly prohibited. If you are not the
 intended recipient (or authorized to receive for the recipient),
 please contact the sender by reply email and delete all copies of this
 message.
 
 For corporate legal information go to:
 http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
  
 
 
 
 
 
  
 
  
 
 

Re: Properties within source code

[John Kramer]

I know that this may not address your question directly, but I suggest that you 
change your approach.

Rather than build two different artifacts for debugging or not debugging, I 
suggest that you make the a runtime configuration.  Look into various logging 
frameworks (log4j, log back) that will allow this.  They are pretty flexible 
and should probably help you.

If they don't address your issue, you should look into using java system 
properties.  The tag argLine will allow you to set them in tests run with the 
surefire plugin.

You can also package a properties file with your code and use maven properties 
to filter that.  However, as far as I know, Maven only has the capability to 
filter resources (such as the aforementioned properties file), not java source 
code (and if it does have that capability, I would suggest not using it as it 
would screw up static source tools).


John Kramer
email: jkra...@mojiva.commailto:jkra...@mojiva.com
mobile: 314.435.2370
skype: kramer.mojiva
twitter: @KramerKnowsTechhttps://twitter.com/KramerKnowsTech
0xCAFEBABE0032


From: Nick Cuneo (ncuneo) ncu...@cisco.commailto:ncu...@cisco.com
Reply-To: Maven Users List 
users@maven.apache.orgmailto:users@maven.apache.org
Date: Friday, November 16, 2012 16:53 PM
To: users@maven.apache.orgmailto:users@maven.apache.org 
users@maven.apache.orgmailto:users@maven.apache.org
Subject: Properties within source code

Hi,

We are attempting to migrate our build environment from being very Ant-centric, 
to be Maven-centric.  We have a source file (Trace.java) that has a couple of 
variables that get set for debug/non-debug builds.  The code is as follows
public boolean DEBUG = ${debug.enabled};

Obviously this won’t compile as is, but with Ant we were able to replace that 
property at compile time so it would build the appropriate package.  I’m trying 
to get that same functionality with Maven… I’ve looked into trying to add the 
file as a resource and creating the property in the pom.xml.  I’ve also tried 
using the google-replace plugin, but that didn’t seem to work well either.  Am 
I just not doing it right?  I’m learning Maven as I go so I figured that’s a 
possibility.  I’ve tried doing searches on the subject with google and looking 
through maven documentation and it feels straightforward but just not working 
for me.

Example from pom:
properties
debug.enabledtrue/debug.enabled
/properties
build
…
resources
resource
directory${basedir}/src/trace/directory
includes
includeTrace.java/include
/includes
/resource
/resources

I see in the log that it’s doing something with the file, maybe not what I was 
intending though:
[INFO] Copying 1 resource

Any help would be appreciative.


Thanks,
 Nick
[Description: http://www.cisco.com/web/europe/images/email/signature/logo02.jpg]

Nicholas Cuneo
Software Engineer
SPVTG
ncu...@cisco.commailto:ncu...@cisco.com
Phone: 1-714-434-2344
Mobile: 1-949-243-4952



3500 Hyland Ave
Costa Mesa, CA
United States
Cisco.comhttp://www.cisco.com/

Download vCard[Description: Virtual Card 
File]http://wwwin-tools.cisco.com/dir/vcard/ncuneo.vcf


[Description: Think before you print.]Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Re: Properties within source code

[Stephen Connolly]

There is support for generating source code from some form of template.
Usually requires a plugin for the template engine, or antrun and
build-helper:add-source

You would keep the template outside if src/main/java and then the
generated source goes to something like target/generated-source/... And
that path gets added as a source root.

But keep in mind the principle of environment agnostic artifacts. Tuning
logging levels is not such, so abusing to do such is a bad plan

On Friday, 16 November 2012, John Kramer wrote:

 I know that this may not address your question directly, but I suggest
 that you change your approach.

 Rather than build two different artifacts for debugging or not debugging,
 I suggest that you make the a runtime configuration.  Look into various
 logging frameworks (log4j, log back) that will allow this.  They are pretty
 flexible and should probably help you.

 If they don't address your issue, you should look into using java system
 properties.  The tag argLine will allow you to set them in tests run with
 the surefire plugin.

 You can also package a properties file with your code and use maven
 properties to filter that.  However, as far as I know, Maven only has the
 capability to filter resources (such as the aforementioned properties
 file), not java source code (and if it does have that capability, I would
 suggest not using it as it would screw up static source tools).


 John Kramer
 email: jkra...@mojiva.com 
 javascript:;mailto:jkra...@mojiva.comjavascript:;
 
 mobile: 314.435.2370
 skype: kramer.mojiva
 twitter: @KramerKnowsTechhttps://twitter.com/KramerKnowsTech
 0xCAFEBABE0032


 From: Nick Cuneo (ncuneo) ncu...@cisco.com javascript:;mailto:
 ncu...@cisco.com javascript:;
 Reply-To: Maven Users List users@maven.apache.org javascript:;mailto:
 users@maven.apache.org javascript:;
 Date: Friday, November 16, 2012 16:53 PM
 To: users@maven.apache.org 
 javascript:;mailto:users@maven.apache.orgjavascript:;
 users@maven.apache.org 
 javascript:;mailto:users@maven.apache.orgjavascript:;
 
 Subject: Properties within source code

 Hi,

 We are attempting to migrate our build environment from being very
 Ant-centric, to be Maven-centric.  We have a source file (Trace.java) that
 has a couple of variables that get set for debug/non-debug builds.  The
 code is as follows
 public boolean DEBUG = ${debug.enabled};

 Obviously this won’t compile as is, but with Ant we were able to replace
 that property at compile time so it would build the appropriate package.
  I’m trying to get that same functionality with Maven… I’ve looked into
 trying to add the file as a resource and creating the property in the
 pom.xml.  I’ve also tried using the google-replace plugin, but that didn’t
 seem to work well either.  Am I just not doing it right?  I’m learning
 Maven as I go so I figured that’s a possibility.  I’ve tried doing searches
 on the subject with google and looking through maven documentation and it
 feels straightforward but just not working for me.

 Example from pom:
 properties
 debug.enabledtrue/debug.enabled
 /properties
 build
 …
 resources
 resource
 directory${basedir}/src/trace/directory
 includes

 includeTrace.java/include
 /includes
 /resource
 /resources

 I see in the log that it’s doing something with the file, maybe not what I
 was intending though:
 [INFO] Copying 1 resource

 Any help would be appreciative.


 Thanks,
  Nick
 [Description:
 http://www.cisco.com/web/europe/images/email/signature/logo02.jpg]

 Nicholas Cuneo
 Software Engineer
 SPVTG
 ncu...@cisco.com javascript:;mailto:ncu...@cisco.com javascript:;
 Phone: 1-714-434-2344
 Mobile: 1-949-243-4952



 3500 Hyland Ave
 Costa Mesa, CA
 United States
 Cisco.comhttp://www.cisco.com/

 Download vCard[Description: Virtual Card File]
 http://wwwin-tools.cisco.com/dir/vcard/ncuneo.vcf


 [Description: Think before you print.]Think before you print.
 This email may contain confidential and privileged material for the sole
 use of the intended recipient. Any review, use, distribution or disclosure
 by others is strictly prohibited. If you are not the intended recipient (or
 authorized to receive for the recipient), please contact the sender by
 reply email and delete all copies of this message.
 For corporate legal information go to:
 http://www.cisco.com/web/about/doing_business/legal/cri/index.html

RE: Properties within source code

[Nick Cuneo (ncuneo)]

I agree this isn't the best approach, however I'm trying to do as much as 
possible with legacy code and trying to not make any changes to source code.

Thanks,
-Nick


-Original Message-
From: John Kramer [mailto:jkra...@mojiva.com] 
Sent: Friday, November 16, 2012 2:03 PM
To: Maven Users List
Subject: Re: Properties within source code

I know that this may not address your question directly, but I suggest that you 
change your approach.

Rather than build two different artifacts for debugging or not debugging, I 
suggest that you make the a runtime configuration.  Look into various logging 
frameworks (log4j, log back) that will allow this.  They are pretty flexible 
and should probably help you.

If they don't address your issue, you should look into using java system 
properties.  The tag argLine will allow you to set them in tests run with the 
surefire plugin.

You can also package a properties file with your code and use maven properties 
to filter that.  However, as far as I know, Maven only has the capability to 
filter resources (such as the aforementioned properties file), not java source 
code (and if it does have that capability, I would suggest not using it as it 
would screw up static source tools).


John Kramer
email: jkra...@mojiva.commailto:jkra...@mojiva.com
mobile: 314.435.2370
skype: kramer.mojiva
twitter: @KramerKnowsTechhttps://twitter.com/KramerKnowsTech
0xCAFEBABE0032


From: Nick Cuneo (ncuneo) ncu...@cisco.commailto:ncu...@cisco.com
Reply-To: Maven Users List 
users@maven.apache.orgmailto:users@maven.apache.org
Date: Friday, November 16, 2012 16:53 PM
To: users@maven.apache.orgmailto:users@maven.apache.org 
users@maven.apache.orgmailto:users@maven.apache.org
Subject: Properties within source code

Hi,

We are attempting to migrate our build environment from being very Ant-centric, 
to be Maven-centric.  We have a source file (Trace.java) that has a couple of 
variables that get set for debug/non-debug builds.  The code is as follows 
public boolean DEBUG = ${debug.enabled};

Obviously this won't compile as is, but with Ant we were able to replace that 
property at compile time so it would build the appropriate package.  I'm trying 
to get that same functionality with Maven... I've looked into trying to add the 
file as a resource and creating the property in the pom.xml.  I've also tried 
using the google-replace plugin, but that didn't seem to work well either.  Am 
I just not doing it right?  I'm learning Maven as I go so I figured that's a 
possibility.  I've tried doing searches on the subject with google and looking 
through maven documentation and it feels straightforward but just not working 
for me.

Example from pom:
properties
debug.enabledtrue/debug.enabled
/properties
build
...
resources
resource
directory${basedir}/src/trace/directory
includes
includeTrace.java/include
/includes
/resource
/resources

I see in the log that it's doing something with the file, maybe not what I was 
intending though:
[INFO] Copying 1 resource

Any help would be appreciative.


Thanks,
 Nick
[Description: http://www.cisco.com/web/europe/images/email/signature/logo02.jpg]

Nicholas Cuneo
Software Engineer
SPVTG
ncu...@cisco.commailto:ncu...@cisco.com
Phone: 1-714-434-2344
Mobile: 1-949-243-4952



3500 Hyland Ave
Costa Mesa, CA
United States
Cisco.comhttp://www.cisco.com/

Download vCard[Description: Virtual Card 
File]http://wwwin-tools.cisco.com/dir/vcard/ncuneo.vcf


[Description: Think before you print.]Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html







-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties file exlusion from dependency

[Wayne Fay]

 Is this possible? If so, how can I do it?

Please spell out what you are thinking for those of us who are unable
to interpret what you are asking about.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties file exlusion from dependency

[Laird Nelson]

On Tue, Aug 14, 2012 at 8:53 AM, Wright, Omari omari.wri...@solers.comwrote:

 Is this possible? If so, how can I do it?


You might be asking:

I depend on an artifact.  It has a properties file in it that gets read or
is otherwise present on the classpath.  This interferes with my system.  I
would like to continue depending on the artifact, but somehow without the
properties file.

If so:

If you depend on an artifact directly (i.e. if it is present in the
dependencies section) then you cannot really modify that dependency.

You could try making use of the maven-dependency-plugin's unpack goal,
which is documented here:
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html

That would let you unpack the artifact somewhere temporary, exclude the
properties file, and perhaps then reassemble it.

Or, if you have control over the artifact you depend on, you could build
two artifacts: one without the properties file and one with it.  Then you
could depend on the one without the properties file.

Just a couple of ideas.

Best,
Laird

-- 
http://about.me/lairdnelson

Re: properties not getting shared

[Maven User]

Ok, a bit more clarity - the child build that fails has a dependency on
another child which has a dependency on something with ${foo.version}.

Once that dependency is attempted to be resolved transitively, the property
is NOT expanded to the -D value, but simply whatever was set in the top
level pom.



On Mon, Jan 23, 2012 at 6:12 PM, Maven User maven.2.u...@gmail.com wrote:

 Hi all -

 I've got a bit of a head scratcher here and while I know this isn't the
 BEST way to solve things, it seems to be how it is getting done.

 We have a parent pom that has a list of a few child modules.  In the
 parent pom, we have a property that defines what version of a dependency we
 should be resolving.

 When building on the command line, sometimes it's easier just to do a
 -Dfoo.version=2.1.2 for example to try out a different release of something.

 Three of the five child poms get it correct.  The fourth keeps defaulting
 to whatever is defined in the top level pom (and the fifth we never get to
 see build).

 I've looked at the GAV for the child pom and it's healthy (pointing to the
 correct pom and everything).

 What are we doing wrong?  This feels like a bug but I couldn't find one
 documented like this...

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly]

the correct scope for those deps should be provided imho.

the problem you have is getting the deps you need, system scope is just a
workaround.

ideally you would create an uberjar from the geologic jar and just install
that into your repo manager.

the focus should be on taking a jar and making an uberjar from its manifest
classpath... should be easy, then install that uberjar in your repo. forget
about identifying which of the 480 odd jars has your dep, when you depend
on geologic specific classes, that's what you need.

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 15 Nov 2011 03:19, Stephen Coy st...@resolvesw.com wrote:

 Hi there,

 I've been a maven user since the early 1.0 days and have contributed
 patches at various times for the ejb-plugin, ear-plugin and others.

 I've also had the unfortunate experience of having to use WebLogic 10+ to
 create useable maven poms for our projects. In fact, when I read the OP I
 knew he was talking about Weblogic even though he did not mention it.

 The *only* way I've been able to do this successfully was with a system
 scoped dependency on the weblogic.jar.

 This is because weblogic contains a maze of relative manifest class paths
 that are truly mind boggling.

 The very first class path entry in weblogic.jar looks like:

 ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
 (plus a dozen or more others)

 That modules directory contains 465 (very OSGI looking) jars and sub
 directories. Do you really think it's practical to install all of these
 into a repository manager? How would you generate the dependencies for each
 pom?

 This would not be an issue for any plain old JEE application. However,
 if you have any need at all for weblogic specific APIs then a system scoped
 dependency is the only practical way. Even when you do figure out which one
 of those ~500 jars contains your API, you then need to read it's manifest
 and pick out its dependencies, and then the dependencies' dependencies, etc.

 If someone has a simple solution to this then I'd like to hear it too.
 Otherwise, *please* restore the system scope functionality.


 Cheers,

 Steve C


 On 14/11/2011, at 2:55 AM, Benson Margulies wrote:

  No possible licensing restriction can prevent you from having your own
  shared repository with nexus or archiva or artifactory and pushing
  whatever you want to it.
 
  For that matter, it's not too hard to write a script that calls
  install:install-file on each of a pile of jar files. You can't do this
  in the reactor and then use the results (AFAIK), but you can run this
  and then run the build.
 
  In other words, anything you can do with system scope you can do with
  less headaches with a repo manager or instal:install-file.
 
 
  On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav be...@rodehav.com
 wrote:
  Last time I went through this I never came all the way to a complete
 list
  but I do remember there were lots of jars missing. I guess I'll have to
  reiterate this again since system scope doesn't seem to be supported
  anymore.
 
  /Bengt
 
  2011/11/12 Wayne Fay wayne...@gmail.com
 
  What else do you need? Why not full client + some reasonable (small)
  handful of other dependencies?
 
  Wayne
 
  On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav be...@rodehav.com
 wrote:
  It works but the full client is not enough for us to be able to build
 our
  application.
 
  Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:
 
  Does this no longer work?
  http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
  On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:
 
  Stephen and Wayne,
 
  I agree that using system scope is undesirable. However, there is a
  reason
  why maven has had this  support - it is needed in real life. In my
  case, I
  use Weblogic. When first trying to migrate our old ant based build
  system
  to maven, I started out by trying to put the Weblogic jar:s in the
  maven
  repo. It just wasn't doable. They have split the big, all
  encompassing,
  jar
  file from previous versions into hundreds of individual jar files. I
  gave
  up after a while. I guess if I could find a tool that could convert
  all
  these jars into one super jar then I could put that jar in the
 maven
  repo. I'm not sure that Oracle's licensing rules would allow it
  though.
 
  Dropping support like this because you don't think it's the best way
  to
  handle things will not give you a loyal user base. We need to solve
  these
  kind of issues somehow. Before you remove support you must provide
 an
  alternate solution. Requiring that hundreds of proprietary jars have
  to
  be
  put in the maven repo (and updated each time we upgrade Weblogic) is
  just
  not realistic. I've been searching for a good tool that can traverse
  the
  manifest classpath's and create a single jar from all 

RE: Properties in settings.xml does not work for system scoped dependencies

[Nord, James]

Not that I am needing to do this but in order to further my understanding...

If you create an Uber JAR - then you can end up in classpath hell - as the 
dependencies aren't correct (it could include common-io 1.2 and you need 
commons-io 1.3 which is declared transitively)  This then means that even 
though you don't depend on commons-io you need to start adding all transitive 
dependencies to your pom just incase the app server ships with a different one 
and the uber jar takes precedence over the transitive dependency.  The J2EE 
container should allow you to override some bits of the provide jars should 
they not?

/James

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: 15 November 2011 08:26
To: Maven Users List
Subject: Re: Properties in settings.xml does not work for system scoped 
dependencies

the correct scope for those deps should be provided imho.

the problem you have is getting the deps you need, system scope is just a 
workaround.

ideally you would create an uberjar from the geologic jar and just install that 
into your repo manager.

the focus should be on taking a jar and making an uberjar from its manifest 
classpath... should be easy, then install that uberjar in your repo. forget 
about identifying which of the 480 odd jars has your dep, when you depend on 
geologic specific classes, that's what you need.

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words 
and other nonsense are a direct result of using swype to type on the screen On 
15 Nov 2011 03:19, Stephen Coy st...@resolvesw.com wrote:

 Hi there,

 I've been a maven user since the early 1.0 days and have contributed
 patches at various times for the ejb-plugin, ear-plugin and others.

 I've also had the unfortunate experience of having to use WebLogic 10+
 to create useable maven poms for our projects. In fact, when I read
 the OP I knew he was talking about Weblogic even though he did not mention it.

 The *only* way I've been able to do this successfully was with a
 system scoped dependency on the weblogic.jar.

 This is because weblogic contains a maze of relative manifest class
 paths that are truly mind boggling.

 The very first class path entry in weblogic.jar looks like:

 ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
 (plus a dozen or more others)

 That modules directory contains 465 (very OSGI looking) jars and sub
 directories. Do you really think it's practical to install all of
 these into a repository manager? How would you generate the
 dependencies for each pom?

 This would not be an issue for any plain old JEE application.
 However, if you have any need at all for weblogic specific APIs then a
 system scoped dependency is the only practical way. Even when you do
 figure out which one of those ~500 jars contains your API, you then
 need to read it's manifest and pick out its dependencies, and then the 
 dependencies' dependencies, etc.

 If someone has a simple solution to this then I'd like to hear it too.
 Otherwise, *please* restore the system scope functionality.


 Cheers,

 Steve C


 On 14/11/2011, at 2:55 AM, Benson Margulies wrote:

  No possible licensing restriction can prevent you from having your
  own shared repository with nexus or archiva or artifactory and
  pushing whatever you want to it.
 
  For that matter, it's not too hard to write a script that calls
  install:install-file on each of a pile of jar files. You can't do
  this in the reactor and then use the results (AFAIK), but you can
  run this and then run the build.
 
  In other words, anything you can do with system scope you can do
  with less headaches with a repo manager or instal:install-file.
 
 
  On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav be...@rodehav.com
 wrote:
  Last time I went through this I never came all the way to a
  complete
 list
  but I do remember there were lots of jars missing. I guess I'll
  have to reiterate this again since system scope doesn't seem to be
  supported anymore.
 
  /Bengt
 
  2011/11/12 Wayne Fay wayne...@gmail.com
 
  What else do you need? Why not full client + some reasonable
  (small) handful of other dependencies?
 
  Wayne
 
  On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav be...@rodehav.com
 wrote:
  It works but the full client is not enough for us to be able to
  build
 our
  application.
 
  Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:
 
  Does this no longer work?
  http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
  On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:
 
  Stephen and Wayne,
 
  I agree that using system scope is undesirable. However, there
  is a
  reason
  why maven has had this  support - it is needed in real life. In
  my
  case, I
  use Weblogic. When first trying to migrate our old ant based
  build
  system
  to maven, I started out by trying to put the Weblogic jar:s in
  the
  maven
  repo. It just wasn't

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly]

Actually this is not going to be as big an issue as you think.

Keep in mind you are not sucking in _all_ the container's jars into
your uber jar, only the public ones (unless you are very lazy... in
which case you're going to have problems anyway)

The container's classloaders should look something a bit like

System - Common - Server
 \- Your App

Now the above is very simplified, but most JEE containers boil down to
something like the above if your app is an EAR you will have a
similar fork with the EAR common dependencies in a shared classloader
and then the EJBs being in one class loader descended from your app's
common and the WARs being in another classloader(s) descended from
common.

So your app should only be depending on things that are in the App
Server's Common classloader, i.e. all the javax.* packages for the JEE
spec the container implements plus the public APIs of the App Server's
additional extensions.

Typically the app server's are reasonably helpful and put their public
jars in one lib folder separate from the server's internal lib
folder... but then again there is no need for them to do that at
all... they should at least call out which jars are safe to depend on
(i.e. public) somewhere in their docs. My understanding is that it is
just the weblogic.jar that you'd want to uber-ize as that is the
public facing API.

You then depend on that uberjar _with_scope_provided_ this is because
the jar is being provided for you.

In weblogic, if you want to use a version of xerces that is not the
one sucked in by weblogic.jar, then you need to configure your app
with a filtering classloader in any case, so the classpath hell will
either be there anyway, or you will have to man up and write the
filtering classloader descriptor anyway. The provided weblogic.jar
dependency will not have any transitive deps in any case (unless you
add them yourself) and being scope=provided, it will not be transitive
itself

-Stephen

On 15 November 2011 09:27, Nord, James jn...@nds.com wrote:
 Not that I am needing to do this but in order to further my understanding...

 If you create an Uber JAR - then you can end up in classpath hell - as the 
 dependencies aren't correct (it could include common-io 1.2 and you need 
 commons-io 1.3 which is declared transitively)  This then means that even 
 though you don't depend on commons-io you need to start adding all transitive 
 dependencies to your pom just incase the app server ships with a different 
 one and the uber jar takes precedence over the transitive dependency.  The 
 J2EE container should allow you to override some bits of the provide jars 
 should they not?

 /James

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: 15 November 2011 08:26
 To: Maven Users List
 Subject: Re: Properties in settings.xml does not work for system scoped 
 dependencies

 the correct scope for those deps should be provided imho.

 the problem you have is getting the deps you need, system scope is just a 
 workaround.

 ideally you would create an uberjar from the geologic jar and just install 
 that into your repo manager.

 the focus should be on taking a jar and making an uberjar from its manifest 
 classpath... should be easy, then install that uberjar in your repo. forget 
 about identifying which of the 480 odd jars has your dep, when you depend on 
 geologic specific classes, that's what you need.

 - Stephen

 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense 
 words and other nonsense are a direct result of using swype to type on the 
 screen On 15 Nov 2011 03:19, Stephen Coy st...@resolvesw.com wrote:

 Hi there,

 I've been a maven user since the early 1.0 days and have contributed
 patches at various times for the ejb-plugin, ear-plugin and others.

 I've also had the unfortunate experience of having to use WebLogic 10+
 to create useable maven poms for our projects. In fact, when I read
 the OP I knew he was talking about Weblogic even though he did not mention 
 it.

 The *only* way I've been able to do this successfully was with a
 system scoped dependency on the weblogic.jar.

 This is because weblogic contains a maze of relative manifest class
 paths that are truly mind boggling.

 The very first class path entry in weblogic.jar looks like:

 ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
 (plus a dozen or more others)

 That modules directory contains 465 (very OSGI looking) jars and sub
 directories. Do you really think it's practical to install all of
 these into a repository manager? How would you generate the
 dependencies for each pom?

 This would not be an issue for any plain old JEE application.
 However, if you have any need at all for weblogic specific APIs then a
 system scoped dependency is the only practical way. Even when you do
 figure out which one of those ~500 jars contains your API, you then
 need to read it's manifest and pick

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Coy]

On 15/11/2011, at 9:24 PM, Stephen Connolly wrote:

 Actually this is not going to be as big an issue as you think.

hmm

 
 Keep in mind you are not sucking in _all_ the container's jars into
 your uber jar, only the public ones (unless you are very lazy... in
 which case you're going to have problems anyway)
 
 The container's classloaders should look something a bit like
 
 System - Common - Server
 \- Your App
 
 Now the above is very simplified, but most JEE containers boil down to
 something like the above if your app is an EAR you will have a
 similar fork with the EAR common dependencies in a shared classloader
 and then the EJBs being in one class loader descended from your app's
 common and the WARs being in another classloader(s) descended from
 common.


I know this. I have ten years on JBoss and over 7 years on WebLogic and 
WebSphere.



 
 So your app should only be depending on things that are in the App
 Server's Common classloader, i.e. all the javax.* packages for the JEE
 spec the container implements plus the public APIs of the App Server's
 additional extensions.

Yep

 
 Typically the app server's are reasonably helpful and put their public
 jars in one lib folder separate from the server's internal lib
 folder... but then again there is no need for them to do that at
 all... they should at least call out which jars are safe to depend on
 (i.e. public) somewhere in their docs.

In fact, WebSphere does this very nicely. Unfortunately WebLogic does not. I 
spent many days on this a couple of years ago. 

 My understanding is that it is
 just the weblogic.jar that you'd want to uber-ize as that is the
 public facing API.

The API that we needed (a Tuxedo client) is buried in one of the modules 
jars, together with it's implementation. And it had OSGI style package 
dependencies that just exploded as I tried to work my way back out of it. We 
get it for free indirectly when including weblogic.jar as a system scope 
dependency through it's manifest classpath.

 
 You then depend on that uberjar _with_scope_provided_ this is because
 the jar is being provided for you.
 
 In weblogic, if you want to use a version of xerces that is not the
 one sucked in by weblogic.jar, then you need to configure your app
 with a filtering classloader in any case, so the classpath hell will
 either be there anyway, or you will have to man up and write the
 filtering classloader descriptor anyway. The provided weblogic.jar
 dependency will not have any transitive deps in any case (unless you
 add them yourself) and being scope=provided, it will not be transitive
 itself

We're talking build time dependencies here. WebLogic appears to be using some 
form of OSGI container that at runtime gives the kind of class visibility 
behaviour that you would expect.

I agree that the system scope is an ugly ugly solution, but in the end one 
has to be pragmatic. This is the only real use case I've *ever* had for 
system scope. Removing that Maven capability makes working with some WebLogic 
APIs a trial for the developers that need them. You're right that we could each 
write a program to analyse the OSGI Import-Package entries (there are no 
Class-Path entries in the modules) of the manifest.mf and try and build some 
kind of uberjar. But really?

All this talk of OSGI makes me wonder if tycho could help somehow.

What do you think?

Steve C

* Incidentally, we never package xerces and friends in our EAR or WAR files. We 
stick to the standard javax.xml apis and use whatever implementation is 
provided by the container. That has always been a recipe for trouble. If you're 
building WAR files and deploying only to a servlet container then YMMV.



 
 -Stephen
 
 On 15 November 2011 09:27, Nord, James jn...@nds.com wrote:
 Not that I am needing to do this but in order to further my understanding...
 
 If you create an Uber JAR - then you can end up in classpath hell - as the 
 dependencies aren't correct (it could include common-io 1.2 and you need 
 commons-io 1.3 which is declared transitively)  This then means that even 
 though you don't depend on commons-io you need to start adding all 
 transitive dependencies to your pom just incase the app server ships with a 
 different one and the uber jar takes precedence over the transitive 
 dependency.  The J2EE container should allow you to override some bits of 
 the provide jars should they not?
 
 /James
 
 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: 15 November 2011 08:26
 To: Maven Users List
 Subject: Re: Properties in settings.xml does not work for system scoped 
 dependencies
 
 the correct scope for those deps should be provided imho.
 
 the problem you have is getting the deps you need, system scope is just a 
 workaround.
 
 ideally you would create an uberjar from the geologic jar and just install 
 that into your repo manager.
 
 the focus should be on taking a jar and making

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Coy]

Hi there,

I've been a maven user since the early 1.0 days and have contributed patches at 
various times for the ejb-plugin, ear-plugin and others.

I've also had the unfortunate experience of having to use WebLogic 10+ to 
create useable maven poms for our projects. In fact, when I read the OP I knew 
he was talking about Weblogic even though he did not mention it.

The *only* way I've been able to do this successfully was with a system scoped 
dependency on the weblogic.jar.

This is because weblogic contains a maze of relative manifest class paths that 
are truly mind boggling.

The very first class path entry in weblogic.jar looks like:

../../../modules/features/weblogic.server.modules_10.3.5.0.jar
(plus a dozen or more others)

That modules directory contains 465 (very OSGI looking) jars and sub 
directories. Do you really think it's practical to install all of these into a 
repository manager? How would you generate the dependencies for each pom?

This would not be an issue for any plain old JEE application. However, if you 
have any need at all for weblogic specific APIs then a system scoped dependency 
is the only practical way. Even when you do figure out which one of those ~500 
jars contains your API, you then need to read it's manifest and pick out its 
dependencies, and then the dependencies' dependencies, etc.

If someone has a simple solution to this then I'd like to hear it too. 
Otherwise, *please* restore the system scope functionality.


Cheers,

Steve C


On 14/11/2011, at 2:55 AM, Benson Margulies wrote:

 No possible licensing restriction can prevent you from having your own
 shared repository with nexus or archiva or artifactory and pushing
 whatever you want to it.
 
 For that matter, it's not too hard to write a script that calls
 install:install-file on each of a pile of jar files. You can't do this
 in the reactor and then use the results (AFAIK), but you can run this
 and then run the build.
 
 In other words, anything you can do with system scope you can do with
 less headaches with a repo manager or instal:install-file.
 
 
 On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav be...@rodehav.com wrote:
 Last time I went through this I never came all the way to a complete list
 but I do remember there were lots of jars missing. I guess I'll have to
 reiterate this again since system scope doesn't seem to be supported
 anymore.
 
 /Bengt
 
 2011/11/12 Wayne Fay wayne...@gmail.com
 
 What else do you need? Why not full client + some reasonable (small)
 handful of other dependencies?
 
 Wayne
 
 On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav be...@rodehav.com wrote:
 It works but the full client is not enough for us to be able to build our
 application.
 
 Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:
 
 Does this no longer work?
 http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
 On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:
 
 Stephen and Wayne,
 
 I agree that using system scope is undesirable. However, there is a
 reason
 why maven has had this  support - it is needed in real life. In my
 case, I
 use Weblogic. When first trying to migrate our old ant based build
 system
 to maven, I started out by trying to put the Weblogic jar:s in the
 maven
 repo. It just wasn't doable. They have split the big, all
 encompassing,
 jar
 file from previous versions into hundreds of individual jar files. I
 gave
 up after a while. I guess if I could find a tool that could convert
 all
 these jars into one super jar then I could put that jar in the maven
 repo. I'm not sure that Oracle's licensing rules would allow it
 though.
 
 Dropping support like this because you don't think it's the best way
 to
 handle things will not give you a loyal user base. We need to solve
 these
 kind of issues somehow. Before you remove support you must provide an
 alternate solution. Requiring that hundreds of proprietary jars have
 to
 be
 put in the maven repo (and updated each time we upgrade Weblogic) is
 just
 not realistic. I've been searching for a good tool that can traverse
 the
 manifest classpath's and create a single jar from all individual jars.
 Do
 you know of any such tool?
 
 The transitive dependency problem is not exactly the way you describe
 it
 Stephen. I don't need transitive dependencies from a system scoped
 dependency but I want the transitive dependencies to work up to the
 system
 scoped dependency:
 
 If A depends on B that depends on S (via a system scoped dependency),
 then
 maven should be able to include S on A's build classpath.
 
 The way maven works right now I tend to agree that system scoped
 dependencies are useless. This is because their location must be hard
 coded
 in the POM. Naturally system scoped dependencies reside in different
 places
 in different environments. In our case it resides where the user has
 installed Weblogic.
 
 /Bengt
 
 
 
 
 
 
 2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com
 
 On 11 November 

Re: Properties in settings.xml does not work for system scoped dependencies

[Benson Margulies]

No possible licensing restriction can prevent you from having your own
shared repository with nexus or archiva or artifactory and pushing
whatever you want to it.

For that matter, it's not too hard to write a script that calls
install:install-file on each of a pile of jar files. You can't do this
in the reactor and then use the results (AFAIK), but you can run this
and then run the build.

In other words, anything you can do with system scope you can do with
less headaches with a repo manager or instal:install-file.


On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav be...@rodehav.com wrote:
 Last time I went through this I never came all the way to a complete list
 but I do remember there were lots of jars missing. I guess I'll have to
 reiterate this again since system scope doesn't seem to be supported
 anymore.

 /Bengt

 2011/11/12 Wayne Fay wayne...@gmail.com

 What else do you need? Why not full client + some reasonable (small)
 handful of other dependencies?

 Wayne

 On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav be...@rodehav.com wrote:
  It works but the full client is not enough for us to be able to build our
  application.
 
  Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:
 
  Does this no longer work?
  http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
   On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:
 
   Stephen and Wayne,
  
   I agree that using system scope is undesirable. However, there is a
  reason
   why maven has had this  support - it is needed in real life. In my
  case, I
   use Weblogic. When first trying to migrate our old ant based build
  system
   to maven, I started out by trying to put the Weblogic jar:s in the
 maven
   repo. It just wasn't doable. They have split the big, all
 encompassing,
  jar
   file from previous versions into hundreds of individual jar files. I
  gave
   up after a while. I guess if I could find a tool that could convert
 all
   these jars into one super jar then I could put that jar in the maven
   repo. I'm not sure that Oracle's licensing rules would allow it
 though.
  
   Dropping support like this because you don't think it's the best way
 to
   handle things will not give you a loyal user base. We need to solve
  these
   kind of issues somehow. Before you remove support you must provide an
   alternate solution. Requiring that hundreds of proprietary jars have
 to
  be
   put in the maven repo (and updated each time we upgrade Weblogic) is
  just
   not realistic. I've been searching for a good tool that can traverse
 the
   manifest classpath's and create a single jar from all individual jars.
  Do
   you know of any such tool?
  
   The transitive dependency problem is not exactly the way you describe
 it
   Stephen. I don't need transitive dependencies from a system scoped
   dependency but I want the transitive dependencies to work up to the
  system
   scoped dependency:
  
   If A depends on B that depends on S (via a system scoped dependency),
  then
   maven should be able to include S on A's build classpath.
  
   The way maven works right now I tend to agree that system scoped
   dependencies are useless. This is because their location must be hard
  coded
   in the POM. Naturally system scoped dependencies reside in different
  places
   in different environments. In our case it resides where the user has
   installed Weblogic.
  
   /Bengt
  
  
  
  
  
  
   2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com
  
On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
 System scoped dependencies are dead. Ignore their zombie like
  walking
 about. Stop fighting maven and just install the jars into a repo

 I agree, but shouldn't we kill system entirely at some point (I
 mean
 in the code) -- if we see a system-scoped dependency, we just fail
  the
 build with an appropriate error message? It is a dead concept IMO
  and
 is simply confusing to users who try to use it.
   
Yes I agree... but lets get 3.0.4 out first ;-)
   
To answer the OP
   
Think of it like this, when you specify a system scope dependency
then you are stating that the system is responsible for providing
 that
dependency _and_ all its dependencies - transitive stops at system
   
Similarly, with provided scope, you are saying that somebody else is
taking care of providing that dependency at run time, and so
 therefore
maven doesn't have to worry about it or its dependencies.

 Wayne


  -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


   
   
 -
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
 

 

Re: Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav]

Last time I went through this I never came all the way to a complete list
but I do remember there were lots of jars missing. I guess I'll have to
reiterate this again since system scope doesn't seem to be supported
anymore.

/Bengt

2011/11/12 Wayne Fay wayne...@gmail.com

 What else do you need? Why not full client + some reasonable (small)
 handful of other dependencies?

 Wayne

 On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav be...@rodehav.com wrote:
  It works but the full client is not enough for us to be able to build our
  application.
 
  Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:
 
  Does this no longer work?
  http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
   On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:
 
   Stephen and Wayne,
  
   I agree that using system scope is undesirable. However, there is a
  reason
   why maven has had this  support - it is needed in real life. In my
  case, I
   use Weblogic. When first trying to migrate our old ant based build
  system
   to maven, I started out by trying to put the Weblogic jar:s in the
 maven
   repo. It just wasn't doable. They have split the big, all
 encompassing,
  jar
   file from previous versions into hundreds of individual jar files. I
  gave
   up after a while. I guess if I could find a tool that could convert
 all
   these jars into one super jar then I could put that jar in the maven
   repo. I'm not sure that Oracle's licensing rules would allow it
 though.
  
   Dropping support like this because you don't think it's the best way
 to
   handle things will not give you a loyal user base. We need to solve
  these
   kind of issues somehow. Before you remove support you must provide an
   alternate solution. Requiring that hundreds of proprietary jars have
 to
  be
   put in the maven repo (and updated each time we upgrade Weblogic) is
  just
   not realistic. I've been searching for a good tool that can traverse
 the
   manifest classpath's and create a single jar from all individual jars.
  Do
   you know of any such tool?
  
   The transitive dependency problem is not exactly the way you describe
 it
   Stephen. I don't need transitive dependencies from a system scoped
   dependency but I want the transitive dependencies to work up to the
  system
   scoped dependency:
  
   If A depends on B that depends on S (via a system scoped dependency),
  then
   maven should be able to include S on A's build classpath.
  
   The way maven works right now I tend to agree that system scoped
   dependencies are useless. This is because their location must be hard
  coded
   in the POM. Naturally system scoped dependencies reside in different
  places
   in different environments. In our case it resides where the user has
   installed Weblogic.
  
   /Bengt
  
  
  
  
  
  
   2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com
  
On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
 System scoped dependencies are dead. Ignore their zombie like
  walking
 about. Stop fighting maven and just install the jars into a repo

 I agree, but shouldn't we kill system entirely at some point (I
 mean
 in the code) -- if we see a system-scoped dependency, we just fail
  the
 build with an appropriate error message? It is a dead concept IMO
  and
 is simply confusing to users who try to use it.
   
Yes I agree... but lets get 3.0.4 out first ;-)
   
To answer the OP
   
Think of it like this, when you specify a system scope dependency
then you are stating that the system is responsible for providing
 that
dependency _and_ all its dependencies - transitive stops at system
   
Similarly, with provided scope, you are saying that somebody else is
taking care of providing that dependency at run time, and so
 therefore
maven doesn't have to worry about it or its dependencies.

 Wayne


  -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


   
   
 -
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly]

System scoped dependencies are dead. Ignore their zombie like walking
about. Stop fighting maven and just install the jars into a repo

On 11 November 2011 16:02, Bengt Rodehav be...@rodehav.com wrote:
 We are using maven 3.0.3 and have problems using property values defined in
 our local settings.xml for specifying systemPath values for system-scoped
 dependencies. It seems this possibility has been removed in maven 3.

 The system-scoped variable is necessary because we depend directly on a
 third party application server jar file which now has hard coded dependency
 jars listed in its MANIFEST. It is simply not practical to install these
 (several dozen - perhaps hundreds) jars into our remote Maven repository.

 The problem is serious because the pom files which use this system-scoped
 dependency do not pass validation when parsed by the reactor, preventing
 any transitive dependencies from being resolved in child projects. The
 current workaround is to define these properties in our parent pom instead,
 but this is not ideal since the values are environment-specific in nature
 and should not be hard coded in the pom.

 I wonder why this has changed in maven 3 and what then is the best practice
 to handle a situation like ours (it must be a common scenario)?

 As a side note we actually discovered this on computers running maven 2.2.1
 but using m2eclipse. M2eclipse seems to use an embedded snapshot version of
 maven 3  for its dependency resolution (we use m2eclipse
 12.0.20101115-1102). It has worked perfectly for a long time but just
 recently started to exhibit this behaviour. We don't really know what has
 triggered this but we are guessing that m2eclipse perhaps updated itself
 with a new snapshot version of maven 3 - not really sure have m2eclipse
 works regarding this.

 I appreciate any help,

 /Bengt


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Wayne Fay]

 System scoped dependencies are dead. Ignore their zombie like walking
 about. Stop fighting maven and just install the jars into a repo

I agree, but shouldn't we kill system entirely at some point (I mean
in the code) -- if we see a system-scoped dependency, we just fail the
build with an appropriate error message? It is a dead concept IMO and
is simply confusing to users who try to use it.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly]

On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
 System scoped dependencies are dead. Ignore their zombie like walking
 about. Stop fighting maven and just install the jars into a repo

 I agree, but shouldn't we kill system entirely at some point (I mean
 in the code) -- if we see a system-scoped dependency, we just fail the
 build with an appropriate error message? It is a dead concept IMO and
 is simply confusing to users who try to use it.

Yes I agree... but lets get 3.0.4 out first ;-)

To answer the OP

Think of it like this, when you specify a system scope dependency
then you are stating that the system is responsible for providing that
dependency _and_ all its dependencies - transitive stops at system

Similarly, with provided scope, you are saying that somebody else is
taking care of providing that dependency at run time, and so therefore
maven doesn't have to worry about it or its dependencies.

 Wayne

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav]

Stephen and Wayne,

I agree that using system scope is undesirable. However, there is a reason
why maven has had this  support - it is needed in real life. In my case, I
use Weblogic. When first trying to migrate our old ant based build system
to maven, I started out by trying to put the Weblogic jar:s in the maven
repo. It just wasn't doable. They have split the big, all encompassing, jar
file from previous versions into hundreds of individual jar files. I gave
up after a while. I guess if I could find a tool that could convert all
these jars into one super jar then I could put that jar in the maven
repo. I'm not sure that Oracle's licensing rules would allow it though.

Dropping support like this because you don't think it's the best way to
handle things will not give you a loyal user base. We need to solve these
kind of issues somehow. Before you remove support you must provide an
alternate solution. Requiring that hundreds of proprietary jars have to be
put in the maven repo (and updated each time we upgrade Weblogic) is just
not realistic. I've been searching for a good tool that can traverse the
manifest classpath's and create a single jar from all individual jars. Do
you know of any such tool?

The transitive dependency problem is not exactly the way you describe it
Stephen. I don't need transitive dependencies from a system scoped
dependency but I want the transitive dependencies to work up to the system
scoped dependency:

If A depends on B that depends on S (via a system scoped dependency), then
maven should be able to include S on A's build classpath.

The way maven works right now I tend to agree that system scoped
dependencies are useless. This is because their location must be hard coded
in the POM. Naturally system scoped dependencies reside in different places
in different environments. In our case it resides where the user has
installed Weblogic.

/Bengt






2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com

 On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
  System scoped dependencies are dead. Ignore their zombie like walking
  about. Stop fighting maven and just install the jars into a repo
 
  I agree, but shouldn't we kill system entirely at some point (I mean
  in the code) -- if we see a system-scoped dependency, we just fail the
  build with an appropriate error message? It is a dead concept IMO and
  is simply confusing to users who try to use it.

 Yes I agree... but lets get 3.0.4 out first ;-)

 To answer the OP

 Think of it like this, when you specify a system scope dependency
 then you are stating that the system is responsible for providing that
 dependency _and_ all its dependencies - transitive stops at system

 Similarly, with provided scope, you are saying that somebody else is
 taking care of providing that dependency at run time, and so therefore
 maven doesn't have to worry about it or its dependencies.
 
  Wayne
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Ryan Connolly]

Does this no longer work?
http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
 On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:

 Stephen and Wayne,

 I agree that using system scope is undesirable. However, there is a reason
 why maven has had this  support - it is needed in real life. In my case, I
 use Weblogic. When first trying to migrate our old ant based build system
 to maven, I started out by trying to put the Weblogic jar:s in the maven
 repo. It just wasn't doable. They have split the big, all encompassing, jar
 file from previous versions into hundreds of individual jar files. I gave
 up after a while. I guess if I could find a tool that could convert all
 these jars into one super jar then I could put that jar in the maven
 repo. I'm not sure that Oracle's licensing rules would allow it though.

 Dropping support like this because you don't think it's the best way to
 handle things will not give you a loyal user base. We need to solve these
 kind of issues somehow. Before you remove support you must provide an
 alternate solution. Requiring that hundreds of proprietary jars have to be
 put in the maven repo (and updated each time we upgrade Weblogic) is just
 not realistic. I've been searching for a good tool that can traverse the
 manifest classpath's and create a single jar from all individual jars. Do
 you know of any such tool?

 The transitive dependency problem is not exactly the way you describe it
 Stephen. I don't need transitive dependencies from a system scoped
 dependency but I want the transitive dependencies to work up to the system
 scoped dependency:

 If A depends on B that depends on S (via a system scoped dependency), then
 maven should be able to include S on A's build classpath.

 The way maven works right now I tend to agree that system scoped
 dependencies are useless. This is because their location must be hard coded
 in the POM. Naturally system scoped dependencies reside in different places
 in different environments. In our case it resides where the user has
 installed Weblogic.

 /Bengt






 2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com

  On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
   System scoped dependencies are dead. Ignore their zombie like walking
   about. Stop fighting maven and just install the jars into a repo
  
   I agree, but shouldn't we kill system entirely at some point (I mean
   in the code) -- if we see a system-scoped dependency, we just fail the
   build with an appropriate error message? It is a dead concept IMO and
   is simply confusing to users who try to use it.
 
  Yes I agree... but lets get 3.0.4 out first ;-)
 
  To answer the OP
 
  Think of it like this, when you specify a system scope dependency
  then you are stating that the system is responsible for providing that
  dependency _and_ all its dependencies - transitive stops at system
 
  Similarly, with provided scope, you are saying that somebody else is
  taking care of providing that dependency at run time, and so therefore
  maven doesn't have to worry about it or its dependencies.
  
   Wayne
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav]

It works but the full client is not enough for us to be able to build our
application.

Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:

 Does this no longer work?
 http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
  On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:

  Stephen and Wayne,
 
  I agree that using system scope is undesirable. However, there is a
reason
  why maven has had this  support - it is needed in real life. In my
case, I
  use Weblogic. When first trying to migrate our old ant based build
system
  to maven, I started out by trying to put the Weblogic jar:s in the maven
  repo. It just wasn't doable. They have split the big, all encompassing,
jar
  file from previous versions into hundreds of individual jar files. I
gave
  up after a while. I guess if I could find a tool that could convert all
  these jars into one super jar then I could put that jar in the maven
  repo. I'm not sure that Oracle's licensing rules would allow it though.
 
  Dropping support like this because you don't think it's the best way to
  handle things will not give you a loyal user base. We need to solve
these
  kind of issues somehow. Before you remove support you must provide an
  alternate solution. Requiring that hundreds of proprietary jars have to
be
  put in the maven repo (and updated each time we upgrade Weblogic) is
just
  not realistic. I've been searching for a good tool that can traverse the
  manifest classpath's and create a single jar from all individual jars.
Do
  you know of any such tool?
 
  The transitive dependency problem is not exactly the way you describe it
  Stephen. I don't need transitive dependencies from a system scoped
  dependency but I want the transitive dependencies to work up to the
system
  scoped dependency:
 
  If A depends on B that depends on S (via a system scoped dependency),
then
  maven should be able to include S on A's build classpath.
 
  The way maven works right now I tend to agree that system scoped
  dependencies are useless. This is because their location must be hard
coded
  in the POM. Naturally system scoped dependencies reside in different
places
  in different environments. In our case it resides where the user has
  installed Weblogic.
 
  /Bengt
 
 
 
 
 
 
  2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com
 
   On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
System scoped dependencies are dead. Ignore their zombie like
walking
about. Stop fighting maven and just install the jars into a repo
   
I agree, but shouldn't we kill system entirely at some point (I mean
in the code) -- if we see a system-scoped dependency, we just fail
the
build with an appropriate error message? It is a dead concept IMO
and
is simply confusing to users who try to use it.
  
   Yes I agree... but lets get 3.0.4 out first ;-)
  
   To answer the OP
  
   Think of it like this, when you specify a system scope dependency
   then you are stating that the system is responsible for providing that
   dependency _and_ all its dependencies - transitive stops at system
  
   Similarly, with provided scope, you are saying that somebody else is
   taking care of providing that dependency at run time, and so therefore
   maven doesn't have to worry about it or its dependencies.
   
Wayne
   
   
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 

Re: Properties in settings.xml does not work for system scoped dependencies

[Wayne Fay]

What else do you need? Why not full client + some reasonable (small)
handful of other dependencies?

Wayne

On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav be...@rodehav.com wrote:
 It works but the full client is not enough for us to be able to build our
 application.

 Den 11 nov 2011 23:11 skrev Ryan Connolly ryn...@gmail.com:

 Does this no longer work?
 http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
  On Nov 11, 2011 3:38 PM, Bengt Rodehav be...@rodehav.com wrote:

  Stephen and Wayne,
 
  I agree that using system scope is undesirable. However, there is a
 reason
  why maven has had this  support - it is needed in real life. In my
 case, I
  use Weblogic. When first trying to migrate our old ant based build
 system
  to maven, I started out by trying to put the Weblogic jar:s in the maven
  repo. It just wasn't doable. They have split the big, all encompassing,
 jar
  file from previous versions into hundreds of individual jar files. I
 gave
  up after a while. I guess if I could find a tool that could convert all
  these jars into one super jar then I could put that jar in the maven
  repo. I'm not sure that Oracle's licensing rules would allow it though.
 
  Dropping support like this because you don't think it's the best way to
  handle things will not give you a loyal user base. We need to solve
 these
  kind of issues somehow. Before you remove support you must provide an
  alternate solution. Requiring that hundreds of proprietary jars have to
 be
  put in the maven repo (and updated each time we upgrade Weblogic) is
 just
  not realistic. I've been searching for a good tool that can traverse the
  manifest classpath's and create a single jar from all individual jars.
 Do
  you know of any such tool?
 
  The transitive dependency problem is not exactly the way you describe it
  Stephen. I don't need transitive dependencies from a system scoped
  dependency but I want the transitive dependencies to work up to the
 system
  scoped dependency:
 
  If A depends on B that depends on S (via a system scoped dependency),
 then
  maven should be able to include S on A's build classpath.
 
  The way maven works right now I tend to agree that system scoped
  dependencies are useless. This is because their location must be hard
 coded
  in the POM. Naturally system scoped dependencies reside in different
 places
  in different environments. In our case it resides where the user has
  installed Weblogic.
 
  /Bengt
 
 
 
 
 
 
  2011/11/11 Stephen Connolly stephen.alan.conno...@gmail.com
 
   On 11 November 2011 16:31, Wayne Fay wayne...@gmail.com wrote:
System scoped dependencies are dead. Ignore their zombie like
 walking
about. Stop fighting maven and just install the jars into a repo
   
I agree, but shouldn't we kill system entirely at some point (I mean
in the code) -- if we see a system-scoped dependency, we just fail
 the
build with an appropriate error message? It is a dead concept IMO
 and
is simply confusing to users who try to use it.
  
   Yes I agree... but lets get 3.0.4 out first ;-)
  
   To answer the OP
  
   Think of it like this, when you specify a system scope dependency
   then you are stating that the system is responsible for providing that
   dependency _and_ all its dependencies - transitive stops at system
  
   Similarly, with provided scope, you are saying that somebody else is
   taking care of providing that dependency at run time, and so therefore
   maven doesn't have to worry about it or its dependencies.
   
Wayne
   
   
 -
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in the archetype

[Asmann, Roland]

Doesn't anybody have an idea?


On 06.11.2010 19:09, Asmann, Roland wrote:
 Hi all,

 I'm having some problems with properties in archetypes. I read that it
 is possible to have files and directories renamed with properties
 (http://jira.codehaus.org/browse/ARCHETYPE-191), but this seems to be
 not working on modules.

 I have a certain project-structure that must be used, and I want the
 modules to be renamed automatically:

 my-test-app
 |-- my-test-ear
 |-- my-test-model
 |-- my-test-services
 |-- my-test-web

 The problem here is that when I tell the archetype that I have a
 property projectName and rename the directories and module-entries in
 the archetype-metadata.xml to look like __projectName__-ear and
 ${projectName}-ear, I don't get those modules!

 I've played around a bit and found that when I use a structure like this:

 my-test
 |-- my-test-ear
 |-- my-test-model

 The archetype-plugin will automatically create directories and entries
 in the archetype-metadata.xml like __rootArtifactId__-ear and
 ${rootArtifactId}-ear.

 Why is this not working for my custom-property?

 --
 Roland Asmann
 Senior Software Engineer

 adesso Austria GmbH
 Floridotower 26. Stock T +43 1 2198790-27
 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927
 A-1210 Wien M +43 664 88657566
 E roland.asm...@adesso.at
 W www.adesso.at

 -
   business. people. technology. 
 -

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


-- 
Roland Asmann
Senior Software Engineer

adesso Austria GmbH
Floridotower 26. Stock  T +43 1 2198790-27
Floridsdorfer Hauptstr. 1   F +43 1 2198790-927
A-1210 Wien M +43 664 88657566
E roland.asm...@adesso.at
W www.adesso.at

-
  business. people. technology. 
-

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties in the archetype

[Joachim Van der Auwera]

I tried using this some time ago and remember this cannot be used for 
generic properties, only for groupId (if I remember correctly). The 
archetype plugin has some limitations at the moment. I hope this can be 
improved soon.


Joachim

On 11/18/2010 12:36 PM, Asmann, Roland wrote:

Doesn't anybody have an idea?


On 06.11.2010 19:09, Asmann, Roland wrote:

Hi all,

I'm having some problems with properties in archetypes. I read that it
is possible to have files and directories renamed with properties
(http://jira.codehaus.org/browse/ARCHETYPE-191), but this seems to be
not working on modules.

I have a certain project-structure that must be used, and I want the
modules to be renamed automatically:

my-test-app
|-- my-test-ear
|-- my-test-model
|-- my-test-services
|-- my-test-web

The problem here is that when I tell the archetype that I have a
property projectName and rename the directories and module-entries in
the archetype-metadata.xml to look like __projectName__-ear and
${projectName}-ear, I don't get those modules!

I've played around a bit and found that when I use a structure like this:

my-test
|-- my-test-ear
|-- my-test-model

The archetype-plugin will automatically create directories and entries
in the archetype-metadata.xml like __rootArtifactId__-ear and
${rootArtifactId}-ear.

Why is this not working for my custom-property?

--
Roland Asmann
Senior Software Engineer

adesso Austria GmbH
Floridotower 26. Stock T +43 1 2198790-27
Floridsdorfer Hauptstr. 1 F +43 1 2198790-927
A-1210 Wien M +43 664 88657566
E roland.asm...@adesso.at
W www.adesso.at

-
business. people. technology.
-

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[chemit]

On Thu, 11 Nov 2010 14:34:05 +0100
chemit che...@codelutin.com wrote:

 Hi guys,
 
 I was testing some of my mojo on windows platform (xp) and how
 surprised I was to see there is some big problems.
 
 I had some 
 [ERROR] 'dependencies.dependency.version' for
 commons-logging:commons-logging:jar is missing. @ line 48, column 17
 
 when having in my mojo pom :
 
  dependency
   groupIdcommons-logging/groupId
   artifactIdcommons-logging/artifactId
  /dependency
 
 which having as parent pom something with the good
 dependenciesManagement filled for this dependency.
 
 Another one, I defined in ma parent pom a mavenVersion property (to
 2.2.1)
 
 In the plugin I had
 
 dependency
   groupIdorg.apache.maven/groupId
   artifactIdmaven-project/artifactId
   version${mavenVersion}/version
   scopeprovided/scope
 /dependency
 
 But once again it did not works, while repeting the property
 definition in plugin pom it works.
 
 I feel a bit disapointing by such behaviour on windows, I did never
 test maven 3.0 before final release and just test it on linux as for
 me java is platform independant. 
 For next releases of maven, before giving my +1, I'll have a check on
 windows first, be sure ;)
 
 Is those problem are known? I did not see anything about this on the
 list, which means one thing to me : windows users does not use maven
 (this was my troll sorry ;)).
 
 Hope something will be done soon about it ;)
   
 

Ok now the problem is identified : There was a mistake done on central
and so the pom obtained was not the good one. 

I first did not look on this way (for me central is safe).

Sorry for all the noise about this on the list.

Cheers,

-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[Vincent Latombe]

I think what Benjamin meant is : please provide an sample project to
reproduce your problem.

Vincent


2010/11/11 Yanko, Curtis curt_ya...@uhc.com

 Very odd indeed, we use properties quite pervasively and I haven't seen
 this.

 I do recall some chicken-n-egg scenarios but this doesn't to fit that mold.


  -Original Message-
  From: chemit [mailto:che...@codelutin.com]
  Sent: Thursday, November 11, 2010 9:42 AM
  To: users@maven.apache.org
  Subject: Re: properties inheritance does not work on windows os
 
  On Thu, 11 Nov 2010 08:27:24 -0600
  Yanko, Curtis curt_ya...@uhc.com wrote:
 
   Is this only on Maven 3.0? We haven't crossed that bridge yet.
 
  Good point, I have just try with version 2.2.1 and result is the same.
 
  I really don't understand why this works on linux but not
  under windows, there is some mysteries somewhere.
 
  Just to note, we use this since some times now (having
  version with a property in dependenciesManagement of a parent
  pom) and we never had the problem (since now :)).
 
  I will have a look in maven jira in case.
 
  Perharps what we are doing is wrong ? I really don't know...
 
  Thanks.
 
 
  --
  Tony Chemit
  
  tél: +33 (0) 2 40 50 29 28
  email: che...@codelutin.com
  http://www.codelutin.com
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 This e-mail, including attachments, may include confidential and/or
 proprietary information, and may be used only by the person or entity
 to which it is addressed. If the reader of this e-mail is not the intended
 recipient or his or her authorized agent, the reader is hereby notified
 that any dissemination, distribution or copying of this e-mail is
 prohibited. If you have received this e-mail in error, please notify the
 sender by replying to this message and delete this e-mail immediately.


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

RE: properties inheritance does not work on windows os

[Yanko, Curtis]

??
 

 -Original Message-
 From: Vincent Latombe [mailto:vincent.lato...@gmail.com] 
 Sent: Friday, November 12, 2010 7:56 AM
 To: Maven Users List
 Subject: Re: properties inheritance does not work on windows os
 
 I think what Benjamin meant is : please provide an sample 
 project to reproduce your problem.
 
 Vincent
 
 
 2010/11/11 Yanko, Curtis curt_ya...@uhc.com
 
  Very odd indeed, we use properties quite pervasively and I haven't 
  seen this.
 
  I do recall some chicken-n-egg scenarios but this doesn't 
 to fit that mold.
 
 
   -Original Message-
   From: chemit [mailto:che...@codelutin.com]
   Sent: Thursday, November 11, 2010 9:42 AM
   To: users@maven.apache.org
   Subject: Re: properties inheritance does not work on windows os
  
   On Thu, 11 Nov 2010 08:27:24 -0600
   Yanko, Curtis curt_ya...@uhc.com wrote:
  
Is this only on Maven 3.0? We haven't crossed that bridge yet.
  
   Good point, I have just try with version 2.2.1 and result 
 is the same.
  
   I really don't understand why this works on linux but not under 
   windows, there is some mysteries somewhere.
  
   Just to note, we use this since some times now (having 
 version with 
   a property in dependenciesManagement of a parent
   pom) and we never had the problem (since now :)).
  
   I will have a look in maven jira in case.
  
   Perharps what we are doing is wrong ? I really don't know...
  
   Thanks.
  
  
   --
   Tony Chemit
   
   tél: +33 (0) 2 40 50 29 28
   email: che...@codelutin.com
   http://www.codelutin.com
  
   
 
   - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
  This e-mail, including attachments, may include confidential and/or 
  proprietary information, and may be used only by the person 
 or entity 
  to which it is addressed. If the reader of this e-mail is not the 
  intended recipient or his or her authorized agent, the reader is 
  hereby notified that any dissemination, distribution or copying of 
  this e-mail is prohibited. If you have received this e-mail 
 in error, 
  please notify the sender by replying to this message and 
 delete this e-mail immediately.
 
 
  
 -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: RE: properties inheritance does not work on windows os

[Vincent Latombe]

My previous message was meant for chemit and his reaction to Benjamin's
message

Vincent
Le 2010 11 12 13:59, Yanko, Curtis curt_ya...@uhc.com a écrit :
 ??


 -Original Message-
 From: Vincent Latombe [mailto:vincent.lato...@gmail.com]
 Sent: Friday, November 12, 2010 7:56 AM
 To: Maven Users List
 Subject: Re: properties inheritance does not work on windows os

 I think what Benjamin meant is : please provide an sample
 project to reproduce your problem.

 Vincent


 2010/11/11 Yanko, Curtis curt_ya...@uhc.com

  Very odd indeed, we use properties quite pervasively and I haven't
  seen this.
 
  I do recall some chicken-n-egg scenarios but this doesn't
 to fit that mold.
 
 
   -Original Message-
   From: chemit [mailto:che...@codelutin.com]
   Sent: Thursday, November 11, 2010 9:42 AM
   To: users@maven.apache.org
   Subject: Re: properties inheritance does not work on windows os
  
   On Thu, 11 Nov 2010 08:27:24 -0600
   Yanko, Curtis curt_ya...@uhc.com wrote:
  
Is this only on Maven 3.0? We haven't crossed that bridge yet.
  
   Good point, I have just try with version 2.2.1 and result
 is the same.
  
   I really don't understand why this works on linux but not under
   windows, there is some mysteries somewhere.
  
   Just to note, we use this since some times now (having
 version with
   a property in dependenciesManagement of a parent
   pom) and we never had the problem (since now :)).
  
   I will have a look in maven jira in case.
  
   Perharps what we are doing is wrong ? I really don't know...
  
   Thanks.
  
  
   --
   Tony Chemit
   
   tél: +33 (0) 2 40 50 29 28
   email: che...@codelutin.com
   http://www.codelutin.com
  
  
 
   - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
  This e-mail, including attachments, may include confidential and/or
  proprietary information, and may be used only by the person
 or entity
  to which it is addressed. If the reader of this e-mail is not the
  intended recipient or his or her authorized agent, the reader is
  hereby notified that any dissemination, distribution or copying of
  this e-mail is prohibited. If you have received this e-mail
 in error,
  please notify the sender by replying to this message and
 delete this e-mail immediately.
 
 
 
 -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 


 This e-mail, including attachments, may include confidential and/or
 proprietary information, and may be used only by the person or entity
 to which it is addressed. If the reader of this e-mail is not the intended
 recipient or his or her authorized agent, the reader is hereby notified
 that any dissemination, distribution or copying of this e-mail is
 prohibited. If you have received this e-mail in error, please notify the
 sender by replying to this message and delete this e-mail immediately.


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

RE: properties inheritance does not work on windows os

[Martin Gainty]

Curt-
 
we can help you only if you send us your pom.xml which invokes the plugin and 
your ant build.xml
http://maven.apache.org/plugins/maven-antrun-plugin/

Martin Gainty 
__ 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und 
Vertraulichkeitanmerkung/Note de déni et de confidentialité

 
Ez az üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy 
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése 
nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi 
alkalmazhatósága sincs.  Mivel az electronikus üzenetek könnyen 
megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet 
tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.



 

 Subject: RE: properties inheritance does not work on windows os
 Date: Fri, 12 Nov 2010 06:58:40 -0600
 From: curt_ya...@uhc.com
 To: users@maven.apache.org
 
 ??
 
 
  -Original Message-
  From: Vincent Latombe [mailto:vincent.lato...@gmail.com] 
  Sent: Friday, November 12, 2010 7:56 AM
  To: Maven Users List
  Subject: Re: properties inheritance does not work on windows os
  
  I think what Benjamin meant is : please provide an sample 
  project to reproduce your problem.
  
  Vincent
  
  
  2010/11/11 Yanko, Curtis curt_ya...@uhc.com
  
   Very odd indeed, we use properties quite pervasively and I haven't 
   seen this.
  
   I do recall some chicken-n-egg scenarios but this doesn't 
  to fit that mold.
  
  
-Original Message-
From: chemit [mailto:che...@codelutin.com]
Sent: Thursday, November 11, 2010 9:42 AM
To: users@maven.apache.org
Subject: Re: properties inheritance does not work on windows os
   
On Thu, 11 Nov 2010 08:27:24 -0600
Yanko, Curtis curt_ya...@uhc.com wrote:
   
 Is this only on Maven 3.0? We haven't crossed that bridge yet.
   
Good point, I have just try with version 2.2.1 and result 
  is the same.
   
I really don't understand why this works on linux but not under 
windows, there is some mysteries somewhere.
   
Just to note, we use this since some times now (having 
  version with 
a property in dependenciesManagement of a parent
pom) and we never had the problem (since now :)).
   
I will have a look in maven jira in case.
   
Perharps what we are doing is wrong ? I really don't know...
   
Thanks.
   
   
--
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com
   

  
- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
   This e-mail, including attachments, may include confidential and/or 
   proprietary information, and may be used only by the person 
  or entity 
   to which it is addressed. If the reader of this e-mail is not the 
   intended recipient or his or her authorized agent, the reader is 
   hereby notified that any dissemination, distribution or copying of 
   this e-mail is prohibited. If you have received this e-mail 
  in error, 
   please notify the sender by replying to this message and 
  delete this e-mail immediately.
  
  
   
  -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
  
 
 This e-mail, including attachments, may include confidential and/or
 proprietary information, and may be used only by the person or entity
 to which it is addressed. If the reader of this e-mail is not the intended
 recipient or his or her authorized agent, the reader is hereby notified
 that any dissemination, distribution or copying of this e-mail is
 prohibited. If you have received this e-mail in error, please notify the
 sender by replying to this message and delete this e-mail immediately

Re: properties inheritance does not work on windows os

[chemit]

On Fri, 12 Nov 2010 09:19:33 -0500
Martin Gainty mgai...@hotmail.com wrote:

I will make reproductible small project to show the problem.

I just try to test on windows but for my part it does not block me
since I do not use windows; it was just to test if it works for people
which like to use our libraries [1]

Thanks.

[1] http://nuiton.org

 
 Curt-
  
 we can help you only if you send us your pom.xml which invokes the
 plugin and your ant build.xml
 http://maven.apache.org/plugins/maven-antrun-plugin/
 
 Martin Gainty 
 __ 

-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[chemit]

On Thu, 11 Nov 2010 14:34:05 +0100
chemit che...@codelutin.com wrote:

 Hi guys,
 
 I was testing some of my mojo on windows platform (xp) and how
 surprised I was to see there is some big problems.
 
 I had some 
 [ERROR] 'dependencies.dependency.version' for
 commons-logging:commons-logging:jar is missing. @ line 48, column 17
 
 when having in my mojo pom :
 
  dependency
   groupIdcommons-logging/groupId
   artifactIdcommons-logging/artifactId
  /dependency
 
 which having as parent pom something with the good
 dependenciesManagement filled for this dependency.
Notice that in my parent pom the version of the dependency is filled by
a property then the second problem seems to me to be the same in fact...

 
 Another one, I defined in ma parent pom a mavenVersion property (to
 2.2.1)
 
 In the plugin I had
 
 dependency
   groupIdorg.apache.maven/groupId
   artifactIdmaven-project/artifactId
   version${mavenVersion}/version
   scopeprovided/scope
 /dependency
 
 But once again it did not works, while repeting the property
 definition in plugin pom it works.
 
 I feel a bit disapointing by such behaviour on windows, I did never
 test maven 3.0 before final release and just test it on linux as for
 me java is platform independant. 
 For next releases of maven, before giving my +1, I'll have a check on
 windows first, be sure ;)
 
 Is those problem are known? I did not see anything about this on the
 list, which means one thing to me : windows users does not use maven
 (this was my troll sorry ;)).
 
 Hope something will be done soon about it ;)
   
 



-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[Benjamin Bentmann]

chemit wrote:


Is those problem are known? I did not see anything about this on the
list, which means one thing to me : windows users does not use maven
(this was my troll sorry ;)).

Hope something will be done soon about it ;)


http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


Benjamin

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: properties inheritance does not work on windows os

[Yanko, Curtis]

We use Windows in some places and I have never run into this and yes, we
use lots of properties and inheritance.



Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day
 

 -Original Message-
 From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] 
 Sent: Thursday, November 11, 2010 9:18 AM
 To: Maven Users List
 Subject: Re: properties inheritance does not work on windows os
 
 chemit wrote:
 
  Is those problem are known? I did not see anything about 
 this on the 
  list, which means one thing to me : windows users does not 
 use maven 
  (this was my troll sorry ;)).
 
  Hope something will be done soon about it ;)
 
 http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
 
 
 Benjamin
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[chemit]

On Thu, 11 Nov 2010 15:17:48 +0100
Benjamin Bentmann benjamin.bentm...@udo.edu wrote:

 chemit wrote:
 
  Is those problem are known? I did not see anything about this on the
  list, which means one thing to me : windows users does not use maven
  (this was my troll sorry ;)).
 
  Hope something will be done soon about it ;)
 
 http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
 
 
This was your personal troll, I suppose ?

I pretty cleary explain the problem and ask if something was known
about it on a user list ?

And you send me to a 2000 miles page,... pretty nice of you :) Having
no time to read these page at the moment, I only keep one of the main
title : 

It doesn't work on windows ;)

Thanks benjamin


 Benjamin
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 



-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: properties inheritance does not work on windows os

[Yanko, Curtis]

Is this only on Maven 3.0? We haven't crossed that bridge yet. 

 -Original Message-
 From: chemit  

 
 Hi guys,
 
 I was testing some of my mojo on windows platform (xp) and 
 how surprised I was to see there is some big problems.
 
 I had some 
 [ERROR] 'dependencies.dependency.version' for
 commons-logging:commons-logging:jar is missing. @ line 48, column 17
 
 when having in my mojo pom :
 
  dependency
   groupIdcommons-logging/groupId
   artifactIdcommons-logging/artifactId
  /dependency
 
 which having as parent pom something with the good 
 dependenciesManagement filled for this dependency.
 
 Another one, I defined in ma parent pom a mavenVersion property (to
 2.2.1)
 
 In the plugin I had
 
 dependency
   groupIdorg.apache.maven/groupId
   artifactIdmaven-project/artifactId
   version${mavenVersion}/version
   scopeprovided/scope
 /dependency
 
 But once again it did not works, while repeting the property 
 definition in plugin pom it works.
 
 I feel a bit disapointing by such behaviour on windows, I did 
 never test maven 3.0 before final release and just test it on 
 linux as for me java is platform independant. 
 For next releases of maven, before giving my +1, I'll have a 
 check on windows first, be sure ;)
 
 Is those problem are known? I did not see anything about this 
 on the list, which means one thing to me : windows users does 
 not use maven (this was my troll sorry ;)).
 
 Hope something will be done soon about it ;)
   
 
 --
 Tony Chemit
 
 tél: +33 (0) 2 40 50 29 28
 email: che...@codelutin.com
 http://www.codelutin.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[chemit]

On Thu, 11 Nov 2010 08:24:45 -0600
Yanko, Curtis curt_ya...@uhc.com wrote:

 We use Windows in some places and I have never run into this and yes,
 we use lots of properties and inheritance.

The problem seems to come from dependencies only when version are
specified by a property.

 
 
 
 Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
 Making IT Happen, one build at a time, 600 times a day
  
 
  -Original Message-
  From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] 
  Sent: Thursday, November 11, 2010 9:18 AM
  To: Maven Users List
  Subject: Re: properties inheritance does not work on windows os
  
  chemit wrote:
  
   Is those problem are known? I did not see anything about 
  this on the 
   list, which means one thing to me : windows users does not 
  use maven 
   (this was my troll sorry ;)).
  
   Hope something will be done soon about it ;)
  
  http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
  
  
  Benjamin
  
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
 This e-mail, including attachments, may include confidential and/or
 proprietary information, and may be used only by the person or entity
 to which it is addressed. If the reader of this e-mail is not the
 intended recipient or his or her authorized agent, the reader is
 hereby notified that any dissemination, distribution or copying of
 this e-mail is prohibited. If you have received this e-mail in error,
 please notify the sender by replying to this message and delete this
 e-mail immediately.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 



-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties inheritance does not work on windows os

[chemit]

On Thu, 11 Nov 2010 08:27:24 -0600
Yanko, Curtis curt_ya...@uhc.com wrote:

 Is this only on Maven 3.0? We haven't crossed that bridge yet. 

Good point, I have just try with version 2.2.1 and result is the same.

I really don't understand why this works on linux but not under
windows, there is some mysteries somewhere.

Just to note, we use this since some times now (having version with a
property in dependenciesManagement of a parent pom) and we never had the
problem (since now :)).

I will have a look in maven jira in case.

Perharps what we are doing is wrong ? I really don't know...

Thanks.


-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com
http://www.codelutin.com

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: properties inheritance does not work on windows os

[Martin Gainty]

Curt-
 
not supporting version for all of your tasks in your build environments will 
not produce stable releases within your SDLC process
you can overcome this problem by promoting your non-version-tagged specific 
tasks to version-specific maven-plugins 
(start with 1.0) which will enable your build process to produce stable release 
distros

Martin- 
__ 
Der Auftrag der Gesundheitspflege liefert nicht Krankenversicherung...aber über 
das Auswählen der Herde 

 

 Date: Thu, 11 Nov 2010 15:30:36 +0100
 From: che...@codelutin.com
 To: users@maven.apache.org
 Subject: Re: properties inheritance does not work on windows os
 
 On Thu, 11 Nov 2010 08:24:45 -0600
 Yanko, Curtis curt_ya...@uhc.com wrote:
 
  We use Windows in some places and I have never run into this and yes,
  we use lots of properties and inheritance.
 
 The problem seems to come from dependencies only when version are
 specified by a property.
 
  
  
  
  Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
  Making IT Happen, one build at a time, 600 times a day
  
  
   -Original Message-
   From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] 
   Sent: Thursday, November 11, 2010 9:18 AM
   To: Maven Users List
   Subject: Re: properties inheritance does not work on windows os
   
   chemit wrote:
   
Is those problem are known? I did not see anything about 
   this on the 
list, which means one thing to me : windows users does not 
   use maven 
(this was my troll sorry ;)).
   
Hope something will be done soon about it ;)
   
   http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
   
   
   Benjamin
   
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
   
   
  
  This e-mail, including attachments, may include confidential and/or
  proprietary information, and may be used only by the person or entity
  to which it is addressed. If the reader of this e-mail is not the
  intended recipient or his or her authorized agent, the reader is
  hereby notified that any dissemination, distribution or copying of
  this e-mail is prohibited. If you have received this e-mail in error,
  please notify the sender by replying to this message and delete this
  e-mail immediately.
  
  
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
  
 
 
 
 -- 
 Tony Chemit
 
 tél: +33 (0) 2 40 50 29 28
 email: che...@codelutin.com
 http://www.codelutin.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
  

RE: properties inheritance does not work on windows os

[Yanko, Curtis]

Very odd indeed, we use properties quite pervasively and I haven't seen this.

I do recall some chicken-n-egg scenarios but this doesn't to fit that mold.
 

 -Original Message-
 From: chemit [mailto:che...@codelutin.com] 
 Sent: Thursday, November 11, 2010 9:42 AM
 To: users@maven.apache.org
 Subject: Re: properties inheritance does not work on windows os
 
 On Thu, 11 Nov 2010 08:27:24 -0600
 Yanko, Curtis curt_ya...@uhc.com wrote:
 
  Is this only on Maven 3.0? We haven't crossed that bridge yet. 
 
 Good point, I have just try with version 2.2.1 and result is the same.
 
 I really don't understand why this works on linux but not 
 under windows, there is some mysteries somewhere.
 
 Just to note, we use this since some times now (having 
 version with a property in dependenciesManagement of a parent 
 pom) and we never had the problem (since now :)).
 
 I will have a look in maven jira in case.
 
 Perharps what we are doing is wrong ? I really don't know...
 
 Thanks.
 
 
 --
 Tony Chemit
 
 tél: +33 (0) 2 40 50 29 28
 email: che...@codelutin.com
 http://www.codelutin.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties in assembly plugin

[Andreas M]

Stefano Nichele-2 wrote:
 
 Hi All,
 in my assembly file I have several fileSets sections and some of them 
 are used to copy some files under PATH/lib , others PATH/bin, others 
 in PATH/licenses. My issue is the I'd like to have PATH configured 
 just in one place and not replicated in all fileSets sections.
 
 Is there a way to set in once in the assembly file or in the pom.xml as 
 configuration property ?
 
 Thanks in advance
 ste
 

Well, I reference ${project.build.directory} with no problems in my
assembly.xml, so you should just be able to define a property in your pom
and go with it. 
Does that not work?

/Andreas
-- 
View this message in context: 
http://old.nabble.com/properties-in-assembly-plugin-tp27767079p27767294.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties in assembly plugin

[Stefano Nichele]

Thanks and sorry
it was easy ...

ste

On 03/03/2010 12.59, Andreas M wrote:



Stefano Nichele-2 wrote:
   

Hi All,
in my assembly file I have several fileSets sections and some of them
are used to copy some files underPATH/lib , othersPATH/bin, others
inPATH/licenses. My issue is the I'd like to havePATH  configured
just in one place and not replicated in all fileSets sections.

Is there a way to set in once in the assembly file or in the pom.xml as
configuration property ?

Thanks in advance
ste

 

Well, I reference ${project.build.directory} with no problems in my
assembly.xml, so you should just be able to define a property in your pom
and go with it.
Does that not work?

/Andreas
   



--
Stefano Nichele

Funambol Chief Architect
Funambol :: Open Source Mobile Cloud Sync and Push Email



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties in settings.xml

[James Russo]

Hello,

	Yes, it is. I've found that putting the real path in the pom.xml  
works fine, but I can't use a variable as the path.  The problem I  
have with putting it in the pom makes the pom very specific rather  
then the settings.xml.


I'm open for other suggestions on how to accomplish the same thing.  
Basically a profile which defines the build rules for NSIS installer  
should only be run when a path to NSIS is defined in the settings.xml  
file for the environment.


thanks,

-jr

On Nov 14, 2009, at 9:20 AM, Sony Antony wrote:


The file,exists block was inside activation right ?

profiles
profile
...
activation
fileexists${nsis.path}/exists/file
/activation

...
profile
profiles



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: properties in settings.xml

[Martin Gainty]

i dont believe regularexpression parsing is currently available but you can 
modify org.apache.maven.profiles.Activation.java
package org.apache.maven.profiles;
@SuppressWarnings( all )
public class Activation
implements java.io.Serializable
{
/* The conditions within the build runtime environment which will trigger  the 
automatic inclusion of the parent build profile. @version $Revision$ $Date$ */
@SuppressWarnings( all )
/**
 *  Specifies that this profile will be activated based on 
existence of a file.  
 */
private ActivationFile file;

  //---/
 //- Methods -/
//---/

/**
 * Get specifies that this profile will be activated based on
 * existence of a file.
 * @return ActivationFile
 */

/**
 * Set specifies that this profile will be activated based on
 * existence of a file.
 * @param file
 */
public void setFile( ActivationFile file )
{
this.file = file;//*Modify this code to acceept 
a Regular Expression and return a ActivationFile***
} //-- void setFile( ActivationFile )
}

!-- you can implement existsFileNameToTestOn/exists as seen here --
!-- the canonical-buildnumber profile is activated when literal .svn file is 
detected in current folder --
!-- existing exists code which will activate a profile called 
canonical-buildnumber --
profile
  idcanonical-buildnumber/id
  activation
file
  exists.svn/exists
/file
  /activation
  build
plugins
  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuildnumber-maven-plugin/artifactId
version1.0-beta-1/version
executions
  execution
phasegenerate-resources/phase
goals
  goalcreate/goal
/goals
  /execution
/executions
configuration
  doCheckfalse/doCheck
  doUpdatefalse/doUpdate
/configuration
  /plugin
/plugins
  /build
/profile

HTH
Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Sat, 14 Nov 2009 09:20:29 -0500
 Subject: Re: properties in settings.xml
 From: sony.ant...@gmail.com
 To: users@maven.apache.org
 
 The file,exists block was inside activation right ?
 
 profiles
 profile
 ...
 activation
 fileexists${nsis.path}/exists/file
 /activation
 
  ...
 profile
 profiles
 
 --sony
 
 On Fri, Nov 13, 2009 at 10:43 PM, James Russo j...@halo3.net wrote:
 
  Hello,
 
 I have a project which uses nsis to create an installer, but NSIS
  isn't available on all of the platforms which I build the project, and I'd
  like it to skip making the NSIS when the makensis isn't available. I'd like
  to make the path to NSIS be configurable in the ~/.m2/settings.xml, so I add
  it to a default profile which I created having a bunch of other
  properties:
 
 
   profiles
 profile
   iddefault/id
   properties
 
   database.driverClassNameorg.postgresql.Driver/database.driverClassName
 database.urljdbc:postgresql://localhost/test/database.url
 database.useruser/database.user
 database.passwordpassword/database.password
 cargo.tomcat.manager.urlhttp://localhost:8081/manager
  /cargo.tomcat.manager.url
 cargo.remote.usernamemanager/cargo.remote.username
 cargo.remote.passwordpassword/cargo.remote.password
 customer.webapp.context//customer.webapp.context
 client.webapp.context/client/client.webapp.context
 nsis.path/usr/local/nsis/nsis-2.45/bin/makensis/nsis.path
 !--
 Introduced by Hudson, uncomment if not being used via
  hudson.
 BUILD_NUMBERdev-build/BUILD_NUMBER
 SVN_REVISIONunknown/SVN_REVISION
 --
   /properties
 /profile
   /profiles
 
  So, I have a nsis.path defined

Re: properties in settings.xml

[James Russo]

Hello,

	I'd rather not have to modify Maven for this. I'm also not looking  
for regular expressions, but rather just interpolation of the  
variables defined by other profiles. I guess the problem is the order  
in which the profiles are defined?


Is there a way to set a variable without using a activate by default  
profile in settings.xml?


-jr



On Nov 14, 2009, at 10:06 AM, Martin Gainty wrote:



i dont believe regularexpression parsing is currently available  
but you can modify org.apache.maven.profiles.Activation.java



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties in settings.xml

[Jörg Schaible]

James Russo wrote:

 Hello,
 
 Yes, it is. I've found that putting the real path in the pom.xml
 works fine, but I can't use a variable as the path.  The problem I
 have with putting it in the pom makes the pom very specific rather
 then the settings.xml.
 
 I'm open for other suggestions on how to accomplish the same thing.
 Basically a profile which defines the build rules for NSIS installer
 should only be run when a path to NSIS is defined in the settings.xml
 file for the environment.

Activate the nsis profile in your settings.xml and use the same profile id
(without an activation element) in your POM.

- Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties in settings.xml

[James Russo]

Activate the nsis profile in your settings.xml and use the same  
profile id

(without an activation element) in your POM.


Perfect. I'm going to go this route.

-jr

Re: Properties file in Maven

[Anders Hammar]

No, not in core Maven. However, I found this plugin:
http://haroon.sis.utoronto.ca/zarar/properties-maven-plugin/

However, if you want to use properties in resource files the resource plugin
can handle external files when doing the filtering:
http://maven.apache.org/plugins/maven-resources-plugin/index.html

/Anders

On Tue, Oct 27, 2009 at 10:01, Sethuraman, Nirmala (NSN - IN/Bangalore) 
nirmala.sethura...@nsn.com wrote:

 Hi

 I am a new user of Maven. I have been looking for using external
 property files in Maven. However I couldn't find any.
 Does maven provide this option (like ANT) for using an external property
 file?

 Best Regards
 Nirmala

Re: properties references

[Anders Hammar]

Out of a logical (design) perspective that sounds weird. The parent
shouldn't have any dependency on the siblings; it's the other way around.
Are you talking about a parent project or an aggregating project?

/Anders

On Tue, Sep 15, 2009 at 10:39, Valentin Jacquemin jacquem...@gmail.comwrote:

 Hi,

 I created a maven structure with a parent pom and for the moment 2 modules
 (web, ejb). I was wondering whether it's possible to references properties
 of those underdeath modules from the parent pom?

 Something like ${modules.ejb.build.directory}... Is there a reference on
 this topic? I were not able to find anything on that subject the maven
 site

 Thanks, regards

 Valentin Jacquemin

Re: properties references

[Valentin Jacquemin]

Here is my structure:

pom
 | ejb
 |  |- pom
 |web
|- pom

In parent pom i use the glassfish plugin to deploy each artifact produced
(ejb, web). In the glassfish plugin i have to specify each component to
deploy and I wanted to fetch the build directory, project name for each one
but I am not able til now I use the glassfish plugin in the parent
because every component will be deployed in the same domain, thus i can set
only once the glassfish instance config...

This may sound weird for sure... I am open for better solutions.

Valentin Jacquemin


On Tue, Sep 15, 2009 at 10:52 AM, Anders Hammar and...@hammar.net wrote:

 Out of a logical (design) perspective that sounds weird. The parent
 shouldn't have any dependency on the siblings; it's the other way around.
 Are you talking about a parent project or an aggregating project?

 /Anders

 On Tue, Sep 15, 2009 at 10:39, Valentin Jacquemin jacquem...@gmail.com
 wrote:

  Hi,
 
  I created a maven structure with a parent pom and for the moment 2
 modules
  (web, ejb). I was wondering whether it's possible to references
 properties
  of those underdeath modules from the parent pom?
 
  Something like ${modules.ejb.build.directory}... Is there a reference on
  this topic? I were not able to find anything on that subject the maven
  site
 
  Thanks, regards
 
  Valentin Jacquemin
 

Re: properties references

[Anders Hammar]

What you have is an aggregating pom, which happens to be the parent pom as
well (I guess).
Why not create a separate project that does the deployment? It should have
dependencies on the artifacts that you want to deploy. You shouldn't
configure the glassfish deploy plugin to use a build/target folder of
another project but you should get the artifact from local/remote repo. I'm
not familiar with the glassfish plugin so I don't know if it can do that
itself or if you need to use the dependency plugin as well to fetch the
artifact first.

Or you could have the glassfish plugin in each project deploying that
project's artifact. Common configuration for the plugin could be handled in
the parent through pluginManagement. I very much boils down to why you're
doing the deployment. Is it part of integration test for instance? Or is it
some kind of feature for developers to easily get it deployed?

/Anders

On Tue, Sep 15, 2009 at 11:01, Valentin Jacquemin jacquem...@gmail.comwrote:

 Here is my structure:

 pom
  | ejb
  |  |- pom
  |web
|- pom

 In parent pom i use the glassfish plugin to deploy each artifact produced
 (ejb, web). In the glassfish plugin i have to specify each component to
 deploy and I wanted to fetch the build directory, project name for each one
 but I am not able til now I use the glassfish plugin in the parent
 because every component will be deployed in the same domain, thus i can set
 only once the glassfish instance config...

 This may sound weird for sure... I am open for better solutions.

 Valentin Jacquemin


 On Tue, Sep 15, 2009 at 10:52 AM, Anders Hammar and...@hammar.net wrote:

  Out of a logical (design) perspective that sounds weird. The parent
  shouldn't have any dependency on the siblings; it's the other way around.
  Are you talking about a parent project or an aggregating project?
 
  /Anders
 
  On Tue, Sep 15, 2009 at 10:39, Valentin Jacquemin jacquem...@gmail.com
  wrote:
 
   Hi,
  
   I created a maven structure with a parent pom and for the moment 2
  modules
   (web, ejb). I was wondering whether it's possible to references
  properties
   of those underdeath modules from the parent pom?
  
   Something like ${modules.ejb.build.directory}... Is there a reference
 on
   this topic? I were not able to find anything on that subject the maven
   site
  
   Thanks, regards
  
   Valentin Jacquemin
  
 

Re: properties references

[Valentin Jacquemin]

Or is it
some kind of feature for developers to easily get it deployed?

No no it's only a personal prototype that i am creating on my own... I am
not really accustomed to maven yet.

Creating a separate project for the deployment could be the way for me.

Thanks!

Valentin Jacquemin


On Tue, Sep 15, 2009 at 11:09 AM, Anders Hammar and...@hammar.net wrote:

 What you have is an aggregating pom, which happens to be the parent pom as
 well (I guess).
 Why not create a separate project that does the deployment? It should have
 dependencies on the artifacts that you want to deploy. You shouldn't
 configure the glassfish deploy plugin to use a build/target folder of
 another project but you should get the artifact from local/remote repo. I'm
 not familiar with the glassfish plugin so I don't know if it can do that
 itself or if you need to use the dependency plugin as well to fetch the
 artifact first.

 Or you could have the glassfish plugin in each project deploying that
 project's artifact. Common configuration for the plugin could be handled in
 the parent through pluginManagement. I very much boils down to why you're
 doing the deployment. Is it part of integration test for instance? Or is it
 some kind of feature for developers to easily get it deployed?

 /Anders

 On Tue, Sep 15, 2009 at 11:01, Valentin Jacquemin jacquem...@gmail.com
 wrote:

  Here is my structure:
 
  pom
   | ejb
   |  |- pom
   |web
 |- pom
 
  In parent pom i use the glassfish plugin to deploy each artifact produced
  (ejb, web). In the glassfish plugin i have to specify each component to
  deploy and I wanted to fetch the build directory, project name for each
 one
  but I am not able til now I use the glassfish plugin in the parent
  because every component will be deployed in the same domain, thus i can
 set
  only once the glassfish instance config...
 
  This may sound weird for sure... I am open for better solutions.
 
  Valentin Jacquemin
 
 
  On Tue, Sep 15, 2009 at 10:52 AM, Anders Hammar and...@hammar.net
 wrote:
 
   Out of a logical (design) perspective that sounds weird. The parent
   shouldn't have any dependency on the siblings; it's the other way
 around.
   Are you talking about a parent project or an aggregating project?
  
   /Anders
  
   On Tue, Sep 15, 2009 at 10:39, Valentin Jacquemin 
 jacquem...@gmail.com
   wrote:
  
Hi,
   
I created a maven structure with a parent pom and for the moment 2
   modules
(web, ejb). I was wondering whether it's possible to references
   properties
of those underdeath modules from the parent pom?
   
Something like ${modules.ejb.build.directory}... Is there a reference
  on
this topic? I were not able to find anything on that subject the
 maven
site
   
Thanks, regards
   
Valentin Jacquemin
   
  
 

Re: properties references

[Valentin Jacquemin]

I created a pom dedicated for the deployment and declared dependencies on my
ejb/web projects but now how can I reference the artifact in the repository
from glassfish-plugin elements?

I am a beginner sorry...

Valentin Jacquemin


On Tue, Sep 15, 2009 at 11:15 AM, Valentin Jacquemin
jacquem...@gmail.comwrote:

 Or is it
 some kind of feature for developers to easily get it deployed?

 No no it's only a personal prototype that i am creating on my own... I am
 not really accustomed to maven yet.

 Creating a separate project for the deployment could be the way for me.

 Thanks!

 Valentin Jacquemin



 On Tue, Sep 15, 2009 at 11:09 AM, Anders Hammar and...@hammar.net wrote:

 What you have is an aggregating pom, which happens to be the parent pom as
 well (I guess).
 Why not create a separate project that does the deployment? It should have
 dependencies on the artifacts that you want to deploy. You shouldn't
 configure the glassfish deploy plugin to use a build/target folder of
 another project but you should get the artifact from local/remote repo.
 I'm
 not familiar with the glassfish plugin so I don't know if it can do that
 itself or if you need to use the dependency plugin as well to fetch the
 artifact first.

 Or you could have the glassfish plugin in each project deploying that
 project's artifact. Common configuration for the plugin could be handled
 in
 the parent through pluginManagement. I very much boils down to why you're
 doing the deployment. Is it part of integration test for instance? Or is
 it
 some kind of feature for developers to easily get it deployed?

 /Anders

 On Tue, Sep 15, 2009 at 11:01, Valentin Jacquemin jacquem...@gmail.com
 wrote:

  Here is my structure:
 
  pom
   | ejb
   |  |- pom
   |web
 |- pom
 
  In parent pom i use the glassfish plugin to deploy each artifact
 produced
  (ejb, web). In the glassfish plugin i have to specify each component to
  deploy and I wanted to fetch the build directory, project name for each
 one
  but I am not able til now I use the glassfish plugin in the parent
  because every component will be deployed in the same domain, thus i can
 set
  only once the glassfish instance config...
 
  This may sound weird for sure... I am open for better solutions.
 
  Valentin Jacquemin
 
 
  On Tue, Sep 15, 2009 at 10:52 AM, Anders Hammar and...@hammar.net
 wrote:
 
   Out of a logical (design) perspective that sounds weird. The parent
   shouldn't have any dependency on the siblings; it's the other way
 around.
   Are you talking about a parent project or an aggregating project?
  
   /Anders
  
   On Tue, Sep 15, 2009 at 10:39, Valentin Jacquemin 
 jacquem...@gmail.com
   wrote:
  
Hi,
   
I created a maven structure with a parent pom and for the moment 2
   modules
(web, ejb). I was wondering whether it's possible to references
   properties
of those underdeath modules from the parent pom?
   
Something like ${modules.ejb.build.directory}... Is there a
 reference
  on
this topic? I were not able to find anything on that subject the
 maven
site
   
Thanks, regards
   
Valentin Jacquemin
   
  
 

Re: properties references

[Anders Hammar]

I'm not familiar with the glassfish plugin. Eitehr the plugin has built in
support for using an artifact dependency or you have to use the dependency
plugin to first fetch the (jar) artifact and then point the glassfish plugin
to use that jar.

dependency plugin goal:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html

/Anders

On Tue, Sep 15, 2009 at 11:28, Valentin Jacquemin jacquem...@gmail.comwrote:

 I created a pom dedicated for the deployment and declared dependencies on
 my
 ejb/web projects but now how can I reference the artifact in the repository
 from glassfish-plugin elements?

 I am a beginner sorry...

 Valentin Jacquemin


 On Tue, Sep 15, 2009 at 11:15 AM, Valentin Jacquemin
 jacquem...@gmail.comwrote:

  Or is it
  some kind of feature for developers to easily get it deployed?
 
  No no it's only a personal prototype that i am creating on my own... I am
  not really accustomed to maven yet.
 
  Creating a separate project for the deployment could be the way for me.
 
  Thanks!
 
  Valentin Jacquemin
 
 
 
  On Tue, Sep 15, 2009 at 11:09 AM, Anders Hammar and...@hammar.net
 wrote:
 
  What you have is an aggregating pom, which happens to be the parent pom
 as
  well (I guess).
  Why not create a separate project that does the deployment? It should
 have
  dependencies on the artifacts that you want to deploy. You shouldn't
  configure the glassfish deploy plugin to use a build/target folder of
  another project but you should get the artifact from local/remote repo.
  I'm
  not familiar with the glassfish plugin so I don't know if it can do that
  itself or if you need to use the dependency plugin as well to fetch the
  artifact first.
 
  Or you could have the glassfish plugin in each project deploying that
  project's artifact. Common configuration for the plugin could be handled
  in
  the parent through pluginManagement. I very much boils down to why
 you're
  doing the deployment. Is it part of integration test for instance? Or is
  it
  some kind of feature for developers to easily get it deployed?
 
  /Anders
 
  On Tue, Sep 15, 2009 at 11:01, Valentin Jacquemin jacquem...@gmail.com
  wrote:
 
   Here is my structure:
  
   pom
| ejb
|  |- pom
|web
  |- pom
  
   In parent pom i use the glassfish plugin to deploy each artifact
  produced
   (ejb, web). In the glassfish plugin i have to specify each component
 to
   deploy and I wanted to fetch the build directory, project name for
 each
  one
   but I am not able til now I use the glassfish plugin in the parent
   because every component will be deployed in the same domain, thus i
 can
  set
   only once the glassfish instance config...
  
   This may sound weird for sure... I am open for better solutions.
  
   Valentin Jacquemin
  
  
   On Tue, Sep 15, 2009 at 10:52 AM, Anders Hammar and...@hammar.net
  wrote:
  
Out of a logical (design) perspective that sounds weird. The parent
shouldn't have any dependency on the siblings; it's the other way
  around.
Are you talking about a parent project or an aggregating project?
   
/Anders
   
On Tue, Sep 15, 2009 at 10:39, Valentin Jacquemin 
  jacquem...@gmail.com
wrote:
   
 Hi,

 I created a maven structure with a parent pom and for the moment 2
modules
 (web, ejb). I was wondering whether it's possible to references
properties
 of those underdeath modules from the parent pom?

 Something like ${modules.ejb.build.directory}... Is there a
  reference
   on
 this topic? I were not able to find anything on that subject the
  maven
 site

 Thanks, regards

 Valentin Jacquemin

   
  
 
 
 

Re: Properties conditional on phase?

[Stephen Connolly]

tell us a bit more about *why* you think you need to do this and we  
might be able to point you towards tge maven way


Sent from my [rhymes with myPod] ;-)

On 24 Jul 2009, at 18:17, Mark H. Wood mw...@iupui.edu wrote:


I want to have a property defined only during certain phases -- I
want to make certain that it doesn't leak out into the packaging, for
example.  Is there a way to do that?

--
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Friends don't let friends publish revisable-form documents.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: properties vs pluginManagement

[Jörg Schaible]

Hi Jim,

Jim Sellers wrote at Donnerstag, 14. Mai 2009 22:37:

 Hi all.
 
 I've got a question for how to best configure plugins in a corporate
 parent
 pom.  One way is to configure the plug in the pluginManagement section,
 the other is to use the properties that the plugin uses.
 
 eg.
   build
 pluginManagement
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-eclipse-plugin/artifactId
   configuration
 wtpmanifesttrue/wtpmanifest
 wtpapplicationxmltrue/wtpapplicationxml
 wtpversion2.0/wtpversion
   /configuration
 /plugin
   /plugins
 /pluginManagement
   /build
 
 vs
 
   properties
 !-- WTP properties used by the maven-eclipse-plugin --
 eclipse.wtpmanifesttrue/eclipse.wtpmanifest
 eclipse.wtpapplicationxmltrue/eclipse.wtpapplicationxml
 wtpversion2.0/wtpversion
   /properties
 
 Is there any advantage of one over the other?

You're comparing apples and pears. An entry in the pluginManagement simply
defines the default configuration that is used, if somebody uses that
plugin in his build. Actually we're combining both methods (well, not for
the version, but for important configuration elements), so you're able to
influence the default configuration by overriding a property definition
with a local entry.

Play with help:effective-pom to see the results.

- Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: properties vs pluginManagement

[Bryan Loofbourrow]

-Original Message-
From: Jim Sellers [mailto:jim.sell...@gmail.com]
Sent: Thursday, May 14, 2009 1:38 PM
To: Maven Users List
Subject: properties vs pluginManagement

Hi all.

I've got a question for how to best configure plugins in a corporate
parent
pom.  One way is to configure the plug in the pluginManagement section,
the
other is to use the properties that the plugin uses.
snip


I strongly prefer the pluginManagement approach. For one thing, it makes
very clear that the property is intended for a plugin, and what plugin
it's intended for, instead of leaving you guessing. Imagine that you
were using the properties approach for a couple years, then someone
handed you the job of eliminating the properties that weren't being
used.

-- Bryan



This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Properties: backslashes in pathname on Windows

[Sean Hennessy]

 ant's ${file.separator} ??

-Original Message-
From: stug23 [mailto:pat.poden...@gmail.com]
Sent: Thursday, April 23, 2009 8:56 PM
To: users@maven.apache.org
Subject: Properties: backslashes in pathname on Windows



Is there a way in Maven 2.0.9 to end up with forward slashes in a 
file/directory pathname on the Windows platform when filtering a property such 
as ${project.parent.basedir}?

I need to supply a file URL for a Hibernate URL specified in a persistence.xml 
configuraton file. The following property statement from a persistence.xml file 
gets filtered as a resource file from src/test/resources into the test-classes 
directory under target.

However on Windows the pathname ends up including backslashes which don't play 
well with Hibernate. The JPA hibernate entity manager cannot resolve a URL with 
backslashes in it.

The XML element in questions looks more or less like this:

property name=hibernate.connection.url 
value=jdbc:hsqldb:file:///${project.parent.basedir}/target/hsql/testdb/

Suggestions on how to accomplish this would be appreciated.

TIA!

--
View this message in context: 
http://www.nabble.com/Properties%3A-backslashes-in-pathname-on-Windows-tp23209361p23209361.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties: backslashes in pathname on Windows

[stug23]

I found a Maven plugin at Google that can replace tokens which I applied to
the filtered xml file.

This does remove the backslashes, however I think a much better solution
would be for Maven to have a simple and direct means of obtaining a file:URL
with correct form via a Maven project property.

Perhaps something like ${project.parent.basedir.url}? At this stage a
feature such as this might be more relevant as a Maven 3.0 addition?

Here is an example of using the maven-replacer-plugin configuration that can
replace tokens:

plugin
groupIdbakersoftware/groupId
artifactIdmaven-replacer-plugin/artifactId
version0.0.9/version
executions
execution
phasetest-compile/phase
goals
goalreplace/goal
/goals
configuration
filetarget/test-classes/persistence.xml/file
token\\/token
value//value
/configuration
/execution
/executions
/plugin


stug23 wrote:
 
 Is there a way in Maven 2.0.9 to end up with forward slashes in a
 file/directory pathname on the Windows platform when filtering a property
 such as ${project.parent.basedir}?
 
 I need to supply a file URL for a Hibernate URL specified in a
 persistence.xml configuraton file. The following property statement from a
 persistence.xml file gets filtered as a resource file from
 src/test/resources into the test-classes directory under target.
 
 However on Windows the pathname ends up including backslashes which don't
 play well with Hibernate. The JPA hibernate entity manager cannot resolve
 a URL with backslashes in it.
 
 The XML element in questions looks more or less like this:
 
 property name=hibernate.connection.url
 value=jdbc:hsqldb:file:///${project.parent.basedir}/target/hsql/testdb/
 
 Suggestions on how to accomplish this would be appreciated.
 
 TIA!
 
 

-- 
View this message in context: 
http://www.nabble.com/Properties%3A-backslashes-in-pathname-on-Windows-tp23209361p23219538.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties files proper location

[Markos Fragkakis]

Markos Fragkakis wrote:

Hi,

I am having some problems that I expected to be common, however I 
could not find a solution online for either.


I want create a maven project for a swing application. My IDE is 
Eclipse. In order to run, the application needs to read a a couple of 
text configuration files, which are located in a params directory, 
in the root directory of the application. So, if ${root} id the 
application directory, these files should be in ${root}/params. 
Furthermore, the application needs to log into the directory ${root}/log.


Until now, without Maven, I had created the directories params and log 
(log was in .cvsignore) in my Eclipse project directory. Every time 
the project was run, the two directories were found and used.


Now, Maven puts its classes in target/classes. In order to run the 
project from within the IDE, I have put the two directories in the 
resources directory. So, when I compile the project, they are put 
inside the target directory, along with the classes and everything 
works. This placing, however, will put them also in the jar file of 
the project, which I would not like, since the configuration files in 
the params directory are supposed to be changes by the user.


What is the correct (by-the-book) placing of the files if I need to be 
able run my project as before, from within the IDE? Are there any 
additional steps, like using the assembly plugin to create the 
directory structure?


This is probably a best practices issue.

Any suggestions / ideas are welcome.

Best regards,
Markos Fragkakis

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Any suggestions? I believe this  is an issue other people have as well, 
and many would benefit if solutions, or even a discussion is documented.


Thanks,

Markos Fragkakis

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties files proper location

[Stevo Slavić]

Hello Markos,

Maybe you could place fail-safe-params.properties with default settings
within jar, thus within src/main/resources, and support them to be
overridden by user using external params.properties file.

Regards,
Stevo.

On Sat, Apr 18, 2009 at 2:52 PM, Markos Fragkakis 
markos.fragka...@agilis-sa.gr wrote:

 Markos Fragkakis wrote:

 Hi,

 I am having some problems that I expected to be common, however I could
 not find a solution online for either.

 I want create a maven project for a swing application. My IDE is Eclipse.
 In order to run, the application needs to read a a couple of text
 configuration files, which are located in a params directory, in the root
 directory of the application. So, if ${root} id the application directory,
 these files should be in ${root}/params. Furthermore, the application needs
 to log into the directory ${root}/log.

 Until now, without Maven, I had created the directories params and log
 (log was in .cvsignore) in my Eclipse project directory. Every time the
 project was run, the two directories were found and used.

 Now, Maven puts its classes in target/classes. In order to run the project
 from within the IDE, I have put the two directories in the resources
 directory. So, when I compile the project, they are put inside the target
 directory, along with the classes and everything works. This placing,
 however, will put them also in the jar file of the project, which I would
 not like, since the configuration files in the params directory are supposed
 to be changes by the user.

 What is the correct (by-the-book) placing of the files if I need to be
 able run my project as before, from within the IDE? Are there any additional
 steps, like using the assembly plugin to create the directory structure?

 This is probably a best practices issue.

 Any suggestions / ideas are welcome.

 Best regards,
 Markos Fragkakis

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

  Any suggestions? I believe this  is an issue other people have as well,
 and many would benefit if solutions, or even a discussion is documented.

 Thanks,


 Markos Fragkakis

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Properties files proper location

[David Hoffer]

My take on this is that there is no 'standard' by the book so-to-speak maven
way of doing this.  The standard thing in maven is to create one artifact
per project so its standard to include files, etc in jar but not to
externalize them.  But that doesn't solve your problem.

However, like you suggested, you can add these other resources via the
assembly plugin however there is no standard folder(s) or practices here you
can do what you want.

If there is something more standard than this; I too, would like to know
about it.

-Dave

On Sat, Apr 18, 2009 at 7:12 AM, Stevo Slavić ssla...@gmail.com wrote:

 Hello Markos,

 Maybe you could place fail-safe-params.properties with default settings
 within jar, thus within src/main/resources, and support them to be
 overridden by user using external params.properties file.

 Regards,
 Stevo.

 On Sat, Apr 18, 2009 at 2:52 PM, Markos Fragkakis 
 markos.fragka...@agilis-sa.gr wrote:

  Markos Fragkakis wrote:
 
  Hi,
 
  I am having some problems that I expected to be common, however I could
  not find a solution online for either.
 
  I want create a maven project for a swing application. My IDE is
 Eclipse.
  In order to run, the application needs to read a a couple of text
  configuration files, which are located in a params directory, in the
 root
  directory of the application. So, if ${root} id the application
 directory,
  these files should be in ${root}/params. Furthermore, the application
 needs
  to log into the directory ${root}/log.
 
  Until now, without Maven, I had created the directories params and log
  (log was in .cvsignore) in my Eclipse project directory. Every time the
  project was run, the two directories were found and used.
 
  Now, Maven puts its classes in target/classes. In order to run the
 project
  from within the IDE, I have put the two directories in the resources
  directory. So, when I compile the project, they are put inside the
 target
  directory, along with the classes and everything works. This placing,
  however, will put them also in the jar file of the project, which I
 would
  not like, since the configuration files in the params directory are
 supposed
  to be changes by the user.
 
  What is the correct (by-the-book) placing of the files if I need to be
  able run my project as before, from within the IDE? Are there any
 additional
  steps, like using the assembly plugin to create the directory structure?
 
  This is probably a best practices issue.
 
  Any suggestions / ideas are welcome.
 
  Best regards,
  Markos Fragkakis
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
   Any suggestions? I believe this  is an issue other people have as well,
  and many would benefit if solutions, or even a discussion is documented.
 
  Thanks,
 
 
  Markos Fragkakis
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: properties substitution problem in pom

[Rusty Wright]

I got it to work by being less aggressive about using property placeholders; 
now the dependencyManagement dependencies use a specific groupId and 
artifactId.  Likewise for the dependency section in the cars-download pom.  But 
I'm still confused about why it wasn't working.  It seems like it's not using 
the properties I gave in the profile.


Rusty Wright wrote:

There's something about properties substition that I don't understand.

I'm getting the error about a missing artifact, the coordinates for the 
artifact it's complaining about are


jdbc-groupId-placeholder:jdbc-artifactId-placeholder:jar:version-jdbc-placeholder 



And the path message is

 Path to dependency:
   1) edu.berkeley.ist.cars:cars-war:war:1.1-SNAPSHOT
   2) edu.berkeley.ist.cars:cars-web:jar:1.1-SNAPSHOT
   3) edu.berkeley.ist.cars:cars-download:jar:1.1-SNAPSHOT
   4) 
jdbc-groupId-placeholder:jdbc-artifactId-placeholder:jar:version-jdbc


The cars-web and cars-download are built from a multi module parent pom, 
which contains (along with the usual stuff)


   dependencyManagement
   dependencies
   dependency
   groupId${jdbc.groupId}/groupId
   artifactId${jdbc.artifactId}/artifactId
   version${version.jdbc}/version
   /dependency
   !-- etc. --
   /dependencies
   /dependencyManagement
   properties
   jdbc.groupIdjdbc-groupId-placeholder/jdbc.groupId
   jdbc.artifactIdjdbc-artifactId-placeholder/jdbc.artifactId
   version.jdbcversion-jdbc-placeholder/version.jdbc
   !-- etc. --
   /properties
   profiles
   profile
   idtest/id

   activation
   activeByDefaultfalse/activeByDefault
   /activation

   properties
   jdbc.driverClasscom.mysql.jdbc.Driver/jdbc.driverClass
   jdbc.groupIdmysql/jdbc.groupId
   jdbc.artifactIdmysql-connector-java/jdbc.artifactId
   version.jdbc5.1.6/version.jdbc
   !-- etc. --
   /properties
   /profile
   /profiles

I'm getting the error when I run mvn -Ptest package in the cars-war 
directory.


In the cars-parent directory I did mvn -Ptest clean package install 
and it installed the jars in my ~/.m2 repo.


The cars-war pom.xml only has a dependency on cars-web.

The pom for cars-download contains

   dependency
   groupId${jdbc.groupId}/groupId
   artifactId${jdbc.artifactId}/artifactId
   /dependency

(When I look at the .pom files in my ~/.m2 repo for cars-download and 
the parent they contain the ${} placeholders, not the substituted 
values, which puzzles me.)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: properties in archetypes?

[Chris_Graham]

[EMAIL PROTECTED] wrote on 18/06/2008 16:50:05:

 Can we make use of our own properties/variables in archetypes?
 
 The m2eclipse plugin allows us to define properties to be used at 
arcetype 
 generation time.
 
 The problem is, I've not see a single references as to _how_ to do 
 this!???
 
 For example:
 
 dependency
 groupId${groupId}/groupId
 artifactId${projectName}Web/artifactId
 version1.0-SNAPSHOT/version
 typewar/type
 /dependency
 
 I would like to be able to define the value of the variable projectName, 

 so, if I defined projectName = Blah, it would expand to:
 
 artifactIdBlahWeb/artifactId
 
 -Chris

To answer my own question (with a little help from some - thanks!):

Create a file called archetype-metadata.xml in the 
\src\main\resources\META-INF\maven directory, and put this into it:

?xml version=1.0 encoding=UTF-8?
archetype-descriptor name=basic-ear

fileSets
fileSet filtered=true packaged=false
directory/directory
includes
include**/*/include
/includes
/fileSet
/fileSets

requiredProperties
requiredProperty key=projectName /
/requiredProperties
/archetype-descriptor

That will process and generate what is needed.

Now, when you call the generate stage, you need to define the the property 
projectName as a system property, by defining it as a system property:

mvn archetype:generate
-Darchetype.interactive=false
-DarchetypeCatalog=local
-DarchetypeGroupId=au.com.warpspeed.archetypes
-DarchetypeArtifactId=basic-ear
-DarchetypeVersion=1.0
-DgroupId=au.com.warpspeed.test
-DartifactId=SampleEAR
-Dversion=1.0-SNAPSHOT
-DprojectName=Sample

If you get an error similar to this:

[INFO] 

[ERROR] BUILD FAILURE
[INFO] 

[INFO] : org.apache.maven.archetype.exception.ArchetypeNotConfigured: 
Archetype au.com.warpspeed.archetypes:build:1.0 is
 not configured
Archetype au.com.warpspeed.archetypes:build:1.0 is not configured

Archetype au.com.warpspeed.archetypes:build:1.0 is not configured

It means that the property has not been specified. Hope this helps.

The full doco can be found at:

http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-metadata.html

-Chris


**
CAUTION - This message is intended for the addressee named above. It may 
contain privileged or confidential information. 

If you are not the intended recipient of this message you must: 
- Not use, copy, distribute or disclose it to anyone other than the addressee;
- Notify the sender via return email; and
- Delete the message (and any related attachments) from your computer 
immediately.

Internet emails are not necessarily secure. Australian Associated Motors 
Insurers Limited ABN 92 004 791 744 (AAMI), and its related entities, do not 
accept responsibility for changes made to this message after it was sent.

Unless otherwise stated, views expressed within this email are the author's own 
and do not represent those of AAMI.
**

Re: Properties.

[Bruno Aranda]

Remove all your neurons first and then use:

mvn invest:property

:D  (sorry)

Re: Properties files exclude from jar artifact

[Saloucious]

Sure assembly will unpack properites in conf dir.

But in my assembly, i would like to define a dependency to this module
So finally, i will have my jar artifact with my properties files embded (for
eg in a lib dir)
and my properties files in conf dir (double)



Wayne Fay wrote:
 
 Use dependencies plugin to unpack the properties files into your
 current module so they will be packaged by assembly into the conf dir
 you require.
 
 Wayne
 
 On 11/9/07, Saloucious [EMAIL PROTECTED] wrote:

 So if  i package properties file into my jars, how can I create finally
 an
 assembly which create a deploy/conf dir with all properties from jar.

 We put all properties into this dir because it is easiest to patch it.





 Wayne Fay wrote:
 
  No such all classifier exists. You must specify each dependency.
 
  Wayne
 
  On 11/6/07, Saloucious [EMAIL PROTECTED] wrote:
 
  Ok, but is it possible to get jar artifact and properties artifact in
 one
  dependency decalaration:
 
  For example, I deploy module1 with jar artifact and properties
 artifact
 
  and in a module2, i declare a dependency  with module1
  Is Maven able to retrieve 2 artifacts (for example with a
  classifierALL/classifier or something like that)
 
  dependency
  groupidmygroup/groupid
  artifactidmodule1/artifactid
  /dependency
 
  Otherwise i must declare 2 dependencies by module, one for binaries
 files
  and one for properties files...
 
 
  Wayne Fay wrote:
  
   You could make another artifact (jar) that consists only of
 properties
   files that are jar'ed together and deploy it into your repo.
  
   Wayne
  
   On 10/26/07, Saloucious [EMAIL PROTECTED] wrote:
  
   Hi,
  
   Acutally, i'm working on a migration from Ant to Maven.
   The old Ant script creates for each project a  jar and  copy
  properties
   files in a deploy dir.
   So these properties file are not embeded in jar.
  
   Now i'm on Maven,
   If I excludes files from jar, they will not be in repository
   I don't find the way to be able to not embed properties file from
 jar
  and
   install them in repo.
   --
   View this message in context:
  
 
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13429857
   Sent from the Maven - Users mailing list archive at Nabble.com.
  
  
  
 -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
 -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
  --
  View this message in context:
 
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13616078
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13669183
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13708126
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties files exclude from jar artifact

[Saloucious]

So if  i package properties file into my jars, how can I create finally an
assembly which create a deploy/conf dir with all properties from jar.

We put all properties into this dir because it is easiest to patch it.





Wayne Fay wrote:
 
 No such all classifier exists. You must specify each dependency.
 
 Wayne
 
 On 11/6/07, Saloucious [EMAIL PROTECTED] wrote:

 Ok, but is it possible to get jar artifact and properties artifact in one
 dependency decalaration:

 For example, I deploy module1 with jar artifact and properties artifact

 and in a module2, i declare a dependency  with module1
 Is Maven able to retrieve 2 artifacts (for example with a
 classifierALL/classifier or something like that)

 dependency
 groupidmygroup/groupid
 artifactidmodule1/artifactid
 /dependency

 Otherwise i must declare 2 dependencies by module, one for binaries files
 and one for properties files...


 Wayne Fay wrote:
 
  You could make another artifact (jar) that consists only of properties
  files that are jar'ed together and deploy it into your repo.
 
  Wayne
 
  On 10/26/07, Saloucious [EMAIL PROTECTED] wrote:
 
  Hi,
 
  Acutally, i'm working on a migration from Ant to Maven.
  The old Ant script creates for each project a  jar and  copy
 properties
  files in a deploy dir.
  So these properties file are not embeded in jar.
 
  Now i'm on Maven,
  If I excludes files from jar, they will not be in repository
  I don't find the way to be able to not embed properties file from jar
 and
  install them in repo.
  --
  View this message in context:
 
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13429857
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13616078
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13669183
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties files exclude from jar artifact

[Wayne Fay]

Use dependencies plugin to unpack the properties files into your
current module so they will be packaged by assembly into the conf dir
you require.

Wayne

On 11/9/07, Saloucious [EMAIL PROTECTED] wrote:

 So if  i package properties file into my jars, how can I create finally an
 assembly which create a deploy/conf dir with all properties from jar.

 We put all properties into this dir because it is easiest to patch it.





 Wayne Fay wrote:
 
  No such all classifier exists. You must specify each dependency.
 
  Wayne
 
  On 11/6/07, Saloucious [EMAIL PROTECTED] wrote:
 
  Ok, but is it possible to get jar artifact and properties artifact in one
  dependency decalaration:
 
  For example, I deploy module1 with jar artifact and properties artifact
 
  and in a module2, i declare a dependency  with module1
  Is Maven able to retrieve 2 artifacts (for example with a
  classifierALL/classifier or something like that)
 
  dependency
  groupidmygroup/groupid
  artifactidmodule1/artifactid
  /dependency
 
  Otherwise i must declare 2 dependencies by module, one for binaries files
  and one for properties files...
 
 
  Wayne Fay wrote:
  
   You could make another artifact (jar) that consists only of properties
   files that are jar'ed together and deploy it into your repo.
  
   Wayne
  
   On 10/26/07, Saloucious [EMAIL PROTECTED] wrote:
  
   Hi,
  
   Acutally, i'm working on a migration from Ant to Maven.
   The old Ant script creates for each project a  jar and  copy
  properties
   files in a deploy dir.
   So these properties file are not embeded in jar.
  
   Now i'm on Maven,
   If I excludes files from jar, they will not be in repository
   I don't find the way to be able to not embed properties file from jar
  and
   install them in repo.
   --
   View this message in context:
  
  http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13429857
   Sent from the Maven - Users mailing list archive at Nabble.com.
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
 
  --
  View this message in context:
  http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13616078
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13669183
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties files exclude from jar artifact

[Wayne Fay]

No such all classifier exists. You must specify each dependency.

Wayne

On 11/6/07, Saloucious [EMAIL PROTECTED] wrote:

 Ok, but is it possible to get jar artifact and properties artifact in one
 dependency decalaration:

 For example, I deploy module1 with jar artifact and properties artifact

 and in a module2, i declare a dependency  with module1
 Is Maven able to retrieve 2 artifacts (for example with a
 classifierALL/classifier or something like that)

 dependency
 groupidmygroup/groupid
 artifactidmodule1/artifactid
 /dependency

 Otherwise i must declare 2 dependencies by module, one for binaries files
 and one for properties files...


 Wayne Fay wrote:
 
  You could make another artifact (jar) that consists only of properties
  files that are jar'ed together and deploy it into your repo.
 
  Wayne
 
  On 10/26/07, Saloucious [EMAIL PROTECTED] wrote:
 
  Hi,
 
  Acutally, i'm working on a migration from Ant to Maven.
  The old Ant script creates for each project a  jar and  copy properties
  files in a deploy dir.
  So these properties file are not embeded in jar.
 
  Now i'm on Maven,
  If I excludes files from jar, they will not be in repository
  I don't find the way to be able to not embed properties file from jar and
  install them in repo.
  --
  View this message in context:
  http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13429857
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13616078
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties files exclude from jar artifact

[Saloucious]

Ok, but is it possible to get jar artifact and properties artifact in one
dependency decalaration:

For example, I deploy module1 with jar artifact and properties artifact

and in a module2, i declare a dependency  with module1
Is Maven able to retrieve 2 artifacts (for example with a
classifierALL/classifier or something like that)

dependency
groupidmygroup/groupid
artifactidmodule1/artifactid
/dependency

Otherwise i must declare 2 dependencies by module, one for binaries files
and one for properties files...


Wayne Fay wrote:
 
 You could make another artifact (jar) that consists only of properties
 files that are jar'ed together and deploy it into your repo.
 
 Wayne
 
 On 10/26/07, Saloucious [EMAIL PROTECTED] wrote:

 Hi,

 Acutally, i'm working on a migration from Ant to Maven.
 The old Ant script creates for each project a  jar and  copy properties
 files in a deploy dir.
 So these properties file are not embeded in jar.

 Now i'm on Maven,
 If I excludes files from jar, they will not be in repository
 I don't find the way to be able to not embed properties file from jar and
 install them in repo.
 --
 View this message in context:
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13429857
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13616078
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties files exclude from jar artifact

[Wayne Fay]

You could make another artifact (jar) that consists only of properties
files that are jar'ed together and deploy it into your repo.

Wayne

On 10/26/07, Saloucious [EMAIL PROTECTED] wrote:

 Hi,

 Acutally, i'm working on a migration from Ant to Maven.
 The old Ant script creates for each project a  jar and  copy properties
 files in a deploy dir.
 So these properties file are not embeded in jar.

 Now i'm on Maven,
 If I excludes files from jar, they will not be in repository
 I don't find the way to be able to not embed properties file from jar and
 install them in repo.
 --
 View this message in context: 
 http://www.nabble.com/Properties-files-exclude-from-jar-artifact-tf4698085s177.html#a13429857
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: properties in settings.xml

[Insitu]

Huang, Yan [EMAIL PROTECTED] writes:

 Hi,

 I noticed that the install phase does not resolve the properties that
 are defined in settings.xml. For example, I use a property in my
 settings.xml to define the release version:

 profile
   idDefaultProfile/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
   myversion1.1.1.1/myversion
   /properties
 /profile


 Now, I have a pom that access that property:

   groupIdmyexample.myexample/groupId
   artifactIdfoo1/artifactId
   version${myversion}/version

 When I run mvn install, it does creat and install foo1-1.1.1.1.jar in
 my local repo in ~/.m2/repository/myexample/ However, when I look at
 the foo1-1.1.1.1.pom file, the version tag is not resolved and instead
 it still refers to ${myversion}. Is it a problem?

AFAIK this is perfectly normal: The deployed .pom file is the actual
pom of the project without any modification. You can find the
effective pom (ie. the one used to build the artifact) inside the
META-INF/ directory of the jar. 

The rationale behind this (speaking within control of more knowledgeable
maven developers) is that the deployed pom can be used as a dependency
to construct another pom withing another process, where the variables
would need to be instantiated to other values according to
settings/profiles/whatever. 

HTH
-- 
OQube  software engineering \ génie logiciel 
Arnaud Bailly, Dr.
\web http://www.oqube.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: properties in settings.xml

[Michael McCallum]

why would you specify your version outside of source control... you will no 
consistency acros difference machines/developers?

On Wednesday 12 September 2007 19:04, Huang, Yan wrote:
 Hi,

 I noticed that the install phase does not resolve the properties that
 are defined in settings.xml. For example, I use a property in my
 settings.xml to define the release version:

 profile
   idDefaultProfile/id
   properties
   myversion1.1.1.1/myversion
   /properties
 /profile


 Now, I have a pom that access that property:

   groupIdmyexample.myexample/groupId
   artifactIdfoo1/artifactId
   version${myversion}/version


-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Re: properties in settings.xml

[Huang, Yan]

Will the deploy phase actually resolve this version property? Or I have to go 
through maven release plug-in?

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu
Sent: Wednesday, September 12, 2007 12:13 AM
To: users@maven.apache.org
Subject: Re: properties in settings.xml

Huang, Yan [EMAIL PROTECTED] writes:

 Hi,

 I noticed that the install phase does not resolve the properties that
 are defined in settings.xml. For example, I use a property in my
 settings.xml to define the release version:

 profile
   idDefaultProfile/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
   myversion1.1.1.1/myversion
   /properties
 /profile


 Now, I have a pom that access that property:

   groupIdmyexample.myexample/groupId
   artifactIdfoo1/artifactId
   version${myversion}/version

 When I run mvn install, it does creat and install foo1-1.1.1.1.jar in
 my local repo in ~/.m2/repository/myexample/ However, when I look at
 the foo1-1.1.1.1.pom file, the version tag is not resolved and instead
 it still refers to ${myversion}. Is it a problem?

AFAIK this is perfectly normal: The deployed .pom file is the actual
pom of the project without any modification. You can find the
effective pom (ie. the one used to build the artifact) inside the
META-INF/ directory of the jar. 

The rationale behind this (speaking within control of more knowledgeable
maven developers) is that the deployed pom can be used as a dependency
to construct another pom withing another process, where the variables
would need to be instantiated to other values according to
settings/profiles/whatever. 

HTH
-- 
OQube  software engineering \ génie logiciel 
Arnaud Bailly, Dr.
\web http://www.oqube.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: properties

[Eric Redmond]

On 8/10/07, John Coleman [EMAIL PROTECTED] wrote:

 Hi,



 How do I return the value of the active profiles id as a property in my
 pom.xml.


Add a property to each profile with a specific property name (eg:

Profile 'dev':
properties
  active.profiledev/active.profile
/properties

Profile 'test':
properties
  active.profiletest/active.profile
/properties

How do I override the property values in profiles.xml on a per
 user basis?


Same way - you'll just have to manually create the custom profiles.xml.
Well, script it at least.

I thought I could put them in ${user.home}/build.properties,
 but that seems not to work?!


No idea.

-- 
Eric Redmond
http://blog.propellors.net

TIA

 John




 Eurobase International Limited and its subsidiaries (Eurobase) are unable
 to exercise control over the content of information in E-Mails. Any views
 and opinions expressed may be personal to the sender and are not necessarily
 those of Eurobase. Eurobase will not enter into any contractual obligations
 in respect of any part of its business in any E-mail.

 Privileged / confidential information may be contained in this message and
 /or any attachments. This E-mail is intended for the use of the addressee(s)
 only and may contain confidential information. If you are not the / an
 intended recipient, you are hereby notified that any use or dissemination of
 this communication is strictly prohibited.  If you receive this transmission
 in error, please notify us immediately, and then delete this E-mail.

 Neither the sender nor Eurobase accepts any liability whatsoever for any
 defects of any kind either in or arising from this E-mail transmission.
 E-Mail transmission cannot be guaranteed to be secure or error-free, as
 messages can be intercepted, lost, corrupted, destroyed, contain viruses, or
 arrive late or incomplete. Eurobase does not accept any responsibility for
 viruses and it is your responsibility to scan any attachments.

 Eurobase Systems Limited is the main trading company in the Eurobase
 International Group; registered in England and Wales as company number
 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex
 CM2 0RE, UK.

Re: properties injection issue

[Aaron Morand]

h, I run mvn using the '-Pprofilename' method for activating my profiles.  This way I can build several version of the same code base on the 
same set of pom files.  I only need to specify a different profile.


When I do 'mvn -Pprofilename help:effective-pom' I get a successful build and 
all the dependencies are listed with the proper version numbers.

I don't understand why 'mvn -Pprofilename help:effective-pom' gives me the dependency list with versions as I'd expect.  Where as when I run my 
build manually (or under Bamboo) 'mvn -e -Pprofilename clean scm:checkout compile install package deploy' I get errors on all the 
sub-dependency's versions.  All the dependency versions are defined in my settings.xml file under the profilename I'm using.


I'm at a loss.

Cheers,

Aaron



Michael Meyer wrote:
Stupid question but is the profile activated? What is the result of: 
'mvn help:active-profiles'
and 'mvn help:effective-pom'? In the output of 'mvn help:effective-pom' 
your properties should be replaced with the version number.


Cheers, michael


Aaron Morand schrieb:

Good day all,

I am having an issue with a project failing, because a dependant 
project isn't using properties defined in my settings.xml file.


I have my settings.xml file in ~/.m2/setttings.xml and also symlinked 
it to /usr/local/maven/conf/settings.xml just so the default locations 
are covered with the same information.


I am upgrading to Maven2 from Maven1 and am dealing with 50+ projects, 
with various interdependencies on each other and 3rd party projects.


To keep the future of managing builds easy, I have defined all the 
dependency versions under profile properties in my settings.xml file.


So, for example, project1 depends on project2, project2 depends on 
project3 and all have dependency version #'s defined in the 
settings.xml file.  What I'm finding is that project2 doesn't appear 
to use the properties defined in the settings.xml file.  Syntactically 
everything appears correct and doesn't cause an error, but the 
project1 build fails based on not finding project2's dependencies.  It 
is looking for ${dependency.project2} which has a value of say, 2.1.  
So in settings.xml I have :

properties
...
dependency.project22.1/dependency.project2
dependency.project33.1/dependency.project3
...
/properties

in project1's pom.xml I have :
dependency
groupIdmy_project/groupId
artifactIdproject2/artifactId
version${dependency.project2}/version
/dependency

and in project2's pom.xml I have :
dependency
groupIdmy_project/groupId
artifactIdproject3/artifactId
version${dependency.project3}/version
/dependency

So it's complaining because it can't find project2's dependency of 
project3.  But it's looking for version ${dependency.project3} not 
version 3.1 that ${dependency.project3} is defined as in the 
settings.xml file.


Why doesn't this work?

Aaron

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: properties injection issue

[Michael Meyer]

Stupid question but is the profile activated? What is the result of: 'mvn 
help:active-profiles'
and 'mvn help:effective-pom'? In the output of 'mvn help:effective-pom' your 
properties should be replaced with the version number.

Cheers, michael


Aaron Morand schrieb:

Good day all,

I am having an issue with a project failing, because a dependant project 
isn't using properties defined in my settings.xml file.


I have my settings.xml file in ~/.m2/setttings.xml and also symlinked it 
to /usr/local/maven/conf/settings.xml just so the default locations are 
covered with the same information.


I am upgrading to Maven2 from Maven1 and am dealing with 50+ projects, 
with various interdependencies on each other and 3rd party projects.


To keep the future of managing builds easy, I have defined all the 
dependency versions under profile properties in my settings.xml file.


So, for example, project1 depends on project2, project2 depends on 
project3 and all have dependency version #'s defined in the settings.xml 
file.  What I'm finding is that project2 doesn't appear to use the 
properties defined in the settings.xml file.  Syntactically everything 
appears correct and doesn't cause an error, but the project1 build fails 
based on not finding project2's dependencies.  It is looking for 
${dependency.project2} which has a value of say, 2.1.  So in 
settings.xml I have :

properties
...
dependency.project22.1/dependency.project2
dependency.project33.1/dependency.project3
...
/properties

in project1's pom.xml I have :
dependency
groupIdmy_project/groupId
artifactIdproject2/artifactId
version${dependency.project2}/version
/dependency

and in project2's pom.xml I have :
dependency
groupIdmy_project/groupId
artifactIdproject3/artifactId
version${dependency.project3}/version
/dependency

So it's complaining because it can't find project2's dependency of 
project3.  But it's looking for version ${dependency.project3} not 
version 3.1 that ${dependency.project3} is defined as in the 
settings.xml file.


Why doesn't this work?

Aaron

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties files in a WAR artifact...

[Nelz]

OK...

First off, thank you Alexander for the suggestions.

Secondly, I realized what I was trying to do...  I am trying to pass
in run-time configuration, and just like any consumer of my artifact,
I need to send in configuration.

So, I created a /src/test/config directory.  In that directory I put
example/reference files log4j.properties.ref and
db.properties.ref.  I added instructions in the README.txt file that
says the users/builders of this project need to make a copy of those
files as log4j.properties and db.properties respectively.  Then,
if they want to make any changes specific to their run-time setup,
they do it in those two files.

For Jetty, I then passed in system properties:
systemProperties
systemProperty
namelog4j.configuration/name

valuefile:/${basedir}/src/test/config/log4j.properties/value
/systemProperty
systemProperty
namelocalDBProps/name   

valuefile:/${basedir}/src/test/config/db.properties/value
/systemProperty
/systemProperties

Seems to be running great, and the new users aren't intimidated...

I am also thinking of adding some antrun to the validate phase to
fail fast and descriptive if the files are not where they are
expected.

- Nelz

On 5/18/07, Alexander Sack [EMAIL PROTECTED] wrote:

Hi Nelz,

Let me throw some ideas at you and take what you can.

Here is what I do for all our internal projects:

In the project's parent POM I have this:

profiles
profile
   idprofile-db-postgresql/id
   properties
 jdbc.driverClassNameorg.postgresql.Driver/jdbc.driverClassName
 jdbc.usernamesomeusername/jdbc.username
 jdbc.passwordsomepassword/jdbc.password
 jdbc.url
jdbc:postgresql://localhost:5432/somedatabase?autoReconnect=true/fjdbc.url
   /properties
   activation
 property
   nameprofile-db-postgresql/name
 /property
   /activation
/profile
  /profiles

This allows me to activate databases based on a command line switch (I know
you don't like this approach).

Your class files are probably loading them from some properties files.  That
properties files can be then included in your WAR or JAR and loaded from the
classpath.

In the example above, I have a sub project that builds a EJB3 jar.  I use
the resource substitution via my pom.xml like:

build
  resources
resource
  directorysrc/main/resources/directory
  filteringtrue/filtering
/resource
  /resources
/build

So within my project, I have a src/main/resources where I stick my files
that I want to be filtered.  Btw, the resources directory is the default
directory for a JAR to pick up extra files so I know it will be included in
my final target output when I launch a build.  Obviously the file included
in src/main/resources looks like this:

someapp.jdbc.ClassName = ${jdbc.driverClassName}
someapp.jdbc.userName = ${jdbc.userName}
...
etc.

You could even have maven filter frame specific files such as an iBatis
config or Hibernate file.  I actually use the above approach to filter out
datasource xml files for JBoss deployments.

Your looking for per user username and password I suppose, so as per:

http://maven.apache.org/guides/introduction/introduction-to-profiles.html

You can EASILY do this via user specific profiles (I'm using the global POM
based one, but the same approach applies, just change where the profile file
is loaded from).

Hopefully some of this helps,

-aps

On 5/18/07, Nelz [EMAIL PROTECTED] wrote:

 Hey All...

 I think I'm hitting one of the biggest problem areas in Maven: Properties.

 I'll put my requirement first, and the wrinkles I see after that.

 1) I need to have a default set of properties for db connection (host,
 port, username, password) that end up next to my compiled .class
 files.
 - Ok: User resource filtering.  But where to put the default property
 values in the POM?

 2) I need each user to be able to override the default in their own
 environment.
 - My users are new, so I'd rather not make then specify anything
 extra at the command line.  (I'd prefer documenting a changes to
 settings.xml first.)
 - Can I have them specify their values in a /settings/profiles/profile
 (that is meant to be an xpath-ish descriptor for example specification
 only) section?

 X-3-X) I also need this to work with the jetty:run (Jetty 6) plugin...
 (I didn't know if the resource filtering would work, but I just
 checked and the Jetty6 plugin has /target/classes as the first entry
 in the classpath...  So, I am 

Re: Properties files in a WAR artifact...

[Alexander Sack]

Hi Nelz,

Let me throw some ideas at you and take what you can.

Here is what I do for all our internal projects:

In the project's parent POM I have this:

profiles
   profile
  idprofile-db-postgresql/id
  properties
jdbc.driverClassNameorg.postgresql.Driver/jdbc.driverClassName
jdbc.usernamesomeusername/jdbc.username
jdbc.passwordsomepassword/jdbc.password
jdbc.url

jdbc:postgresql://localhost:5432/somedatabase?autoReconnect=true/fjdbc.url

  /properties
  activation
property
  nameprofile-db-postgresql/name
/property
  /activation
   /profile
 /profiles

This allows me to activate databases based on a command line switch (I know
you don't like this approach).

Your class files are probably loading them from some properties files.  That
properties files can be then included in your WAR or JAR and loaded from the
classpath.

In the example above, I have a sub project that builds a EJB3 jar.  I use
the resource substitution via my pom.xml like:

build
 resources
   resource
 directorysrc/main/resources/directory
 filteringtrue/filtering
   /resource
 /resources
/build

So within my project, I have a src/main/resources where I stick my files
that I want to be filtered.  Btw, the resources directory is the default
directory for a JAR to pick up extra files so I know it will be included in
my final target output when I launch a build.  Obviously the file included
in src/main/resources looks like this:

someapp.jdbc.ClassName = ${jdbc.driverClassName}
someapp.jdbc.userName = ${jdbc.userName}
...
etc.

You could even have maven filter frame specific files such as an iBatis
config or Hibernate file.  I actually use the above approach to filter out
datasource xml files for JBoss deployments.

Your looking for per user username and password I suppose, so as per:

http://maven.apache.org/guides/introduction/introduction-to-profiles.html

You can EASILY do this via user specific profiles (I'm using the global POM
based one, but the same approach applies, just change where the profile file
is loaded from).

Hopefully some of this helps,

-aps

On 5/18/07, Nelz [EMAIL PROTECTED] wrote:


Hey All...

I think I'm hitting one of the biggest problem areas in Maven: Properties.

I'll put my requirement first, and the wrinkles I see after that.

1) I need to have a default set of properties for db connection (host,
port, username, password) that end up next to my compiled .class
files.
- Ok: User resource filtering.  But where to put the default property
values in the POM?

2) I need each user to be able to override the default in their own
environment.
- My users are new, so I'd rather not make then specify anything
extra at the command line.  (I'd prefer documenting a changes to
settings.xml first.)
- Can I have them specify their values in a /settings/profiles/profile
(that is meant to be an xpath-ish descriptor for example specification
only) section?

X-3-X) I also need this to work with the jetty:run (Jetty 6) plugin...
(I didn't know if the resource filtering would work, but I just
checked and the Jetty6 plugin has /target/classes as the first entry
in the classpath...  So, I am good on this point.)

Am I going about this the wrong way?  Isn't 2-tier web-app development
explicitly requiring non-portability?

- nelz


Here's what I've gathered so far from:
1a)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
What lies behind us and what lies in front of us is of little concern to
what lies within us. -Ralph Waldo Emerson