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]
<mailto:[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]
<mailto:[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]> <mailto:[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]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
Quoting Emmanuel Venisse < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[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]>>
<mailto: [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]>>
> > <mailto: [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!
