Am Tue, 18 May 2010 05:12:45 -0700 hat
"Jamie Whitehouse" <[email protected]>
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:[email protected]]
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 <[email protected]>
geschrieben:
> On 18 May 2010 08:40, Markus Muenkel
><[email protected]>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 <goal>single</goal>
>>>>
>>>>
>>>>
>>>> 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:
>>
>> <plugin>
>> <artifactId>maven-assembly-plugin</artifactId>
>> <executions>
>> <execution>
>> <id>make-assembly</id>
>> <phase>package</phase>
>>
>
> ^^^ good, if you use a phase prior to package
it would fail
>
>
>> <goals>
>> <goal>single</goal>
>>
>
> ^^^ good that is the correct goal to call
>
>
>> </goals>
>> </execution>
>> </executions>
>> <configuration>
>> <descriptors>
>> <descriptor>assembly_descriptor.xml</descriptor>
>> </descriptors>
>> <finalName>commons</finalName>
>> </configuration>
>> </plugin>
>>
>> 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
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>commons.util</artifactId>
<version>0.0.3-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.acme</groupId>
<artifactId>commons.util.test</artifactId>
<version>0.0.3-SNAPSHOT</version>
</dependency>
</dependencies>
while the assembly_descriptor.xml contains
<dependencySets>
<dependencySet>
<includes>
<include>com.acme:commons.util:jar</include>
<include>com.acme:commons.util.test:jar</include>
</includes>
<unpack>false</unpack>
<outputDirectory>${bundles.folder}</outputDirectory>
<outputFileNameMapping>${artifact.groupId}.${artifact.artifact
Id}-${artifact.version}.${artifact.extension}
</outputFileNameMapping>
<useProjectArtifact>false</useProjectArtifact>
</dependencySet>
</dependencySets>
>
> 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 "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:
>>[email protected]
>> For additional commands, e-mail:
>>[email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files
attached may contain confidential and proprietary
information of Alcatel-Lucent and/or its affiliated
entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting,
or refraining from acting, on any information contained
in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the sender immediately,
destroy the original transmission and its attachments and
do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any
medium. Copyright in this e-mail and any attachments
belongs to Alcatel-Lucent and/or its affiliated entities.
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
For additional commands, e-mail:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
