commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Maven bugs when building Sanselan
Date Fri, 02 Mar 2012 16:54:09 GMT
On 2 March 2012 05:28, Damjan Jovanovic <damjan.jov@gmail.com> wrote:
> On Thu, Mar 1, 2012 at 11:37 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>> On 2012-02-29 19:00, Damjan Jovanovic wrote:
>>> Hi
>>>
>>> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
>>> having showstopper problems with Maven.
>>>
>>> The first problem, now fixed, was that "mvn assembly:assembly" failed
>>> due to the Maven Assembly plugin failing to add a non-ASCII filename
>>> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
>>> because Plexus Archiver had a bug that wrongly assumed number of chars
>>> = number of bytes, an assumption that quickly fails on UTF-8 locales
>>> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
>>> Plexus Archiver, they quickly included that patch in the next release,
>>> and Maven Assembly then made a 2.3 release which unknowingly pulled in
>>> that new release of Plexus Archiver. So by increasing the needed
>>> version of Maven Assembly to 2.3, I got that working now :). I see
>>> someone recently patched the Commons parent POM with the same version
>>> change - even better.
>>>
>>> The second is that "mvn site" fails because Clirr can't compare some
>>> inner classes properly, and the Maven Clirr plugin doesn't properly
>>> count and delete classes that can't be compared, leading to
>>> ArrayIndexOutOfBoundsException
>>> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
>>> http://jira.codehaus.org/browse/MCLIRR-25 and
>>> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
>>> working patch to that bug, but there's been no response yet and the
>>> project seems dead :(.
>>
>> I am unable to reproduce this error using current trunk of Sanselan. Are
>> you using some local modifications to your pom.xml that specifies which
>> artifact Clirr should compare against?
>>
>> All I get is this:
>>
>> [INFO] Unable to find a previous version of the project in the repository
>> [INFO] Not generating Clirr report as there is no previous version of
>> the library to compare against
>>
>
> Clirr doesn't find the 0.97 release because the groupId and artifactId
> for it were different.
> It breaks for me because I somehow have Sanselan 0.98 (a version that
> was never released) in my ~/.m2 directory.
> But there is still a Clirr bug here which will affect future releases
> even if it doesn't affect this one.
>
> I will attach the minimum set of Sanselan 0.98 files needed to
> reproduce this bug to the bug report.

I don't think applies here, but I have seen Clirr failures in the past
that went away when the code was compiled with a different compiler.

The failure occurred for me when code compiled by Eclipse was being
checked (as can happen if using Eclipse to develop).
Using mvn clean before running clirr fixed the issue.
[It was a while ago; I think that was the the way it happened, rather
than the reverse]

See also the issue I raised a year ago:

https://jira.codehaus.org/browse/MCLIRR-36

It would be good if someone in Maven-land could take a look; fixing
the array bug should be trivial for someone that is familiar with
building Maven plugins.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message