felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: [Vote] release maven-bundle-plugin 1.4.2
Date Wed, 06 Aug 2008 06:33:54 GMT
2008/8/6 Sahoo <Sahoo@sun.com>

> We are currently experiencing severe build disruptions because of
>>> https://issues.apache.org/jira/browse/FELIX-661. It happens almost every
>>> every other build on all kinds of platforms.
>> This is certainly odd because I've never seen this before (I work on
>> Windows, Mac and Linux) and would have expected others to report it before
>> now. Therefore to fix this speedily we would need a recreatable testcase
>> that shows the problem - doesn't need to be small, just publicly
>> accessible.
> Yes, it is publicly available. Instructions are:
> svn co https://svn.dev.java.net/svn/glassfish-svn/trunk/v3
> mvn clean install

thanks, I've started runs on various machines to recreate this

> Do it a few times and I am sure you shall be able to reproduce the bug.
> I will update the bug with this info.
>> BTW, does this happen when a single developer runs the build on their own
>> machine (with no other builds running) or does it only occur on a build
>> machine that may be potentially running many builds?
> On single developer m/c as well as build m/c. BTW, our build m/c uses
> different local cache for different builds, so effectively it behaves like a
> single developer build.

excellent - just wanted to avoid that particular maven gotcha...

> We actually don't specify the version in pom.xml (that seems to be a bad
> thing, but that's a separate issue), so I am sure maven will resolve it to
> 1.4.1 which is the last released artifact, right? In fact, I just removed
> maven-bundle-plugin from my local repo, and maven downloaded 1.4.1. So, I
> am sure we use 1.4.1.

yes, it's usually recommended you lock down plugin versions
to ensure reproducible builds - btw, the maven-enforcer-plugin
(see http://maven.apache.org/plugins/maven-enforcer-plugin)
can help with this

>  btw, I don't see a patch attached to the JIRA issue - does the patch solve
>> your current build issues?
> Yes, it appears to have fixed the issue. Harsha ran the build in a loop for
> more than 100 iterations.

good to know - could you attach the patch to the JIRA issue?
(preferably as a collection of subversion diffs or unified diffs)

> Hopefully, you can reproduce the issue using the supplied information. I
> totally understand it is late in the release cycle, but let's at least
> validate the bug, then we can think of a plan of action for a custom
> release.

exactly - it may be there's a minimal patch that's required to
avoid the failure, which would be easier to add at this stage

then we can go through the code thoroughly in the next release.

> certainly the earlier I know of potential issues the easier it is to plan,
>> so I'd strongly encourage users of the bundleplugin to report bugs and
>> feature requests on JIRA as soon as possible - and if you're expecting to
>> move to the new release, please test against the early snapshots as much
>> as
>> possible.
> Actually long back I sent a mail with this issue. See:
> http://markmail.org/message/dcav7rketvp4nfpe
> At that time I was suspecting it to be a JDK issue, so filed a JDK bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6713913
> Our JDK engineer and Harsha spent some time to conclude that JDK behavior
> can't be changed, so callers have to be modified. The whole thing delayed
> the process.

ah, I assumed everything was ok when I didn't heard back
from you - thanks for tracking down the cause, these things
can be hard to debug

> Thanks for your speedy response. It is realy appreciated.
> Regards,
> Sahoo
Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message