Re: properties in maven-remote-resources-plugin

[Delany]

Solved. The remote project was packaging type pom.

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

Thanks,
Delany

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

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

Re: properties in maven-remote-resources-plugin

[Delany]

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

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

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

and then

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

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

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

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

Thanks,


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

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

Re: properties in maven-remote-resources-plugin

[Delany]

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

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

Thanks,


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

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

Re: properties in maven-remote-resources-plugin

[Hervé BOUTEMY]

please try to write:

  
1.12
  

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

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

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

Regards,

Hervé

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

Re: properties in maven-remote-resources-plugin

[Delany]

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

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

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

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

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

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

[image: image.png]

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

Thanks,

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

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

Re: properties in maven-remote-resources-plugin

[Anthony Whitford]

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

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

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

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

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


Hope this helps,

Anthony


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

Re: properties in maven-remote-resources-plugin

[Delany]

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

[image: image.png]

It can do this

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

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

I need it to do this

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

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

Thanks,
Delany


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

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

Re: properties in maven-remote-resources-plugin

[Anthony Whitford]

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



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

Re: properties in maven-remote-resources-plugin

[Delany]

Well I gave it my best shot

  
maven-remote-resources-plugin

  
process-remote-resources

  process


  
dbs:commondb:${bully}
  
  
3
  

  

  

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


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

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

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

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

