db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <michael.bousc...@akquinet.de>
Subject Re: Internal dependency problem with clean build on the release branch
Date Wed, 14 Aug 2013 10:54:52 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message