Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
Am Tue, 18 May 2010 05:12:45 -0700 hat
"Jamie Whitehouse"
geschrieben:
The use of an explicit version is the problem. Instead
of
0.0.3-SNAPSHOT try depending on ${project.version}. In
my experience
using the fixed version the assembly plugin (and others
like the
dependency copy goals) will use what's in the local repo
not what's in
the reactor.
As suggested I changed the dependency versions to
${project.version}, but it did not help. The
release:prepare goal aborts with the same error:
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO]
--
--
[INFO] [INFO] Failed to create assembly: Failed to resolve
dependencies for proj
ect: com.acme:commons.distribution:pom:0.0.6
[INFO]
[INFO] Missing:
[INFO] --
[INFO] 1) com.acme:commons.util:jar:0.0.6
[INFO]
[INFO] Try downloading the file manually from the
project website.
[INFO]
[INFO] Then, install it using the command:
[INFO] mvn install:install-file -DgroupId=com.acme
-DartifactId=commo
ns.util -Dversion=0.0.6 -Dpackaging=jar
-Dfile=/path/to/file
[INFO]
[INFO] Alternatively, if you host your own repository
you can deploy the file
there:
[INFO] mvn deploy:deploy-file -DgroupId=com.acme
-DartifactId=commons
.util -Dversion=0.0.6 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -Dreposit
oryId=[id]
[INFO]
[INFO] Path to dependency:
[INFO] 1) com.acme:commons.distribution:pom:0.0.6
[INFO] 2) com.acme:commons.util:jar:0.0.6
[INFO]
[INFO] 2) com.acme:commons.util.test:jar:0.0.6
[INFO]
[INFO] Try downloading the file manually from the
project website.
[INFO]
[INFO] Then, install it using the command:
[INFO] mvn install:install-file -DgroupId=com.acme
-DartifactId=commo
ns.util.test -Dversion=0.0.6 -Dpackaging=jar
-Dfile=/path/to/file
[INFO]
[INFO] Alternatively, if you host your own repository
you can deploy the file
there:
[INFO] mvn deploy:deploy-file -DgroupId=com.acme
-DartifactId=commons
.util.test -Dversion=0.0.6 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -Dre
positoryId=[id]
[INFO]
[INFO] Path to dependency:
[INFO] 1) com.acme:commons.distribution:pom:0.0.6
[INFO] 2) com.acme:commons.util.test:jar:0.0.6
Note that building the assembly runs fine. Only when the
build is started in the context of mvn release:prepare the
error occurs.
-Original Message-
From: Markus Muenkel
[mailto:markus.muen...@fernuni-hagen.de]
Sent: Tuesday, May 18, 2010 6:54 AM
To: Maven Users List
Subject: Re: mvn release:prepare fails with missing
artifacts
when project to be released runs an assembly
Am Tue, 18 May 2010 09:10:05 +0100 hat
Stephen Connolly
geschrieben:
> On 18 May 2010 08:40, Markus Muenkel
>wrote:
>
>>
>>>> I'm releasing a Maven2 multi-module project. One
of the
modules is
>>>>a POM
>>>>
>>>>> project ("assembly project") that uses the
maven-assembly-plugin
>>>>>in
>>>>>> order
>>>>>> to
>>>>>> build an assembly (zip archive). The artifacts to
be assembled
>>>>>>are specified via dependencies in the POM. They
point
to modules
>>>>>>contained in the same multi-module project.
>>>>>>
>>>>>> When running mvn release:prepare on the
multi-module
project, the
>>>>>>build of the assembly project fails with the
message that the
>>>>>>dependencies cannot be resolved. These
dependencies are
>>>>>>reported with the version that should be
released,
e.g. 0.0.3.
>>>>>>Before running the goal, all dependency versions
are
>>>>>>0.0.3-SNAPSHOT.
>>>>>>
>>>>>> What seems to happen is that the snapshot version
0.0.3-SNAPSHOT
>>>>>>is replaced by 0.0.3 and then the assembly plugin
is started
>>>>>>(which is bound to the package phase).
>>>>>>
>>>>>>
>>>>>
>>>>> what goal did you bind with?
>>>>>
>>>>> It needs to be assembly:single
>>>>>
>>>>>
>>>>> Yes, it is single
>>>>
>>>>
>>>>
>>>> The assembly plugin tries to resolve the
dependencies based on
>>>>version
>>>>>
>>>>>> 0.0.3 which however do not yet exist at that
point.
>>>>>>
>>>>>>
>>>>>> The exist in the reactor, providing the project
in which
>>>>>>assembly is
>>>>> being
>>>>> invoked has dependencies on those artifacts so
that maven knows
>
RE: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
The use of an explicit version is the problem. Instead of
0.0.3-SNAPSHOT try depending on ${project.version}. In my experience
using the fixed version the assembly plugin (and others like the
dependency copy goals) will use what's in the local repo not what's in
the reactor.
> -Original Message-
> From: Markus Muenkel [mailto:markus.muen...@fernuni-hagen.de]
> Sent: Tuesday, May 18, 2010 6:54 AM
> To: Maven Users List
> Subject: Re: mvn release:prepare fails with missing artifacts
> when project to be released runs an assembly
>
> Am Tue, 18 May 2010 09:10:05 +0100 hat
> Stephen Connolly
> geschrieben:
> > On 18 May 2010 08:40, Markus Muenkel
> >wrote:
> >
> >>
> >>>> I'm releasing a Maven2 multi-module project. One of the
> modules is
> >>>>a POM
> >>>>
> >>>>> project ("assembly project") that uses the
> maven-assembly-plugin
> >>>>>in
> >>>>>> order
> >>>>>> to
> >>>>>> build an assembly (zip archive). The artifacts to be assembled
> >>>>>>are specified via dependencies in the POM. They point
> to modules
> >>>>>>contained in the same multi-module project.
> >>>>>>
> >>>>>> When running mvn release:prepare on the multi-module
> project, the
> >>>>>>build of the assembly project fails with the message that the
> >>>>>>dependencies cannot be resolved. These dependencies are
> >>>>>>reported with the version that should be released,
> e.g. 0.0.3.
> >>>>>>Before running the goal, all dependency versions are
> >>>>>>0.0.3-SNAPSHOT.
> >>>>>>
> >>>>>> What seems to happen is that the snapshot version
> 0.0.3-SNAPSHOT
> >>>>>>is replaced by 0.0.3 and then the assembly plugin is started
> >>>>>>(which is bound to the package phase).
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> what goal did you bind with?
> >>>>>
> >>>>> It needs to be assembly:single
> >>>>>
> >>>>>
> >>>>> Yes, it is single
> >>>>
> >>>>
> >>>>
> >>>> The assembly plugin tries to resolve the dependencies based on
> >>>>version
> >>>>>
> >>>>>> 0.0.3 which however do not yet exist at that point.
> >>>>>>
> >>>>>>
> >>>>>> The exist in the reactor, providing the project in which
> >>>>>>assembly is
> >>>>> being
> >>>>> invoked has dependencies on those artifacts so that maven knows
> >>>>>the build order must build the dependent projects first.
> >>>>>
> >>>>> to test if you have this working, here is a simple test
> >>>>>procedure:
> >>>>> 1. mvn versions:set
> >>>>>-DnewVersion=0.0.3-reltesting-SNAPSHOT
> >>>>> 2. mvn clean verify
> >>>>> 3. mvn versions:rollback
> >>>>>
> >>>>> 3. mvn versions:revert
> >>>>
> >>>> I executed this test procedure on the assembly project
> and in fact
> >>>>it produces the same problem as described above: the
> artifacts to
> >>>>be assembled are looked up in the repository with version
> >>>>0.0.3-reltesting-SNAPSHOT and the build fails because the
> >>>>artifacts have not yet been installed with this version.
> >>>>
> >>>> For me it looks like a hen-and-egg problem: releasing
> the assembly
> >>>>project implies building the assembly in the release
> version, but
> >>>>the assembly in turn requires the released artifacts to be
> >>>>installed in the repository.
> >>>>
> >>>> Would it be possible to have the release procedure work
> like this:
> >>>> 1) Release plugin changes the version in the multi
> module project
> >>>>(that includes the assembly project and the artifacts to be
> >>>>assembled), i.e. to
> >>>> 0.0.4
> >>>> 2) The artifacts to be assembled are built and installed in the
> >>>>repository in version 0.0.4
> >>>> 3) The assem
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 18 May 2010 11:56, Markus Muenkel wrote:
> Am Tue, 18 May 2010 09:10:05 +0100 hat
> Stephen Connolly geschrieben:
>
>> On 18 May 2010 08:40, Markus Muenkel > >wrote:
>>
>>
>>
>>> I'm releasing a Maven2 multi-module project. One of the modules is a
> POM
>
> project ("assembly project") that uses the maven-assembly-plugin in
>>
>>> order
>>> to
>>> build an assembly (zip archive). The artifacts to be assembled are
>>> specified
>>> via dependencies in the POM. They point to modules contained in the
>>> same
>>> multi-module project.
>>>
>>> When running mvn release:prepare on the multi-module project, the
>>> build
>>> of
>>> the assembly project fails with the message that the dependencies
>>> cannot
>>> be
>>> resolved. These dependencies are reported with the version that
>>> should
>>> be
>>> released, e.g. 0.0.3. Before running the goal, all dependency
>>> versions
>>> are
>>> 0.0.3-SNAPSHOT.
>>>
>>> What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is
>>> replaced by 0.0.3 and then the assembly plugin is started (which is
>>> bound
>>> to
>>> the package phase).
>>>
>>>
>>>
>> what goal did you bind with?
>>
>> It needs to be assembly:single
>>
>>
>> Yes, it is single
>>
>
>
>
> The assembly plugin tries to resolve the dependencies based on version
>
>>
>> 0.0.3 which however do not yet exist at that point.
>>>
>>>
>>> The exist in the reactor, providing the project in which assembly is
>>>
>> being
>> invoked has dependencies on those artifacts so that maven knows the
>> build
>> order must build the dependent projects first.
>>
>> to test if you have this working, here is a simple test procedure:
>> 1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT
>> 2. mvn clean verify
>> 3. mvn versions:rollback
>>
>> 3. mvn versions:revert
>>
>
> I executed this test procedure on the assembly project and in fact it
> produces the same problem as described above: the artifacts to be
> assembled
> are looked up in the repository with version 0.0.3-reltesting-SNAPSHOT
> and
> the build fails because the artifacts have not yet been installed with
> this
> version.
>
> For me it looks like a hen-and-egg problem: releasing the assembly
> project
> implies building the assembly in the release version, but the assembly
> in
> turn requires the released artifacts to be installed in the repository.
>
> Would it be possible to have the release procedure work like this:
> 1) Release plugin changes the version in the multi module project (that
> includes the assembly project and the artifacts to be assembled), i.e.
> to
> 0.0.4
> 2) The artifacts to be assembled are built and installed in the
> repository
> in version 0.0.4
> 3) The assembly is run and picks up the artifacts to be assembled from
> the
> repository in version 0.0.4
> 4) The assembly project is installed in the repository in version 0.0.4
> Currently the install step in 2) is not happening -- this seems to be
> the
> crucial part
>
>
> If you bind things to the correct phases and have the correct project
>
structure then there is no need to invoke the local repository and
everything is resolved from the reactor.
You just need to restructure your project.
Where is the assembly created?
Where is that in relation to it's dependencies?
The project structure is currently as follows:
>>>
>>> commons
>>> |
>>> |-- commons.util
>>> |
>>> |-- commons.util.test
>>> |
>>> |-- commons.distribution
>>> | |
>>> | |-- assembly_descriptor.xml
>>>
>>> where commons.distribution is the "assembly project". Its pom.xml
>>> configures the assembly plugin like this:
>>>
>>>
>>> maven-assembly-plugin
>>>
>>>
>>> make-assembly
>>> package
>>>
>>>
>>^^^ good, if you use a phase prior to package it would fail
>>
>>
>>
>>> single
>>>
>>>
>>^^^ good that is the correct goal to call
>>
>>
>>
>>>
>>>
>>>
>>>
>>> assembly_descriptor.xml
>>>
>>> commons
>>>
>>>
>>>
>>> The projects contained in the assembly are the two sibling projects
>>> commons.util and commons.util.test (both are Java projects packaged as
>>> jar).
>>> They are included in the assembly descriptor via dependencySets (I'm not
>>> sure if moduleSets would be more appropriate in this case)
>>>
>>>
>> are they also listed as dependecies of commons.distribution?
>>
>
> Yes, they are listed as
>
>
>com.acme
>commons.util
>0.0.3-SNAPSHOT
>
>
>com.acme
>commons.util.test
>0.0.3-SNAPSHOT
>
>
>
> while the assembly_descriptor.xml contains
>
>
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
Am Tue, 18 May 2010 09:10:05 +0100 hat
Stephen Connolly
geschrieben:
On 18 May 2010 08:40, Markus Muenkel
wrote:
I'm releasing a Maven2 multi-module project. One of the
modules is a POM
project ("assembly project") that uses the
maven-assembly-plugin in
order
to
build an assembly (zip archive). The artifacts to be
assembled are
specified
via dependencies in the POM. They point to modules
contained in the
same
multi-module project.
When running mvn release:prepare on the multi-module
project, the build
of
the assembly project fails with the message that the
dependencies
cannot
be
resolved. These dependencies are reported with the
version that should
be
released, e.g. 0.0.3. Before running the goal, all
dependency versions
are
0.0.3-SNAPSHOT.
What seems to happen is that the snapshot version
0.0.3-SNAPSHOT is
replaced by 0.0.3 and then the assembly plugin is
started (which is
bound
to
the package phase).
what goal did you bind with?
It needs to be assembly:single
Yes, it is single
The assembly plugin tries to resolve the dependencies
based on version
0.0.3 which however do not yet exist at that point.
The exist in the reactor, providing the project in
which assembly is
being
invoked has dependencies on those artifacts so that
maven knows the
build
order must build the dependent projects first.
to test if you have this working, here is a simple test
procedure:
1. mvn versions:set
-DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback
3. mvn versions:revert
I executed this test procedure on the assembly project
and in fact it
produces the same problem as described above: the
artifacts to be
assembled
are looked up in the repository with version
0.0.3-reltesting-SNAPSHOT
and
the build fails because the artifacts have not yet been
installed with
this
version.
For me it looks like a hen-and-egg problem: releasing
the assembly
project
implies building the assembly in the release version,
but the assembly in
turn requires the released artifacts to be installed in
the repository.
Would it be possible to have the release procedure work
like this:
1) Release plugin changes the version in the multi
module project (that
includes the assembly project and the artifacts to be
assembled), i.e. to
0.0.4
2) The artifacts to be assembled are built and installed
in the
repository
in version 0.0.4
3) The assembly is run and picks up the artifacts to be
assembled from
the
repository in version 0.0.4
4) The assembly project is installed in the repository
in version 0.0.4
Currently the install step in 2) is not happening --
this seems to be the
crucial part
If you bind things to the correct phases and have the
correct project
structure then there is no need to invoke the local
repository and
everything is resolved from the reactor.
You just need to restructure your project.
Where is the assembly created?
Where is that in relation to it's dependencies?
The project structure is currently as follows:
commons
|
|-- commons.util
|
|-- commons.util.test
|
|-- commons.distribution
| |
| |-- assembly_descriptor.xml
where commons.distribution is the "assembly project".
Its pom.xml
configures the assembly plugin like this:
maven-assembly-plugin
make-assembly
package
^^^ good, if you use a phase prior to package it
would fail
single
^^^ good that is the correct goal to call
assembly_descriptor.xml
commons
The projects contained in the assembly are the two
sibling projects
commons.util and commons.util.test (both are Java
projects packaged as jar).
They are included in the assembly descriptor via
dependencySets (I'm not
sure if moduleSets would be more appropriate in this
case)
are they also listed as dependecies of
commons.distribution?
Yes, they are listed as
com.acme
commons.util
0.0.3-SNAPSHOT
com.acme
commons.util.test
0.0.3-SNAPSHOT
while the assembly_descriptor.xml contains
com.acme:commons.util:jar
com.acme:commons.util.test:jar
false
${bundles.folder}
${artifact.groupId}.${artifact.artifactId}-${artifact.version}.${artifact.extension}
false
what is the build plan?
to find the build plan run
mvn validate
and the build plan is the listing of projects in the
order they will be
built.
Forgot to attach the build plan - here it is:
[INFO] Reactor build order:
[INFO] com.sap.helix.commons
[INFO] com.sap.helix.commons.util
[INFO] com.sap.helix.commons.util.test
[INFO] com.sap.helix.commons.distribution
commons.distribution needs to come after the ones you
want to include.
- Markus
you cannot create an assembly in a project which is the
xpath:/project/parent of the dependencies to be included
in the assembly
-Stephen
- Markus
it is essential that you only run up the lifecycle
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
Am Tue, 18 May 2010 09:10:05 +0100 hat
Stephen Connolly
geschrieben:
On 18 May 2010 08:40, Markus Muenkel
wrote:
I'm releasing a Maven2 multi-module project. One of the
modules is a POM
project ("assembly project") that uses the
maven-assembly-plugin in
order
to
build an assembly (zip archive). The artifacts to be
assembled are
specified
via dependencies in the POM. They point to modules
contained in the
same
multi-module project.
When running mvn release:prepare on the multi-module
project, the build
of
the assembly project fails with the message that the
dependencies
cannot
be
resolved. These dependencies are reported with the
version that should
be
released, e.g. 0.0.3. Before running the goal, all
dependency versions
are
0.0.3-SNAPSHOT.
What seems to happen is that the snapshot version
0.0.3-SNAPSHOT is
replaced by 0.0.3 and then the assembly plugin is
started (which is
bound
to
the package phase).
what goal did you bind with?
It needs to be assembly:single
Yes, it is single
The assembly plugin tries to resolve the dependencies
based on version
0.0.3 which however do not yet exist at that point.
The exist in the reactor, providing the project in
which assembly is
being
invoked has dependencies on those artifacts so that
maven knows the
build
order must build the dependent projects first.
to test if you have this working, here is a simple test
procedure:
1. mvn versions:set
-DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback
3. mvn versions:revert
I executed this test procedure on the assembly project
and in fact it
produces the same problem as described above: the
artifacts to be
assembled
are looked up in the repository with version
0.0.3-reltesting-SNAPSHOT
and
the build fails because the artifacts have not yet been
installed with
this
version.
For me it looks like a hen-and-egg problem: releasing
the assembly
project
implies building the assembly in the release version,
but the assembly in
turn requires the released artifacts to be installed in
the repository.
Would it be possible to have the release procedure work
like this:
1) Release plugin changes the version in the multi
module project (that
includes the assembly project and the artifacts to be
assembled), i.e. to
0.0.4
2) The artifacts to be assembled are built and installed
in the
repository
in version 0.0.4
3) The assembly is run and picks up the artifacts to be
assembled from
the
repository in version 0.0.4
4) The assembly project is installed in the repository
in version 0.0.4
Currently the install step in 2) is not happening --
this seems to be the
crucial part
If you bind things to the correct phases and have the
correct project
structure then there is no need to invoke the local
repository and
everything is resolved from the reactor.
You just need to restructure your project.
Where is the assembly created?
Where is that in relation to it's dependencies?
The project structure is currently as follows:
commons
|
|-- commons.util
|
|-- commons.util.test
|
|-- commons.distribution
| |
| |-- assembly_descriptor.xml
where commons.distribution is the "assembly project".
Its pom.xml
configures the assembly plugin like this:
maven-assembly-plugin
make-assembly
package
^^^ good, if you use a phase prior to package it
would fail
single
^^^ good that is the correct goal to call
assembly_descriptor.xml
commons
The projects contained in the assembly are the two
sibling projects
commons.util and commons.util.test (both are Java
projects packaged as jar).
They are included in the assembly descriptor via
dependencySets (I'm not
sure if moduleSets would be more appropriate in this
case)
are they also listed as dependecies of
commons.distribution?
Yes, they are listed as
com.acme
commons.util
0.0.3-SNAPSHOT
com.acme
commons.util.test
0.0.3-SNAPSHOT
while the assembly_descriptor.xml contains
com.acme:commons.util:jar
com.acme:commons.util.test:jar
false
${bundles.folder}
${artifact.groupId}.${artifact.artifactId}-${artifact.version}.${artifact.extension}
false
what is the build plan?
to find the build plan run
mvn validate
and the build plan is the listing of projects in the
order they will be
built.
commons.distribution needs to come after the ones you
want to include.
- Markus
you cannot create an assembly in a project which is the
xpath:/project/parent of the dependencies to be included
in the assembly
-Stephen
- Markus
it is essential that you only run up the lifecycle as
far as verify when
testing, as if you go as far as install, the artifacts
will have been
pushed
to the local repo (and hence issues with your reactor
will be missed)
If you are under the clock [i.e. your manager is sayi
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 18 May 2010 08:40, Markus Muenkel wrote:
>
>>> I'm releasing a Maven2 multi-module project. One of the modules is a POM
>>>
project ("assembly project") that uses the maven-assembly-plugin in
> order
> to
> build an assembly (zip archive). The artifacts to be assembled are
> specified
> via dependencies in the POM. They point to modules contained in the
> same
> multi-module project.
>
> When running mvn release:prepare on the multi-module project, the build
> of
> the assembly project fails with the message that the dependencies
> cannot
> be
> resolved. These dependencies are reported with the version that should
> be
> released, e.g. 0.0.3. Before running the goal, all dependency versions
> are
> 0.0.3-SNAPSHOT.
>
> What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is
> replaced by 0.0.3 and then the assembly plugin is started (which is
> bound
> to
> the package phase).
>
>
what goal did you bind with?
It needs to be assembly:single
Yes, it is single
>>>
>>>
>>>
>>> The assembly plugin tries to resolve the dependencies based on version
> 0.0.3 which however do not yet exist at that point.
>
>
> The exist in the reactor, providing the project in which assembly is
being
invoked has dependencies on those artifacts so that maven knows the
build
order must build the dependent projects first.
to test if you have this working, here is a simple test procedure:
1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback
3. mvn versions:revert
>>>
>>> I executed this test procedure on the assembly project and in fact it
>>> produces the same problem as described above: the artifacts to be
>>> assembled
>>> are looked up in the repository with version 0.0.3-reltesting-SNAPSHOT
>>> and
>>> the build fails because the artifacts have not yet been installed with
>>> this
>>> version.
>>>
>>> For me it looks like a hen-and-egg problem: releasing the assembly
>>> project
>>> implies building the assembly in the release version, but the assembly in
>>> turn requires the released artifacts to be installed in the repository.
>>>
>>> Would it be possible to have the release procedure work like this:
>>> 1) Release plugin changes the version in the multi module project (that
>>> includes the assembly project and the artifacts to be assembled), i.e. to
>>> 0.0.4
>>> 2) The artifacts to be assembled are built and installed in the
>>> repository
>>> in version 0.0.4
>>> 3) The assembly is run and picks up the artifacts to be assembled from
>>> the
>>> repository in version 0.0.4
>>> 4) The assembly project is installed in the repository in version 0.0.4
>>> Currently the install step in 2) is not happening -- this seems to be the
>>> crucial part
>>>
>>>
>>> If you bind things to the correct phases and have the correct project
>> structure then there is no need to invoke the local repository and
>> everything is resolved from the reactor.
>>
>> You just need to restructure your project.
>>
>> Where is the assembly created?
>>
>> Where is that in relation to it's dependencies?
>>
>> The project structure is currently as follows:
>
> commons
> |
> |-- commons.util
> |
> |-- commons.util.test
> |
> |-- commons.distribution
> | |
> | |-- assembly_descriptor.xml
>
> where commons.distribution is the "assembly project". Its pom.xml
> configures the assembly plugin like this:
>
>
> maven-assembly-plugin
>
>
> make-assembly
> package
>
^^^ good, if you use a phase prior to package it would fail
>
>single
>
^^^ good that is the correct goal to call
>
>
>
>
>
> assembly_descriptor.xml
>
>commons
>
>
>
> The projects contained in the assembly are the two sibling projects
> commons.util and commons.util.test (both are Java projects packaged as jar).
> They are included in the assembly descriptor via dependencySets (I'm not
> sure if moduleSets would be more appropriate in this case)
>
are they also listed as dependecies of commons.distribution?
what is the build plan?
to find the build plan run
mvn validate
and the build plan is the listing of projects in the order they will be
built.
commons.distribution needs to come after the ones you want to include.
>
> - Markus
>
>
> you cannot create an assembly in a project which is the
>> xpath:/project/parent of the dependencies to be included in the assembly
>>
>> -Stephen
>>
>>
>> - Markus
>>>
>>>
>>>
>>> it is essential that you only run up the lifecycle as far as verify when
testing, as if you go as far as install, the artifacts will have been
pushed
to the local repo (and hence issues with your reactor will be missed)
If you are under the clock [i.e. your manager is saying "thi
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
I'm releasing a Maven2 multi-module project. One of the
modules is a POM
project ("assembly project") that uses the
maven-assembly-plugin in order
to
build an assembly (zip archive). The artifacts to be
assembled are
specified
via dependencies in the POM. They point to modules
contained in the same
multi-module project.
When running mvn release:prepare on the multi-module
project, the build
of
the assembly project fails with the message that the
dependencies cannot
be
resolved. These dependencies are reported with the
version that should be
released, e.g. 0.0.3. Before running the goal, all
dependency versions
are
0.0.3-SNAPSHOT.
What seems to happen is that the snapshot version
0.0.3-SNAPSHOT is
replaced by 0.0.3 and then the assembly plugin is
started (which is bound
to
the package phase).
what goal did you bind with?
It needs to be assembly:single
Yes, it is single
The assembly plugin tries to resolve the dependencies
based on version
0.0.3 which however do not yet exist at that point.
The exist in the reactor, providing the project in which
assembly is being
invoked has dependencies on those artifacts so that
maven knows the build
order must build the dependent projects first.
to test if you have this working, here is a simple test
procedure:
1. mvn versions:set
-DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback
3. mvn versions:revert
I executed this test procedure on the assembly project
and in fact it
produces the same problem as described above: the
artifacts to be assembled
are looked up in the repository with version
0.0.3-reltesting-SNAPSHOT and
the build fails because the artifacts have not yet been
installed with this
version.
For me it looks like a hen-and-egg problem: releasing
the assembly project
implies building the assembly in the release version,
but the assembly in
turn requires the released artifacts to be installed in
the repository.
Would it be possible to have the release procedure work
like this:
1) Release plugin changes the version in the multi
module project (that
includes the assembly project and the artifacts to be
assembled), i.e. to
0.0.4
2) The artifacts to be assembled are built and installed
in the repository
in version 0.0.4
3) The assembly is run and picks up the artifacts to be
assembled from the
repository in version 0.0.4
4) The assembly project is installed in the repository
in version 0.0.4
Currently the install step in 2) is not happening --
this seems to be the
crucial part
If you bind things to the correct phases and have the
correct project
structure then there is no need to invoke the local
repository and
everything is resolved from the reactor.
You just need to restructure your project.
Where is the assembly created?
Where is that in relation to it's dependencies?
The project structure is currently as follows:
commons
|
|-- commons.util
|
|-- commons.util.test
|
|-- commons.distribution
| |
| |-- assembly_descriptor.xml
where commons.distribution is the "assembly project". Its
pom.xml configures the assembly plugin like this:
maven-assembly-plugin
make-assembly
package
single
assembly_descriptor.xml
commons
The projects contained in the assembly are the two sibling
projects commons.util and commons.util.test (both are Java
projects packaged as jar). They are included in the
assembly descriptor via dependencySets (I'm not sure if
moduleSets would be more appropriate in this case)
- Markus
you cannot create an assembly in a project which is the
xpath:/project/parent of the dependencies to be included
in the assembly
-Stephen
- Markus
it is essential that you only run up the lifecycle as
far as verify when
testing, as if you go as far as install, the artifacts
will have been
pushed
to the local repo (and hence issues with your reactor
will be missed)
If you are under the clock [i.e. your manager is saying
"this needs to be
released yesterday, why did you recommend maven, your
future at this
company
is being questioned"] then just change the
preparationGoals from "clean
verify" to "clean install" to get a release out the
door. But the reality
is
that such a release can end up with mixed build
artifacts, wherein the
dependencies copied into your assembly where the ones
built during the
release:prepare, while the same artifacts copied to your
remote repository
were built during release:perform... so that if somebody
checks say the
md5
of the jar inside the assembly against the md5 of that
same jar deployed
to
the maven repo, they will find that the checksums do not
match (different
timestamps)... additionally, if you use remoteTagging
(which you pretty
much
need to) and somebody commits while release:prepare is
running, then the
release:perform will checkout different code and the
subtle issues of
bundled artifact mismatches
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 17 May 2010 14:13, Markus Muenkel wrote:
>
> I'm releasing a Maven2 multi-module project. One of the modules is a POM
>>> project ("assembly project") that uses the maven-assembly-plugin in order
>>> to
>>> build an assembly (zip archive). The artifacts to be assembled are
>>> specified
>>> via dependencies in the POM. They point to modules contained in the same
>>> multi-module project.
>>>
>>> When running mvn release:prepare on the multi-module project, the build
>>> of
>>> the assembly project fails with the message that the dependencies cannot
>>> be
>>> resolved. These dependencies are reported with the version that should be
>>> released, e.g. 0.0.3. Before running the goal, all dependency versions
>>> are
>>> 0.0.3-SNAPSHOT.
>>>
>>> What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is
>>> replaced by 0.0.3 and then the assembly plugin is started (which is bound
>>> to
>>> the package phase).
>>>
>>
>>
>> what goal did you bind with?
>>
>> It needs to be assembly:single
>>
>>
> Yes, it is single
>
>
>
>> The assembly plugin tries to resolve the dependencies based on version
>>> 0.0.3 which however do not yet exist at that point.
>>>
>>>
>> The exist in the reactor, providing the project in which assembly is being
>> invoked has dependencies on those artifacts so that maven knows the build
>> order must build the dependent projects first.
>>
>> to test if you have this working, here is a simple test procedure:
>> 1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT
>> 2. mvn clean verify
>> 3. mvn versions:rollback
>>
> 3. mvn versions:revert
>
> I executed this test procedure on the assembly project and in fact it
> produces the same problem as described above: the artifacts to be assembled
> are looked up in the repository with version 0.0.3-reltesting-SNAPSHOT and
> the build fails because the artifacts have not yet been installed with this
> version.
>
> For me it looks like a hen-and-egg problem: releasing the assembly project
> implies building the assembly in the release version, but the assembly in
> turn requires the released artifacts to be installed in the repository.
>
> Would it be possible to have the release procedure work like this:
> 1) Release plugin changes the version in the multi module project (that
> includes the assembly project and the artifacts to be assembled), i.e. to
> 0.0.4
> 2) The artifacts to be assembled are built and installed in the repository
> in version 0.0.4
> 3) The assembly is run and picks up the artifacts to be assembled from the
> repository in version 0.0.4
> 4) The assembly project is installed in the repository in version 0.0.4
> Currently the install step in 2) is not happening -- this seems to be the
> crucial part
>
>
If you bind things to the correct phases and have the correct project
structure then there is no need to invoke the local repository and
everything is resolved from the reactor.
You just need to restructure your project.
Where is the assembly created?
Where is that in relation to it's dependencies?
you cannot create an assembly in a project which is the
xpath:/project/parent of the dependencies to be included in the assembly
-Stephen
> - Markus
>
>
>
>> it is essential that you only run up the lifecycle as far as verify when
>> testing, as if you go as far as install, the artifacts will have been
>> pushed
>> to the local repo (and hence issues with your reactor will be missed)
>>
>> If you are under the clock [i.e. your manager is saying "this needs to be
>> released yesterday, why did you recommend maven, your future at this
>> company
>> is being questioned"] then just change the preparationGoals from "clean
>> verify" to "clean install" to get a release out the door. But the reality
>> is
>> that such a release can end up with mixed build artifacts, wherein the
>> dependencies copied into your assembly where the ones built during the
>> release:prepare, while the same artifacts copied to your remote repository
>> were built during release:perform... so that if somebody checks say the
>> md5
>> of the jar inside the assembly against the md5 of that same jar deployed
>> to
>> the maven repo, they will find that the checksums do not match (different
>> timestamps)... additionally, if you use remoteTagging (which you pretty
>> much
>> need to) and somebody commits while release:prepare is running, then the
>> release:perform will checkout different code and the subtle issues of
>> bundled artifact mismatches _will_ bite you in the ass.
>>
>> So what I am saying is that you need to fix it so that your build works
>> with
>> "clean verify" on a virgin version number (i.e. a version number that has
>> never been built before)... but if time pressures are forced on you, you
>> can
>> get a release out... just don't forget to fix the real problem
>>
>> -Stephen
>>
>> I guess it is not a problem in Maven but I'm missing practice on how to
>>
>>> perform a successful release in this situation.
>>>
>>>
>
>
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
I'm releasing a Maven2 multi-module project. One of the
modules is a POM
project ("assembly project") that uses the
maven-assembly-plugin in order to
build an assembly (zip archive). The artifacts to be
assembled are specified
via dependencies in the POM. They point to modules
contained in the same
multi-module project.
When running mvn release:prepare on the multi-module
project, the build of
the assembly project fails with the message that the
dependencies cannot be
resolved. These dependencies are reported with the
version that should be
released, e.g. 0.0.3. Before running the goal, all
dependency versions are
0.0.3-SNAPSHOT.
What seems to happen is that the snapshot version
0.0.3-SNAPSHOT is
replaced by 0.0.3 and then the assembly plugin is
started (which is bound to
the package phase).
what goal did you bind with?
It needs to be assembly:single
Yes, it is single
The assembly plugin tries to resolve the dependencies
based on version
0.0.3 which however do not yet exist at that point.
The exist in the reactor, providing the project in which
assembly is being
invoked has dependencies on those artifacts so that
maven knows the build
order must build the dependent projects first.
to test if you have this working, here is a simple test
procedure:
1. mvn versions:set
-DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback
3. mvn versions:revert
I executed this test procedure on the assembly project and
in fact it produces the same problem as described above:
the artifacts to be assembled are looked up in the
repository with version 0.0.3-reltesting-SNAPSHOT and the
build fails because the artifacts have not yet been
installed with this version.
For me it looks like a hen-and-egg problem: releasing the
assembly project implies building the assembly in the
release version, but the assembly in turn requires the
released artifacts to be installed in the repository.
Would it be possible to have the release procedure work
like this:
1) Release plugin changes the version in the multi module
project (that includes the assembly project and the
artifacts to be assembled), i.e. to 0.0.4
2) The artifacts to be assembled are built and installed
in the repository in version 0.0.4
3) The assembly is run and picks up the artifacts to be
assembled from the repository in version 0.0.4
4) The assembly project is installed in the repository in
version 0.0.4
Currently the install step in 2) is not happening -- this
seems to be the crucial part
- Markus
it is essential that you only run up the lifecycle as
far as verify when
testing, as if you go as far as install, the artifacts
will have been pushed
to the local repo (and hence issues with your reactor
will be missed)
If you are under the clock [i.e. your manager is saying
"this needs to be
released yesterday, why did you recommend maven, your
future at this company
is being questioned"] then just change the
preparationGoals from "clean
verify" to "clean install" to get a release out the
door. But the reality is
that such a release can end up with mixed build
artifacts, wherein the
dependencies copied into your assembly where the ones
built during the
release:prepare, while the same artifacts copied to your
remote repository
were built during release:perform... so that if somebody
checks say the md5
of the jar inside the assembly against the md5 of that
same jar deployed to
the maven repo, they will find that the checksums do not
match (different
timestamps)... additionally, if you use remoteTagging
(which you pretty much
need to) and somebody commits while release:prepare is
running, then the
release:perform will checkout different code and the
subtle issues of
bundled artifact mismatches _will_ bite you in the ass.
So what I am saying is that you need to fix it so that
your build works with
"clean verify" on a virgin version number (i.e. a
version number that has
never been built before)... but if time pressures are
forced on you, you can
get a release out... just don't forget to fix the real
problem
-Stephen
I guess it is not a problem in Maven but I'm missing
practice on how to
perform a successful release in this situation.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 11 May 2010 17:16, Markus Muenkel wrote:
> I'm releasing a Maven2 multi-module project. One of the modules is a POM
> project ("assembly project") that uses the maven-assembly-plugin in order to
> build an assembly (zip archive). The artifacts to be assembled are specified
> via dependencies in the POM. They point to modules contained in the same
> multi-module project.
>
> When running mvn release:prepare on the multi-module project, the build of
> the assembly project fails with the message that the dependencies cannot be
> resolved. These dependencies are reported with the version that should be
> released, e.g. 0.0.3. Before running the goal, all dependency versions are
> 0.0.3-SNAPSHOT.
>
> What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is
> replaced by 0.0.3 and then the assembly plugin is started (which is bound to
> the package phase).
what goal did you bind with?
It needs to be assembly:single
> The assembly plugin tries to resolve the dependencies based on version
> 0.0.3 which however do not yet exist at that point.
>
The exist in the reactor, providing the project in which assembly is being
invoked has dependencies on those artifacts so that maven knows the build
order must build the dependent projects first.
to test if you have this working, here is a simple test procedure:
1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback
it is essential that you only run up the lifecycle as far as verify when
testing, as if you go as far as install, the artifacts will have been pushed
to the local repo (and hence issues with your reactor will be missed)
If you are under the clock [i.e. your manager is saying "this needs to be
released yesterday, why did you recommend maven, your future at this company
is being questioned"] then just change the preparationGoals from "clean
verify" to "clean install" to get a release out the door. But the reality is
that such a release can end up with mixed build artifacts, wherein the
dependencies copied into your assembly where the ones built during the
release:prepare, while the same artifacts copied to your remote repository
were built during release:perform... so that if somebody checks say the md5
of the jar inside the assembly against the md5 of that same jar deployed to
the maven repo, they will find that the checksums do not match (different
timestamps)... additionally, if you use remoteTagging (which you pretty much
need to) and somebody commits while release:prepare is running, then the
release:perform will checkout different code and the subtle issues of
bundled artifact mismatches _will_ bite you in the ass.
So what I am saying is that you need to fix it so that your build works with
"clean verify" on a virgin version number (i.e. a version number that has
never been built before)... but if time pressures are forced on you, you can
get a release out... just don't forget to fix the real problem
-Stephen
I guess it is not a problem in Maven but I'm missing practice on how to
> perform a successful release in this situation.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
