You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "Stephane Bailliez (JIRA)" <ji...@apache.org> on 2006/12/27 14:11:20 UTC
[jira] Created: (IVY-364) Default status behavior in StatusManager
Default status behavior in StatusManager
----------------------------------------
Key: IVY-364
URL: http://issues.apache.org/jira/browse/IVY-364
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 1.4.1
Reporter: Stephane Bailliez
Priority: Trivial
Looking at StatusManager and XmlIvyConfigurationParser.
It is unclear whether or not a null default status is valid.
The SAX code goes the extra step not to put null, yet the StatusManager deals with null by automatically setting the last element of the statuses (why is that ? so that means that order is relevant ? what's the rationale ? )
Failing on null and checking that the default status is actually really on the provided list of statuses would be my preference.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IVY-364) Default status behavior in
StatusManager
Posted by "Stephane Bailliez (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/IVY-364?page=comments#action_12461075 ]
Stephane Bailliez commented on IVY-364:
---------------------------------------
I don't like the current implementation for the following reasons:
The problem when such things are done the way it is, is that you find yourself torn...limits are stretch so you find the need to introduce log about it because it is abnormal and can be useful to debug... so you add logs as well. So a simple component is suddenly tasked not only to find a default behavior but also to log about it. Which complexifies the code. Not mentioning that then you will have sometimes a mix between stateless and stateful code.
It would be much better to push this default logic to the configuration of the component (ie: when it is parsed). The configuration level is the scope where you are able to centralize the decision of running with this parameter and using this as a default because this was not provided, etc... and you will find yourself with logs at this level because this is common practice.
> Default status behavior in StatusManager
> ----------------------------------------
>
> Key: IVY-364
> URL: http://issues.apache.org/jira/browse/IVY-364
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.1
> Reporter: Stephane Bailliez
> Priority: Trivial
>
> Looking at StatusManager and XmlIvyConfigurationParser.
> It is unclear whether or not a null default status is valid.
> The SAX code goes the extra step not to put null, yet the StatusManager deals with null by automatically setting the last element of the statuses (why is that ? so that means that order is relevant ? what's the rationale ? )
> Failing on null and checking that the default status is actually really on the provided list of statuses would be my preference.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IVY-364) Default status behavior in
StatusManager
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/IVY-364?page=comments#action_12461053 ]
Xavier Hanin commented on IVY-364:
----------------------------------
I'd say that if you do not set the default status the last one will be used as default status, as documented here:
http://www.jayasoft.org/ivy/doc/configuration/statuses.html
So the extra step in XmlIvyConfigurationParser is not necessary. Since using the last status is what is documented with Ivy 1.4, I prefer keeping things like that. But I agree this need to be better documented and explained, as you suggest in IVY-362.
> Default status behavior in StatusManager
> ----------------------------------------
>
> Key: IVY-364
> URL: http://issues.apache.org/jira/browse/IVY-364
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.1
> Reporter: Stephane Bailliez
> Priority: Trivial
>
> Looking at StatusManager and XmlIvyConfigurationParser.
> It is unclear whether or not a null default status is valid.
> The SAX code goes the extra step not to put null, yet the StatusManager deals with null by automatically setting the last element of the statuses (why is that ? so that means that order is relevant ? what's the rationale ? )
> Failing on null and checking that the default status is actually really on the provided list of statuses would be my preference.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (IVY-364) Default status behavior in StatusManager
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles Scokart updated IVY-364:
-------------------------------
Fix Version/s: 2.0
> Default status behavior in StatusManager
> ----------------------------------------
>
> Key: IVY-364
> URL: https://issues.apache.org/jira/browse/IVY-364
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.4.1
> Reporter: Stephane Bailliez
> Priority: Trivial
> Fix For: 2.0
>
>
> Looking at StatusManager and XmlIvyConfigurationParser.
> It is unclear whether or not a null default status is valid.
> The SAX code goes the extra step not to put null, yet the StatusManager deals with null by automatically setting the last element of the statuses (why is that ? so that means that order is relevant ? what's the rationale ? )
> Failing on null and checking that the default status is actually really on the provided list of statuses would be my preference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.