Let me whip up an example:
<clearcase>
<viewstore>\\${hostname}\viewstore</viewstore>
</clearcase>
If we could pull this off, then probably all users in a certain company could use the same file. If we can't figure out the hostname, then we will need to have a different file for each user.
regards,
Wim
2005/11/30, dan tran <[EMAIL PROTECTED]>:
It makes me feel better. Perhaps we can get clearcase provider to look for a property file under ${user.home}.Shall it be ${user.home}/.m2/clearcase-settings.xml ?-D
On 11/30/05, Jeff Jensen <[EMAIL PROTECTED]> wrote:
Quoting Emmanuel Venisse < [EMAIL PROTECTED]>:
>
>
> Wim Deblauwe a écrit :
> >
> >
> > 2005/11/30, dan tran <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]
>>:
> >
> >
> >
> > On 11/30/05, *Wim Deblauwe* < [EMAIL PROTECTED]![]()
> > <mailto: [EMAIL PROTECTED]>> wrote:
> >
> > Good suggestions there Dan! It is indeed platform dependant and
> > following the maven 2 way, we should be able to put those things
> > in the settings.xml. Is that possible? That way, it's not needed
> > anymore in the scm url.
> >
> >
> > Unfortunatly we dont have access to setting.xml from maven-scm.
> > Therefore we may endup
> > implementing access to setting.xml in both maven-scm-plugin and
> > maven-release-plugin.
> > We may be able to replace release:perform step with scm:bootstrap.
> > So only one place has
> > the setting info. However I dont know if settings.xml has room for
> > this type of user preferences.
> >
> >
> > Should we mail Brett or someone else about this?
>
> I don't want to access to settings.xml in maven-scm. setting.xml in a maven2
> file and maven-scm can
> be use without it, so i think it isn't a good idea to create a maven2 file
> for an independant tool.
> If clearcase infos can't be specified in scm url, i think it's better to use
> system property or we
> can read an environment variable like CLEARCASE_VIEW_STORE_PATH
My .02: I would want all config info in the config files. Not env vars, etc.
For homogenous environments, each user can get the info from the source
controlled config files.
> > Does Continuum 'checkout' the code, builds and then removes the working
> > directory again? Or does the working directory remain and is there some
> > kind of update command that should happen?
>
> We don't remove working directory actually, and we update this directory in
> each build. In future
> version, continuum users will can choose to update or checkout sources. For
> example update for
> hourly builds and full checkout for nightly builds
Just FYI - Perforce requires a "remove from workspace" to remove all the files
locally, as it tracks all file versions it gives each user. This is why
updates are so blazingly faster than its competition. One can manually delete
the files, but Perforce will still think you have them. A Perforce user does
the same action for a "update get latest" and a "full get latest": just a
sync/get latest. Removing all the files and then doing a get latest will have
the same end result, just take a lot longer!
