db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <mcai...@sonic.net>
Subject Re: Internal dependency problem with clean build on the release branch
Date Thu, 15 Aug 2013 18:28:05 GMT
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!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


Mime
View raw message