On 11 Aug 06, at 11:25 AM 11 Aug 06, John Casey wrote:
it doesn't backup the whole local repository, only the files that
will be
affected by a plugin install. It should be relatively stable in
terms of the
backup/restore data transfer size...varying only by the number of
repositories that were consulted for that artifact (because there
is a set
of metadata files for each remote repository).
I'm not sure what you mean by encapsulating things needed by the
runtime.
What I want to avoid is introducing excessive design changes to the
core
just so we can enable plugin manipulation that wouldn't happen in a
normal
use case.
I think this is a normal use case. A concrete example being the
embedder pointing at a completely separate repository structure for,
say, Geronimo. They use a Maven repository for their own use and you
should be able to flip a parameter and use the encapsulated
requirements for runtime: a repository, any configuration, any
directories which hold configuration, caches, or anything of that
nature. I think touching the repository that is actually used in the
day-to-day is sort of fugly. If the plugin interacts with any
artifacts then all those are going to be affected as so if you're
doing integration tests on the Jetty plugin then you're going to pull
in a whole raft of other dependencies, you're sure you're picking all
that up and restoring it fully? I think some things with artifact
resolution are a little loosy goosy at moment and not touching the
users repository I think would be a better option.
-john
On 8/11/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 11 Aug 06, at 9:18 AM 11 Aug 06, John Casey wrote:
> This should be solved by the stage/unstage mojos in the plugin-test
> plugin.
> That's its only current purpose. It will stage a new plugin
> artifact into
> the local repository, backing up what was there before, then
clear the
> pluginManager's cache of that plugin, in case it's been resolved
> already.
> Unstaging (de-staging?) will restore the backed up data, and clear
> the cache
> again.
>
We should move toward encapsulating anything the runtime requires so
we could parameterize it on execution so that you don't have to
tamper with the local repository. If someone has a massive local
repository that could get pretty time consuming.
> -john
>
> On 8/11/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Vincent Massol wrote:
>>
>> > Also, Kenney do you know if the it plugin can now be used to
test a
>> plugin
>> > that is being built for the first time? I remember that I didn't
>> activate it
>> > on the clover plugin because it would work only if the clover
>> plugin was
>> > installed in the local repository and this came after
integration
>> testing.
>> > Thus you would always run it tests on the previous version of
>> the plugin
>> > (looked up from the local repo). I think I had a jira issue for
>> this.
>> I'm
>> > offline now but I'll try to dig it up if need be.
>>
>> The following issue [1] should provide that: it was blocking the
>> use of
>> the it plugin; once fixed, it worked fine. If the local repository
>> version of the plugin is used instead, then I suggest we re-
open the
>> issue.
>>
>> [1] http://jira.codehaus.org/browse/MNG-870
>>
>> -- Kenney
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
Jason van Zyl
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jason van Zyl
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
