The bug Andrey reported doesn't have anything to do with Clover as far as I can tell. It looks like that one is that Clover can't find all the bits of code in order to assemble the results, probably because the modules don't correctly point to each other. That is just one reason I want to get rid of the hack which prevents us from using Maven as it is designed.
I don't like Maven at all, but I'm not advocating we change. I'm where you were 2.5 years ago: cursing it that it makes the simplest things so complicated. And of course it is so buggy, that you can't tell whether you've made a configuration error or maven is just broken. Fixing things on Hudson has the added enjoyment of waiting 2 hours to see if what you just did helped. If Tuscany is building ahead of you in the queue, then maybe 4 hours.
So here is where we are:
1. If we want Javadocs for 3.0 then we need to hack that branch to work around the fact that maven can't build javadocs properly. Maybe we need to add this to the appropriate modules:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Andrey, would that work around the maven bug you found?
2. If we want to avoid some ongoing pain and hassle, we need to remove the need to 'install' every module. That will probably fix Clover as well. To me that seems straightforward and if that means some people need to add one more pom to their project, well they should either suck it, complain to maven developers or use another build tool. At the same time I'd move everything into one namespace for simplicity.
3. Once javadoc building is working again I'll rewrite the scripts which suck them into the web site. That is very simple and will only take a few minutes.
4. Once all the above is sorted, I'll get back to the goal of running tests against mysql, MSSQL, Oracle, etc.
Andrus, I've added your user name (same as your svn user) to Hudson as an administrator. Let me know if you can't log in. And let me know if you change anything so I know not to change it back. We have four jobs: a pair for creating docs and a pair for running tests. They are split that way since the docs jobs are slow and don't need to run once per database type. We have two jobs tracking 3.0 and two tracking trunk. Clover builds properly now, instruments everything, but then doesn't find a single instrumented class. Findbugs I switched on to see what it would do, but I never got to finish configuring it.
Ari
On 27/12/09 10:21 PM, Andrus Adamchik wrote:
> Hear you. You've been around when we started a switch to Maven, so you
> probably remember me cursing about broken builds roughly on a weekly
> basis. After ~2.5 years of pain now I finally have confidence that I can
> deal with most Maven problems and can't see myself going back to Ant or
> any other of the Java build systems that I know of. Of course we'll keep
> tripping over bugs in new plugin versions, etc., so having our own
> backend repository and fixed plugin versions is likely a needed
> improvement.
>
> Also hopefully the Clover issue will be resolved per Andrey's comment
> and I'd be glad to help diagnosing the broken 1.6 build (which of course
> was caused by my commit).
>
> Andrus
>
>
>
> On Dec 27, 2009, at 1:01 AM, Aristedes Maniatis wrote:
>
>> On 27/12/09 1:39 AM, Andrus Adamchik wrote:
>>>
>>> On Dec 26, 2009, at 3:50 PM, Aristedes Maniatis wrote:
>>>
>>>> Well, we don't have either. Can I suggest for simplicity that we only
>>>> have org.apache.cayenne and nothing else? That's one less thing to
>>>> think about then. I'm happy to go make the change and run a few tests
>>>> if you don't object.
>>>
>>> I suggest to not rush with this. The current layout works ok for us and
>>> this change doesn't buy us anything.
>>
>>
>> Other than the fact that I spent about 6 hours trying to get Clover
>> working and ultimately failed. I'm guessing this is the reason why.
>>
>> http://hudson.zones.apache.org/hudson/job/Cayenne-doc/19/clover-report/
>>
>> And the chasing my tail I've experienced because I've built the
>> project without remembering to 'install' it every single time.
>>
>>
>>> The issue here is not that much the size of it, but rather
>>> user-friendliness and simplicity in handling the artifacts by the end
>>> users. E.g. if I am to deploy Cayenne to my own repo manually for some
>>> reason, I'd have to remember somehow that 1 or 2 parent artifacts also
>>> have to be deployed. This has been a constant annoyance for me with
>>> other frameworks, so I wish that our public modules are only 1 level
>>> deep, and therefore more "portable".
>>
>> If this convoluted and non-standard way of setting up a project is all
>> to work around this one bug in maven (I have no idea why it would need
>> to download the parent pom anyway), then I suggest we let end-users
>> complain to the maven developers. I've wasted many hours on reading
>> the crappy maven docs and trying to figure out what is going on. How
>> to selectively disable modules so that this can work again:
>>
>> http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/
>>
>> or why this isn't working:
>>
>> http://hudson.zones.apache.org/hudson/view/Cayenne/job/Cayenne-doc30/
>>
>>
>> Right now I'm over it. If anyone else can get the project to build the
>> same way twice in a row, please have my blessing to go and change the
>> Hudson configuration.....
>>
>>
>> Ari
>>
>> --
>>
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
----------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Sun Dec 27 2009 - 20:56:33 EST