ok, I'm implementing all of this. We'll see how it goes. But I need to test this ofcourse. How can I use/update Continuum 1.0.1 to test with ClearCase?

regards,

Wim

2005/12/1, Wim Deblauwe < [EMAIL PROTECTED]>:
I agree 100% that we will need proper help. I'm a firm believer that if a feature is not documented, it does not exist, because no-one will know how to use it.

2005/12/1, Emmanuel Venisse < [EMAIL PROTECTED]>:
I'm agree for a new file, but not in ${ user.home}/.m2 because maven-scm and m2 are independant.
You can use ${user.home}/.scm

When it will be implemented, you'll should update the site content and explain how maven-scm works
with clearcase.

Emmanuel

Wim Deblauwe a écrit :
> 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!
>
>
>



Reply via email to