You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michelle Caisse <mc...@sonic.net> on 2013/08/10 20:03:07 UTC
Internal dependency problem with clean build on the release branch
Hi all,
Preparatory to attempting a release, I cleaned my local repository and
did "mvn clean install". On building exectck, I got a build error:
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) javax.jdo:jdo-api:jar:3.1
This is because, per the apache instructions, our release artifacts have
-SNAPSHOT versions, but all dependencies, including the dependency on
the api jar that we are in the process of releasing, are to non
-SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we are
dependent on jdo-api-3.1.jar. What is the best way around this issue?
-- Michelle
Re: Internal dependency problem with clean build on the release branch
Posted by Michael Bouschen <mi...@akquinet.de>.
Hi Michelle,
> Thanks for catching my error, Michael.
you're welcome.
>
> Did we decide at a meeting that it is not a good idea to include the
> api in the tck source bundle?
>
What I recall is that we want to have a single source distribution
including everything, am I right?
Regards Michael
> -- Michelle
>
> On 8/14/2013 3:54 AM, Michael Bouschen wrote:
>
>> Hi Michelle,
>>
>> I also got a fright yesterday: no .zip and .gz files! Then I realized
>> I have to use the apache-release profile in order to generate the src
>> distribution files.
>> Then I tried 'mvn -Papache-release clean package'. This creates a
>> target directory on top level:
>>
>> % ls -l target
>> total 7904
>> drwxrwxr-x 2 mbouschen staff 68 14 Aug 12:08 archive-tmp
>> -rw-rw-r-- 1 mbouschen staff 1170374 14 Aug 12:08
>> jdo-3.1-SNAPSHOT-src.tar.gz
>> -rw-rw-r-- 1 mbouschen staff 2871855 14 Aug 12:08
>> jdo-3.1-SNAPSHOT-src.zip
>>
>>
>> About the root pom: apache-11.pom updates a couple of plugin
>> versions, so maybe we should use that.
>>
>> I changed the root pom as suggested and a 'mvn clean install' works
>> as expected, meaning the change does not break anything when running
>> the tck. But I did not try to deploy.
>>
>> Regards Michael
>>
>>> Hi Michael,
>>>
>>> Something seems to have gone wrong with assembly.xml. It now does
>>> not create the .zip and .gz files in the local repository on "mvn
>>> clean install", though it does still create all the subproject jars.
>>>
>>> I can try playing with the changes to the root pom that you suggest.
>>> But I notice there is an apache-11.pom now. Maybe we should be using
>>> that.
>>>
>>> -- Michelle
>>>
>>> On 8/13/2013 9:22 AM, Michael Bouschen wrote:
>>>> Hi Michelle,
>>>>> Michael,
>>>>>
>>>>> I've checked in the changes to the branch, with internal
>>>>> dependency version now set to 3.1-SNAPSHOT. That appears to work,
>>>>> but I'm encountering several more problems.
>>>>> 1. The release zip file does not include the parent-pom project,
>>>>> so you can't build from the release.
>>>> there was a bug in the assembly.xml: the section listing all our
>>>> submodules used a wrong groupid for the parent-pom (javax.jdo
>>>> instead of org.apache.jdo). So when packaging the src-file it was
>>>> looking for an artifact that does not exist. I fixed the assembly
>>>> and checked it in. For some reason the assembly.xml inculded the
>>>> assembly definition <assembly> ... </assembly> three times. I
>>>> removed the duplicates.
>>>>
>>>>> 2. When I attempt to do mvn deploy, I get the following error. It
>>>>> looks like we need some more xml in our poms.
>>>>>
>>>>
>>>> This is strage, because the apache parent pom defines these
>>>> settings. I found the following in apache-10.pom:
>>>>
>>>> <distributionManagement>
>>>> <repository>
>>>> <id>apache.releases.https</id>
>>>> <name>Apache Release Distribution Repository</name>
>>>> <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
>>>>
>>>> </repository>
>>>> <snapshotRepository>
>>>> <id>apache.snapshots.https</id>
>>>> <name>${distMgmtSnapshotsName}</name>
>>>> <url>${distMgmtSnapshotsUrl}</url>
>>>> </snapshotRepository>
>>>> </distributionManagement>
>>>>
>>>> I think this is what we need, correct?
>>>>
>>>> Maybe the issue is that the root pom.xml in 3.1-rc1 does not define
>>>> a parent pom. Only the pom.xml in paranet-pom refers the apache
>>>> parent-pom.
>>>> Would it work if our root pom uses the JDO parent-pom as the parent
>>>> pom?
>>>>
>>>> <parent>
>>>> <groupId>org.apache.jdo</groupId>
>>>> <artifactId>parent-pom</artifactId>
>>>> <version>3.1-SNAPSHOT</version>
>>>> <relativePath>parent-pom</relativePath>
>>>> </parent>
>>>>
>>>> Regards Michael
>>>>
>>>>> [ERROR] BUILD ERROR
>>>>> [INFO]
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> [INFO] Failed to configure plugin parameters for:
>>>>> org.apache.maven.plugins:maven-deploy-plugin:2.4
>>>>>
>>>>> check that the following section of the pom.xml is present and
>>>>> correct:
>>>>>
>>>>> <distributionManagement>
>>>>> <!-- use the following if you're not using a snapshot version. -->
>>>>> <repository>
>>>>> <id>repo</id>
>>>>> <name>Repository Name</name>
>>>>> <url>scp://host/path/to/repo</url>
>>>>> </repository>
>>>>> <!-- use the following if you ARE using a snapshot version. -->
>>>>> <snapshotRepository>
>>>>> <id>repo</id>
>>>>> <name>Repository Name</name>
>>>>> <url>scp://host/path/to/repo</url>
>>>>> </snapshotRepository>
>>>>> </distributionManagement>
>>>>>
>>>>> -- Michelle
>>>>>
>>>>> On 8/12/2013 10:44 PM, Michael Bouschen wrote:
>>>>>> Hi Michelle,
>>>>>>
>>>>>> sorry for the late response, I found your email today.
>>>>>>
>>>>>> You mentioned "but all dependencies, including the dependency on
>>>>>> the api jar that we are in the process of releasing, are to non
>>>>>> -SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we
>>>>>> are dependent on jdo-api-3.1.jar".
>>>>>>
>>>>>> I think that our own submodules (like jdo-api) still can have
>>>>>> -SNAPSHOT versions in the dependencies section of the pom. The
>>>>>> maven release plugin will update these -SNAPSHOT version names,
>>>>>> too. I propose you change the version of the jdo-api in the
>>>>>> dependencies section to 3.1-SNAPSHOT.
>>>>>>
>>>>>> Can you send me a patch with your changes of the 3.1-rc1 branch,
>>>>>> then I try a mvn clean install with a clean local repository.
>>>>>>
>>>>>> Regards Michael
>>>>>>
>>>>>>> Yeah, I don't know of a way unless there's some kind of option
>>>>>>> in the maven release plugin that lets you set up your pom some
>>>>>>> other way. Here's a link to someone who seems to have a similar
>>>>>>> problem, as far as I understand what they are saying:
>>>>>>> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>>>>>>>
>>>>>>> Michael has some familiarity with the maven versions plugin that
>>>>>>> is mentioned in the response.
>>>>>>>
>>>>>>> -- Michelle
>>>>>>>
>>>>>>> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>>>>>>>> Sounds pretty strange. So it would be impossible to release
>>>>>>>> co-dependent artifacts?
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Preparatory to attempting a release, I cleaned my local
>>>>>>>>> repository and did "mvn clean install". On building exectck,
>>>>>>>>> I got a build error:
>>>>>>>>>
>>>>>>>>> [ERROR] BUILD ERROR
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> [INFO] Failed to resolve artifact.
>>>>>>>>>
>>>>>>>>> Missing:
>>>>>>>>> ----------
>>>>>>>>> 1) javax.jdo:jdo-api:jar:3.1
>>>>>>>>>
>>>>>>>>> This is because, per the apache instructions, our release
>>>>>>>>> artifacts have -SNAPSHOT versions, but all dependencies,
>>>>>>>>> including the dependency on the api jar that we are in the
>>>>>>>>> process of releasing, are to non -SNAPSHOT versions. So, we
>>>>>>>>> build jdo-api-3.1-SNAPSHOT.jar, but we are dependent on
>>>>>>>>> jdo-api-3.1.jar. What is the best way around this issue?
>>>>>>>>>
>>>>>>>>> -- Michelle
>>>>>>>> Craig L Russell
>>>>>>>> Architect, Oracle
>>>>>>>> http://db.apache.org/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
*Michael Bouschen*
*Prokurist*
akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Web: www.akquinet.de <http://www.akquinet.de>
akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Re: Internal dependency problem with clean build on the release branch
Posted by Michelle Caisse <mc...@sonic.net>.
Thanks for catching my error, Michael.
Did we decide at a meeting that it is not a good idea to include the api
in the tck source bundle?
-- Michelle
On 8/14/2013 3:54 AM, Michael Bouschen wrote:
> Hi Michelle,
>
> I also got a fright yesterday: no .zip and .gz files! Then I realized
> I have to use the apache-release profile in order to generate the src
> distribution files.
> Then I tried 'mvn -Papache-release clean package'. This creates a
> target directory on top level:
>
> % ls -l target
> total 7904
> drwxrwxr-x 2 mbouschen staff 68 14 Aug 12:08 archive-tmp
> -rw-rw-r-- 1 mbouschen staff 1170374 14 Aug 12:08
> jdo-3.1-SNAPSHOT-src.tar.gz
> -rw-rw-r-- 1 mbouschen staff 2871855 14 Aug 12:08
> jdo-3.1-SNAPSHOT-src.zip
>
>
> About the root pom: apache-11.pom updates a couple of plugin versions,
> so maybe we should use that.
>
> I changed the root pom as suggested and a 'mvn clean install' works as
> expected, meaning the change does not break anything when running the
> tck. But I did not try to deploy.
>
> Regards Michael
>
>> Hi Michael,
>>
>> Something seems to have gone wrong with assembly.xml. It now does not
>> create the .zip and .gz files in the local repository on "mvn clean
>> install", though it does still create all the subproject jars.
>>
>> I can try playing with the changes to the root pom that you suggest.
>> But I notice there is an apache-11.pom now. Maybe we should be using
>> that.
>>
>> -- Michelle
>>
>> On 8/13/2013 9:22 AM, Michael Bouschen wrote:
>>> Hi Michelle,
>>>> Michael,
>>>>
>>>> I've checked in the changes to the branch, with internal dependency
>>>> version now set to 3.1-SNAPSHOT. That appears to work, but I'm
>>>> encountering several more problems.
>>>> 1. The release zip file does not include the parent-pom project, so
>>>> you can't build from the release.
>>> there was a bug in the assembly.xml: the section listing all our
>>> submodules used a wrong groupid for the parent-pom (javax.jdo
>>> instead of org.apache.jdo). So when packaging the src-file it was
>>> looking for an artifact that does not exist. I fixed the assembly
>>> and checked it in. For some reason the assembly.xml inculded the
>>> assembly definition <assembly> ... </assembly> three times. I
>>> removed the duplicates.
>>>
>>>> 2. When I attempt to do mvn deploy, I get the following error. It
>>>> looks like we need some more xml in our poms.
>>>>
>>>
>>> This is strage, because the apache parent pom defines these
>>> settings. I found the following in apache-10.pom:
>>>
>>> <distributionManagement>
>>> <repository>
>>> <id>apache.releases.https</id>
>>> <name>Apache Release Distribution Repository</name>
>>> <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
>>>
>>> </repository>
>>> <snapshotRepository>
>>> <id>apache.snapshots.https</id>
>>> <name>${distMgmtSnapshotsName}</name>
>>> <url>${distMgmtSnapshotsUrl}</url>
>>> </snapshotRepository>
>>> </distributionManagement>
>>>
>>> I think this is what we need, correct?
>>>
>>> Maybe the issue is that the root pom.xml in 3.1-rc1 does not define
>>> a parent pom. Only the pom.xml in paranet-pom refers the apache
>>> parent-pom.
>>> Would it work if our root pom uses the JDO parent-pom as the parent
>>> pom?
>>>
>>> <parent>
>>> <groupId>org.apache.jdo</groupId>
>>> <artifactId>parent-pom</artifactId>
>>> <version>3.1-SNAPSHOT</version>
>>> <relativePath>parent-pom</relativePath>
>>> </parent>
>>>
>>> Regards Michael
>>>
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> [INFO] Failed to configure plugin parameters for:
>>>> org.apache.maven.plugins:maven-deploy-plugin:2.4
>>>>
>>>> check that the following section of the pom.xml is present and
>>>> correct:
>>>>
>>>> <distributionManagement>
>>>> <!-- use the following if you're not using a snapshot version. -->
>>>> <repository>
>>>> <id>repo</id>
>>>> <name>Repository Name</name>
>>>> <url>scp://host/path/to/repo</url>
>>>> </repository>
>>>> <!-- use the following if you ARE using a snapshot version. -->
>>>> <snapshotRepository>
>>>> <id>repo</id>
>>>> <name>Repository Name</name>
>>>> <url>scp://host/path/to/repo</url>
>>>> </snapshotRepository>
>>>> </distributionManagement>
>>>>
>>>> -- Michelle
>>>>
>>>> On 8/12/2013 10:44 PM, Michael Bouschen wrote:
>>>>> Hi Michelle,
>>>>>
>>>>> sorry for the late response, I found your email today.
>>>>>
>>>>> You mentioned "but all dependencies, including the dependency on
>>>>> the api jar that we are in the process of releasing, are to non
>>>>> -SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we
>>>>> are dependent on jdo-api-3.1.jar".
>>>>>
>>>>> I think that our own submodules (like jdo-api) still can have
>>>>> -SNAPSHOT versions in the dependencies section of the pom. The
>>>>> maven release plugin will update these -SNAPSHOT version names,
>>>>> too. I propose you change the version of the jdo-api in the
>>>>> dependencies section to 3.1-SNAPSHOT.
>>>>>
>>>>> Can you send me a patch with your changes of the 3.1-rc1 branch,
>>>>> then I try a mvn clean install with a clean local repository.
>>>>>
>>>>> Regards Michael
>>>>>
>>>>>> Yeah, I don't know of a way unless there's some kind of option in
>>>>>> the maven release plugin that lets you set up your pom some other
>>>>>> way. Here's a link to someone who seems to have a similar
>>>>>> problem, as far as I understand what they are saying:
>>>>>> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>>>>>>
>>>>>> Michael has some familiarity with the maven versions plugin that
>>>>>> is mentioned in the response.
>>>>>>
>>>>>> -- Michelle
>>>>>>
>>>>>> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>>>>>>> Sounds pretty strange. So it would be impossible to release
>>>>>>> co-dependent artifacts?
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Preparatory to attempting a release, I cleaned my local
>>>>>>>> repository and did "mvn clean install". On building exectck, I
>>>>>>>> got a build error:
>>>>>>>>
>>>>>>>> [ERROR] BUILD ERROR
>>>>>>>> [INFO]
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> [INFO] Failed to resolve artifact.
>>>>>>>>
>>>>>>>> Missing:
>>>>>>>> ----------
>>>>>>>> 1) javax.jdo:jdo-api:jar:3.1
>>>>>>>>
>>>>>>>> This is because, per the apache instructions, our release
>>>>>>>> artifacts have -SNAPSHOT versions, but all dependencies,
>>>>>>>> including the dependency on the api jar that we are in the
>>>>>>>> process of releasing, are to non -SNAPSHOT versions. So, we
>>>>>>>> build jdo-api-3.1-SNAPSHOT.jar, but we are dependent on
>>>>>>>> jdo-api-3.1.jar. What is the best way around this issue?
>>>>>>>>
>>>>>>>> -- Michelle
>>>>>>> Craig L Russell
>>>>>>> Architect, Oracle
>>>>>>> http://db.apache.org/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Internal dependency problem with clean build on the release branch
Posted by Michael Bouschen <mi...@akquinet.de>.
Hi Michelle,
I also got a fright yesterday: no .zip and .gz files! Then I realized I
have to use the apache-release profile in order to generate the src
distribution files.
Then I tried 'mvn -Papache-release clean package'. This creates a target
directory on top level:
% ls -l target
total 7904
drwxrwxr-x 2 mbouschen staff 68 14 Aug 12:08 archive-tmp
-rw-rw-r-- 1 mbouschen staff 1170374 14 Aug 12:08
jdo-3.1-SNAPSHOT-src.tar.gz
-rw-rw-r-- 1 mbouschen staff 2871855 14 Aug 12:08
jdo-3.1-SNAPSHOT-src.zip
About the root pom: apache-11.pom updates a couple of plugin versions,
so maybe we should use that.
I changed the root pom as suggested and a 'mvn clean install' works as
expected, meaning the change does not break anything when running the
tck. But I did not try to deploy.
Regards Michael
> Hi Michael,
>
> Something seems to have gone wrong with assembly.xml. It now does not
> create the .zip and .gz files in the local repository on "mvn clean
> install", though it does still create all the subproject jars.
>
> I can try playing with the changes to the root pom that you suggest.
> But I notice there is an apache-11.pom now. Maybe we should be using
> that.
>
> -- Michelle
>
> On 8/13/2013 9:22 AM, Michael Bouschen wrote:
>> Hi Michelle,
>>> Michael,
>>>
>>> I've checked in the changes to the branch, with internal dependency
>>> version now set to 3.1-SNAPSHOT. That appears to work, but I'm
>>> encountering several more problems.
>>> 1. The release zip file does not include the parent-pom project, so
>>> you can't build from the release.
>> there was a bug in the assembly.xml: the section listing all our
>> submodules used a wrong groupid for the parent-pom (javax.jdo instead
>> of org.apache.jdo). So when packaging the src-file it was looking for
>> an artifact that does not exist. I fixed the assembly and checked it
>> in. For some reason the assembly.xml inculded the assembly definition
>> <assembly> ... </assembly> three times. I removed the duplicates.
>>
>>> 2. When I attempt to do mvn deploy, I get the following error. It
>>> looks like we need some more xml in our poms.
>>>
>>
>> This is strage, because the apache parent pom defines these settings.
>> I found the following in apache-10.pom:
>>
>> <distributionManagement>
>> <repository>
>> <id>apache.releases.https</id>
>> <name>Apache Release Distribution Repository</name>
>> <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
>>
>> </repository>
>> <snapshotRepository>
>> <id>apache.snapshots.https</id>
>> <name>${distMgmtSnapshotsName}</name>
>> <url>${distMgmtSnapshotsUrl}</url>
>> </snapshotRepository>
>> </distributionManagement>
>>
>> I think this is what we need, correct?
>>
>> Maybe the issue is that the root pom.xml in 3.1-rc1 does not define a
>> parent pom. Only the pom.xml in paranet-pom refers the apache
>> parent-pom.
>> Would it work if our root pom uses the JDO parent-pom as the parent pom?
>>
>> <parent>
>> <groupId>org.apache.jdo</groupId>
>> <artifactId>parent-pom</artifactId>
>> <version>3.1-SNAPSHOT</version>
>> <relativePath>parent-pom</relativePath>
>> </parent>
>>
>> Regards Michael
>>
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> ------------------------------------------------------------------------
>>>
>>> [INFO] Failed to configure plugin parameters for:
>>> org.apache.maven.plugins:maven-deploy-plugin:2.4
>>>
>>> check that the following section of the pom.xml is present and correct:
>>>
>>> <distributionManagement>
>>> <!-- use the following if you're not using a snapshot version. -->
>>> <repository>
>>> <id>repo</id>
>>> <name>Repository Name</name>
>>> <url>scp://host/path/to/repo</url>
>>> </repository>
>>> <!-- use the following if you ARE using a snapshot version. -->
>>> <snapshotRepository>
>>> <id>repo</id>
>>> <name>Repository Name</name>
>>> <url>scp://host/path/to/repo</url>
>>> </snapshotRepository>
>>> </distributionManagement>
>>>
>>> -- Michelle
>>>
>>> On 8/12/2013 10:44 PM, Michael Bouschen wrote:
>>>> Hi Michelle,
>>>>
>>>> sorry for the late response, I found your email today.
>>>>
>>>> You mentioned "but all dependencies, including the dependency on
>>>> the api jar that we are in the process of releasing, are to non
>>>> -SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we
>>>> are dependent on jdo-api-3.1.jar".
>>>>
>>>> I think that our own submodules (like jdo-api) still can have
>>>> -SNAPSHOT versions in the dependencies section of the pom. The
>>>> maven release plugin will update these -SNAPSHOT version names,
>>>> too. I propose you change the version of the jdo-api in the
>>>> dependencies section to 3.1-SNAPSHOT.
>>>>
>>>> Can you send me a patch with your changes of the 3.1-rc1 branch,
>>>> then I try a mvn clean install with a clean local repository.
>>>>
>>>> Regards Michael
>>>>
>>>>> Yeah, I don't know of a way unless there's some kind of option in
>>>>> the maven release plugin that lets you set up your pom some other
>>>>> way. Here's a link to someone who seems to have a similar problem,
>>>>> as far as I understand what they are saying:
>>>>> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>>>>>
>>>>> Michael has some familiarity with the maven versions plugin that
>>>>> is mentioned in the response.
>>>>>
>>>>> -- Michelle
>>>>>
>>>>> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>>>>>> Sounds pretty strange. So it would be impossible to release
>>>>>> co-dependent artifacts?
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Preparatory to attempting a release, I cleaned my local
>>>>>>> repository and did "mvn clean install". On building exectck, I
>>>>>>> got a build error:
>>>>>>>
>>>>>>> [ERROR] BUILD ERROR
>>>>>>> [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] Failed to resolve artifact.
>>>>>>>
>>>>>>> Missing:
>>>>>>> ----------
>>>>>>> 1) javax.jdo:jdo-api:jar:3.1
>>>>>>>
>>>>>>> This is because, per the apache instructions, our release
>>>>>>> artifacts have -SNAPSHOT versions, but all dependencies,
>>>>>>> including the dependency on the api jar that we are in the
>>>>>>> process of releasing, are to non -SNAPSHOT versions. So, we
>>>>>>> build jdo-api-3.1-SNAPSHOT.jar, but we are dependent on
>>>>>>> jdo-api-3.1.jar. What is the best way around this issue?
>>>>>>>
>>>>>>> -- Michelle
>>>>>> Craig L Russell
>>>>>> Architect, Oracle
>>>>>> http://db.apache.org/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
*Michael Bouschen*
*Prokurist*
akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Web: www.akquinet.de <http://www.akquinet.de>
akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Re: Internal dependency problem with clean build on the release branch
Posted by Michelle Caisse <mc...@sonic.net>.
Hi Michael,
Something seems to have gone wrong with assembly.xml. It now does not
create the .zip and .gz files in the local repository on "mvn clean
install", though it does still create all the subproject jars.
I can try playing with the changes to the root pom that you suggest. But
I notice there is an apache-11.pom now. Maybe we should be using that.
-- Michelle
On 8/13/2013 9:22 AM, Michael Bouschen wrote:
> Hi Michelle,
>> Michael,
>>
>> I've checked in the changes to the branch, with internal dependency
>> version now set to 3.1-SNAPSHOT. That appears to work, but I'm
>> encountering several more problems.
>> 1. The release zip file does not include the parent-pom project, so
>> you can't build from the release.
> there was a bug in the assembly.xml: the section listing all our
> submodules used a wrong groupid for the parent-pom (javax.jdo instead
> of org.apache.jdo). So when packaging the src-file it was looking for
> an artifact that does not exist. I fixed the assembly and checked it
> in. For some reason the assembly.xml inculded the assembly definition
> <assembly> ... </assembly> three times. I removed the duplicates.
>
>> 2. When I attempt to do mvn deploy, I get the following error. It
>> looks like we need some more xml in our poms.
>>
>
> This is strage, because the apache parent pom defines these settings.
> I found the following in apache-10.pom:
>
> <distributionManagement>
> <repository>
> <id>apache.releases.https</id>
> <name>Apache Release Distribution Repository</name>
> <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
>
> </repository>
> <snapshotRepository>
> <id>apache.snapshots.https</id>
> <name>${distMgmtSnapshotsName}</name>
> <url>${distMgmtSnapshotsUrl}</url>
> </snapshotRepository>
> </distributionManagement>
>
> I think this is what we need, correct?
>
> Maybe the issue is that the root pom.xml in 3.1-rc1 does not define a
> parent pom. Only the pom.xml in paranet-pom refers the apache parent-pom.
> Would it work if our root pom uses the JDO parent-pom as the parent pom?
>
> <parent>
> <groupId>org.apache.jdo</groupId>
> <artifactId>parent-pom</artifactId>
> <version>3.1-SNAPSHOT</version>
> <relativePath>parent-pom</relativePath>
> </parent>
>
> Regards Michael
>
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Failed to configure plugin parameters for:
>> org.apache.maven.plugins:maven-deploy-plugin:2.4
>>
>> check that the following section of the pom.xml is present and correct:
>>
>> <distributionManagement>
>> <!-- use the following if you're not using a snapshot version. -->
>> <repository>
>> <id>repo</id>
>> <name>Repository Name</name>
>> <url>scp://host/path/to/repo</url>
>> </repository>
>> <!-- use the following if you ARE using a snapshot version. -->
>> <snapshotRepository>
>> <id>repo</id>
>> <name>Repository Name</name>
>> <url>scp://host/path/to/repo</url>
>> </snapshotRepository>
>> </distributionManagement>
>>
>> -- Michelle
>>
>> On 8/12/2013 10:44 PM, Michael Bouschen wrote:
>>> Hi Michelle,
>>>
>>> sorry for the late response, I found your email today.
>>>
>>> You mentioned "but all dependencies, including the dependency on the
>>> api jar that we are in the process of releasing, are to non
>>> -SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we
>>> are dependent on jdo-api-3.1.jar".
>>>
>>> I think that our own submodules (like jdo-api) still can have
>>> -SNAPSHOT versions in the dependencies section of the pom. The maven
>>> release plugin will update these -SNAPSHOT version names, too. I
>>> propose you change the version of the jdo-api in the dependencies
>>> section to 3.1-SNAPSHOT.
>>>
>>> Can you send me a patch with your changes of the 3.1-rc1 branch,
>>> then I try a mvn clean install with a clean local repository.
>>>
>>> Regards Michael
>>>
>>>> Yeah, I don't know of a way unless there's some kind of option in
>>>> the maven release plugin that lets you set up your pom some other
>>>> way. Here's a link to someone who seems to have a similar problem,
>>>> as far as I understand what they are saying:
>>>> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>>>>
>>>> Michael has some familiarity with the maven versions plugin that is
>>>> mentioned in the response.
>>>>
>>>> -- Michelle
>>>>
>>>> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>>>>> Sounds pretty strange. So it would be impossible to release
>>>>> co-dependent artifacts?
>>>>>
>>>>> Craig
>>>>>
>>>>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Preparatory to attempting a release, I cleaned my local
>>>>>> repository and did "mvn clean install". On building exectck, I
>>>>>> got a build error:
>>>>>>
>>>>>> [ERROR] BUILD ERROR
>>>>>> [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> [INFO] Failed to resolve artifact.
>>>>>>
>>>>>> Missing:
>>>>>> ----------
>>>>>> 1) javax.jdo:jdo-api:jar:3.1
>>>>>>
>>>>>> This is because, per the apache instructions, our release
>>>>>> artifacts have -SNAPSHOT versions, but all dependencies,
>>>>>> including the dependency on the api jar that we are in the
>>>>>> process of releasing, are to non -SNAPSHOT versions. So, we build
>>>>>> jdo-api-3.1-SNAPSHOT.jar, but we are dependent on
>>>>>> jdo-api-3.1.jar. What is the best way around this issue?
>>>>>>
>>>>>> -- Michelle
>>>>> Craig L Russell
>>>>> Architect, Oracle
>>>>> http://db.apache.org/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Internal dependency problem with clean build on the release branch
Posted by Michael Bouschen <mi...@akquinet.de>.
Hi Michelle,
> Michael,
>
> I've checked in the changes to the branch, with internal dependency
> version now set to 3.1-SNAPSHOT. That appears to work, but I'm
> encountering several more problems.
> 1. The release zip file does not include the parent-pom project, so
> you can't build from the release.
there was a bug in the assembly.xml: the section listing all our
submodules used a wrong groupid for the parent-pom (javax.jdo instead of
org.apache.jdo). So when packaging the src-file it was looking for an
artifact that does not exist. I fixed the assembly and checked it in.
For some reason the assembly.xml inculded the assembly definition
<assembly> ... </assembly> three times. I removed the duplicates.
> 2. When I attempt to do mvn deploy, I get the following error. It
> looks like we need some more xml in our poms.
>
This is strage, because the apache parent pom defines these settings. I
found the following in apache-10.pom:
<distributionManagement>
<repository>
<id>apache.releases.https</id>
<name>Apache Release Distribution Repository</name>
<url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
</repository>
<snapshotRepository>
<id>apache.snapshots.https</id>
<name>${distMgmtSnapshotsName}</name>
<url>${distMgmtSnapshotsUrl}</url>
</snapshotRepository>
</distributionManagement>
I think this is what we need, correct?
Maybe the issue is that the root pom.xml in 3.1-rc1 does not define a
parent pom. Only the pom.xml in paranet-pom refers the apache parent-pom.
Would it work if our root pom uses the JDO parent-pom as the parent pom?
<parent>
<groupId>org.apache.jdo</groupId>
<artifactId>parent-pom</artifactId>
<version>3.1-SNAPSHOT</version>
<relativePath>parent-pom</relativePath>
</parent>
Regards Michael
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to configure plugin parameters for:
> org.apache.maven.plugins:maven-deploy-plugin:2.4
>
> check that the following section of the pom.xml is present and correct:
>
> <distributionManagement>
> <!-- use the following if you're not using a snapshot version. -->
> <repository>
> <id>repo</id>
> <name>Repository Name</name>
> <url>scp://host/path/to/repo</url>
> </repository>
> <!-- use the following if you ARE using a snapshot version. -->
> <snapshotRepository>
> <id>repo</id>
> <name>Repository Name</name>
> <url>scp://host/path/to/repo</url>
> </snapshotRepository>
> </distributionManagement>
>
> -- Michelle
>
> On 8/12/2013 10:44 PM, Michael Bouschen wrote:
>> Hi Michelle,
>>
>> sorry for the late response, I found your email today.
>>
>> You mentioned "but all dependencies, including the dependency on the
>> api jar that we are in the process of releasing, are to non -SNAPSHOT
>> versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we are dependent
>> on jdo-api-3.1.jar".
>>
>> I think that our own submodules (like jdo-api) still can have
>> -SNAPSHOT versions in the dependencies section of the pom. The maven
>> release plugin will update these -SNAPSHOT version names, too. I
>> propose you change the version of the jdo-api in the dependencies
>> section to 3.1-SNAPSHOT.
>>
>> Can you send me a patch with your changes of the 3.1-rc1 branch, then
>> I try a mvn clean install with a clean local repository.
>>
>> Regards Michael
>>
>>> Yeah, I don't know of a way unless there's some kind of option in
>>> the maven release plugin that lets you set up your pom some other
>>> way. Here's a link to someone who seems to have a similar problem,
>>> as far as I understand what they are saying:
>>> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>>>
>>> Michael has some familiarity with the maven versions plugin that is
>>> mentioned in the response.
>>>
>>> -- Michelle
>>>
>>> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>>>> Sounds pretty strange. So it would be impossible to release
>>>> co-dependent artifacts?
>>>>
>>>> Craig
>>>>
>>>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Preparatory to attempting a release, I cleaned my local repository
>>>>> and did "mvn clean install". On building exectck, I got a build
>>>>> error:
>>>>>
>>>>> [ERROR] BUILD ERROR
>>>>> [INFO]
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> [INFO] Failed to resolve artifact.
>>>>>
>>>>> Missing:
>>>>> ----------
>>>>> 1) javax.jdo:jdo-api:jar:3.1
>>>>>
>>>>> This is because, per the apache instructions, our release
>>>>> artifacts have -SNAPSHOT versions, but all dependencies, including
>>>>> the dependency on the api jar that we are in the process of
>>>>> releasing, are to non -SNAPSHOT versions. So, we build
>>>>> jdo-api-3.1-SNAPSHOT.jar, but we are dependent on jdo-api-3.1.jar.
>>>>> What is the best way around this issue?
>>>>>
>>>>> -- Michelle
>>>> Craig L Russell
>>>> Architect, Oracle
>>>> http://db.apache.org/jdo
>>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
--
*Michael Bouschen*
*Prokurist*
akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Web: www.akquinet.de <http://www.akquinet.de>
akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Re: Internal dependency problem with clean build on the release branch
Posted by Michelle Caisse <mc...@sonic.net>.
Michael,
I've checked in the changes to the branch, with internal dependency
version now set to 3.1-SNAPSHOT. That appears to work, but I'm
encountering several more problems.
1. The release zip file does not include the parent-pom project, so you
can't build from the release.
2. When I attempt to do mvn deploy, I get the following error. It looks
like we need some more xml in our poms.
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-deploy-plugin:2.4
check that the following section of the pom.xml is present and correct:
<distributionManagement>
<!-- use the following if you're not using a snapshot version. -->
<repository>
<id>repo</id>
<name>Repository Name</name>
<url>scp://host/path/to/repo</url>
</repository>
<!-- use the following if you ARE using a snapshot version. -->
<snapshotRepository>
<id>repo</id>
<name>Repository Name</name>
<url>scp://host/path/to/repo</url>
</snapshotRepository>
</distributionManagement>
-- Michelle
On 8/12/2013 10:44 PM, Michael Bouschen wrote:
> Hi Michelle,
>
> sorry for the late response, I found your email today.
>
> You mentioned "but all dependencies, including the dependency on the
> api jar that we are in the process of releasing, are to non -SNAPSHOT
> versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we are dependent
> on jdo-api-3.1.jar".
>
> I think that our own submodules (like jdo-api) still can have
> -SNAPSHOT versions in the dependencies section of the pom. The maven
> release plugin will update these -SNAPSHOT version names, too. I
> propose you change the version of the jdo-api in the dependencies
> section to 3.1-SNAPSHOT.
>
> Can you send me a patch with your changes of the 3.1-rc1 branch, then
> I try a mvn clean install with a clean local repository.
>
> Regards Michael
>
>> Yeah, I don't know of a way unless there's some kind of option in the
>> maven release plugin that lets you set up your pom some other way.
>> Here's a link to someone who seems to have a similar problem, as far
>> as I understand what they are saying:
>> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>>
>> Michael has some familiarity with the maven versions plugin that is
>> mentioned in the response.
>>
>> -- Michelle
>>
>> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>>> Sounds pretty strange. So it would be impossible to release
>>> co-dependent artifacts?
>>>
>>> Craig
>>>
>>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>>
>>>> Hi all,
>>>>
>>>> Preparatory to attempting a release, I cleaned my local repository
>>>> and did "mvn clean install". On building exectck, I got a build
>>>> error:
>>>>
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> [INFO] Failed to resolve artifact.
>>>>
>>>> Missing:
>>>> ----------
>>>> 1) javax.jdo:jdo-api:jar:3.1
>>>>
>>>> This is because, per the apache instructions, our release artifacts
>>>> have -SNAPSHOT versions, but all dependencies, including the
>>>> dependency on the api jar that we are in the process of releasing,
>>>> are to non -SNAPSHOT versions. So, we build
>>>> jdo-api-3.1-SNAPSHOT.jar, but we are dependent on jdo-api-3.1.jar.
>>>> What is the best way around this issue?
>>>>
>>>> -- Michelle
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
>>>
>>
>
>
Re: Internal dependency problem with clean build on the release branch
Posted by Michael Bouschen <mi...@akquinet.de>.
Hi Michelle,
sorry for the late response, I found your email today.
You mentioned "but all dependencies, including the dependency on the api
jar that we are in the process of releasing, are to non -SNAPSHOT
versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we are dependent on
jdo-api-3.1.jar".
I think that our own submodules (like jdo-api) still can have -SNAPSHOT
versions in the dependencies section of the pom. The maven release
plugin will update these -SNAPSHOT version names, too. I propose you
change the version of the jdo-api in the dependencies section to
3.1-SNAPSHOT.
Can you send me a patch with your changes of the 3.1-rc1 branch, then I
try a mvn clean install with a clean local repository.
Regards Michael
> Yeah, I don't know of a way unless there's some kind of option in the
> maven release plugin that lets you set up your pom some other way.
> Here's a link to someone who seems to have a similar problem, as far
> as I understand what they are saying:
> http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
>
> Michael has some familiarity with the maven versions plugin that is
> mentioned in the response.
>
> -- Michelle
>
> On 8/10/2013 12:26 PM, Craig L Russell wrote:
>> Sounds pretty strange. So it would be impossible to release
>> co-dependent artifacts?
>>
>> Craig
>>
>> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>>
>>> Hi all,
>>>
>>> Preparatory to attempting a release, I cleaned my local repository
>>> and did "mvn clean install". On building exectck, I got a build error:
>>>
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> ------------------------------------------------------------------------
>>>
>>> [INFO] Failed to resolve artifact.
>>>
>>> Missing:
>>> ----------
>>> 1) javax.jdo:jdo-api:jar:3.1
>>>
>>> This is because, per the apache instructions, our release artifacts
>>> have -SNAPSHOT versions, but all dependencies, including the
>>> dependency on the api jar that we are in the process of releasing,
>>> are to non -SNAPSHOT versions. So, we build
>>> jdo-api-3.1-SNAPSHOT.jar, but we are dependent on jdo-api-3.1.jar.
>>> What is the best way around this issue?
>>>
>>> -- Michelle
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
>
--
*Michael Bouschen*
*Prokurist*
akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Web: www.akquinet.de <http://www.akquinet.de>
akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680
Re: Internal dependency problem with clean build on the release branch
Posted by Michelle Caisse <mc...@sonic.net>.
Yeah, I don't know of a way unless there's some kind of option in the
maven release plugin that lets you set up your pom some other way.
Here's a link to someone who seems to have a similar problem, as far as
I understand what they are saying:
http://stackoverflow.com/questions/8411424/automating-maven-artifact-releasing
Michael has some familiarity with the maven versions plugin that is
mentioned in the response.
-- Michelle
On 8/10/2013 12:26 PM, Craig L Russell wrote:
> Sounds pretty strange. So it would be impossible to release co-dependent artifacts?
>
> Craig
>
> On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
>
>> Hi all,
>>
>> Preparatory to attempting a release, I cleaned my local repository and did "mvn clean install". On building exectck, I got a build error:
>>
>> [ERROR] BUILD ERROR
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Failed to resolve artifact.
>>
>> Missing:
>> ----------
>> 1) javax.jdo:jdo-api:jar:3.1
>>
>> This is because, per the apache instructions, our release artifacts have -SNAPSHOT versions, but all dependencies, including the dependency on the api jar that we are in the process of releasing, are to non -SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we are dependent on jdo-api-3.1.jar. What is the best way around this issue?
>>
>> -- Michelle
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: Internal dependency problem with clean build on the release branch
Posted by Craig L Russell <cr...@oracle.com>.
Sounds pretty strange. So it would be impossible to release co-dependent artifacts?
Craig
On Aug 10, 2013, at 11:03 AM, Michelle Caisse wrote:
> Hi all,
>
> Preparatory to attempting a release, I cleaned my local repository and did "mvn clean install". On building exectck, I got a build error:
>
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> Missing:
> ----------
> 1) javax.jdo:jdo-api:jar:3.1
>
> This is because, per the apache instructions, our release artifacts have -SNAPSHOT versions, but all dependencies, including the dependency on the api jar that we are in the process of releasing, are to non -SNAPSHOT versions. So, we build jdo-api-3.1-SNAPSHOT.jar, but we are dependent on jdo-api-3.1.jar. What is the best way around this issue?
>
> -- Michelle
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!