Re: Internal dependency problem with clean build on the release branch
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
idapache.releases.https/id
nameApache Release Distribution Repository/name
urlhttps://repository.apache.org/service/local/staging/deploy/maven2/url
/repository
snapshotRepository
idapache.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
groupIdorg.apache.jdo/groupId
artifactIdparent-pom/artifactId
version3.1-SNAPSHOT/version
relativePathparent-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
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/repository
!-- use the following if you ARE using a snapshot version. --
snapshotRepository
idrepo/id
nameRepository Name/name
urlscp://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:
Re: Internal dependency problem with clean build on the release branch
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
idapache.releases.https/id
nameApache Release Distribution Repository/name
urlhttps://repository.apache.org/service/local/staging/deploy/maven2/url
/repository
snapshotRepository
idapache.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
groupIdorg.apache.jdo/groupId
artifactIdparent-pom/artifactId
version3.1-SNAPSHOT/version
relativePathparent-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
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/repository
!-- use the following if you ARE using a snapshot version. --
snapshotRepository
idrepo/id
nameRepository Name/name
urlscp://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
Re: Internal dependency problem with clean build on the release branch
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
idapache.releases.https/id
nameApache Release Distribution Repository/name
urlhttps://repository.apache.org/service/local/staging/deploy/maven2/url
/repository
snapshotRepository
idapache.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
groupIdorg.apache.jdo/groupId
artifactIdparent-pom/artifactId
version3.1-SNAPSHOT/version
relativePathparent-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
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/repository
!-- use the following if you ARE using a snapshot version. --
snapshotRepository
idrepo/id
nameRepository Name/name
urlscp://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
Re: Internal dependency problem with clean build on the release branch
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
idapache.releases.https/id
nameApache Release Distribution Repository/name
urlhttps://repository.apache.org/service/local/staging/deploy/maven2/url
/repository
snapshotRepository
idapache.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
groupIdorg.apache.jdo/groupId
artifactIdparent-pom/artifactId
version3.1-SNAPSHOT/version
relativePathparent-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
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/repository
!-- use the following if you ARE using a snapshot version. --
snapshotRepository
idrepo/id
nameRepository Name/name
urlscp://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.russ...@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.bousc...@akquinet.de
Web: www.akquinet.de http://www.akquinet.de
akquinet tech@spree GmbH,
Re: Internal dependency problem with clean build on the release branch
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.russ...@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.bousc...@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
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
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.russ...@oracle.com P.S. A good JDO? O, Gasp!
Re: Internal dependency problem with clean build on the release branch
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.russ...@oracle.com P.S. A good JDO? O, Gasp!
