> another issue is raised because each project in continuum required a client
> spec
it's a continuum / scm issue
> and the number can be too high.
perforce licensing is based on user
for example evaluation perforce allows 2 users 5 clients
so it means that continuum can have only build 5 projec
>Ok, it seems to be good. Can you send us your patches?
no it's not good because i've change also
public class PerforceScmProvider
public static String getRepoPath( ScmLogger log,
PerforceScmProviderRepository repo, File basedir )
if (false)//FIXME pom.exists() )
but it's not a fine solution
I
Index:
main/java/org/apache/maven/scm/provider/perforce/command/changelog/PerforceChangeLogCommand.java
===
---
main/java/org/apache/maven/scm/provider/perforce/command/changelog/PerforceChangeLogCommand.java
(revision 529895)
+++
>Do you have tested Continuum/Perforce with more than one projects? I think
it doesn't work with two and more.
yes, several project and several scm
>Do you have patched Continuum and/or Maven-SCM?
yes, both slightly but the aim is to make it working (no matter if there's
feature lost) not having
>If you know well the perforce command line, maybe you can help Mike on the
Maven SCM Perforce provider because he
>doesn't use Continuum so he don't know pb with Perforce/Continuum and can't
fix them.
currently I use (built from svn - jdk 1.5) continuum & archiva deployed in
tomcat 6
several th
>System.clearProperty doesn't exist in jdk 1.4
don't realize it ...
> Perforce isn't well supported in continuum due to a Maven-SCM issue in
> the perforce provider (http://jira.codehaus.org/browse/SCM-292)
> When this issue will be fixed, Continuum will work well with Perforce.
jira should be i
hello,
option 1 will be a good solution with the drawback that some people will
fall into trouble because they are "not allowed" to change anything and
cannot upgrade (belong to theses...)
option 3 is the best world to me
I think that a naming convention to express the version of the underlying
