Re: New Task: Debian packaging with jdeb
committed, should appear on the website soon Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Task: Debian packaging with jdeb
On Mon, 2008-06-16 at 16:52 +0200, Emmanuel Bourg wrote: > Hi all, > > I'd like to advertise the jdeb task on the 'External Tools and Tasks' > page of the Ant site. It's a task for building debian packages. Here is > the description: > > name: jdeb > > description: JDeb provides an Ant task and a Maven plugin to create > Debian packages from Java builds in a truly cross platform manner. Build > your Debian packages on any platform that has Java support. Windows, > Linux - it does not require additional native tools installed. > Sounds very cwel need to try it out. Thanks for the contribution. salu2 > compatibility: Ant 1.7 (not tested on earlier versions) > > url: http://vafer.org/projects/jdeb/ > > contact: [EMAIL PROTECTED] > > license: The Apache Software License 2.0 > > > Thank you, > > Emmanuel Bourg > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Task: Debian packaging with jdeb
Stefan Bodewig a écrit : committed, should appear on the website soon Thanks a lot Stefan. Just curious, is Ant accepting new core tasks nowadays. jdeb might be a useful addition when it's mature enough to complement the existing rpm task. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Task: Debian packaging with jdeb
On Tue, 17 Jun 2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote: > Just curious, is Ant accepting new core tasks nowadays. Probably, if something really is a core concern (say a new tool becoming part of a more recent JDK). For something like jdeb it would be unlikely since it is very specific. We do accept new Ant library projects, though > jdeb might be a useful addition when it's mature enough to > complement the existing rpm task. I'd rather move the rpm task out of core and into a separate AntLib (which is true for a lot of tasks that make up an Ant distribution). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Locking in Project and PropertyHelper
Hi all, while looking into https://issues.apache.org/bugzilla/show_bug.cgi?id=45194 I realized that we are currently pretty inconsistent with our usage of locking in Project. Right now we have: * locking on the Project instance for the logging subsystem (add or remove a BuildListener and the actual logging) * locking on the PropertyHelper instance on all public PropertyHelper methods * locking on the Project instance when associating a task with the current thread - but not when reading it * locking of the references table when setting a reference, but not when reading it The first two cause the race condition noted in the bug report since the methods in PropertyHelper may log stuff while another thread is active logging something and its currently executing BuildListener tries to read property. There are two places where we potentially call external (non-Ant) code inside of a synchronized section: while logging (a BuildListener) and while accessing properties (a PropertySetter or PropertyEvaluator). Either should be avoided, but I'm not sure we can. We use locking for the log system for two reasons: locking the collection of listeners and setting a flag that allows us to detect recursive invocations of the logging system in order to avoid infinite loops (a BuildListener writing to System.out/err). I suggest the following changes: * add locking to getThreadTask, but don't use the project instance but rather something like the threadTasks table (and use that in registerTreadTask, of course). * remove the locking of references completely. Given we hand out full control via Project.getReferences to whoever is there, locking the write access to make the "do I need to print a warning? Add the reference" operation atomic seems pretty useless to me. * lock the listener collection in the add/remove listener methods, in fireMessageLogged lock the listeners, clone them, give up the lock, work on the clone * turn the loggingMessage flag into a ThreadLocal, don't lock for it at all. The last two changes allow BuildListeners to be executed without holding any locks - this should avoid the deadlock in issue 45194. * I'm not completely sure what the reasons for locking in PropertyHelper are and whether: * lock the delegates collections in add and clone it in all the other methods * invoke the delegate without any locks * lock on the property helper instance after all delegates have been invoked would meet all the needs. Matt? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Issue 45190 and Ant 1.7.1
Hi all, I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with a rather trivial patch http://svn.apache.org/viewvc?view=rev&revision=668624 and now the reporter asks whether this could go into 1.7.1. While I understand that he needs the bug fixed, I also wouldn't want to cause any delay of the 1.7.1 release. Kev, would you accept the patch into the 1.7 branch and go ahead with the release or would it slow you down if it got merged? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking in Project and PropertyHelper
On Tue, 17 Jun 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > I suggest the following changes: > > * lock the listener collection in the add/remove listener methods, > in fireMessageLogged lock the listeners, clone them, give up the > lock, work on the clone alternatively copy listeners on change in the add/remove cases since we are probably writing far more log messages than we add or remove listeners. Same would apply to the delegates in PropertyHelper. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking in Project and PropertyHelper
On Tue, Jun 17, 2008 at 1:57 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jun 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>
>> I suggest the following changes:
>>
>> * lock the listener collection in the add/remove listener methods,
>> in fireMessageLogged lock the listeners, clone them, give up the
>> lock, work on the clone
>
> alternatively copy listeners on change in the add/remove cases since
> we are probably writing far more log messages than we add or remove
> listeners. Same would apply to the delegates in PropertyHelper.
We currently do copy the listeners.
public synchronized void addBuildListener(BuildListener listener) {
Vector newListeners = getBuildListeners();
newListeners.addElement(listener);
listeners = newListeners;
Simply removing the lock on the project object would
not help as multiple threads could call the add/remove method at the same time.
We would need something like jdk5's CopyOnWriteArrayList to do this
correctly.
Peter
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking in Project and PropertyHelper
On Tue, 17 Jun 2008, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2008 at 1:57 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > On Tue, 17 Jun 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> >
> >> I suggest the following changes:
> >>
> >> * lock the listener collection in the add/remove listener methods,
> >> in fireMessageLogged lock the listeners, clone them, give up the
> >> lock, work on the clone
> >
> > alternatively copy listeners on change in the add/remove cases since
> > we are probably writing far more log messages than we add or remove
> > listeners. Same would apply to the delegates in PropertyHelper.
>
> We currently do copy the listeners.
Why didn't I see that? Silly.
> public synchronized void addBuildListener(BuildListener listener) {
>
> Vector newListeners = getBuildListeners();
> newListeners.addElement(listener);
> listeners = newListeners;
>
> Simply removing the lock on the project object would not help
I know and I hope I didn't sound as if I was suggesting that. I'd
introduce a dedicated lock object instead of using the project
instance here, though.
We could remove the lock in fireMessageLogged.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue 45190 and Ant 1.7.1
Hi Stefan, > I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with > a rather trivial patch > http://svn.apache.org/viewvc?view=rev&revision=668624 and now the > reporter asks whether this could go into 1.7.1. > > While I understand that he needs the bug fixed, I also wouldn't want > to cause any delay of the 1.7.1 release. > > Kev, would you accept the patch into the 1.7 branch and go ahead with > the release or would it slow you down if it got merged? If I accepted this, would I need to re-issue a beta and wait the required time for people to retest before starting the release process? I'm only happy to accept it if this has no bearing on the release process right now :) I'm currently on holiday (from work) with some folks over from Oz, so my free coding/releasing time is quite low right now. I hope to have time in the next week or so to start the release - I don't really want to delay and have a beta3/4 release and then be releasing the final version sometime in September! :) Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking in Project and PropertyHelper
Stefan: Your suggested changes on PropertyHelper sound reasonable; I'm playing with them now. -Matt --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Hi all, > > while looking into > https://issues.apache.org/bugzilla/show_bug.cgi?id=45194 > I realized > that we are currently pretty inconsistent with our > usage of locking in > Project. > > Right now we have: > > * locking on the Project instance for the logging > subsystem (add or > remove a BuildListener and the actual logging) > > * locking on the PropertyHelper instance on all > public PropertyHelper > methods > > * locking on the Project instance when associating a > task with the > current thread - but not when reading it > > * locking of the references table when setting a > reference, but not > when reading it > > The first two cause the race condition noted in the > bug report since > the methods in PropertyHelper may log stuff while > another thread is > active logging something and its currently executing > BuildListener > tries to read property. > > There are two places where we potentially call > external (non-Ant) code > inside of a synchronized section: while logging (a > BuildListener) and > while accessing properties (a PropertySetter or > PropertyEvaluator). > Either should be avoided, but I'm not sure we can. > > We use locking for the log system for two reasons: > locking the > collection of listeners and setting a flag that > allows us to detect > recursive invocations of the logging system in order > to avoid infinite > loops (a BuildListener writing to System.out/err). > > I suggest the following changes: > > * add locking to getThreadTask, but don't use the > project instance but > rather something like the threadTasks table (and > use that in > registerTreadTask, of course). > > * remove the locking of references completely. > Given we hand out full > control via Project.getReferences to whoever is > there, locking the > write access to make the "do I need to print a > warning? Add the > reference" operation atomic seems pretty useless > to me. > > * lock the listener collection in the add/remove > listener methods, > in fireMessageLogged lock the listeners, clone > them, give up the > lock, work on the clone > > * turn the loggingMessage flag into a ThreadLocal, > don't lock for it > at all. > > The last two changes allow BuildListeners to be > executed without > holding any locks - this should avoid the deadlock > in issue 45194. > > * I'm not completely sure what the reasons for > locking in > PropertyHelper are and whether: > > * lock the delegates collections in add and clone > it in all the > other methods > > * invoke the delegate without any locks > > * lock on the property helper instance after all > delegates have been > invoked > > would meet all the needs. Matt? > > Stefan > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r668724 - in /ant/core/trunk/src/main/org/apache/tools/ant: taskdefs/ taskdefs/email/ taskdefs/optional/ types/resources/ types/resources/comparators/
On Tue, 17 Jun 2008, <[EMAIL PROTECTED]> wrote: > [43348] Use FileProvider interface Great! Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
