Luciano Resende wrote:
I'll take a deeper look at your proposed changes later today or in the
morning, as I'm in the middle of something now... I have one quick
question ...
ContributionRepository was created to allow remote contributions to be
stored in a local repository to be processed by the contribution
service. You now have extended the repository responsibilities to also
track the list of contributions added to the domain, but not
physically stored in the repository, but I still see store and
addContribution implementations working in a disconnected way today in
ContributionRepositoryImpl. Well, I guess I understand why you did it,
basically to be able to pass a list of contribution to the listeners,
so in my scenario, I can use that to instantiate a
ImportAllModelResolverImpl, but we probably need a better discussion
on what are the responsibilities of the Repository, as there were
some interest of extending it's usage for other scenarios as discussed
in [1], and then review its implementation based on the outcome of
these discussion. Well, I just want to raise the issue to avoid
confusion later on...
[1] http://www.mail-archive.com/[email protected]/msg20100.html
I left all existing methods in place as I'm anticipating that we'll want
to merge them at some point:
- find / getContribution
- remove / removeContribution
- store / addContribution and updateContribution
all look pretty similar :)
If you think that tracking the contributions installed on an SCA domain
is not the responsibility of ContributionRepository, I'm also happy to
move these methods out into a different class... Whatever option we
choose, we'll need a clean class - cleaner than a Hashmap buried inside
ContributionServiceImpl :) - to track which contributions are installed
on a domain.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
