You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@continuum.apache.org by Matt Raible <mr...@gmail.com> on 2006/08/29 23:42:50 UTC
Continuum tries to checkout artifactId instead of module
Since I've got most of AppFuse ported to Maven 2, I decided to give
Continuum a try today. I used the following URL for my pom.xml:
https://appfuse.dev.java.net/source/browse/*checkout*/appfuse/trunk/pom.xml
Continuum finds all the projects from my pom.xml files, but it tries
to checkout the artifactId instead of just using the directories under
the parent. For example, here's the error I get for the first module:
Provider message: The svn command failed.
Command output:
-------------------------------------------------------------------------------
svn: URL 'https://appfuse.dev.java.net/svn/appfuse/trunk/appfuse-data-common'
doesn't exist
-------------------------------------------------------------------------------
Why doesn't it just re-use trunk/data/common - that's what's specified
in the root-level pom.xml for this artifact?
Thanks,
Matt
Re: Continuum tries to checkout artifactId instead of module
Posted by Brett Porter <br...@gmail.com>.
I've been bitten by Continuum stubbornly honouring the SCM URL in the
POM above all else before too.
Apart from reading it on initial import, for the modules and after
updates do you think we should change it to use the real SCM URL and
produce a build warning if the POM differs instead?
- Brett
On 30/08/06, Emmanuel Venisse <em...@venisse.net> wrote:
> This pb is a maven pb when directory name isn't equals to the artifactId. In your case, the
> directory is data and artifactId is appfuse-data
>
> You can check the scm url resolution in your child pom with this command 'mvn help:effective-pom'
>
> you can choose between two solutions for this pb.
> 1. rename your directory to the artifactId
> 2. Add the scm url in all your child pom
>
> I prefer 1.
>
> Emmanuel
>
> Matt Raible a écrit :
> > Since I've got most of AppFuse ported to Maven 2, I decided to give
> > Continuum a try today. I used the following URL for my pom.xml:
> >
> > https://appfuse.dev.java.net/source/browse/*checkout*/appfuse/trunk/pom.xml
> >
> > Continuum finds all the projects from my pom.xml files, but it tries
> > to checkout the artifactId instead of just using the directories under
> > the parent. For example, here's the error I get for the first module:
> >
> > Provider message: The svn command failed.
> > Command output:
> > -------------------------------------------------------------------------------
> >
> > svn: URL
> > 'https://appfuse.dev.java.net/svn/appfuse/trunk/appfuse-data-common'
> > doesn't exist
> > -------------------------------------------------------------------------------
> >
> >
> > Why doesn't it just re-use trunk/data/common - that's what's specified
> > in the root-level pom.xml for this artifact?
> >
> > Thanks,
> >
> > Matt
> >
> >
> >
>
>
--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/
Re: Continuum tries to checkout artifactId instead of module
Posted by Emmanuel Venisse <em...@venisse.net>.
It wasn't a bug but a known limitation in maven inheritance in child pom. I implemented a workaround in continuum and will be available in 1.1
Emmanuel
idallas a écrit :
> Is this issue considered a bug, or a known limitation? (I didn't find
> anything in Jira)
>
> It seems like if Maven is able to handle projects with child atrifactIds
> that != directory names, Continuum should support that too.
>
> It's definitely a deal-breaker for me personally, and I suspect it would be
> for a lot of other users as well.
>
> --ian
>
>
> Emmanuel Venisse wrote:
>> you can choose between two solutions for this pb.
>> 1. rename your directory to the artifactId
>> 2. Add the scm url in all your child pom
>> I prefer 1.
>>
>
Re: Continuum tries to checkout artifactId instead of module
Posted by idallas <ia...@yahoo.com>.
Is this issue considered a bug, or a known limitation? (I didn't find
anything in Jira)
It seems like if Maven is able to handle projects with child atrifactIds
that != directory names, Continuum should support that too.
It's definitely a deal-breaker for me personally, and I suspect it would be
for a lot of other users as well.
--ian
Emmanuel Venisse wrote:
>
> you can choose between two solutions for this pb.
> 1. rename your directory to the artifactId
> 2. Add the scm url in all your child pom
> I prefer 1.
>
--
View this message in context: http://www.nabble.com/Continuum-tries-to-checkout-artifactId-instead-of-module-tf2186430.html#a7566347
Sent from the Continuum - Users mailing list archive at Nabble.com.
Re: Continuum tries to checkout artifactId instead of module
Posted by Emmanuel Venisse <em...@venisse.net>.
This pb is a maven pb when directory name isn't equals to the artifactId. In your case, the
directory is data and artifactId is appfuse-data
You can check the scm url resolution in your child pom with this command 'mvn help:effective-pom'
you can choose between two solutions for this pb.
1. rename your directory to the artifactId
2. Add the scm url in all your child pom
I prefer 1.
Emmanuel
Matt Raible a écrit :
> Since I've got most of AppFuse ported to Maven 2, I decided to give
> Continuum a try today. I used the following URL for my pom.xml:
>
> https://appfuse.dev.java.net/source/browse/*checkout*/appfuse/trunk/pom.xml
>
> Continuum finds all the projects from my pom.xml files, but it tries
> to checkout the artifactId instead of just using the directories under
> the parent. For example, here's the error I get for the first module:
>
> Provider message: The svn command failed.
> Command output:
> -------------------------------------------------------------------------------
>
> svn: URL
> 'https://appfuse.dev.java.net/svn/appfuse/trunk/appfuse-data-common'
> doesn't exist
> -------------------------------------------------------------------------------
>
>
> Why doesn't it just re-use trunk/data/common - that's what's specified
> in the root-level pom.xml for this artifact?
>
> Thanks,
>
> Matt
>
>
>