You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Stuart McCulloch <st...@jayway.net> on 2008/08/06 07:02:02 UTC
Re: [Vote] release maven-bundle-plugin 1.4.2
2008/8/6 Sahoo <sa...@sun.com>
> 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.
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.
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)
btw, I don't see a patch attached to the JIRA issue - does the patch solve
your current build issues?
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.
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.
Thanks,
> Sahoo
>
> Stuart McCulloch wrote:
>
>> Hi folks,
>>
>> I'd like to start a vote for the 1.4.2 release of the maven-bundle-plugin,
>> which contains a number of minor fixes (see the changelog for details)
>> as well as some additional OBR functionality contributed by Clement.
>>
>> I've built and signed the release candidate and made it available here:
>>
>>
>>
>> http://people.apache.org/~mcculls/releases/felix/maven-bundle-plugin/org/apache/felix/maven-bundle-plugin/1.4.2<http://people.apache.org/%7Emcculls/releases/felix/maven-bundle-plugin/org/apache/felix/maven-bundle-plugin/1.4.2>
>>
>> You can also find the KEYS file for verifying the signature in this
>> directory.
>> So, please check the release and cast your votes. (vote will run for
>> 72hrs)
>>
>>
>>
>
--
Cheers, Stuart
Re: [Vote] release maven-bundle-plugin 1.4.2
Posted by Stuart McCulloch <st...@jayway.net>.
2008/8/6 Sahoo <Sa...@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
Re: [Vote] release maven-bundle-plugin 1.4.2
Posted by Sahoo <Sa...@Sun.COM>.
Hi Stuart,
Stuart McCulloch wrote:
> 2008/8/6 Sahoo <sa...@sun.com>
>
>
>> 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
Re: [Vote] release maven-bundle-plugin 1.4.2
Posted by Sahoo <Sa...@Sun.COM>.
Hi Stuart,
Stuart McCulloch wrote:
> 2008/8/6 Sahoo <sa...@sun.com>
>
>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org