Re: Maybe we should open up depends for all targets
On 2008-11-20, Dominique Devienne [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 10:21 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: target-group is-a target. A plain target is a target as opposed to a target-group. Since I have conceptualized them in my head as something different than targets, I forget that implementation-wise they remain targets. Not only implementation-wise, also in my head, conceptually. I actually think it would be better if the code made them distinct classes, possibly extracting an interface for the perform and dependency getting parts, but that's a different story. From the user and documentation perspective, the fact that a target-group is a target under the cover should be de-emphasized IMHO. I wonder what sort of difference between target and target-group people see, I don't seem to get it, sorry. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote: 2008/11/20 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote: - What about the if/unless? This would be pretty hard to implement as you saw yourself later on. What if the same target is in the depends list of two different target-groups? What about making an 'or' between the conditions ? Is this really what would be intended? What if one target-group has an if attribute while the other one has not, or if the have contradicting attributes? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: target-group committed
On 2008-11-21, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: Suppose you have a build with 10 target-group which represent 10 different generic step of your build process (like compile / package/ test/ etc...) Then I'd consider this to be the public API and import it. And behind you have 30 submodules that have one or many target associated (or not) to that target-groups (compile-java,compile-scala,compile-whatever,javadoc,etc) They'd be implementation details of the public API and I'd include them. As target-group are top-level target, as a user i would prefer to see target-group separated instead of having to lookup at ALL target available. So you are really asking for a way to suppress the targets that are merely implementation details, or to de-emphasize them. What you really want is a distinction between public targets and their implementations. This distiction isn't necessarily the same as the one between targets and target-groups. I coud very well envision public targets and not-so-public target-groups. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AntXtras + Ant 1.8 (unhappy duo apparently)
On 2008-11-12, Wascally Wabbit [EMAIL PROTECTED] wrote: Could you send me a backlink to the possible incompatibilities and/or the breaking changes to the current Ant code? I'm afraid there hasn't been too much discussion on the list (the best I can find is http://marc.info/?t=11818165307r=1w=2 and you've been involved) but most simply happened in code. The most relevant changes are related to bugzilla issue 42736 https://issues.apache.org/bugzilla/show_bug.cgi?id=42736 and have been committed in svn revision 554394 http://svn.apache.org/viewvc?diff_format=hview=revrevision=554394 - most later changes have been refinements and I'm afraid you'll have to walk through the svn log of PropertyHelper and maybe other classes to find the rationles behind them. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maybe we should open up depends for all targets
2008/11/21 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-20, Dominique Devienne [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 10:21 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: target-group is-a target. A plain target is a target as opposed to a target-group. Since I have conceptualized them in my head as something different than targets, I forget that implementation-wise they remain targets. Not only implementation-wise, also in my head, conceptually. I actually think it would be better if the code made them distinct classes, possibly extracting an interface for the perform and dependency getting parts, but that's a different story. From the user and documentation perspective, the fact that a target-group is a target under the cover should be de-emphasized IMHO. I wonder what sort of difference between target and target-group people see, I don't seem to get it, sorry. Stefan I'm not sure exactely of what sort of difference I see (normal because we didn't manage to define it), but here my feeling about the difference : - There is a difference of granularity. - Between targets, you have a relations of prerequisites. A target depends on things being produced by other target (that the dependee target knows). - Between targets and target-group, you have an idea of 'PartOf' relationship (with only the part having knowledge of its group). -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt phases
2008/11/21 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote: 2008/11/20 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote: - What about the if/unless? This would be pretty hard to implement as you saw yourself later on. What if the same target is in the depends list of two different target-groups? What about making an 'or' between the conditions ? Is this really what would be intended? What if one target-group has an if attribute while the other one has not, or if the have contradicting attributes? Stefan The idea is to plug a target into a target group. If a target is plugged into 2 target-group, and only one target group needs to be executed, then that target still needs to be executed to satisfy the execution of the other group. Concerning the conflict, we already have it with if and unless (it is just that they are closer). But I agree, it might be confusing. At least until we found a right view for the target and the target-group (something that I feel we don't have yet). -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Yet an other view for target-group
The concept of target-group seems confusing for the moment. I would like to try to prpopose an other view to see if it bring more concensus. Instead of having one special type of target to define a new concept, maybe we need 2 : target-group and target-part. With the caracteristics that : * target-group and target-part can both have depends to any target. * target-part can declare that they are part of 1 or more target-group. * target-group have no content (not sure that's require for the view that we want). At execution, everything behave like if the content of the target-part were executed inside that target-groups (possible multiple time if the part is part of multiple group). The depends of the part being transfered to the group. I think this view support the high granularity build, with a clear layering without conflicting with the current depends relationships. -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
