You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm-dev@maven.apache.org by Wim Deblauwe <wi...@gmail.com> on 2005/12/01 08:17:27 UTC
Re: ClearCase 'checkout' implementation
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 <da...@gmail.com>:
>
> 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 <je...@upstairstechnology.com> wrote:
> >
> > Quoting Emmanuel Venisse <em...@venisse.net>:
> >
> > >
> > >
> > > Wim Deblauwe a écrit :
> > > >
> > > >
> > > > 2005/11/30, dan tran <dantran@gmail.com <mailto:dantran@gmail.com
> > >>:
> > > >
> > > >
> > > >
> > > > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > > > <mailto: wim.deblauwe@gmail.com>> 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!
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
:)
file an issue and we'll try to add this feature in continuum.
Emmanuel
Wim Deblauwe a écrit :
> True, it would be nice to have dynamic views as well, but this is
> currently the only solution with the way that Continuum works. So, if
> snapshots don't work for you, then I guess you will need to bother
> Emmanuel ;)
>
> regards,
>
> Wim
>
> 2005/12/1, dan tran <dantran@gmail.com <ma...@gmail.com>>:
>
> yup, I never try this before. but teh checkout time will be very
> long for my chase since my legacy system has a lots of dead,
> seldomlyused,larged files.
>
> I rather to stay on the dynamic view rather than snapshot view.
>
> If your system is new and you are carefully organize your soure
> tree, snapshot could be the way to go. but if you are using snapshot
> view
> and the developer using dyanmic view, there will potential finger
> pointing when the build goes wrong.
>
> -Dan
>
>
>
> On 12/1/05, *Wim Deblauwe* <wim.deblauwe@gmail.com
> <ma...@gmail.com>> wrote:
>
> That is not true if you create a snapshot view. It can be in any
> directory. I already implemented and tested this. You can then
> do a 'cleartool update' and that will update the snapshot view.
>
> regards,
>
> Wim
>
> 2005/12/1, dan tran <dantran@gmail.com <ma...@gmail.com>>:
>
> After checkout, clearcase dictates to location of checkout
> directory
>
> on my windows
>
> m:/view-name
>
> on my unix
>
> /view/${view-name}/vobs
>
> So continuum must allow a way to change per build entry to
> the new working direct
> rather ${continuum-workdir}/#
>
> We must stay on clearcase directory inorder to do other
> update/changelog commands
>
> -Dan
>
>
> On 12/1/05, *Emmanuel Venisse* <emmanuel@venisse.net
> <ma...@venisse.net>> wrote:
>
>> I prefer that too, so I filed
>> http://jira.codehaus.org/browse/CONTINUUM-491
> <http://jira.codehaus.org/browse/CONTINUUM-491>. If that
> is easy to fix,
>> could you send me the fix so I continue testing?
>>
>
> I'll fix it today or tomorrow.
>
> Emmanuel
>
>
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
True, it would be nice to have dynamic views as well, but this is currently
the only solution with the way that Continuum works. So, if snapshots don't
work for you, then I guess you will need to bother Emmanuel ;)
regards,
Wim
2005/12/1, dan tran <da...@gmail.com>:
>
> yup, I never try this before. but teh checkout time will be very long
> for my chase since my legacy system has a lots of dead, seldomlyused,larged
> files.
>
> I rather to stay on the dynamic view rather than snapshot view.
>
> If your system is new and you are carefully organize your soure tree,
> snapshot could be the way to go. but if you are using snapshot view
> and the developer using dyanmic view, there will potential finger pointing
> when the build goes wrong.
>
> -Dan
>
>
>
> On 12/1/05, Wim Deblauwe <wi...@gmail.com> wrote:
> >
> > That is not true if you create a snapshot view. It can be in any
> > directory. I already implemented and tested this. You can then do a
> > 'cleartool update' and that will update the snapshot view.
> >
> > regards,
> >
> > Wim
> >
> > 2005/12/1, dan tran <da...@gmail.com>:
> > >
> > > After checkout, clearcase dictates to location of checkout directory
> > >
> > > on my windows
> > >
> > > m:/view-name
> > >
> > > on my unix
> > >
> > > /view/${view-name}/vobs
> > >
> > > So continuum must allow a way to change per build entry to the new
> > > working direct
> > > rather ${continuum-workdir}/#
> > >
> > > We must stay on clearcase directory inorder to do other
> > > update/changelog commands
> > >
> > > -Dan
> > >
> > >
> > > On 12/1/05, Emmanuel Venisse <emmanuel@venisse.net > wrote:
> > > >
> > > > > I prefer that too, so I filed
> > > > > http://jira.codehaus.org/browse/CONTINUUM-491 . If that is easy to
> > > > fix,
> > > > > could you send me the fix so I continue testing?
> > > > >
> > > >
> > > > I'll fix it today or tomorrow.
> > > >
> > > > Emmanuel
> > > >
> > > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
yup, I never try this before. but teh checkout time will be very long for
my chase since my legacy system has a lots of dead, seldomlyused,larged
files.
I rather to stay on the dynamic view rather than snapshot view.
If your system is new and you are carefully organize your soure tree,
snapshot could be the way to go. but if you are using snapshot view
and the developer using dyanmic view, there will potential finger pointing
when the build goes wrong.
-Dan
On 12/1/05, Wim Deblauwe <wi...@gmail.com> wrote:
>
> That is not true if you create a snapshot view. It can be in any
> directory. I already implemented and tested this. You can then do a
> 'cleartool update' and that will update the snapshot view.
>
> regards,
>
> Wim
>
> 2005/12/1, dan tran <da...@gmail.com>:
> >
> > After checkout, clearcase dictates to location of checkout directory
> >
> > on my windows
> >
> > m:/view-name
> >
> > on my unix
> >
> > /view/${view-name}/vobs
> >
> > So continuum must allow a way to change per build entry to the new
> > working direct
> > rather ${continuum-workdir}/#
> >
> > We must stay on clearcase directory inorder to do other update/changelog
> > commands
> >
> > -Dan
> >
> >
> > On 12/1/05, Emmanuel Venisse <emmanuel@venisse.net > wrote:
> > >
> > > > I prefer that too, so I filed
> > > > http://jira.codehaus.org/browse/CONTINUUM-491 . If that is easy to
> > > fix,
> > > > could you send me the fix so I continue testing?
> > > >
> > >
> > > I'll fix it today or tomorrow.
> > >
> > > Emmanuel
> > >
> > >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
That is not true if you create a snapshot view. It can be in any directory.
I already implemented and tested this. You can then do a 'cleartool update'
and that will update the snapshot view.
regards,
Wim
2005/12/1, dan tran <da...@gmail.com>:
>
> After checkout, clearcase dictates to location of checkout directory
>
> on my windows
>
> m:/view-name
>
> on my unix
>
> /view/${view-name}/vobs
>
> So continuum must allow a way to change per build entry to the new working
> direct
> rather ${continuum-workdir}/#
>
> We must stay on clearcase directory inorder to do other update/changelog
> commands
>
> -Dan
>
>
> On 12/1/05, Emmanuel Venisse <em...@venisse.net> wrote:
> >
> > > I prefer that too, so I filed
> > > http://jira.codehaus.org/browse/CONTINUUM-491 . If that is easy to
> > fix,
> > > could you send me the fix so I continue testing?
> > >
> >
> > I'll fix it today or tomorrow.
> >
> > Emmanuel
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by dan tran <da...@gmail.com>.
After checkout, clearcase dictates to location of checkout directory
on my windows
m:/view-name
on my unix
/view/${view-name}/vobs
So continuum must allow a way to change per build entry to the new working
direct
rather ${continuum-workdir}/#
We must stay on clearcase directory inorder to do other update/changelog
commands
-Dan
On 12/1/05, Emmanuel Venisse <em...@venisse.net> wrote:
>
> > I prefer that too, so I filed
> > http://jira.codehaus.org/browse/CONTINUUM-491. If that is easy to fix,
> > could you send me the fix so I continue testing?
> >
>
> I'll fix it today or tomorrow.
>
> Emmanuel
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
> I prefer that too, so I filed
> http://jira.codehaus.org/browse/CONTINUUM-491. If that is easy to fix,
> could you send me the fix so I continue testing?
>
I'll fix it today or tomorrow.
Emmanuel
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
>
>
> Wim Deblauwe a écrit :
> > ah, I haven't done that yet. I'm currently testing with a hardcoded
> value.
> >
> > I managed to checkout to the working directory, but 2 problems:
> >
> > 1) ClearCase does not want to checkout to an already existing directory,
> > so in the checkout command, I first delete the directory to checkout to.
> > It is then re-created by ClearCase. This seems to work fine in my test,
> > so I think this is ok.
>
> if it doesn't want to checkout to an alreasy existing directory, you can
> perhaps test the existence
> of the directory and if it exists, run update command.
I will try if that is possible. I still have to implement the update
command. I tested with a no-op implementation to get me started now.
>
> > 2) pom.xml is not in the root, so the build fails with:
> > Could not find the model file 'C:\Program Files\Apache Software
> > Foundation\continuum-
> 1.0.1\bin\win32\..\..\apps\continuum\working-directory\32\pom.xml'
>
> Why it isn't in root directory? can you checkout mymodule content in
> working directory?
Nope, I haven't found a way. Maybe Dan knows a way?
>
> > That is normal since it is in
> > "...working-directory\32\my_vob\modules\mymodule". ClearCase re-creates
> > the vob structure and everything in between up to where the module
> > actually is. What I have been thinking is creating a temperary snapshot
> > view and then copy everything from that temp location to
> > "working-directory\32". Problem is that I don't know where pom.xml is in
> > that structure, so I don't know how to that.
> > Other solution is that the user updates the build definition to point to
> > the location of the pom, but I tried that and it does not work.
> > Continuum does not seem to take that into account. Is that a known bug?
>
> I think it isn't a good solution to checkout in a temp directory and copy
> all files in the correct
> directory, because it will be slow to do the copy, and updaute will
> perhaps be less esay to do.
>
> I prefer the second solution if you cant checkout mymodule in working
> directory. You're right, it's
> a bug, please, file an issue and i'll fix it before 1.0.2 release.
I prefer that too, so I filed http://jira.codehaus.org/browse/CONTINUUM-491.
If that is easy to fix, could you send me the fix so I continue testing?
regards,
Wim
Emmanuel
> >
> > regards,
> >
> > Wim
> >
> > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> > I talk about file parsing in ${user.home}/.scm/
> >
> > Wim Deblauwe a écrit :
> > >
> > >
> > > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> > <ma...@venisse.net>
> > > <mailto: emmanuel@venisse.net <ma...@venisse.net>>>:
> > >
> > > Remove all maven-scm libs from
> > ${continuum}/apps/continuum/lib and
> > > put in it all new maven-scm libs.
> > >
> > > What do you use for scm file parsing?
> > >
> > > Emmanuel
> > >
> > >
> > > Euh.. just stringtokenizer, like this:
> > >
> > > public class ClearCaseScmProviderRepository
> > > extends ScmProviderRepository
> > > {
> > > private String viewName;
> > > private File configSpec;
> > >
> > > /**
> > > *
> > > * @param url format is [view_name]:[url_to_configspec] or
> > > [view_name]|[url_to_configspec]
> > > */
> > > public ClearCaseScmProviderRepository( String url )
> > > throws ScmRepositoryException
> > > {
> > > try
> > > {
> > > System.out.println( "url = " + url );
> > > parseUrl( url );
> > > }
> > > catch ( MalformedURLException e )
> > > {
> > > throw new ScmRepositoryException( "Illegal URL: " +
> url +
> > > "(" + e.getMessage() + ")" );
> > > }
> > > catch ( URISyntaxException e )
> > > {
> > > throw new ScmRepositoryException( "Illegal URL: " +
> url +
> > > "(" + e.getMessage() + ")" );
> > > }
> > > catch ( UnknownHostException e )
> > > {
> > > throw new ScmRepositoryException( "Illegal URL: " +
> url +
> > > "(" + e.getMessage() + ")" );
> > > }
> > > }
> > >
> > > private void parseUrl( String url )
> > > throws MalformedURLException, URISyntaxException,
> > > UnknownHostException
> > > {
> > > if( url.indexOf( '|' ) != -1 )
> > > {
> > > StringTokenizer tokenizer = new StringTokenizer( url,
> > "|" );
> > > fillInProperties( tokenizer );
> > > }
> > > else
> > > {
> > > StringTokenizer tokenizer = new StringTokenizer( url,
> > ":" );
> > > fillInProperties( tokenizer );
> > > }
> > > }
> > >
> > > private void fillInProperties( StringTokenizer tokenizer )
> > > throws UnknownHostException, URISyntaxException,
> > > MalformedURLException
> > > {
> > > if( tokenizer.countTokens() == 1 )
> > > {
> > > //No view name was given
> > > viewName = getDefaultViewName();
> > > String spec = tokenizer.nextToken();
> > > System.out.println( "spec = " + spec );
> > > configSpec = createConfigSpecFile( spec );
> > > }
> > > else
> > > {
> > > viewName = tokenizer.nextToken();
> > > System.out.println( "viewName = " + viewName );
> > > String pathname = tokenizer.nextToken();
> > > System.out.println( "pathname = " + pathname );
> > > configSpec = createConfigSpecFile( pathname );
> > > }
> > > }
> > >
> > > private File createConfigSpecFile( String spec )
> > > throws URISyntaxException, MalformedURLException
> > > {
> > > File result;
> > > if( spec.indexOf( ':' ) == -1 )
> > > {
> > > result = new File( spec );
> > > }
> > > else
> > > {
> > > result = new File( new URL( spec ).toURI() );
> > > }
> > > return result;
> > > }
> > >
> > > /**
> > > * Default: ${hostname}-{ user.name <http://user.name>
> > <http://user.name>}-${artifactId}
> > > * @return
> > > */
> > > private String getDefaultViewName()
> > > throws UnknownHostException
> > > {
> > > String username = System.getProperty( "user.name
> > <http://user.name>
> > > <http://user.name>", "nouser" );
> > > String hostname = getHostName();
> > > return username + "-" + hostname + "-maven";
> > > }
> > >
> > > private String getHostName()
> > > throws UnknownHostException
> > > {
> > > return InetAddress.getLocalHost().getHostName();
> > > }
> > >
> > > public String getViewName()
> > > {
> > > return viewName;
> > > }
> > >
> > > public File getConfigSpec()
> > > {
> > > return configSpec;
> > > }
> > > }
> > >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
Wim Deblauwe a écrit :
> ah, I haven't done that yet. I'm currently testing with a hardcoded value.
>
> I managed to checkout to the working directory, but 2 problems:
>
> 1) ClearCase does not want to checkout to an already existing directory,
> so in the checkout command, I first delete the directory to checkout to.
> It is then re-created by ClearCase. This seems to work fine in my test,
> so I think this is ok.
if it doesn't want to checkout to an alreasy existing directory, you can perhaps test the existence
of the directory and if it exists, run update command.
>
> 2) pom.xml is not in the root, so the build fails with:
> Could not find the model file 'C:\Program Files\Apache Software
> Foundation\continuum-1.0.1\bin\win32\..\..\apps\continuum\working-directory\32\pom.xml'
Why it isn't in root directory? can you checkout mymodule content in working directory?
>
> That is normal since it is in
> "...working-directory\32\my_vob\modules\mymodule". ClearCase re-creates
> the vob structure and everything in between up to where the module
> actually is. What I have been thinking is creating a temperary snapshot
> view and then copy everything from that temp location to
> "working-directory\32". Problem is that I don't know where pom.xml is in
> that structure, so I don't know how to that.
> Other solution is that the user updates the build definition to point to
> the location of the pom, but I tried that and it does not work.
> Continuum does not seem to take that into account. Is that a known bug?
I think it isn't a good solution to checkout in a temp directory and copy all files in the correct
directory, because it will be slow to do the copy, and updaute will perhaps be less esay to do.
I prefer the second solution if you cant checkout mymodule in working directory. You're right, it's
a bug, please, file an issue and i'll fix it before 1.0.2 release.
Emmanuel
>
> regards,
>
> Wim
>
> 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> I talk about file parsing in ${user.home}/.scm/
>
> Wim Deblauwe a écrit :
> >
> >
> > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> <ma...@venisse.net>
> > <mailto: emmanuel@venisse.net <ma...@venisse.net>>>:
> >
> > Remove all maven-scm libs from
> ${continuum}/apps/continuum/lib and
> > put in it all new maven-scm libs.
> >
> > What do you use for scm file parsing?
> >
> > Emmanuel
> >
> >
> > Euh.. just stringtokenizer, like this:
> >
> > public class ClearCaseScmProviderRepository
> > extends ScmProviderRepository
> > {
> > private String viewName;
> > private File configSpec;
> >
> > /**
> > *
> > * @param url format is [view_name]:[url_to_configspec] or
> > [view_name]|[url_to_configspec]
> > */
> > public ClearCaseScmProviderRepository( String url )
> > throws ScmRepositoryException
> > {
> > try
> > {
> > System.out.println( "url = " + url );
> > parseUrl( url );
> > }
> > catch ( MalformedURLException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( URISyntaxException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( UnknownHostException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > }
> >
> > private void parseUrl( String url )
> > throws MalformedURLException, URISyntaxException,
> > UnknownHostException
> > {
> > if( url.indexOf( '|' ) != -1 )
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url,
> "|" );
> > fillInProperties( tokenizer );
> > }
> > else
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url,
> ":" );
> > fillInProperties( tokenizer );
> > }
> > }
> >
> > private void fillInProperties( StringTokenizer tokenizer )
> > throws UnknownHostException, URISyntaxException,
> > MalformedURLException
> > {
> > if( tokenizer.countTokens() == 1 )
> > {
> > //No view name was given
> > viewName = getDefaultViewName();
> > String spec = tokenizer.nextToken();
> > System.out.println( "spec = " + spec );
> > configSpec = createConfigSpecFile( spec );
> > }
> > else
> > {
> > viewName = tokenizer.nextToken();
> > System.out.println( "viewName = " + viewName );
> > String pathname = tokenizer.nextToken();
> > System.out.println( "pathname = " + pathname );
> > configSpec = createConfigSpecFile( pathname );
> > }
> > }
> >
> > private File createConfigSpecFile( String spec )
> > throws URISyntaxException, MalformedURLException
> > {
> > File result;
> > if( spec.indexOf( ':' ) == -1 )
> > {
> > result = new File( spec );
> > }
> > else
> > {
> > result = new File( new URL( spec ).toURI() );
> > }
> > return result;
> > }
> >
> > /**
> > * Default: ${hostname}-{ user.name <http://user.name>
> <http://user.name>}-${artifactId}
> > * @return
> > */
> > private String getDefaultViewName()
> > throws UnknownHostException
> > {
> > String username = System.getProperty( "user.name
> <http://user.name>
> > <http://user.name>", "nouser" );
> > String hostname = getHostName();
> > return username + "-" + hostname + "-maven";
> > }
> >
> > private String getHostName()
> > throws UnknownHostException
> > {
> > return InetAddress.getLocalHost().getHostName();
> > }
> >
> > public String getViewName()
> > {
> > return viewName;
> > }
> >
> > public File getConfigSpec()
> > {
> > return configSpec;
> > }
> > }
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
ah, I haven't done that yet. I'm currently testing with a hardcoded value.
I managed to checkout to the working directory, but 2 problems:
1) ClearCase does not want to checkout to an already existing directory, so
in the checkout command, I first delete the directory to checkout to. It is
then re-created by ClearCase. This seems to work fine in my test, so I think
this is ok.
2) pom.xml is not in the root, so the build fails with:
Could not find the model file 'C:\Program Files\Apache Software
Foundation\continuum-
1.0.1\bin\win32\..\..\apps\continuum\working-directory\32\pom.xml'
That is normal since it is in
"...working-directory\32\my_vob\modules\mymodule". ClearCase re-creates the
vob structure and everything in between up to where the module actually is.
What I have been thinking is creating a temperary snapshot view and then
copy everything from that temp location to "working-directory\32". Problem
is that I don't know where pom.xml is in that structure, so I don't know how
to that.
Other solution is that the user updates the build definition to point to the
location of the pom, but I tried that and it does not work. Continuum does
not seem to take that into account. Is that a known bug?
regards,
Wim
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
> I talk about file parsing in ${user.home}/.scm/
>
> Wim Deblauwe a écrit :
> >
> >
> > 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> > Remove all maven-scm libs from ${continuum}/apps/continuum/lib and
> > put in it all new maven-scm libs.
> >
> > What do you use for scm file parsing?
> >
> > Emmanuel
> >
> >
> > Euh.. just stringtokenizer, like this:
> >
> > public class ClearCaseScmProviderRepository
> > extends ScmProviderRepository
> > {
> > private String viewName;
> > private File configSpec;
> >
> > /**
> > *
> > * @param url format is [view_name]:[url_to_configspec] or
> > [view_name]|[url_to_configspec]
> > */
> > public ClearCaseScmProviderRepository( String url )
> > throws ScmRepositoryException
> > {
> > try
> > {
> > System.out.println( "url = " + url );
> > parseUrl( url );
> > }
> > catch ( MalformedURLException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( URISyntaxException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > catch ( UnknownHostException e )
> > {
> > throw new ScmRepositoryException( "Illegal URL: " + url +
> > "(" + e.getMessage() + ")" );
> > }
> > }
> >
> > private void parseUrl( String url )
> > throws MalformedURLException, URISyntaxException,
> > UnknownHostException
> > {
> > if( url.indexOf( '|' ) != -1 )
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url, "|" );
> > fillInProperties( tokenizer );
> > }
> > else
> > {
> > StringTokenizer tokenizer = new StringTokenizer( url, ":" );
> > fillInProperties( tokenizer );
> > }
> > }
> >
> > private void fillInProperties( StringTokenizer tokenizer )
> > throws UnknownHostException, URISyntaxException,
> > MalformedURLException
> > {
> > if( tokenizer.countTokens() == 1 )
> > {
> > //No view name was given
> > viewName = getDefaultViewName();
> > String spec = tokenizer.nextToken();
> > System.out.println( "spec = " + spec );
> > configSpec = createConfigSpecFile( spec );
> > }
> > else
> > {
> > viewName = tokenizer.nextToken();
> > System.out.println( "viewName = " + viewName );
> > String pathname = tokenizer.nextToken();
> > System.out.println( "pathname = " + pathname );
> > configSpec = createConfigSpecFile( pathname );
> > }
> > }
> >
> > private File createConfigSpecFile( String spec )
> > throws URISyntaxException, MalformedURLException
> > {
> > File result;
> > if( spec.indexOf( ':' ) == -1 )
> > {
> > result = new File( spec );
> > }
> > else
> > {
> > result = new File( new URL( spec ).toURI() );
> > }
> > return result;
> > }
> >
> > /**
> > * Default: ${hostname}-{user.name <http://user.name>}-${artifactId}
> > * @return
> > */
> > private String getDefaultViewName()
> > throws UnknownHostException
> > {
> > String username = System.getProperty( "user.name
> > <http://user.name>", "nouser" );
> > String hostname = getHostName();
> > return username + "-" + hostname + "-maven";
> > }
> >
> > private String getHostName()
> > throws UnknownHostException
> > {
> > return InetAddress.getLocalHost().getHostName();
> > }
> >
> > public String getViewName()
> > {
> > return viewName;
> > }
> >
> > public File getConfigSpec()
> > {
> > return configSpec;
> > }
> > }
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
I talk about file parsing in ${user.home}/.scm/
Wim Deblauwe a écrit :
>
>
> 2005/12/1, Emmanuel Venisse <emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> Remove all maven-scm libs from ${continuum}/apps/continuum/lib and
> put in it all new maven-scm libs.
>
> What do you use for scm file parsing?
>
> Emmanuel
>
>
> Euh.. just stringtokenizer, like this:
>
> public class ClearCaseScmProviderRepository
> extends ScmProviderRepository
> {
> private String viewName;
> private File configSpec;
>
> /**
> *
> * @param url format is [view_name]:[url_to_configspec] or
> [view_name]|[url_to_configspec]
> */
> public ClearCaseScmProviderRepository( String url )
> throws ScmRepositoryException
> {
> try
> {
> System.out.println( "url = " + url );
> parseUrl( url );
> }
> catch ( MalformedURLException e )
> {
> throw new ScmRepositoryException( "Illegal URL: " + url +
> "(" + e.getMessage() + ")" );
> }
> catch ( URISyntaxException e )
> {
> throw new ScmRepositoryException( "Illegal URL: " + url +
> "(" + e.getMessage() + ")" );
> }
> catch ( UnknownHostException e )
> {
> throw new ScmRepositoryException( "Illegal URL: " + url +
> "(" + e.getMessage() + ")" );
> }
> }
>
> private void parseUrl( String url )
> throws MalformedURLException, URISyntaxException,
> UnknownHostException
> {
> if( url.indexOf( '|' ) != -1 )
> {
> StringTokenizer tokenizer = new StringTokenizer( url, "|" );
> fillInProperties( tokenizer );
> }
> else
> {
> StringTokenizer tokenizer = new StringTokenizer( url, ":" );
> fillInProperties( tokenizer );
> }
> }
>
> private void fillInProperties( StringTokenizer tokenizer )
> throws UnknownHostException, URISyntaxException,
> MalformedURLException
> {
> if( tokenizer.countTokens() == 1 )
> {
> //No view name was given
> viewName = getDefaultViewName();
> String spec = tokenizer.nextToken();
> System.out.println( "spec = " + spec );
> configSpec = createConfigSpecFile( spec );
> }
> else
> {
> viewName = tokenizer.nextToken();
> System.out.println( "viewName = " + viewName );
> String pathname = tokenizer.nextToken();
> System.out.println( "pathname = " + pathname );
> configSpec = createConfigSpecFile( pathname );
> }
> }
>
> private File createConfigSpecFile( String spec )
> throws URISyntaxException, MalformedURLException
> {
> File result;
> if( spec.indexOf( ':' ) == -1 )
> {
> result = new File( spec );
> }
> else
> {
> result = new File( new URL( spec ).toURI() );
> }
> return result;
> }
>
> /**
> * Default: ${hostname}-{user.name <http://user.name>}-${artifactId}
> * @return
> */
> private String getDefaultViewName()
> throws UnknownHostException
> {
> String username = System.getProperty( "user.name
> <http://user.name>", "nouser" );
> String hostname = getHostName();
> return username + "-" + hostname + "-maven";
> }
>
> private String getHostName()
> throws UnknownHostException
> {
> return InetAddress.getLocalHost().getHostName();
> }
>
> public String getViewName()
> {
> return viewName;
> }
>
> public File getConfigSpec()
> {
> return configSpec;
> }
> }
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
2005/12/1, Emmanuel Venisse <em...@venisse.net>:
>
> Remove all maven-scm libs from ${continuum}/apps/continuum/lib and put in
> it all new maven-scm libs.
>
> What do you use for scm file parsing?
>
> Emmanuel
>
Euh.. just stringtokenizer, like this:
public class ClearCaseScmProviderRepository
extends ScmProviderRepository
{
private String viewName;
private File configSpec;
/**
*
* @param url format is [view_name]:[url_to_configspec] or
[view_name]|[url_to_configspec]
*/
public ClearCaseScmProviderRepository( String url )
throws ScmRepositoryException
{
try
{
System.out.println( "url = " + url );
parseUrl( url );
}
catch ( MalformedURLException e )
{
throw new ScmRepositoryException( "Illegal URL: " + url + "(" +
e.getMessage() + ")" );
}
catch ( URISyntaxException e )
{
throw new ScmRepositoryException( "Illegal URL: " + url + "(" +
e.getMessage() + ")" );
}
catch ( UnknownHostException e )
{
throw new ScmRepositoryException( "Illegal URL: " + url + "(" +
e.getMessage() + ")" );
}
}
private void parseUrl( String url )
throws MalformedURLException, URISyntaxException,
UnknownHostException
{
if( url.indexOf( '|' ) != -1 )
{
StringTokenizer tokenizer = new StringTokenizer( url, "|" );
fillInProperties( tokenizer );
}
else
{
StringTokenizer tokenizer = new StringTokenizer( url, ":" );
fillInProperties( tokenizer );
}
}
private void fillInProperties( StringTokenizer tokenizer )
throws UnknownHostException, URISyntaxException,
MalformedURLException
{
if( tokenizer.countTokens() == 1 )
{
//No view name was given
viewName = getDefaultViewName();
String spec = tokenizer.nextToken();
System.out.println( "spec = " + spec );
configSpec = createConfigSpecFile( spec );
}
else
{
viewName = tokenizer.nextToken();
System.out.println( "viewName = " + viewName );
String pathname = tokenizer.nextToken();
System.out.println( "pathname = " + pathname );
configSpec = createConfigSpecFile( pathname );
}
}
private File createConfigSpecFile( String spec )
throws URISyntaxException, MalformedURLException
{
File result;
if( spec.indexOf( ':' ) == -1 )
{
result = new File( spec );
}
else
{
result = new File( new URL( spec ).toURI() );
}
return result;
}
/**
* Default: ${hostname}-{user.name}-${artifactId}
* @return
*/
private String getDefaultViewName()
throws UnknownHostException
{
String username = System.getProperty( "user.name", "nouser" );
String hostname = getHostName();
return username + "-" + hostname + "-maven";
}
private String getHostName()
throws UnknownHostException
{
return InetAddress.getLocalHost().getHostName();
}
public String getViewName()
{
return viewName;
}
public File getConfigSpec()
{
return configSpec;
}
}
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
Remove all maven-scm libs from ${continuum}/apps/continuum/lib and put in it all new maven-scm libs.
What do you use for scm file parsing?
Emmanuel
Wim Deblauwe a écrit :
> 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 < wim.deblauwe@gmail.com
> <ma...@gmail.com>>:
>
> 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 < emmanuel@venisse.net
> <ma...@venisse.net>>:
>
> 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 < dantran@gmail.com
> <ma...@gmail.com> <mailto:dantran@gmail.com
> <ma...@gmail.com>>>:
>>
>> 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* <
> jeffjensen@upstairstechnology.com
> <ma...@upstairstechnology.com>
>> <mailto:jeffjensen@upstairstechnology.com
> <ma...@upstairstechnology.com>>> wrote:
>>
>> Quoting Emmanuel Venisse < emmanuel@venisse.net
> <ma...@venisse.net>
>> <mailto:emmanuel@venisse.net
> <ma...@venisse.net>>>:
>>
>> >
>> >
>> > Wim Deblauwe a écrit :
>> > >
>> > >
>> > > 2005/11/30, dan tran <dantran@gmail.com
> <ma...@gmail.com>
>> <mailto: dantran@gmail.com <ma...@gmail.com>>
> <mailto: dantran@gmail.com <ma...@gmail.com>
>> <mailto:dantran@gmail.com <ma...@gmail.com>>>>:
>> > >
>> > >
>> > >
>> > > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> <ma...@gmail.com>
>> <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>>
>> > > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>
>> <mailto:wim.deblauwe@gmail.com
> <ma...@gmail.com>>>> 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!
>>
>>
>>
>
>
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
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 <wi...@gmail.com>:
>
> 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 < emmanuel@venisse.net>:
> >
> > 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 < dantran@gmail.com <ma...@gmail.com>>:
> > >
> > > 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* <jeffjensen@upstairstechnology.com
> > > <ma...@upstairstechnology.com>> wrote:
> > >
> > > Quoting Emmanuel Venisse < emmanuel@venisse.net
> > > <ma...@venisse.net>>:
> > >
> > >>
> > >>
> > >> Wim Deblauwe a écrit :
> > >> >
> > >> >
> > >> > 2005/11/30, dan tran <dantran@gmail.com
> > > <ma...@gmail.com> <mailto: dantran@gmail.com
> > > <ma...@gmail.com>>>:
> > >> >
> > >> >
> > >> >
> > >> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > > <ma...@gmail.com>
> > >> > <mailto: wim.deblauwe@gmail.com
> > > <ma...@gmail.com>>> 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!
> > >
> > >
> > >
> >
> >
>
Re: ClearCase 'checkout' implementation
Posted by Wim Deblauwe <wi...@gmail.com>.
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 <em...@venisse.net>:
>
> 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 <dantran@gmail.com <ma...@gmail.com>>:
> >
> > 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* <jeffjensen@upstairstechnology.com
> > <ma...@upstairstechnology.com>> wrote:
> >
> > Quoting Emmanuel Venisse < emmanuel@venisse.net
> > <ma...@venisse.net>>:
> >
> >>
> >>
> >> Wim Deblauwe a écrit :
> >> >
> >> >
> >> > 2005/11/30, dan tran <dantran@gmail.com
> > <ma...@gmail.com> <mailto:dantran@gmail.com
> > <ma...@gmail.com>>>:
> >> >
> >> >
> >> >
> >> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> > <ma...@gmail.com>
> >> > <mailto: wim.deblauwe@gmail.com
> > <ma...@gmail.com>>> 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!
> >
> >
> >
>
>
Re: ClearCase 'checkout' implementation
Posted by Emmanuel Venisse <em...@venisse.net>.
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 <dantran@gmail.com <ma...@gmail.com>>:
>
> 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* <jeffjensen@upstairstechnology.com
> <ma...@upstairstechnology.com>> wrote:
>
> Quoting Emmanuel Venisse < emmanuel@venisse.net
> <ma...@venisse.net>>:
>
>>
>>
>> Wim Deblauwe a écrit :
>> >
>> >
>> > 2005/11/30, dan tran <dantran@gmail.com
> <ma...@gmail.com> <mailto:dantran@gmail.com
> <ma...@gmail.com>>>:
>> >
>> >
>> >
>> > On 11/30/05, *Wim Deblauwe* < wim.deblauwe@gmail.com
> <ma...@gmail.com>
>> > <mailto: wim.deblauwe@gmail.com
> <ma...@gmail.com>>> 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!
>
>
>