Dear All,
> I think we should comment the kres reference in the toplevel pom.xml > in the mean time and re-enable it as soon as Enrico or someone else > tells me which jars to upload to the nuxeo maven repo and that we have > tested that the toplevel build is fully functional without any manual > operation. Also I don't want to upload those 3 jars twice under > different names, so there might have non trivial changes to do in the > kres build config (I am not sure what the shared-dependency variant > stands for). +1 for this temporary solution. I think is the best solution now. This decouple the problems, at least. Then we will move on solving the issues one by one. @Olivier. We will come back to you and perform any necessary changes on the kres code to avoid manual install of bundles. I am not familiar with hudson and I did not perceived the manual install of libraries as a blocking issue. Anyway, we will fix this and the other kres-related issues soon, most of them are already solved in other kres forks (for instance the wrong dependencies in the pom files have been fixed for integrate kres in another IKS activity. Unfortunately the most of the kres code has been written bu Alessandro, Andrea and Elvio, which only recently are going to become committers. Hope this clarifies the situation from our side. Enrico On 10 February 2011 10:40, Olivier Grisel <[email protected]> wrote: > 2011/2/10 Bertrand Delacretaz <[email protected]>: >> Hi Valentina, >> >> On Wed, Feb 9, 2011 at 11:19 PM, valentina presutti >> <[email protected]> wrote: >>> Thanks Fabian, it was clear indeed. >>> What I meant is that if it's a matter of the failing tests maybe it's >>> enough to fix them (and I believe we >>> need to be more careful before committing next times).... >> >> The main problem with the kres build is that it requires running a >> script to install jars in the local Maven repository >> (see >> https://svn.apache.org/repos/asf/incubator/stanbol/trunk/kres/README.txt). >> This won't work in a Hudson build (https://hudson.apache.org) which I >> hope to setup soon. > > Yes this is the real deal. > > Also when I checkout a new java project for evaluation and I see a > toplevel pom.xml I expect that a single "mvn install" or "mvn > assembly:assembly" will get me up and running. Having to manually > install jars makes me a sad, sad panda. > > The fact that those jars are not licensed under an ASF compliant make > us not able to push them on the official ASF mvn repository. I can > update the 3 documented jars on the nuxeo vendors repository as a > temporary solution but the one dependency that is not documented, I > don't know how to handle it. > > I think we should comment the kres reference in the toplevel pom.xml > in the mean time and re-enable it as soon as Enrico or someone else > tells me which jars to upload to the nuxeo maven repo and that we have > tested that the toplevel build is fully functional without any manual > operation. Also I don't want to upload those 3 jars twice under > different names, so there might have non trivial changes to do in the > kres build config (I am not sure what the shared-dependency variant > stands for). > >>> Licensing shouldn't be an issue at the moment...btw, we're working also for >>> that, but unfortunately it does not >>> depend only on us :( >> >> It is an issue in that it prevents us from releasing kres - until >> that's fixed, as I said I'm +1 on disabling kres temporarily in the >> default build. People working on it can reactivate the kres build >> using a simple mvn -P option. > > Or they can just cd into the kres folder and build from there (after > installing the missing jars manually). > > -- > Olivier > http://twitter.com/ogrisel - http://github.com/ogrisel > -- Enrico Daga -- http://www.enridaga.net skype: enri-pan
