[
https://issues.apache.org/jira/browse/ONAMI-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955004#comment-13955004
]
Simone Tripodi commented on ONAMI-102:
--------------------------------------
cool thanks a lot [~ash2k] for your efforts - I am having a look at the
attached patch tonight (my local timezone) and will let you know ASAP! :)
> Redesign the Modules structure in order to simply APIs usage
> ------------------------------------------------------------
>
> Key: ONAMI-102
> URL: https://issues.apache.org/jira/browse/ONAMI-102
> Project: Apache Onami
> Issue Type: Improvement
> Components: lifecycle
> Affects Versions: lifecycle-0.2.0
> Reporter: Simone Tripodi
> Assignee: Mikhail Mazursky
> Fix For: lifecycle-0.2.0
>
> Attachments: LifeCycleModule.java, LifeCycleStageModule.java
>
>
> We already started discussing about it in the ML, but let's track progresses
> on JIRA.
> I detected few areas of approaching the lifecycle design:
> * IIUC, we want to manage a series of annotations which identify the
> sequence of staging steps in the lifecycle, so IMHO the
> AbstractLifeCycleModule constructor with just one annotation has to
> disappear; it would be nice to have a varargs array, which would simplify the
> signature - and the usage from our users - but it would generate an annoying
> warning to our users; IMHO it is still acceptable, but in case we don't find
> an agreement here, Iterable should be the best way to pass the annotations
> sequence to the module.
> * ListBuilder: as already discussed, this sound too generic: I'd propose
> something like AnnotationsLifecycleSequenceBuilder (maybe it is too verbose
> :P) but I'd opt for something that gives a precise idea, not a generic one;
> * Again on the list builder, as we discussed, IMHO the wrapped data
> structure should be a LinkedHashSet: it preserves the sequence and makes
> efficient the check for duplicates - if the list has a duplicate, I bet the
> lifecycle event would be handled twice;
> * Builder pattern: the way to get the builder is IMHO a little too verbose:
> Builder.newBuilder() is not a pattern that makes me particularly happy, I'd
> rather opt for inner class builder such as {{new ConcreteClass.Builder()}}
> which is used in the AsyncHttpClient - WDYT?
> I can even make a proposal, in order to show you better my ideas, and attach
> a patch to discuss together
--
This message was sent by Atlassian JIRA
(v6.2#6252)
