[Building Sakai] Nightly2 trunk build broken?

[Anthony Whyte]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091001/eeec0cfa/attachment.bin