2008/8/6 Sahoo <[EMAIL PROTECTED]> > 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
