[izpack-devel] mutually exclusive packs
vralev at redhat.com
Tue Nov 14 15:32:48 CET 2006
These "chained" declarations made me thinking about an alternative
syntax. How about instead of having <excludes>, add a new attribute to
the pack tag:
<pack name="1" installGroups="1" required="no" excludeGroup="group1">
<pack name="2" installGroups="1" required="no" excludeGroup="group1">
<pack name="3" installGroups="1" required="no" excludeGroup="another
<pack name="4" installGroups="1" required="no" excludeGroup="another
This way, all packs in the same excludeGroup will be mutually exclusive.
I think there is no need to support multiple excludeGroups per pack
because of the tie cases, but if want I can do that too.
Is this any better?
Bartz, Klaus wrote:
> Hi Vladimir,
> I think both possitions are possible. If I have no
> docu, I assume a behavior like I would implement it.
> Rest context related.
> You know, we have some features where the documentation is not
> optimal. I think we should not do it at new features.
>> -----Original Message-----
>> From: izpack-devel-bounces at lists.berlios.de
>> [mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Vladimir
>> Sent: Monday, November 13, 2006 7:18 PM
>> To: izpack-devel at lists.berlios.de
>> Subject: Re: [izpack-devel] mutually exclusive packs
>> The user should simply be advised to do:
>> pack1 excludes (pack2 and pack3)
>> pack2 excludes (pack3 and pack1)
>> pack3 excludes (pack1 and pack2)
> That's the problem with the docu... You know it because you have
> implement it and I will show into the sources if I get a problem.
> But many user do not like the hint "the sources are the best
> Therefore my request for a docu from the developer.
>> I think the problem with your "shortcut"-syntax is that the graph may
>> contain many cycles like:
>> pack1 excludes (pack2 and pack4)
>> pack2 excludes pack3
>> pack3 excludes pack1
>> pack4 excludes pack3
>> or even worse...
>> Of course I can implement transitive exclusion (like the
>> transitive dependencies) - if (pack1 excludes pack2) AND
>> (pack2 excludes pack3) THEN (pack1 excludes (pack2 and pack3)).
>> In this case however I will disallow *any* cycles in the exclusion
>> graph, because the recursion will go forever. I personally think that
>> the exclusions are better without transitive traversal, but if
>> you want
>> something else I will do it.
>> Another useful syntactical shortcut would be to implicitly create the
>> symmetric exclude - if (pack1 excludes pack2) THEN automatically do
>> (pack2 excludes pack1), but this breaks the declarative symmetry?
> I tend to support implicit symmetry.
> May be it breaks the declarative symmetry, but it suppress an
> asymmetric execution.
> selection of pack2 deselects pack1 but selection of pack1 do not
> deselect pack2.
>> PS. I found a bug in the code I sent you (packs with no
>> "excludes" tags
>> cause exceptions), I will be making more changes too.
> Nice. Additional if you declare a nonexistent pack as excludes a
> null pointer exception raises in the installer. May be a verification
> at compile time will be better.
>> I am waiting for your comments and will send the final code soon.
>> Bartz, Klaus wrote:
>>> Hi Vladimir,
>>> today I have tested a little bit.
>>> If the exclusion will be declared as full cross references
>>> it works fine.
>>> But what should be happen with
>>> pack1 excludes pack2
>>> pack2 excludes pack3
>>> pack3 excludes pack1
>>> If I select first pack1 and then pack2 both are selected.
>>> If I select first pack2 and then pack1 only pack1 is selected.
>>> Not a real szenario? May be, but I am certain that someone
>>> does it in the future and calls why this not work as he/she assumed.
>>> Therefore we should clear this in front.
>>> I tend to say that an implicit backward exclusion should be
>>> performed; means
>>> If I selct first pack1 and then pack2 only pack2 is selected.
>>> If I selct first pack2 and then pack1 only pack1 is selected.
>>> What is your meaning, what say the others?
>> izpack-devel mailing list
>> izpack-devel at lists.berlios.de
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
Vladimir Ralev, JBoss/RedHat
More information about the izpack-devel