Hi Stuart,

Stuart McCulloch wrote:
2008/8/6 Sahoo <[EMAIL PROTECTED]>

Hi,


Hi Sahoo,


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

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? I ask because there's a
design issue in Maven that means the local repository is not protected
against concurrent reading/writing.

So if you have multiple builds running concurrently against the same local
repository you will see occasional failures wrt. changed files, no matter
what improvements are made to the plugin code.

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.
If you look at the comments made by Harsha, you shall see that we have spent
considerable time before concluding that it is not possible to change the
behavior of Zip/jar utility of JDK, hence it has to be handled by clients of
those utilities, which happens to be both the plugin as well as bnd. I
believe Harsha has even attached a patch for this. I know it's a bit late in
the game, but is there any chance of getting this fix in 1.4.2?


if I'd been told about this sooner then possibly, but not at this stage -
unless of course this problem doesn't occur with 1.4.1 (but that uses the
same version of Bnd, so it should also behave the same)
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.
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.
fixing this properly will require changes to Bnd and a Maven shared
component which are managed by other teams with their own release schedules
- also the latest Bnd library contains other changes, so I'd want to do lots
of testing before moving up to the new version.

we could look into doing a custom release, using patched source files to
override the classes in the original dependencies - but then I'd definitely
need access to a recreatable testcase and your patch to apply and verify the
changes.

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.
If not, we will probably have to cut our own release off 1.4.2 to use in our
build system, something we really don't like, but we may be left with no
option.


that might be the best option for now, especially as I won't be online at
all from the 10th to 24th.

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.

Thanks for your speedy response. It is realy appreciated.

Regards,
Sahoo

Reply via email to