[Building Sakai] Nightly2 trunk build broken?

Steve Swinsburg steve.swinsburg at gmail.com
Fri Oct 2 05:58:58 PDT 2009 

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"
>>

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

More information about the sakai-dev mailing list