You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by William Ferguson <Wi...@yarris.com> on 2008/01/11 00:45:45 UTC
RE: - possible maven defect?
Marshall,
the standard solution for what you are attempting would be to
install/deploy those libraries "not managed by Maven" into your own
repository or corporate repository and then you *would* have access to
them.
William
> -----Original Message-----
> From: Marshall Schor [mailto:msa@schor.com]
> Sent: Friday, 11 January 2008 9:40 AM
> To: Maven Users List
> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
> Sender is forged (SPF Fail)
>
> We define shared values as <property> elements in a parent
> POM and use them in child POMs. We have fragments like this,
> near the top of the parent POM:
>
> . . .
> <properties>
> . . .
> <uimaj-ee-version>0.7.0</uimaj-version>
>
> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
> </uimaj-release-version>
>
> . . .
> <version>0.7.0-incubating-SNAPSHOT</version>
>
> I noticed I might be able to replace the
>
> <version>0.7.0-incubating-SNAPSHOT</version>
>
> with
>
> <version>${uimaj-ee-release-version}</version>
>
> This only kind of worked. The way it would fail, would be
> if there were no existing versions of the parent POM in any
> repository, then the "mvn install" command for the parent POM
> would fail when scanning the child POMs, saying, for example:
>
> [ERROR] FATAL ERROR
> [INFO]
>
> --------------------------------------------------------------
> ----------
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID:
> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>
> Reason: Cannot find parent: org.apache.uima:uimaj-ee for project:
> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
> project
> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>
> I found (as a workaround) that if I modified the parent POM
> to have no children (commenting out the <module> elements),
> then mvn install for the parent POM would run; furthermore, I
> could then uncomment out the <module> children and mvn
> install on the parent POM would now build the children OK (I
> guess because the parent POM was findable in the local repository).
>
> This problem doesn't seem to occur if the parent POM doesn't
> use substitutable property values for its own <version>
> number. In that case the parent POM need not be previously
> installed in the local repository.
>
> Is this expected behavior in Maven, or is this a defect?
>
> -Marshall
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by Marshall Schor <ms...@schor.com>.
Marshall Schor wrote:
> Thank you for your reply.
> I tried to look up what the command line parameter "-N" was for maven
> - but couldn't find any reference to it. Can you please point me to
> where the command line parameters for maven are defined so I can learn
> what this does?
I found documentation for this by typing mvn -?. mvn -N install on the
parent would appear to install the parent to the local repo, without
executing the subgoals.
-Marshall
>
> I'm a little confused on why parents are not to be installed. Did you
> mean that parents shouldn't be installed using the "mvn install" command?
> Thanks for your help. -Marshall
>
> Michael McCallum wrote:
>> not a defect and IMO you should never install parents
>>
>> you can just do an install on the parent with mvn -N
>> for my projects any user first gets a settings.xml and then can check
>> out and build any artifact in isotation without the need to mvn
>> install anything
>>
>> relying on the parent to inherit version numbers etc gets pretty ugly
>> and error prone you would be best to encasulate dependencies like
>> that in a pom project
>>
>> On Fri, 11 Jan 2008 13:05:37 Marshall Schor wrote:
>>
>>> William Ferguson wrote:
>>>
>>>> Marshall,
>>>>
>>>> the standard solution for what you are attempting would be to
>>>> install/deploy those libraries "not managed by Maven" into your own
>>>> repository or corporate repository and then you *would* have access to
>>>> them.
>>>>
>>>> William
>>>>
>>> Hi William -
>>>
>>> I must have not communicated well. All of the libraries are manged by
>>> Maven. The situation where the failure occurs is like a startup - when
>>> a user first checks out the set of projects (having child POMs) and the
>>> main parent POM, then tries to do a "mvn install" on the parent.
>>>
>>> (I'm assuming here that they check out a development level, where the
>>> components have not been installed to any repository, yet).
>>>
>>> This first "mvn install" is intended to install of the parts into the
>>> local repository, but it only works if you don't use ${ ... } variable
>>> substitution in the way I was trying to use it.
>>>
>>> My question is whether this limitation on use of variable substitution
>>> is a maven defect, or whether it is working as designed (in which
>>> case -
>>> I'd appreciate learning what the philosophy is behind this design
>>> choice).
>>>
>>> -Marshall
>>>
>>>
>>>>> -----Original Message-----
>>>>> From: Marshall Schor [mailto:msa@schor.com]
>>>>> Sent: Friday, 11 January 2008 9:40 AM
>>>>> To: Maven Users List
>>>>> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
>>>>> Sender is forged (SPF Fail)
>>>>>
>>>>> We define shared values as <property> elements in a parent
>>>>> POM and use them in child POMs. We have fragments like this,
>>>>> near the top of the parent POM:
>>>>>
>>>>> . . .
>>>>> <properties>
>>>>> . . .
>>>>> <uimaj-ee-version>0.7.0</uimaj-version>
>>>>>
>>>>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
>>>>> </uimaj-release-version>
>>>>>
>>>>> . . .
>>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>>
>>>>> I noticed I might be able to replace the
>>>>>
>>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>>
>>>>> with
>>>>>
>>>>> <version>${uimaj-ee-release-version}</version>
>>>>>
>>>>> This only kind of worked. The way it would fail, would be
>>>>> if there were no existing versions of the parent POM in any
>>>>> repository, then the "mvn install" command for the parent POM
>>>>> would fail when scanning the child POMs, saying, for example:
>>>>>
>>>>> [ERROR] FATAL ERROR
>>>>> [INFO]
>>>>>
>>>>> --------------------------------------------------------------
>>>>> ----------
>>>>> [INFO] Error building POM (may not be this project's POM).
>>>>>
>>>>>
>>>>> Project ID:
>>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>>
>>>>> Reason: Cannot find parent: org.apache.uima:uimaj-ee for project:
>>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
>>>>> project
>>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>>
>>>>> I found (as a workaround) that if I modified the parent POM
>>>>> to have no children (commenting out the <module> elements),
>>>>> then mvn install for the parent POM would run; furthermore, I
>>>>> could then uncomment out the <module> children and mvn
>>>>> install on the parent POM would now build the children OK (I
>>>>> guess because the parent POM was findable in the local repository).
>>>>>
>>>>> This problem doesn't seem to occur if the parent POM doesn't
>>>>> use substitutable property values for its own <version>
>>>>> number. In that case the parent POM need not be previously
>>>>> installed in the local repository.
>>>>>
>>>>> Is this expected behavior in Maven, or is this a defect?
>>>>>
>>>>> -Marshall
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by Marshall Schor <ms...@schor.com>.
Thank you for your reply.
I tried to look up what the command line parameter "-N" was for maven -
but couldn't find any reference to it. Can you please point me to where
the command line parameters for maven are defined so I can learn what
this does?
I'm a little confused on why parents are not to be installed. Did you
mean that parents shouldn't be installed using the "mvn install" command?
Thanks for your help. -Marshall
Michael McCallum wrote:
> not a defect and IMO you should never install parents
>
> you can just do an install on the parent with mvn -N
>
> for my projects any user first gets a settings.xml and then can check out and
> build any artifact in isotation without the need to mvn install anything
>
> relying on the parent to inherit version numbers etc gets pretty ugly and
> error prone you would be best to encasulate dependencies like that in a pom
> project
>
> On Fri, 11 Jan 2008 13:05:37 Marshall Schor wrote:
>
>> William Ferguson wrote:
>>
>>> Marshall,
>>>
>>> the standard solution for what you are attempting would be to
>>> install/deploy those libraries "not managed by Maven" into your own
>>> repository or corporate repository and then you *would* have access to
>>> them.
>>>
>>> William
>>>
>> Hi William -
>>
>> I must have not communicated well. All of the libraries are manged by
>> Maven. The situation where the failure occurs is like a startup - when
>> a user first checks out the set of projects (having child POMs) and the
>> main parent POM, then tries to do a "mvn install" on the parent.
>>
>> (I'm assuming here that they check out a development level, where the
>> components have not been installed to any repository, yet).
>>
>> This first "mvn install" is intended to install of the parts into the
>> local repository, but it only works if you don't use ${ ... } variable
>> substitution in the way I was trying to use it.
>>
>> My question is whether this limitation on use of variable substitution
>> is a maven defect, or whether it is working as designed (in which case -
>> I'd appreciate learning what the philosophy is behind this design choice).
>>
>> -Marshall
>>
>>
>>>> -----Original Message-----
>>>> From: Marshall Schor [mailto:msa@schor.com]
>>>> Sent: Friday, 11 January 2008 9:40 AM
>>>> To: Maven Users List
>>>> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
>>>> Sender is forged (SPF Fail)
>>>>
>>>> We define shared values as <property> elements in a parent
>>>> POM and use them in child POMs. We have fragments like this,
>>>> near the top of the parent POM:
>>>>
>>>> . . .
>>>> <properties>
>>>> . . .
>>>> <uimaj-ee-version>0.7.0</uimaj-version>
>>>>
>>>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
>>>> </uimaj-release-version>
>>>>
>>>> . . .
>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>
>>>> I noticed I might be able to replace the
>>>>
>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>
>>>> with
>>>>
>>>> <version>${uimaj-ee-release-version}</version>
>>>>
>>>> This only kind of worked. The way it would fail, would be
>>>> if there were no existing versions of the parent POM in any
>>>> repository, then the "mvn install" command for the parent POM
>>>> would fail when scanning the child POMs, saying, for example:
>>>>
>>>> [ERROR] FATAL ERROR
>>>> [INFO]
>>>>
>>>> --------------------------------------------------------------
>>>> ----------
>>>> [INFO] Error building POM (may not be this project's POM).
>>>>
>>>>
>>>> Project ID:
>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>
>>>> Reason: Cannot find parent: org.apache.uima:uimaj-ee for project:
>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
>>>> project
>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>
>>>> I found (as a workaround) that if I modified the parent POM
>>>> to have no children (commenting out the <module> elements),
>>>> then mvn install for the parent POM would run; furthermore, I
>>>> could then uncomment out the <module> children and mvn
>>>> install on the parent POM would now build the children OK (I
>>>> guess because the parent POM was findable in the local repository).
>>>>
>>>> This problem doesn't seem to occur if the parent POM doesn't
>>>> use substitutable property values for its own <version>
>>>> number. In that case the parent POM need not be previously
>>>> installed in the local repository.
>>>>
>>>> Is this expected behavior in Maven, or is this a defect?
>>>>
>>>> -Marshall
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by Michael McCallum <gh...@apache.org>.
not a defect and IMO you should never install parents
you can just do an install on the parent with mvn -N
for my projects any user first gets a settings.xml and then can check out and
build any artifact in isotation without the need to mvn install anything
relying on the parent to inherit version numbers etc gets pretty ugly and
error prone you would be best to encasulate dependencies like that in a pom
project
On Fri, 11 Jan 2008 13:05:37 Marshall Schor wrote:
> William Ferguson wrote:
> > Marshall,
> >
> > the standard solution for what you are attempting would be to
> > install/deploy those libraries "not managed by Maven" into your own
> > repository or corporate repository and then you *would* have access to
> > them.
> >
> > William
>
> Hi William -
>
> I must have not communicated well. All of the libraries are manged by
> Maven. The situation where the failure occurs is like a startup - when
> a user first checks out the set of projects (having child POMs) and the
> main parent POM, then tries to do a "mvn install" on the parent.
>
> (I'm assuming here that they check out a development level, where the
> components have not been installed to any repository, yet).
>
> This first "mvn install" is intended to install of the parts into the
> local repository, but it only works if you don't use ${ ... } variable
> substitution in the way I was trying to use it.
>
> My question is whether this limitation on use of variable substitution
> is a maven defect, or whether it is working as designed (in which case -
> I'd appreciate learning what the philosophy is behind this design choice).
>
> -Marshall
>
> >> -----Original Message-----
> >> From: Marshall Schor [mailto:msa@schor.com]
> >> Sent: Friday, 11 January 2008 9:40 AM
> >> To: Maven Users List
> >> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
> >> Sender is forged (SPF Fail)
> >>
> >> We define shared values as <property> elements in a parent
> >> POM and use them in child POMs. We have fragments like this,
> >> near the top of the parent POM:
> >>
> >> . . .
> >> <properties>
> >> . . .
> >> <uimaj-ee-version>0.7.0</uimaj-version>
> >>
> >> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
> >> </uimaj-release-version>
> >>
> >> . . .
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> I noticed I might be able to replace the
> >>
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> with
> >>
> >> <version>${uimaj-ee-release-version}</version>
> >>
> >> This only kind of worked. The way it would fail, would be
> >> if there were no existing versions of the parent POM in any
> >> repository, then the "mvn install" command for the parent POM
> >> would fail when scanning the child POMs, saying, for example:
> >>
> >> [ERROR] FATAL ERROR
> >> [INFO]
> >>
> >> --------------------------------------------------------------
> >> ----------
> >> [INFO] Error building POM (may not be this project's POM).
> >>
> >>
> >> Project ID:
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> Reason: Cannot find parent: org.apache.uima:uimaj-ee for project:
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
> >> project
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> I found (as a workaround) that if I modified the parent POM
> >> to have no children (commenting out the <module> elements),
> >> then mvn install for the parent POM would run; furthermore, I
> >> could then uncomment out the <module> children and mvn
> >> install on the parent POM would now build the children OK (I
> >> guess because the parent POM was findable in the local repository).
> >>
> >> This problem doesn't seem to occur if the parent POM doesn't
> >> use substitutable property values for its own <version>
> >> number. In that case the parent POM need not be previously
> >> installed in the local repository.
> >>
> >> Is this expected behavior in Maven, or is this a defect?
> >>
> >> -Marshall
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by Marshall Schor <ms...@schor.com>.
William Ferguson wrote:
> >From what you've said it seems that all your problems are solved by
> hardcoding the version in the parent.
> Ie don't use the property. Which is standard practice.
>
> I don't know what causes the problem that you are describing, but if it
> goes away when you stop punishing yourself with it then that would be a
> good option IMHO.
>
Hi William -
The only reason I was, as you say, "punishing myself" with this approach
was an attempt to follow the DRY philosophy (
http://en.wikipedia.org/wiki/Don't_repeat_yourself
<http://en.wikipedia.org/wiki/Don%27t_repeat_yourself> ), which has
served us well in the past in reducing maintenance difficulties. It's
possible that using maven's Release plugin would alleviate some of this,
and I'll look into that further. We do have version info in places I
don't think Maven would know about (such as in our documentation, and
inside the names of our Eclipse plugins - which use a slightly different
syntax than normal maven things.)
Thanks for your help and advice.
-Marshall
> William
>
>
>
>> -----Original Message-----
>> From: Marshall Schor [mailto:msa@schor.com]
>> Sent: Friday, 11 January 2008 12:42 PM
>> To: Maven Users List
>> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
>> - Sender is forged (SPF Fail)
>>
>> William Ferguson wrote:
>>
>>> My apologies Marshall, not quite sure how it occurred but my answer
>>> was for an entirely different question by someone else.
>>>
>>> To answer your question, Maven seems to be working largely
>>>
>> as designed.
>>
>>> I'm actually surprised that your child POMs could build in any
>>> scenario if their reference to the parent POM contains a build
>>> property only found in the parent POM. Because that would
>>>
>> be a circular reference.
>>
>>>
>>>
>> True, but that's not what we're doing, exactly. In our code,
>> the "reference to the parent POM" *is* *"hard-coded", and
>> doesn't contain any references such as
>> ${property-defined-in-parent} for the very reason you describe.
>>
>>> You should really have groupId, artifactId and version
>>>
>> hard-coded in
>>
>>> all POMs.
>>>
>>>
>> Well, that's the question. We have groupId and artifactId
>> hard-coded.
>> The version *is* inheriting from the parent, via a
>> ${property-defined-in-parent} (*this is working*).
>> What's not working is the parent itself being able to have a
>> ${property-defined-in-itself} value for the <version> value.
>>
>>> The standard Maven way of doing things would be to have the version
>>> hard-coded with a similar value as the version of the parent in the
>>> child POMs. You would then use the release-plugin to manage the
>>> increment of the version.
>>>
>>> Is there a particular reason that you needed to define ?
>>> <uimaj-ee-version>0.7.0</uimaj-version>
>>>
>>>
>>>
>>>
>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-
>>
>>> release-version> I think you need to reconsider your
>>>
>> project version.
>>
>>> I think you want it as 0.7.0-SNAPSHOT.
>>> "incubating" would seem to belong as part of an artifactId
>>>
>> or assembly
>>
>>> annotation (see the asembly plugin).
>>> I hope this helps.
>>>
>>>
>> Because we are a project in the Apache Incubator, our version
>> names include the word "incubator" in them to insure that
>> users realize they are working with an incubating project.
>>
>> The reason we define version numbers this way is that we have
>> some conflicting naming standards - some require
>> 0.7.0-incubating-SNAPSHOT, while others (Eclipse plugins, in
>> particular) want 0.7.0.incubating-SNAPSHOT (not the "."
>> instead of the '-' in front of the word "incubating".
>>
>> So we thought that we could put all this kind of stuff in one
>> common, factored out, "parent", and be done with it :-)
>>
>> -Marshall
>>
>>> William
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Marshall Schor [mailto:msa@schor.com]
>>>> Sent: Friday, 11 January 2008 10:06 AM
>>>> To: Maven Users List
>>>> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
>>>> - Sender is forged (SPF Fail)
>>>>
>>>> William Ferguson wrote:
>>>>
>>>>
>>>>> Marshall,
>>>>>
>>>>> the standard solution for what you are attempting would be to
>>>>> install/deploy those libraries "not managed by Maven"
>>>>>
>> into your own
>>
>>>>> repository or corporate repository and then you *would*
>>>>>
>>>>>
>>>> have access to
>>>>
>>>>
>>>>> them.
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>>
>>>> Hi William -
>>>>
>>>> I must have not communicated well. All of the libraries
>>>>
>> are manged
>>
>>>> by Maven. The situation where the failure occurs is like
>>>>
>> a startup -
>>
>>>> when a user first checks out the set of projects (having
>>>>
>> child POMs)
>>
>>>> and the main parent POM, then tries to do a "mvn install" on the
>>>> parent.
>>>>
>>>> (I'm assuming here that they check out a development
>>>>
>> level, where the
>>
>>>> components have not been installed to any repository, yet).
>>>>
>>>> This first "mvn install" is intended to install of the
>>>>
>> parts into the
>>
>>>> local repository, but it only works if you don't use ${ ... }
>>>> variable substitution in the way I was trying to use it.
>>>>
>>>> My question is whether this limitation on use of variable
>>>> substitution is a maven defect, or whether it is working
>>>>
>> as designed
>>
>>>> (in which case - I'd appreciate learning what the philosophy is
>>>> behind this design choice).
>>>>
>>>> -Marshall
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Marshall Schor [mailto:msa@schor.com]
>>>>>> Sent: Friday, 11 January 2008 9:40 AM
>>>>>> To: Maven Users List
>>>>>> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
>>>>>>
>>>>>>
>>>> Sender is
>>>>
>>>>
>>>>>> forged (SPF Fail)
>>>>>>
>>>>>> We define shared values as <property> elements in a
>>>>>>
>> parent POM and
>>
>>>>>> use them in child POMs. We have fragments like this, near
>>>>>>
>>>>>>
>>>> the top of
>>>>
>>>>
>>>>>> the parent POM:
>>>>>>
>>>>>> . . .
>>>>>> <properties>
>>>>>> . . .
>>>>>> <uimaj-ee-version>0.7.0</uimaj-version>
>>>>>>
>>>>>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
>>>>>> </uimaj-release-version>
>>>>>>
>>>>>> . . .
>>>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>>>
>>>>>> I noticed I might be able to replace the
>>>>>>
>>>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>>>
>>>>>> with
>>>>>>
>>>>>> <version>${uimaj-ee-release-version}</version>
>>>>>>
>>>>>> This only kind of worked. The way it would fail, would
>>>>>>
>>>>>>
>>>> be if there
>>>>
>>>>
>>>>>> were no existing versions of the parent POM in any
>>>>>>
>>>>>>
>>>> repository, then
>>>>
>>>>
>>>>>> the "mvn install" command for the parent POM would fail
>>>>>>
>>>>>>
>>>> when scanning
>>>>
>>>>
>>>>>> the child POMs, saying, for example:
>>>>>>
>>>>>> [ERROR] FATAL ERROR
>>>>>> [INFO]
>>>>>>
>>>>>> --------------------------------------------------------------
>>>>>> ----------
>>>>>> [INFO] Error building POM (may not be this project's POM).
>>>>>>
>>>>>>
>>>>>> Project ID:
>>>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>>>
>>>>>> Reason: Cannot find parent: org.apache.uima:uimaj-ee
>>>>>>
>>>>>>
>>>> for project:
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
>>>>
>>>>
>>>>>> project
>>>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>>>
>>>>>> I found (as a workaround) that if I modified the parent
>>>>>>
>>>>>>
>>>> POM to have
>>>>
>>>>
>>>>>> no children (commenting out the <module> elements), then
>>>>>>
>>>>>>
>>>> mvn install
>>>>
>>>>
>>>>>> for the parent POM would run; furthermore, I could then
>>>>>>
>>>>>>
>>>> uncomment out
>>>>
>>>>
>>>>>> the <module> children and mvn install on the parent POM
>>>>>>
>> would now
>>
>>>>>> build the children OK (I guess because the parent POM was
>>>>>>
>>>>>>
>>>> findable in
>>>>
>>>>
>>>>>> the local repository).
>>>>>>
>>>>>> This problem doesn't seem to occur if the parent POM doesn't use
>>>>>> substitutable property values for its own <version>
>>>>>>
>>>>>>
>>>> number. In that
>>>>
>>>>
>>>>>> case the parent POM need not be previously installed in
>>>>>>
>> the local
>>
>>>>>> repository.
>>>>>>
>>>>>> Is this expected behavior in Maven, or is this a defect?
>>>>>>
>>>>>> -Marshall
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>
>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>
>>>>
>>>>
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by William Ferguson <Wi...@yarris.com>.
>From what you've said it seems that all your problems are solved by
hardcoding the version in the parent.
Ie don't use the property. Which is standard practice.
I don't know what causes the problem that you are describing, but if it
goes away when you stop punishing yourself with it then that would be a
good option IMHO.
William
> -----Original Message-----
> From: Marshall Schor [mailto:msa@schor.com]
> Sent: Friday, 11 January 2008 12:42 PM
> To: Maven Users List
> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
> - Sender is forged (SPF Fail)
>
> William Ferguson wrote:
> > My apologies Marshall, not quite sure how it occurred but my answer
> > was for an entirely different question by someone else.
> >
> > To answer your question, Maven seems to be working largely
> as designed.
> > I'm actually surprised that your child POMs could build in any
> > scenario if their reference to the parent POM contains a build
> > property only found in the parent POM. Because that would
> be a circular reference.
> >
> True, but that's not what we're doing, exactly. In our code,
> the "reference to the parent POM" *is* *"hard-coded", and
> doesn't contain any references such as
> ${property-defined-in-parent} for the very reason you describe.
> > You should really have groupId, artifactId and version
> hard-coded in
> > all POMs.
> >
> Well, that's the question. We have groupId and artifactId
> hard-coded.
> The version *is* inheriting from the parent, via a
> ${property-defined-in-parent} (*this is working*).
> What's not working is the parent itself being able to have a
> ${property-defined-in-itself} value for the <version> value.
> > The standard Maven way of doing things would be to have the version
> > hard-coded with a similar value as the version of the parent in the
> > child POMs. You would then use the release-plugin to manage the
> > increment of the version.
> >
> > Is there a particular reason that you needed to define ?
> > <uimaj-ee-version>0.7.0</uimaj-version>
> >
> >
> >
> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-
> > release-version> I think you need to reconsider your
> project version.
> > I think you want it as 0.7.0-SNAPSHOT.
> > "incubating" would seem to belong as part of an artifactId
> or assembly
> > annotation (see the asembly plugin).
> > I hope this helps.
> >
> Because we are a project in the Apache Incubator, our version
> names include the word "incubator" in them to insure that
> users realize they are working with an incubating project.
>
> The reason we define version numbers this way is that we have
> some conflicting naming standards - some require
> 0.7.0-incubating-SNAPSHOT, while others (Eclipse plugins, in
> particular) want 0.7.0.incubating-SNAPSHOT (not the "."
> instead of the '-' in front of the word "incubating".
>
> So we thought that we could put all this kind of stuff in one
> common, factored out, "parent", and be done with it :-)
>
> -Marshall
> > William
> >
> >
> >> -----Original Message-----
> >> From: Marshall Schor [mailto:msa@schor.com]
> >> Sent: Friday, 11 January 2008 10:06 AM
> >> To: Maven Users List
> >> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
> >> - Sender is forged (SPF Fail)
> >>
> >> William Ferguson wrote:
> >>
> >>> Marshall,
> >>>
> >>> the standard solution for what you are attempting would be to
> >>> install/deploy those libraries "not managed by Maven"
> into your own
> >>> repository or corporate repository and then you *would*
> >>>
> >> have access to
> >>
> >>> them.
> >>>
> >>> William
> >>>
> >>>
> >> Hi William -
> >>
> >> I must have not communicated well. All of the libraries
> are manged
> >> by Maven. The situation where the failure occurs is like
> a startup -
> >> when a user first checks out the set of projects (having
> child POMs)
> >> and the main parent POM, then tries to do a "mvn install" on the
> >> parent.
> >>
> >> (I'm assuming here that they check out a development
> level, where the
> >> components have not been installed to any repository, yet).
> >>
> >> This first "mvn install" is intended to install of the
> parts into the
> >> local repository, but it only works if you don't use ${ ... }
> >> variable substitution in the way I was trying to use it.
> >>
> >> My question is whether this limitation on use of variable
> >> substitution is a maven defect, or whether it is working
> as designed
> >> (in which case - I'd appreciate learning what the philosophy is
> >> behind this design choice).
> >>
> >> -Marshall
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Marshall Schor [mailto:msa@schor.com]
> >>>> Sent: Friday, 11 January 2008 9:40 AM
> >>>> To: Maven Users List
> >>>> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
> >>>>
> >> Sender is
> >>
> >>>> forged (SPF Fail)
> >>>>
> >>>> We define shared values as <property> elements in a
> parent POM and
> >>>> use them in child POMs. We have fragments like this, near
> >>>>
> >> the top of
> >>
> >>>> the parent POM:
> >>>>
> >>>> . . .
> >>>> <properties>
> >>>> . . .
> >>>> <uimaj-ee-version>0.7.0</uimaj-version>
> >>>>
> >>>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
> >>>> </uimaj-release-version>
> >>>>
> >>>> . . .
> >>>> <version>0.7.0-incubating-SNAPSHOT</version>
> >>>>
> >>>> I noticed I might be able to replace the
> >>>>
> >>>> <version>0.7.0-incubating-SNAPSHOT</version>
> >>>>
> >>>> with
> >>>>
> >>>> <version>${uimaj-ee-release-version}</version>
> >>>>
> >>>> This only kind of worked. The way it would fail, would
> >>>>
> >> be if there
> >>
> >>>> were no existing versions of the parent POM in any
> >>>>
> >> repository, then
> >>
> >>>> the "mvn install" command for the parent POM would fail
> >>>>
> >> when scanning
> >>
> >>>> the child POMs, saying, for example:
> >>>>
> >>>> [ERROR] FATAL ERROR
> >>>> [INFO]
> >>>>
> >>>> --------------------------------------------------------------
> >>>> ----------
> >>>> [INFO] Error building POM (may not be this project's POM).
> >>>>
> >>>>
> >>>> Project ID:
> >>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>>>
> >>>> Reason: Cannot find parent: org.apache.uima:uimaj-ee
> >>>>
> >> for project:
> >>
> >>>>
> >>>>
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
> >>
> >>>> project
> >>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>>>
> >>>> I found (as a workaround) that if I modified the parent
> >>>>
> >> POM to have
> >>
> >>>> no children (commenting out the <module> elements), then
> >>>>
> >> mvn install
> >>
> >>>> for the parent POM would run; furthermore, I could then
> >>>>
> >> uncomment out
> >>
> >>>> the <module> children and mvn install on the parent POM
> would now
> >>>> build the children OK (I guess because the parent POM was
> >>>>
> >> findable in
> >>
> >>>> the local repository).
> >>>>
> >>>> This problem doesn't seem to occur if the parent POM doesn't use
> >>>> substitutable property values for its own <version>
> >>>>
> >> number. In that
> >>
> >>>> case the parent POM need not be previously installed in
> the local
> >>>> repository.
> >>>>
> >>>> Is this expected behavior in Maven, or is this a defect?
> >>>>
> >>>> -Marshall
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by Marshall Schor <ms...@schor.com>.
William Ferguson wrote:
> My apologies Marshall, not quite sure how it occurred but my answer was
> for an entirely different question by someone else.
>
> To answer your question, Maven seems to be working largely as designed.
> I'm actually surprised that your child POMs could build in any scenario
> if their reference to the parent POM contains a build property only
> found in the parent POM. Because that would be a circular reference.
>
True, but that's not what we're doing, exactly. In our code, the
"reference to the parent POM" *is* *"hard-coded", and doesn't contain
any references such as ${property-defined-in-parent} for the very reason
you describe.
> You should really have groupId, artifactId and version hard-coded in all
> POMs.
>
Well, that's the question. We have groupId and artifactId hard-coded.
The version *is* inheriting from the parent, via a
${property-defined-in-parent} (*this is working*).
What's not working is the parent itself being able to have a
${property-defined-in-itself} value for the <version> value.
> The standard Maven way of doing things would be to have the version
> hard-coded with a similar value as the version of the parent in the
> child POMs. You would then use the release-plugin to manage the
> increment of the version.
>
> Is there a particular reason that you needed to define ?
> <uimaj-ee-version>0.7.0</uimaj-version>
>
> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-release-version>
> I think you need to reconsider your project version. I think you want it
> as 0.7.0-SNAPSHOT.
> "incubating" would seem to belong as part of an artifactId or assembly
> annotation (see the asembly plugin).
> I hope this helps.
>
Because we are a project in the Apache Incubator, our version names
include the word "incubator" in them to insure that users realize they
are working with an incubating project.
The reason we define version numbers this way is that we have some
conflicting naming standards - some require
0.7.0-incubating-SNAPSHOT, while others (Eclipse plugins, in particular)
want
0.7.0.incubating-SNAPSHOT (not the "." instead of the '-' in front of
the word "incubating".
So we thought that we could put all this kind of stuff in one common,
factored out, "parent", and be done with it :-)
-Marshall
> William
>
>
>> -----Original Message-----
>> From: Marshall Schor [mailto:msa@schor.com]
>> Sent: Friday, 11 January 2008 10:06 AM
>> To: Maven Users List
>> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
>> - Sender is forged (SPF Fail)
>>
>> William Ferguson wrote:
>>
>>> Marshall,
>>>
>>> the standard solution for what you are attempting would be to
>>> install/deploy those libraries "not managed by Maven" into your own
>>> repository or corporate repository and then you *would*
>>>
>> have access to
>>
>>> them.
>>>
>>> William
>>>
>>>
>> Hi William -
>>
>> I must have not communicated well. All of the libraries are
>> manged by Maven. The situation where the failure occurs is
>> like a startup - when a user first checks out the set of
>> projects (having child POMs) and the main parent POM, then
>> tries to do a "mvn install" on the parent.
>>
>> (I'm assuming here that they check out a development level,
>> where the components have not been installed to any repository, yet).
>>
>> This first "mvn install" is intended to install of the parts
>> into the local repository, but it only works if you don't use
>> ${ ... } variable substitution in the way I was trying to use it.
>>
>> My question is whether this limitation on use of variable
>> substitution is a maven defect, or whether it is working as
>> designed (in which case - I'd appreciate learning what the
>> philosophy is behind this design choice).
>>
>> -Marshall
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Marshall Schor [mailto:msa@schor.com]
>>>> Sent: Friday, 11 January 2008 9:40 AM
>>>> To: Maven Users List
>>>> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
>>>>
>> Sender is
>>
>>>> forged (SPF Fail)
>>>>
>>>> We define shared values as <property> elements in a parent POM and
>>>> use them in child POMs. We have fragments like this, near
>>>>
>> the top of
>>
>>>> the parent POM:
>>>>
>>>> . . .
>>>> <properties>
>>>> . . .
>>>> <uimaj-ee-version>0.7.0</uimaj-version>
>>>>
>>>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
>>>> </uimaj-release-version>
>>>>
>>>> . . .
>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>
>>>> I noticed I might be able to replace the
>>>>
>>>> <version>0.7.0-incubating-SNAPSHOT</version>
>>>>
>>>> with
>>>>
>>>> <version>${uimaj-ee-release-version}</version>
>>>>
>>>> This only kind of worked. The way it would fail, would
>>>>
>> be if there
>>
>>>> were no existing versions of the parent POM in any
>>>>
>> repository, then
>>
>>>> the "mvn install" command for the parent POM would fail
>>>>
>> when scanning
>>
>>>> the child POMs, saying, for example:
>>>>
>>>> [ERROR] FATAL ERROR
>>>> [INFO]
>>>>
>>>> --------------------------------------------------------------
>>>> ----------
>>>> [INFO] Error building POM (may not be this project's POM).
>>>>
>>>>
>>>> Project ID:
>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>
>>>> Reason: Cannot find parent: org.apache.uima:uimaj-ee
>>>>
>> for project:
>>
>>>>
>>>>
>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
>>
>>>> project
>>>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>>>
>>>> I found (as a workaround) that if I modified the parent
>>>>
>> POM to have
>>
>>>> no children (commenting out the <module> elements), then
>>>>
>> mvn install
>>
>>>> for the parent POM would run; furthermore, I could then
>>>>
>> uncomment out
>>
>>>> the <module> children and mvn install on the parent POM would now
>>>> build the children OK (I guess because the parent POM was
>>>>
>> findable in
>>
>>>> the local repository).
>>>>
>>>> This problem doesn't seem to occur if the parent POM doesn't use
>>>> substitutable property values for its own <version>
>>>>
>> number. In that
>>
>>>> case the parent POM need not be previously installed in the local
>>>> repository.
>>>>
>>>> Is this expected behavior in Maven, or is this a defect?
>>>>
>>>> -Marshall
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Antwort: Re: - possible maven defect?
Posted by to...@gi-de.com.
Hi,
joining your discussion I´ve another question:
...
You should really have groupId, artifactId and version hard-coded in all
POMs.
...
In our project we have 2 parent poms,
- one for "technical" belongings (definition of repositories, versions of
plugins and so on) and
- one for "functional" belongings (definition of versions and external
libraries )
Every child pom (about > 30) is inherited from those.
Now, when we release a child project - how will the parent pom be
released?
Is it necessary to modify the versionnumber of the parent, each time it
changes?
If so, we have to modify the parent version number in all our child
projects....
=> What is best practive to manage the versions of the parent and child
poms in conjunction?
Thanx for any advice
torsten
"William Ferguson" <Wi...@yarris.com>
11.01.2008 02:41
Bitte antworten an
"Maven Users List" <us...@maven.apache.org>
An
"Maven Users List" <us...@maven.apache.org>
Kopie
Thema
Re: - possible maven defect?
My apologies Marshall, not quite sure how it occurred but my answer was
for an entirely different question by someone else.
To answer your question, Maven seems to be working largely as designed.
I'm actually surprised that your child POMs could build in any scenario
if their reference to the parent POM contains a build property only
found in the parent POM. Because that would be a circular reference.
You should really have groupId, artifactId and version hard-coded in all
POMs.
The standard Maven way of doing things would be to have the version
hard-coded with a similar value as the version of the parent in the
child POMs. You would then use the release-plugin to manage the
increment of the version.
Is there a particular reason that you needed to define ?
<uimaj-ee-version>0.7.0</uimaj-version>
<uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-re
lease-version>
I think you need to reconsider your project version. I think you want it
as 0.7.0-SNAPSHOT.
"incubating" would seem to belong as part of an artifactId or assembly
annotation (see the asembly plugin).
I hope this helps.
William
> -----Original Message-----
> From: Marshall Schor [mailto:msa@schor.com]
> Sent: Friday, 11 January 2008 10:06 AM
> To: Maven Users List
> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
> - Sender is forged (SPF Fail)
>
> William Ferguson wrote:
> > Marshall,
> >
> > the standard solution for what you are attempting would be to
> > install/deploy those libraries "not managed by Maven" into your own
> > repository or corporate repository and then you *would*
> have access to
> > them.
> >
> > William
> >
> Hi William -
>
> I must have not communicated well. All of the libraries are
> manged by Maven. The situation where the failure occurs is
> like a startup - when a user first checks out the set of
> projects (having child POMs) and the main parent POM, then
> tries to do a "mvn install" on the parent.
>
> (I'm assuming here that they check out a development level,
> where the components have not been installed to any repository, yet).
>
> This first "mvn install" is intended to install of the parts
> into the local repository, but it only works if you don't use
> ${ ... } variable substitution in the way I was trying to use it.
>
> My question is whether this limitation on use of variable
> substitution is a maven defect, or whether it is working as
> designed (in which case - I'd appreciate learning what the
> philosophy is behind this design choice).
>
> -Marshall
> >
> >> -----Original Message-----
> >> From: Marshall Schor [mailto:msa@schor.com]
> >> Sent: Friday, 11 January 2008 9:40 AM
> >> To: Maven Users List
> >> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
> Sender is
> >> forged (SPF Fail)
> >>
> >> We define shared values as <property> elements in a parent POM and
> >> use them in child POMs. We have fragments like this, near
> the top of
> >> the parent POM:
> >>
> >> . . .
> >> <properties>
> >> . . .
> >> <uimaj-ee-version>0.7.0</uimaj-version>
> >>
> >> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
> >> </uimaj-release-version>
> >>
> >> . . .
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> I noticed I might be able to replace the
> >>
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> with
> >>
> >> <version>${uimaj-ee-release-version}</version>
> >>
> >> This only kind of worked. The way it would fail, would
> be if there
> >> were no existing versions of the parent POM in any
> repository, then
> >> the "mvn install" command for the parent POM would fail
> when scanning
> >> the child POMs, saying, for example:
> >>
> >> [ERROR] FATAL ERROR
> >> [INFO]
> >>
> >> --------------------------------------------------------------
> >> ----------
> >> [INFO] Error building POM (may not be this project's POM).
> >>
> >>
> >> Project ID:
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> Reason: Cannot find parent: org.apache.uima:uimaj-ee
> for project:
> >>
> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
> >> project
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> I found (as a workaround) that if I modified the parent
> POM to have
> >> no children (commenting out the <module> elements), then
> mvn install
> >> for the parent POM would run; furthermore, I could then
> uncomment out
> >> the <module> children and mvn install on the parent POM would now
> >> build the children OK (I guess because the parent POM was
> findable in
> >> the local repository).
> >>
> >> This problem doesn't seem to occur if the parent POM doesn't use
> >> substitutable property values for its own <version>
> number. In that
> >> case the parent POM need not be previously installed in the local
> >> repository.
> >>
> >> Is this expected behavior in Maven, or is this a defect?
> >>
> >> -Marshall
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by William Ferguson <Wi...@yarris.com>.
My apologies Marshall, not quite sure how it occurred but my answer was
for an entirely different question by someone else.
To answer your question, Maven seems to be working largely as designed.
I'm actually surprised that your child POMs could build in any scenario
if their reference to the parent POM contains a build property only
found in the parent POM. Because that would be a circular reference.
You should really have groupId, artifactId and version hard-coded in all
POMs.
The standard Maven way of doing things would be to have the version
hard-coded with a similar value as the version of the parent in the
child POMs. You would then use the release-plugin to manage the
increment of the version.
Is there a particular reason that you needed to define ?
<uimaj-ee-version>0.7.0</uimaj-version>
<uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-re
lease-version>
I think you need to reconsider your project version. I think you want it
as 0.7.0-SNAPSHOT.
"incubating" would seem to belong as part of an artifactId or assembly
annotation (see the asembly plugin).
I hope this helps.
William
> -----Original Message-----
> From: Marshall Schor [mailto:msa@schor.com]
> Sent: Friday, 11 January 2008 10:06 AM
> To: Maven Users List
> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
> - Sender is forged (SPF Fail)
>
> William Ferguson wrote:
> > Marshall,
> >
> > the standard solution for what you are attempting would be to
> > install/deploy those libraries "not managed by Maven" into your own
> > repository or corporate repository and then you *would*
> have access to
> > them.
> >
> > William
> >
> Hi William -
>
> I must have not communicated well. All of the libraries are
> manged by Maven. The situation where the failure occurs is
> like a startup - when a user first checks out the set of
> projects (having child POMs) and the main parent POM, then
> tries to do a "mvn install" on the parent.
>
> (I'm assuming here that they check out a development level,
> where the components have not been installed to any repository, yet).
>
> This first "mvn install" is intended to install of the parts
> into the local repository, but it only works if you don't use
> ${ ... } variable substitution in the way I was trying to use it.
>
> My question is whether this limitation on use of variable
> substitution is a maven defect, or whether it is working as
> designed (in which case - I'd appreciate learning what the
> philosophy is behind this design choice).
>
> -Marshall
> >
> >> -----Original Message-----
> >> From: Marshall Schor [mailto:msa@schor.com]
> >> Sent: Friday, 11 January 2008 9:40 AM
> >> To: Maven Users List
> >> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
> Sender is
> >> forged (SPF Fail)
> >>
> >> We define shared values as <property> elements in a parent POM and
> >> use them in child POMs. We have fragments like this, near
> the top of
> >> the parent POM:
> >>
> >> . . .
> >> <properties>
> >> . . .
> >> <uimaj-ee-version>0.7.0</uimaj-version>
> >>
> >> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
> >> </uimaj-release-version>
> >>
> >> . . .
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> I noticed I might be able to replace the
> >>
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> with
> >>
> >> <version>${uimaj-ee-release-version}</version>
> >>
> >> This only kind of worked. The way it would fail, would
> be if there
> >> were no existing versions of the parent POM in any
> repository, then
> >> the "mvn install" command for the parent POM would fail
> when scanning
> >> the child POMs, saying, for example:
> >>
> >> [ERROR] FATAL ERROR
> >> [INFO]
> >>
> >> --------------------------------------------------------------
> >> ----------
> >> [INFO] Error building POM (may not be this project's POM).
> >>
> >>
> >> Project ID:
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> Reason: Cannot find parent: org.apache.uima:uimaj-ee
> for project:
> >>
> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
> >> project
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> I found (as a workaround) that if I modified the parent
> POM to have
> >> no children (commenting out the <module> elements), then
> mvn install
> >> for the parent POM would run; furthermore, I could then
> uncomment out
> >> the <module> children and mvn install on the parent POM would now
> >> build the children OK (I guess because the parent POM was
> findable in
> >> the local repository).
> >>
> >> This problem doesn't seem to occur if the parent POM doesn't use
> >> substitutable property values for its own <version>
> number. In that
> >> case the parent POM need not be previously installed in the local
> >> repository.
> >>
> >> Is this expected behavior in Maven, or is this a defect?
> >>
> >> -Marshall
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: - possible maven defect?
Posted by Marshall Schor <ms...@schor.com>.
William Ferguson wrote:
> Marshall,
>
> the standard solution for what you are attempting would be to
> install/deploy those libraries "not managed by Maven" into your own
> repository or corporate repository and then you *would* have access to
> them.
>
> William
>
Hi William -
I must have not communicated well. All of the libraries are manged by
Maven. The situation where the failure occurs is like a startup - when
a user first checks out the set of projects (having child POMs) and the
main parent POM, then tries to do a "mvn install" on the parent.
(I'm assuming here that they check out a development level, where the
components have not been installed to any repository, yet).
This first "mvn install" is intended to install of the parts into the
local repository, but it only works if you don't use ${ ... } variable
substitution in the way I was trying to use it.
My question is whether this limitation on use of variable substitution
is a maven defect, or whether it is working as designed (in which case -
I'd appreciate learning what the philosophy is behind this design choice).
-Marshall
>
>> -----Original Message-----
>> From: Marshall Schor [mailto:msa@schor.com]
>> Sent: Friday, 11 January 2008 9:40 AM
>> To: Maven Users List
>> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
>> Sender is forged (SPF Fail)
>>
>> We define shared values as <property> elements in a parent
>> POM and use them in child POMs. We have fragments like this,
>> near the top of the parent POM:
>>
>> . . .
>> <properties>
>> . . .
>> <uimaj-ee-version>0.7.0</uimaj-version>
>>
>> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
>> </uimaj-release-version>
>>
>> . . .
>> <version>0.7.0-incubating-SNAPSHOT</version>
>>
>> I noticed I might be able to replace the
>>
>> <version>0.7.0-incubating-SNAPSHOT</version>
>>
>> with
>>
>> <version>${uimaj-ee-release-version}</version>
>>
>> This only kind of worked. The way it would fail, would be
>> if there were no existing versions of the parent POM in any
>> repository, then the "mvn install" command for the parent POM
>> would fail when scanning the child POMs, saying, for example:
>>
>> [ERROR] FATAL ERROR
>> [INFO]
>>
>> --------------------------------------------------------------
>> ----------
>> [INFO] Error building POM (may not be this project's POM).
>>
>>
>> Project ID:
>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>
>> Reason: Cannot find parent: org.apache.uima:uimaj-ee for project:
>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
>> project
>> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
>>
>> I found (as a workaround) that if I modified the parent POM
>> to have no children (commenting out the <module> elements),
>> then mvn install for the parent POM would run; furthermore, I
>> could then uncomment out the <module> children and mvn
>> install on the parent POM would now build the children OK (I
>> guess because the parent POM was findable in the local repository).
>>
>> This problem doesn't seem to occur if the parent POM doesn't
>> use substitutable property values for its own <version>
>> number. In that case the parent POM need not be previously
>> installed in the local repository.
>>
>> Is this expected behavior in Maven, or is this a defect?
>>
>> -Marshall
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org