I like that. I agree that we should not (ab)use settings.xml for a
custom plugin. If we now agree on the format for the file, we are set to
go :)
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] <mailto:[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]
<mailto:[EMAIL PROTECTED]>> wrote:
Quoting Emmanuel Venisse < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Wim Deblauwe a écrit :
>
>
> 2005/11/30, dan tran <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>:
>
>
>
> On 11/30/05, *Wim Deblauwe* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [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!