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 Piotr Kosiorowski <pk...@gmail.com> on 2006/01/27 21:39:10 UTC
maven2 & Continuum & ClearCase
Hello,
I was trying to setup a CI server for my project using maven2 &
Continuum with ClearCase on Unix. I think I made it work finally but
found some issues with it - especially with maven-scm-clearcase. So I
will try to describe my findings here. I might be wrong as I am not that
experienced with both maven2 and ClearCase.
1) Update fails in version 1.0.beta2 and in trunk because
update command uses changelog command without setting logger on it - so
changelog command fails with NullPointerException at the beggining of
execution in:
getLogger().debug( "executing changelog command..." );
The required change is in
ClearCaseUpdateCommand.java:
protected ChangeLogCommand getChangeLogCommand()
{
return new ClearCaseChangeLogCommand();
}
should be:
protected ChangeLogCommand getChangeLogCommand()
{
ClearCaseChangeLogCommand c= new ClearCaseChangeLogCommand();
c.setLogger(getLogger());
return c;
}
2) Checkout fails on Unix:
Lets assume it uses
/abc/def/1 as a working directory
First thing it does is it removes /abc/def/1 directory and than sets
working directory to
/abc/def/1/..
with:
command.setWorkingDirectory( new File(
workingDirectory,"..").getAbsolutePath() );
But because /abc/def/1 does not exists at this point command execution
fails (on Unix - I do not know how it works on Windows).
It should set it to
/abc/def
using
command.setWorkingDirectory( new File( workingDirectory, ".."
).getCanonicalPath() );
This change is to be introduced in ClearCaseCheckOutCommand.java.
3) I do not run ClearCase LT but I do not want to use -vws parameter for
checkout command - my environment is configured to work without it and
in fact I cannot even find a way to make it work with this parameter
from command line. In my opinion the best approach would be not to use
default view storage if one is not present in configuration file, but
skip -vws parameter in command line construction in this case. If
someone wants -vws parameter to be passed he should specify it in
config file.
I have some other minor issues but these ones are difficult to workaround.
Regards
Piotr Kosiorowski
Re: maven2 & Continuum & ClearCase
Posted by Wim Deblauwe <wi...@gmail.com>.
Hi Piotr,
I implemented ClearCase support, but I only tested on windows. I have zero
experience on Linux, so your comments are highly appreciated!
see below...
2006/1/27, Piotr Kosiorowski <pk...@gmail.com>:
>
> Hello,
>
> I was trying to setup a CI server for my project using maven2 &
> Continuum with ClearCase on Unix. I think I made it work finally but
> found some issues with it - especially with maven-scm-clearcase. So I
> will try to describe my findings here. I might be wrong as I am not that
> experienced with both maven2 and ClearCase.
>
> 1) Update fails in version 1.0.beta2 and in trunk because
> update command uses changelog command without setting logger on it - so
> changelog command fails with NullPointerException at the beggining of
> execution in:
> getLogger().debug( "executing changelog command..." );
>
> The required change is in
> ClearCaseUpdateCommand.java:
> protected ChangeLogCommand getChangeLogCommand()
> {
> return new ClearCaseChangeLogCommand();
> }
> should be:
> protected ChangeLogCommand getChangeLogCommand()
> {
> ClearCaseChangeLogCommand c= new ClearCaseChangeLogCommand();
> c.setLogger(getLogger());
> return c;
> }
I'm not sure who should set the logger, so maybe Emmanuel can answer this?
2) Checkout fails on Unix:
> Lets assume it uses
> /abc/def/1 as a working directory
> First thing it does is it removes /abc/def/1 directory and than sets
> working directory to
> /abc/def/1/..
> with:
> command.setWorkingDirectory( new File(
> workingDirectory,"..").getAbsolutePath() );
>
> But because /abc/def/1 does not exists at this point command execution
> fails (on Unix - I do not know how it works on Windows).
> It should set it to
> /abc/def
> using
> command.setWorkingDirectory( new File( workingDirectory, ".."
> ).getCanonicalPath() );
>
> This change is to be introduced in ClearCaseCheckOutCommand.java.
This works on windows, but seeming that it does not on linux, we should
change this. Create a JIRA issue for this.
3) I do not run ClearCase LT but I do not want to use -vws parameter for
> checkout command - my environment is configured to work without it and
> in fact I cannot even find a way to make it work with this parameter
> from command line. In my opinion the best approach would be not to use
> default view storage if one is not present in configuration file, but
> skip -vws parameter in command line construction in this case. If
> someone wants -vws parameter to be passed he should specify it in
> config file.
I did not know that was possible. I would propose to have an extra flag in
the clearcase-settings.xml file. Something like "useViewStorage". Please
create a JIRA for this also.
I have some other minor issues but these ones are difficult to workaround.
Please list them all, so we know about them and the clearcase plugin can
improve.
regards,
Wim
Regards
> Piotr Kosiorowski
>
>
>
Re: Some thoughts after implementing a new provider in maven-scm
Posted by Emmanuel Venisse <em...@venisse.net>.
You can reopen it.
Emmanuel
Torbjørn Smørgrav a écrit :
> I can't reproduce it, but I did some changes that might solve the issue.
>
> Should I make another JIRA issue for that patch or reopen issue 143?
> And if new; should I create the issue and later upload the patch (to get the
> issue id)?
>
> Regards
> Torbjørn
>
> -----Original Message-----
> From: Emmanuel Venisse [mailto:emmanuel@venisse.net]
> Sent: 30. januar 2006 17:35
> To: scm-dev@maven.apache.org
> Subject: Re: Some thoughts after implementing a new provider in
> maven-scm
>
>
>
>
> Torbjørn Smørgrav a écrit :
>
>>>I tried to build your provider before add it in svn but without success.
>>>All tests fail on windows.
>>
>>
>>Do you have the test output?
>>
>>Torbjørn
>>
>>
>>
>>
>
>
>
>
>
RE: Some thoughts after implementing a new provider in maven-scm
Posted by Torbjørn Smørgrav <ts...@stavanger.oilfield.slb.com>.
I can't reproduce it, but I did some changes that might solve the issue.
Should I make another JIRA issue for that patch or reopen issue 143?
And if new; should I create the issue and later upload the patch (to get the
issue id)?
Regards
Torbjørn
-----Original Message-----
From: Emmanuel Venisse [mailto:emmanuel@venisse.net]
Sent: 30. januar 2006 17:35
To: scm-dev@maven.apache.org
Subject: Re: Some thoughts after implementing a new provider in
maven-scm
Torbjørn Smørgrav a écrit :
>>I tried to build your provider before add it in svn but without success.
>>All tests fail on windows.
>
>
> Do you have the test output?
>
> Torbjørn
>
>
>
>
Re: Some thoughts after implementing a new provider in maven-scm
Posted by Emmanuel Venisse <em...@venisse.net>.
Torbjørn Smørgrav a écrit :
>>I tried to build your provider before add it in svn but without success.
>>All tests fail on windows.
>
>
> Do you have the test output?
>
> Torbjørn
>
>
>
>
RE: Some thoughts after implementing a new provider in maven-scm
Posted by Torbjørn Smørgrav <ts...@stavanger.oilfield.slb.com>.
> I tried to build your provider before add it in svn but without success.
> All tests fail on windows.
Do you have the test output?
Torbjørn
Re: Some thoughts after implementing a new provider in maven-scm
Posted by Emmanuel Venisse <em...@venisse.net>.
Torbjørn Smørgrav a écrit :
> 1. maven-scm-test
> This module was essential for me. It made me realise that I had misinterpret
> 50% of the api :)
> Ofcourse I could argue that the javadoc of the api itself was insufficient,
> but that does not take away
> the glory of the test module. I would really like to see the test module
> more extensive in the future.
You can contribute by adding more javadoc and improve maven-scm-test ;-)
>
> A couple of issues with the diff test:
> a) I found it confusing that all files with a diff should be flagged as
> modified
> even if they where added or deleted.
> b) The test has an assert on the range tag '@@' that may be a bit too
> strict. Either can the the range field
> of the tag can be implisit, or bazaar has wrong diff output. Eg. @@ -0,0
> +1,1 @@ is equal to @@ -0,0 +1 @@ if
> the file is added and has only one line.
>
> What about making a common diff output parser that could be used by all diff
> consumers?
Propose a solution and we'll can discuss about it, but i'd like to have a common diff output
>
> 2. maven-scm-api
> I found it very hard to simplify the usage of command results.
> Most result classes are equal, only the name differ. I could have removed
> some 13 lines of code and
> 2 cyclomatic complexity in all commands if we could unify the ScmResult API.
> eg. by adding a copy
> constructor the the ScmResult class and a (ScmResult, Files) constructor in
> most of the other
> CommandScmResult classes. What about a result factory? That would also unify
> the result _behavior_.
Which classes do you refer? If we can simplify all, i'm agree.
>
> 4. Code redundancy
> I think more effort should be put in to centralize code, and to move
> responibility from each provider
> to a common manager. Such things are difficult to do upfront, but now we
> have 7 providers and
> we can see what kind of freedom the provider needs and what could be
> centralized.
For each part, you can file an issue and attach a patch.
>
> All in all, I had a great time implementing the Bazaar provider
> and I think you have done a great job.
Thanks.
I tried to build your provider before add it in svn but without success.
All tests fail on windows.
Emmanuel
Some thoughts after implementing a new provider in maven-scm
Posted by Torbjørn Smørgrav <ts...@stavanger.oilfield.slb.com>.
1. maven-scm-test
This module was essential for me. It made me realise that I had misinterpret
50% of the api :)
Ofcourse I could argue that the javadoc of the api itself was insufficient,
but that does not take away
the glory of the test module. I would really like to see the test module
more extensive in the future.
A couple of issues with the diff test:
a) I found it confusing that all files with a diff should be flagged as
modified
even if they where added or deleted.
b) The test has an assert on the range tag '@@' that may be a bit too
strict. Either can the the range field
of the tag can be implisit, or bazaar has wrong diff output. Eg. @@ -0,0
+1,1 @@ is equal to @@ -0,0 +1 @@ if
the file is added and has only one line.
What about making a common diff output parser that could be used by all diff
consumers?
2. maven-scm-api
I found it very hard to simplify the usage of command results.
Most result classes are equal, only the name differ. I could have removed
some 13 lines of code and
2 cyclomatic complexity in all commands if we could unify the ScmResult API.
eg. by adding a copy
constructor the the ScmResult class and a (ScmResult, Files) constructor in
most of the other
CommandScmResult classes. What about a result factory? That would also unify
the result _behavior_.
4. Code redundancy
I think more effort should be put in to centralize code, and to move
responibility from each provider
to a common manager. Such things are difficult to do upfront, but now we
have 7 providers and
we can see what kind of freedom the provider needs and what could be
centralized.
All in all, I had a great time implementing the Bazaar provider
and I think you have done a great job.
Regards
Torbjørn
Re: maven2 & Continuum & ClearCase
Posted by Emmanuel Venisse <em...@venisse.net>.
>
> Do you want me to create JIRA issues for these 3 issues?
Yes, please.
Emmanuel
Re: maven2 & Continuum & ClearCase
Posted by Piotr Kosiorowski <pk...@gmail.com>.
Emmanuel Venisse wrote:
> >> getLogger().debug( "executing changelog command..." );
>>
>> The required change is in
>> ClearCaseUpdateCommand.java:
>> protected ChangeLogCommand getChangeLogCommand()
>> {
>> return new ClearCaseChangeLogCommand();
>> }
>> should be:
>> protected ChangeLogCommand getChangeLogCommand()
>> {
>> ClearCaseChangeLogCommand c= new ClearCaseChangeLogCommand();
>> c.setLogger(getLogger());
>> return c;
>> }
>
> This change must be done in maven-scm-api and not in clearcase provider.
>
I copied the way it is done in cvs, perforce and starteam providers -
when a command creates other command to execute it - it always sets a
logger on it. In fact as command requires logger to work I would add it
as a constructor param and removed default constructor. But I have no
experience with this code - so I am not sure how to do it at
maven-scm-api level.
>> 2) Checkout fails on Unix:
> command.setWorkingDirectory( workingDirectory.getParentFile() );
+1. Simple solutions sometimes are difficult to find during debugging.
>> 3) I do not run ClearCase LT but I do not want to use -vws parameter
>> for checkout command - my environment is configured to work without it
>> and in fact I cannot even find a way to make it work with this
>> parameter from command line. In my opinion the best approach would be
>> not to use default view storage if one is not present in configuration
>> file, but skip -vws parameter in command line construction in this
>> case. If someone wants -vws parameter to be passed he should specify
>> it in config file.
>
> I don't use Clearcase, so i don't know what is the msot common usage
> (-vws or not) but we use it actually as default. I think it will be
> better for users to keep it ads default and add the availability in conf
> file to don't use it.
> Wim, Dan, any thoughts?
>
In fact - I do not care what the default is if only I can change it - I
am not experienced enough with ClearCase to judge wich one is more common.
>> I have some other minor issues but these ones are difficult to
>> workaround.
>
> post them.
>
I will write separate email on it this week - I am not 100% sure right
now where the fix should be placed (continuum, maven2, or clearcase
provider) but will try to descibe them as well as I can.
Do you want me to create JIRA issues for these 3 issues?
Regards
Piotr
Re: maven2 & Continuum & ClearCase
Posted by Emmanuel Venisse <em...@venisse.net>.
Piotr Kosiorowski a écrit :
> Hello,
>
> I was trying to setup a CI server for my project using maven2 &
> Continuum with ClearCase on Unix. I think I made it work finally but
> found some issues with it - especially with maven-scm-clearcase. So I
> will try to describe my findings here. I might be wrong as I am not that
> experienced with both maven2 and ClearCase.
>
> 1) Update fails in version 1.0.beta2 and in trunk because
> update command uses changelog command without setting logger on it - so
> changelog command fails with NullPointerException at the beggining of
> execution in:
> getLogger().debug( "executing changelog command..." );
>
> The required change is in
> ClearCaseUpdateCommand.java:
> protected ChangeLogCommand getChangeLogCommand()
> {
> return new ClearCaseChangeLogCommand();
> }
> should be:
> protected ChangeLogCommand getChangeLogCommand()
> {
> ClearCaseChangeLogCommand c= new ClearCaseChangeLogCommand();
> c.setLogger(getLogger());
> return c;
> }
This change must be done in maven-scm-api and not in clearcase provider.
>
> 2) Checkout fails on Unix:
> Lets assume it uses
> /abc/def/1 as a working directory
> First thing it does is it removes /abc/def/1 directory and than sets
> working directory to
> /abc/def/1/..
> with:
> command.setWorkingDirectory( new File(
> workingDirectory,"..").getAbsolutePath() );
>
> But because /abc/def/1 does not exists at this point command execution
> fails (on Unix - I do not know how it works on Windows).
> It should set it to
> /abc/def
> using
> command.setWorkingDirectory( new File( workingDirectory, ".."
> ).getCanonicalPath() );
I'd prefer :
command.setWorkingDirectory( workingDirectory.getParentFile() );
>
> This change is to be introduced in ClearCaseCheckOutCommand.java.
>
> 3) I do not run ClearCase LT but I do not want to use -vws parameter for
> checkout command - my environment is configured to work without it and
> in fact I cannot even find a way to make it work with this parameter
> from command line. In my opinion the best approach would be not to use
> default view storage if one is not present in configuration file, but
> skip -vws parameter in command line construction in this case. If
> someone wants -vws parameter to be passed he should specify it in
> config file.
I don't use Clearcase, so i don't know what is the msot common usage (-vws or not) but we use it
actually as default. I think it will be better for users to keep it ads default and add the
availability in conf file to don't use it.
Wim, Dan, any thoughts?
>
> I have some other minor issues but these ones are difficult to workaround.
post them.
Emmanuel