the algorithm to get a fresh copy for each DB access should be independent 
of the cached DB algorithm?

so when the oper thinks they are getting a fresh copy when in fact they're 
getting the copy from cache
would not be good?

is there a architecture document available which reflects the 2 testcases?

is there ever a  testcase scenario available where the 2 algorithm's coincide?

Martin 
______________________________________________ 
Disclaimer and confidentiality note 
Everything in this e-mail and any attachments relates to the official business 
of Sender. This transmission is of a confidential nature and Sender does not 
endorse distribution to any party other than intended recipient. Sender does 
not necessarily endorse content contained within this transmission. 


> Date: Tue, 7 Oct 2008 09:06:49 -0700
> From: [EMAIL PROTECTED]
> To: [email protected]
> Subject: Help with assembly (?) plugin
> 
> 
> All,
> 
> Can someone first of all either confirm that I am on the right track or tell
> me that I am an idiot and point me in the right direction.
> 
> If I *am* on the right track, can someone give me a shove towards the right
> configuration.
> 
> I have a module that is part of a larger project. It is required by two
> other modules, but each requires a subtly different configuration. I would
> like to minimise (eliminate) any code duplication and have each dependency
> get built automagically. At present my developers are working around it by
> manually toggling the configuration file and the artifact name but I know
> there has to be a better way to do it.
> 
> Basically, we have a load of data access code that hits a datasource. I need
> to build two versions of this artifact, one which is configured to cache the
> hits from the datasource and the other which is to hit the datasource each
> time. This is configured in a file embedded within the jar by the build.
> 
> I figure that I should be able to make one module with all the code and the
> default (cache) setup in it. I think that I can then configure the no-cache
> module to depend on the cache version and then use the assembly plugin to
> unpack the jar into the build directory then have the no-cache configuration
> file stomp on the cache version and have the jar be all packaged back up
> again.
> 
> Am I right in my line of thinking?
> 
> Thanks in advance for any help.
> 
> 
> Later,
> 
> Andy Law
> -- 
> View this message in context: 
> http://www.nabble.com/Help-with-assembly-%28-%29-plugin-tp19861584p19861584.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

_________________________________________________________________
Get more out of the Web. Learn 10 hidden secrets of Windows Live.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008

Reply via email to