[Building Sakai] Nightly2 trunk build broken?

Berg, A.M. A.M.Berg at uva.nl
Fri Oct 2 07:07:16 PDT 2009 

<begin speculation>
How about an antrun dependency bug?

http://jira.codehaus.org/browse/MANTRUN-106
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-antrun-plugin/src/site/fml/faq.fml?view=markup&pathrev=790402
<speculation off>

Alan Berg

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg




-----Original Message-----
From: sakai-dev-bounces at collab.sakaiproject.org on behalf of Anthony Whyte
Sent: Fri 10/2/2009 15:22
To: David Horwitz
Cc: sakai-dev Developers
Subject: Re: [Building Sakai] Nightly2 trunk build broken?
 
To further test this hypothesis I've left search in and removed sam  
from the build (lots of modules is why I chose it) and seeing what  
happens.

Anth


On Oct 2, 2009, at 9:02 AM, David Horwitz wrote:

> That was my speculation something about a plugin bug or some weirdness
> like that.
>
> I have ruled out that is the new standard-tool pom parents for common
> and search.
>
> to test your postulation I've removed search from the build - lets see
> if that changes the result ....
>
> D
>
> Steve Swinsburg wrote:
>> So how come if we manually go into the site-manage project and  
>> issue a
>> build it will work, but fail when its part of the full build?
>>
>> Have their been any additional plugins introduced into the main poms
>> that could be breaking it?
>> <begin speculation>
>> If so, maybe the particular plugin has a bug whereby there is a limit
>> to the number of artifacts that can be built at any one time (say 99)
>> and it just so happens that the site-manage-api artifact is at that
>> golden number (ie 99th in the list), since there seems to be nothing
>> wrong with it. Each project has 3 or 4 module each, its a possibility
>> it could hit some predetermined number around that spot.
>> <speculation off>
>>
>> Totally random thoughts there!
>>
>> Steve
>>
>>
>>
>> On 02/10/2009, at 9:23 PM, David Horwitz wrote:
>>
>>> There should be a line like this:
>>>
>>> [INFO] [jar:jar]
>>> [INFO] Building jar:
>>> /home/dhorwitz/trunk/site-manage/site-manage-api/api/target/site- 
>>> manage-api-2.7.0-SNAPSHOT.jar
>>>
>>> [INFO] [install:install]
>>> [INFO] Installing
>>> /home/dhorwitz/trunk/site-manage/site-manage-api/api/target/site- 
>>> manage-api-2.7.0-SNAPSHOT.jar
>>> to
>>> /home/dhorwitz/.m2/repository/org/sakaiproject/sitemanage/site- 
>>> manage-api/2.7.0-SNAPSHOT/site-manage-api-2.7.0-SNAPSHOT.jar
>>>
>>>
>>> D
>>>
>>> Steve Swinsburg wrote:
>>>>
>>>> Scratch that, trashing the m2 repo and rebuilding trunk still fails
>>>> with site-manage-api:
>>>>
>>>> Downloading:
>>>> http://source.sakaiproject.org/maven2-snapshots/org/sakaiproject/sakai-site-manage-api/2.7.0-SNAPSHOT/sakai-site-manage-api-2.7.0-SNAPSHOT.jar
>>>>
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>> [INFO] Failed to resolve artifact.
>>>>
>>>> Missing:
>>>> ----------
>>>> 1) org.sakaiproject:sakai-site-manage-api:jar:2.7.0-SNAPSHOT
>>>>
>>>> However, building that part manually gets at least that artifact
>>>> created, as Chuck reported as well.
>>>>
>>>> Back to the maven hand-holding....
>>>>
>>>> Steve
>>>>
>>>> On 02/10/2009, at 3:22 PM, Steve Swinsburg wrote:
>>>>
>>>>
>>>>> Trunk just built for me, yes I was amazed too!
>>>>> r67058
>>>>>
>>>>> I cleaned out my repo yesterday and it was failing - with a little
>>>>> coaxing it eventually built though.
>>>>> Now it seems ok, without anything special, just a mvn clean  
>>>>> install.
>>>>> I didn't clean out my repo this time around though (too afraid!)
>>>>>
>>>>> cheers,
>>>>> Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 02/10/2009, at 9:58 AM, Anthony Whyte wrote:
>>>>>
>>>>>
>>>>>> My trunk build failed in the same manner as nightly: site-manage-
>>>>>> hbm failing to resolve the site-manage-api artifact.  I started
>>>>>> with a thoroughly empty repo and attempted a build using Maven
>>>>>> 2.1.0.  I don't have any definitive answers as to the cause of  
>>>>>> the
>>>>>> build failure but reviewing the org/sakaiproject portion of .m2
>>>>>> reveals some anomalies.
>>>>>>
>>>>>> I. kernel <parent> variations
>>>>>>
>>>>>> The typical trunk Sakai module inherits it kernel dependencies  
>>>>>> from
>>>>>> the /master/pom.xml, currently kernel-1.1.0-beta02-SNAPSHOT.
>>>>>> However, a sakai-standard-tool pom has been developed and common
>>>>>> and search snapshots rely on it for kernel and other inherited
>>>>>> dependencies.  The sakai-standard-tool pom, both 2.7.0-SNAPSHOT  
>>>>>> and
>>>>>> a 2.7.0-build01 release rely on the kernel 1.1.0-beta01 release  
>>>>>> for
>>>>>> inherited dependencies.  So common and search pull in an
>>>>>> alternative subset of kernel artifacts including the component-
>>>>>> manager, api and util.  At a minimum these projects are pulling
>>>>>> down redundant artifacts, bloating local repos unnecessarily.
>>>>>> Perhaps the inclusion of alternate versions of the kernel in  
>>>>>> trunk
>>>>>> code are causing other problems.
>>>>>>
>>>>>> I recommend that we keep all trunk projects synced to a single
>>>>>> kernel version, snapshot or otherwise.  I also recommend that the
>>>>>> sakai-standard-tool snapshot artifact that trunk common and  
>>>>>> search
>>>>>> rely on have its pom <parent> updated to kernel-1.1.0-beta02-
>>>>>> SNAPSHOT to eliminate, at least for now, trunk variations in  
>>>>>> kernel
>>>>>> dependencies.  I also recommend harmonizing both trunk common and
>>>>>> search snapshots base pom <parent> to the same updated snapshot
>>>>>> version of sakai-standard tool.
>>>>>>
>>>>>> II. Lingering M2 dependencies
>>>>>>
>>>>>> The M2 dependencies downloaded during a trunk install is due, as
>>>>>> David Horwitz noted earlier, to one or more tool projects relying
>>>>>> on old RSF dependencies.  Samigo is the culprit here.  It still
>>>>>> relies on RSF 0.7.2, which has dependencies on the old M2 master
>>>>>> and sakai-util projects.  I recommend that Samigo update it's RSF
>>>>>> dependencies; we might also consider adding an explicit  
>>>>>> <exclusion>
>>>>>> to block these transitive dependencies.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Anth
>>>>>>
>>>>>>
>>>>>> On Oct 1, 2009, at 6:13 PM, Joshua Swink wrote:
>>>>>>
>>>>>>
>>>>>>> I had the same problem (Failed to resolve artifact
>>>>>>> org.sakaiproject:sakai-site-manage-api:jar:2.7.0-SNAPSHOT) on a
>>>>>>> system
>>>>>>> where I build Sakai infrequently. On another system where I  
>>>>>>> build
>>>>>>> Sakai more frequently, it works. I copied the .m2 repository  
>>>>>>> from
>>>>>>> the
>>>>>>> working system to the non-working system, which fixed the  
>>>>>>> problem.
>>>>>>> So
>>>>>>> my guess is that this artifact is was available for a limited  
>>>>>>> time.
>>>>>>>
>>>>>>> As a further test I tried deleting the .m2 directory entirely  
>>>>>>> and
>>>>>>> building Sakai... it failed saying:
>>>>>>>
>>>>>>> Unable to find the mojo
>>>>>>> 'org.sakaiproject.maven.plugins:sakai:1.2.0:deploy' in the  
>>>>>>> plugin
>>>>>>> 'org.sakaiproject.maven.plugins:sakai'
>>>>>>> Component descriptor cannot be found in the component  
>>>>>>> repository:
>>>>>>> org 
>>>>>>> .apache.maven.plugin.Mojoorg.sakaiproject.maven.plugins:sakai:
>>>>>>> 1.2.0:deploy.
>>>>>>>
>>>>>>> It seems that setting up a Sakai build environment from scratch
>>>>>>> would
>>>>>>> entail chasing down several missing artifacts.
>>>>>>>
>>>>>>> Josh
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 1, 2009 at 1:40 PM, Anthony Whyte  
>>>>>>> <arwhyte at umich.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I've been working on 2.6.1 release stuff, attending a feverish
>>>>>>>> three-year-old and watching my slow connection pull down jar
>>>>>>>> after jar into
>>>>>>>> an absolutely empty .m2/repository as I build trunk against a
>>>>>>>> fresh Tomcat
>>>>>>>> (5.5.26) and empty MySQL db (5.0.83).  The build has yet to
>>>>>>>> explode but I
>>>>>>>> see that two versions of the kernel have been installed in  
>>>>>>>> the repo
>>>>>>>> (1.1.0-beta01 and 1.1.0-beta02-SNAPSHOT).  That's not so good.
>>>>>>>>
>>>>>>>> More news in a bit.
>>>>>>>>
>>>>>>>> Anth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 1, 2009, at 3:25 PM, csev wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Jim,
>>>>>>>>>
>>>>>>>>> Here is how to get a safe old version:
>>>>>>>>>
>>>>>>>>> http://www.dr-chuck.com/csev-blog/000656.html
>>>>>>>>>
>>>>>>>>> And the version in the example *is* safe.  Of course - you  
>>>>>>>>> want to
>>>>>>>>> pull the trunk of whatever you are working on...
>>>>>>>>>
>>>>>>>>> I am looking into the broken trunk too - it looks like  
>>>>>>>>> sevreral
>>>>>>>>> things.  The last good build was
>>>>>>>>>
>>>>>>>>> 09-26-04:00:01
>>>>>>>>>
>>>>>>>>> Since then it has not built - but the reason for breakage  
>>>>>>>>> has been
>>>>>>>>> different every few hours.
>>>>>>>>>
>>>>>>>>> /Chuck
>>>>>>>>>
>>>>>>>>> On Oct 1, 2009, at 1:54 PM, Jim Eng wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> http://nightly2.sakaiproject.org/logs/sakai-nightly/build-2009-10-01-12:00:01.log.txt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm having the same problem that nightly2 is having.  Matthew
>>>>>>>>>> told me
>>>>>>>>>> that the problem might actually be in kernel.
>>>>>>>>>>
>>>>>>>>>> Is anybody working on this?
>>>>>>>>>>
>>>>>>>>>> Is there some recent revision I could use to that does build?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Jim
>>>>>>>>>> _______________________________________________
>>>>>>>>>> sakai-dev mailing list
>>>>>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>>>>>
>>>>>>>>>> TO UNSUBSCRIBE: send email to
>>>>>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>>>>>>> with a subject of "unsubscribe"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> sakai-dev mailing list
>>>>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>>>>
>>>>>>>>> TO UNSUBSCRIBE: send email to
>>>>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject  
>>>>>>>>> of
>>>>>>>>> "unsubscribe"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sakai-dev mailing list
>>>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>>>
>>>>>>>> TO UNSUBSCRIBE: send email to
>>>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>>>>> with a subject of "unsubscribe"
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to
>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org
>>>>>> with a subject of "unsubscribe"
>>>>>>
>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>> "unsubscribe"
>>>>
>>
>>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091002/b312a8e3/attachment.html

More information about the sakai-dev mailing list