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 Thu, 15 Aug 2013 20:02:55 GMT
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

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