Actually, pointing at a different local repo for the purposes of a build is trivial. However, in the case of testing a plugin, you have to install the plugin somewhere, then run a build that uses that plugin...this is not the case with anything other than Maven components, which makes it an exceptional use case. If Geronimo wants to fire off a build during their integration tests, they will be able to specify the local repository location without a problem, using either the embedder or the invoker.
Once we get nearer a release of the new embedder, I'd like to converge the two, and hopefully get it down to a fork flag to determine which is used. But the plugin-test stuff is different, and it's an exotic use case. Also, if we're going to stop touching the local repository during a build, when will we use it? If you were to use the repository-assembly stuff from the assembly plugin to generate a one-time use repository containing all of your dependencies, then I can imagine forking off a local repository for integration testing. However, unless you're on a busy build server where you could reasonably expect to encounter race conditions on artifact resolution by way of the local repo, I would really hope that Maven would resolve to the same set of artifacts over two successive builds like this. I do think this would be a good option for many people when running integration tests (for instance, on large Continuum deployments). But for many users, this will be an unnecessary performance degradation. -john On 8/11/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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]
