[Building Sakai] Nightly2 trunk build broken?
David Horwitz
david.horwitz at uct.ac.za
Fri Oct 2 07:30:15 PDT 2009
Hmm A possible suspect. My testing seems to suggest something to do with
plugin inheritance, brought in by search (which now inherits from
standard-tool pom rather than master) Removing search seems to lead to
predictable builds. So I have:
1) Removed search as a built module
2) Added a deployer to deploy the new search assembly (similar to the
kernel deployer)
We where going to do this anyway and it should have the affect of
significantly improving build times.
I suspect the culprit is a plugin definition getting pulled in from
kernel. For some reason this is not triggered by the commons project but
is by search. I'll investigate and probably switch to dependency import
on the standard-tool pom once we have a more up to date version of maven.
D
Berg, A.M. wrote:
> <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/399c7c39/attachment.html
More information about the sakai-dev
mailing list