[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 


Cheers,

Greg Trasuk

> On Aug 18, 2015, at 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" 
> 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

[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" 
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 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 
wrote:

> Thanks for the link.  It was quite informative, but I'm again a little
> confused because it is stated in your explanation,
> the  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  element inside a 
> 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 
> > 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:
> > >
> > > 
> > > com.code54.mojo
> > > buildversion-plugin
> > >  1.0.3
> > > 
> > > .MM.dd HH:mm
> > >  
> > > 
> > > 
> > >  
> > > set-properties
> > > 
> > >  
> > > 
> > > 
> > >
> > > 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:
> > >
> > > 
> > > 
> > > Middleware build information
> > >  java:app/env/sw-version
> > > java.lang.String
> > >  ${build-commit} @ ${build-tstamp} built on
> > > ${maven.build.timestamp}
> > > 
> > > 
> > >
> > > 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

[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  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  element inside a 
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 
> 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:
> >
> > 
> > com.code54.mojo
> > buildversion-plugin
> >  1.0.3
> > 
> > .MM.dd HH:mm
> >  
> > 
> > 
> >  
> > set-properties
> > 
> >  
> > 
> > 
> >
> > 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:
> >
> > 
> > 
> > Middleware build information
> >  java:app/env/sw-version
> > java.lang.String
> >  ${build-commit} @ ${build-tstamp} built on
> > ${maven.build.timestamp}
> > 
> > 
> >
> > 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

[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  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:
>
> 
> com.code54.mojo
> buildversion-plugin
>  1.0.3
> 
> .MM.dd HH:mm
>  
> 
> 
>  
> set-properties
> 
>  
> 
> 
>
> 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:
>
> 
> 
> Middleware build information
>  java:app/env/sw-version
> java.lang.String
>  ${build-commit} @ ${build-tstamp} built on
> ${maven.build.timestamp}
> 
> 
>
> 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" 
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 
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"  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:


com.code54.mojo
buildversion-plugin
  1.0.3

.MM.dd HH:mm
  


  
set-properties

  



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:



Middleware build information
  java:app/env/sw-version
java.lang.String
  ${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}



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

[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" 
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 
> 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"  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:
> > >
> > > 
> > > com.code54.mojo
> > > buildversion-plugin
> > >  1.0.3
> > > 
> > > .MM.dd HH:mm
> > >  
> > > 
> > > 
> > >  
> > > set-properties
> > > 
> > >  
> > > 
> > > 
> > >
> > > 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:
> > >
> > > 
> > > 
> > > Middleware build information
> > >  java:app/env/sw-version
> > > java.lang.String
> > >  ${build-commit} @ ${build-tstamp} built on
> > > ${maven.build.timestamp}
> > > 
> > > 
> > >
> > > 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  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 
> > 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" 
> 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:
> > > >
> > > > 
> > > > com.code54.mojo
> > > > buildversion-plugin
> > > >  1.0.3
> > > > 
> > > > .MM.dd HH:mm
> > > >  
> > > > 
> > > > 
> > > >  
> > > > set-properties
> > > > 
> > > >  
> > > > 
> > > > 
> > > >
> > > > 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:
> > > >
> > > > 
> > > > 
> > > > Middleware build information
> > > >  java:app/env/sw-version
> > > > java.lang.String
> > > >  ${build-commit} @ ${build-tstamp} built on
> > > > ${maven.build.timestamp}
> > > > 
> > > > 
> > > >
> > > > 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

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 
> 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"  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:
> > >
> > > 
> > > com.code54.mojo
> > > buildversion-plugin
> > >  1.0.3
> > > 
> > > .MM.dd HH:mm
> > >  
> > > 
> > > 
> > >  
> > > set-properties
> > > 
> > >  
> > > 
> > > 
> > >
> > > 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:
> > >
> > > 
> > > 
> > > Middleware build information
> > >  java:app/env/sw-version
> > > java.lang.String
> > >  ${build-commit} @ ${build-tstamp} built on
> > > ${maven.build.timestamp}
> > > 
> > > 
> > >
> > > 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  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"  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:
> >
> > 
> > com.code54.mojo
> > buildversion-plugin
> >  1.0.3
> > 
> > .MM.dd HH:mm
> >  
> > 
> > 
> >  
> > set-properties
> > 
> >  
> > 
> > 
> >
> > 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:
> >
> > 
> > 
> > Middleware build information
> >  java:app/env/sw-version
> > java.lang.String
> >  ${build-commit} @ ${build-tstamp} built on
> > ${maven.build.timestamp}
> > 
> > 
> >
> > 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

[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"  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:
>
> 
> com.code54.mojo
> buildversion-plugin
>  1.0.3
> 
> .MM.dd HH:mm
>  
> 
> 
>  
> set-properties
> 
>  
> 
> 
>
> 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:
>
> 
> 
> Middleware build information
>  java:app/env/sw-version
> java.lang.String
>  ${build-commit} @ ${build-tstamp} built on
> ${maven.build.timestamp}
> 
> 
>
> 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 true
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:
> 
> 
> 
> true
> 
> 
> 
> 
> 
> …
> 
> 
> 
> 
> 
> 
> ${basedir}/src/trace
> 
> 
> 
> 
> Trace.java
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 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

[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  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<mailto:jkra...@mojiva.com>
mobile: 314.435.2370
skype: kramer.mojiva
twitter: @KramerKnowsTech<https://twitter.com/KramerKnowsTech>
0xCAFEBABE0032


From: "Nick Cuneo (ncuneo)" mailto:ncu...@cisco.com>>
Reply-To: Maven Users List 
mailto:users@maven.apache.org>>
Date: Friday, November 16, 2012 16:53 PM
To: "users@maven.apache.org<mailto:users@maven.apache.org>" 
mailto: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:

true


...


${basedir}/src/trace

Trace.java




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<mailto:ncu...@cisco.com>
Phone: 1-714-434-2344
Mobile: 1-949-243-4952



3500 Hyland Ave
Costa Mesa, CA
United States
Cisco.com<http://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 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  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 
>  >
> mobile: 314.435.2370
> skype: kramer.mojiva
> twitter: @KramerKnowsTech
> 0xCAFEBABE0032
>
>
> From: "Nick Cuneo (ncuneo)"  ncu...@cisco.com >>
> Reply-To: Maven Users List  users@maven.apache.org >>
> Date: Friday, November 16, 2012 16:53 PM
> To: "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:
> 
> true
> 
> 
> …
> 
> 
> ${basedir}/src/trace
> 
>
> Trace.java
> 
> 
> 
>
> 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 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

[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  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
mobile: 314.435.2370
skype: kramer.mojiva
twitter: @KramerKnowsTech
0xCAFEBABE0032


From: "Nick Cuneo (ncuneo)" mailto:ncu...@cisco.com>>
Reply-To: Maven Users List 
mailto:users@maven.apache.org>>
Date: Friday, November 16, 2012 16:53 PM
To: "users@maven.apache.org" 
mailto: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:

true


…


${basedir}/src/trace

Trace.java




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 vCard[Description: 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 file exlusion from dependency

[Laird Nelson]

On Tue, Aug 14, 2012 at 8:53 AM, Wright, Omari wrote:

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

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

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"  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 
> 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 
> >>
> >>> 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 
> wrote:
> >>>> It works but the full client is not enough for us to be able to
> >>>> build
> our
> >>>> applicati

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"  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 
> 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 
> >>
> >>> 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 
> 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" :
> >
> > 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"  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 pro

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

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  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 
>
>> 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  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" :
>> >>
>> >> 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"  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 
>> >> >
>> >> > > On 11 November 2011 16:31, Wayne Fay  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
>> >> > > >
>> >> > > >
>> > -

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 

> 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  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" :
> >>
> >> 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"  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 
> >> >
> >> > > On 11 November 2011 16:31, Wayne Fay  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

[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  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" :
>>
>> 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"  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 
>> >
>> > > On 11 November 2011 16:31, Wayne Fay  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

[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" :
>
> 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"  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 
> >
> > > On 11 November 2011 16:31, Wayne Fay  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"  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 
>
> > On 11 November 2011 16:31, Wayne Fay  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 

> On 11 November 2011 16:31, Wayne Fay  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

[Stephen Connolly]

On 11 November 2011 16:31, Wayne Fay  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]

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

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  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 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 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 inheritance does not work on windows os

[chemit]

On Thu, 11 Nov 2010 14:34:05 +0100
chemit  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 :
> 
>  
>   commons-logging
>   commons-logging
>  
> 
> 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
> 
> 
>   org.apache.maven
>   maven-project
>   ${mavenVersion}
>   provided
> 
> 
> 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

[chemit]

On Fri, 12 Nov 2010 09:19:33 -0500
Martin Gainty  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

[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 
> > 
> > > 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"  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, distrib

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

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

[Vincent Latombe]

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

Vincent


2010/11/11 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"  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]

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

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

[chemit]

On Thu, 11 Nov 2010 08:24:45 -0600
"Yanko, Curtis"  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]

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 :
> 
>  
>   commons-logging
>   commons-logging
>  
> 
> 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
> 
> 
>   org.apache.maven
>   maven-project
>   ${mavenVersion}
>   provided
> 
> 
> 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 15:17:48 +0100
Benjamin Bentmann  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]

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

[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

[chemit]

On Thu, 11 Nov 2010 14:34:05 +0100
chemit  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 :
> 
>  
>   commons-logging
>   commons-logging
>  
> 
> 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
> 
> 
>   org.apache.maven
>   maven-project
>   ${mavenVersion}
>   provided
> 
> 
> 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 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 under/lib , others/bin, others
in/licenses. My issue is the I'd like to have  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 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 /lib , others /bin, others 
> in /licenses. My issue is the I'd like to have  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 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 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]

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

[Martin Gainty]

i dont believe expression 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 )
}





  canonical-buildnumber
  

  .svn

  
  

  
org.codehaus.mojo
buildnumber-maven-plugin
1.0-beta-1

  
generate-resources

  create

  


  false
  false

  

  


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 ,exists> block was inside  right ?
> 
> 
> 
> ...
> 
> ${nsis.path}
> 
> 
>  ...
> 
> 
> 
> --sony
> 
> On Fri, Nov 13, 2009 at 10:43 PM, James Russo  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:
> >
> >
> >  
> >
> >  default
> >  
> >
> >  org.postgresql.Driver
> >jdbc:postgresql://localhost/test
> >user
> >password
> >http://localhost:8081/manager
> > 
> >manager
> >password
> >/
> >/client
> >/usr/local/nsis/nsis-2.45/bin/makensis
> >
> >  
> >
> >  
> >
> > So, I have a nsis.path defined in there.  However, I am trying to activate
> > the profile in my pom and neither way works. I've tried to just
> > activate the profile in the pom based on presence of nsis.path variable and
> > that doesn't work. And then I've also tried to do:
> >
> > ${nsis.path}
> >
> > and that doesn't work either.
> >
> > How can I accomplish this? I could activate it manually with -P, but I'd
> > rather just have everything in the settings.xml file since I need to visit
> > that to setup the environment anyways.
> >
> > thanks!
> >
> > -jr
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
  
_
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/

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 ,exists> block was inside  right ?



...

${nsis.path}


...





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

Re: properties in settings.xml

[Sony Antony]

The ,exists> block was inside  right ?



...

${nsis.path}


 ...



--sony

On Fri, Nov 13, 2009 at 10:43 PM, James Russo  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:
>
>
>  
>
>  default
>  
>
>  org.postgresql.Driver
>jdbc:postgresql://localhost/test
>user
>password
>http://localhost:8081/manager
> 
>manager
>password
>/
>/client
>/usr/local/nsis/nsis-2.45/bin/makensis
>
>  
>
>  
>
> So, I have a nsis.path defined in there.  However, I am trying to activate
> the profile in my pom and neither way works. I've tried to just
> activate the profile in the pom based on presence of nsis.path variable and
> that doesn't work. And then I've also tried to do:
>
> ${nsis.path}
>
> and that doesn't work either.
>
> How can I accomplish this? I could activate it manually with -P, but I'd
> rather just have everything in the settings.xml file since I need to visit
> that to setup the environment anyways.
>
> thanks!
>
> -jr
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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]

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

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

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

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

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 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"  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.
>   
> 
>   
> 
>   org.apache.maven.plugins
>   maven-eclipse-plugin
>   
> true
> true
> 2.0
>   
> 
>   
> 
>   
> 
> vs
> 
>   
> 
> true
> true
> 2.0
>   
> 
> 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.



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

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


bakersoftware
maven-replacer-plugin
0.0.9


test-compile

replace


target/test-classes/persistence.xml
\\
/






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



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

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


   
   
   
   ${jdbc.groupId}
   ${jdbc.artifactId}
   ${version.jdbc}
   
   
   
   
   
   jdbc-groupId-placeholder
   jdbc-artifactId-placeholder
   version-jdbc-placeholder
   
   
   
   
   test

   
   false
   

   
   com.mysql.jdbc.Driver
   mysql
   mysql-connector-java
   5.1.6
   
   
   
   

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

   
   ${jdbc.groupId}
   ${jdbc.artifactId}
   

(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:
> 
> 
> ${groupId}
> ${projectName}Web
> 1.0-SNAPSHOT
> war
> 
> 
> I would like to be able to define the value of the variable projectName, 

> so, if I defined projectName = Blah, it would expand to:
> 
> BlahWeb
> 
> -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:








**/*









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
>> >> ALL> >>
>> >> 
>> >> mygroup
>> >> module1
>> >> 
>> >>
>> >> 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

[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
> >> ALL >>
> >> 
> >> mygroup
> >> module1
> >> 
> >>
> >> 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

[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
>> ALL>
>> 
>> mygroup
>> module1
>> 
>>
>> 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]

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
> ALL
> 
> mygroup
> module1
> 
>
> 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
ALL
mygroup
module1


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: 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:
>
> 
>   DefaultProfile
>   
> true
>   
>   
>   1.1.1.1
>   
> 
>
>
> Now, I have a pom that access that property:
>
>   myexample.myexample
>   foo1
>   ${myversion}
>
> 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 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:
>
> 
>   DefaultProfile
>   
>   1.1.1.1
>   
> 
>
>
> Now, I have a pom that access that property:
>
>   myexample.myexample
>   foo1
>   ${myversion}
>

-- 
Michael McCallum
Enterprise Engineer
mailto:[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:
>
> 
>   DefaultProfile
>   
> true
>   
>   
>   1.1.1.1
>   
> 
>
>
> Now, I have a pom that access that property:
>
>   myexample.myexample
>   foo1
>   ${myversion}
>
> 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

[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':

  dev


Profile 'test':

  test


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 :


...
2.1
3.1
...


in project1's pom.xml I have :

my_project
project2
${dependency.project2}


and in project2's pom.xml I have :

my_project
project3
${dependency.project3}


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 :


...
2.1
3.1
...


in project1's pom.xml I have :

my_project
project2
${dependency.project2}


and in project2's pom.xml I have :

my_project
project3
${dependency.project3}


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:


log4j.configuration

file:/${basedir}/src/test/config/log4j.properties


localDBProps   

file:/${basedir}/src/test/config/db.properties



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:



   profile-db-postgresql
   
 org.postgresql.Driver
 someusername
 somepassword
 jdbc:postgresql://localhost:5432/somedatabase?autoReconnect=true
   
   
 
   profile-db-postgresql
 
   

  

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:


  

  src/main/resources
  true

  


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 b