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.russ...@oracle.com
P.S. A good JDO? O, Gasp!
