yup something like <developerConnection>static:scm:git:https://...
And the trailing / is rather unhandy. Some scms just crash if you don't use the correct trailing ;) LieGrue, strub --- On Thu, 7/28/11, Benson Margulies <bimargul...@gmail.com> wrote: > From: Benson Margulies <bimargul...@gmail.com> > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" <dev@maven.apache.org> > Date: Thursday, July 28, 2011, 9:45 PM > Is static: really superior to scm2: > and then more colons allowing > arbitrary keyword-value pairs? > > On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg <strub...@yahoo.de> > wrote: > > Hi! > > > > A small update: > > > > Benjamin mentioned that this might also be useful for > site URLs if a user like to define the effective URLs of the > sub-module site via ${project.version}/${project.artifactId} > or similar. > > > > So we just came up with "static:" as prefix. > > > > More soon via Jira. > > > > LieGrue, > > strub > > > > --- On Thu, 7/28/11, Brian Fox <bri...@infinity.nu> > wrote: > > > >> From: Brian Fox <bri...@infinity.nu> > >> Subject: Re: [DISCUSS] SCM child-project URL > composition > >> To: "Maven Developers List" <dev@maven.apache.org> > >> Date: Thursday, July 28, 2011, 9:32 PM > >> not crazy about the syntax, but > >> generally yes i think that makes sense. > >> > >> I've long maintained that we need something > similar for > >> properties to > >> balance between "resolve at build time" and > "resolve at > >> fetch from > >> repo" type of issues. > >> > >> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg > <strub...@yahoo.de> > >> wrote: > >> > Hi John, Brian > >> > > >> > Just to make sure I did understand that > correctly: > >> > you propose to use a special URL prefix to > tell the > >> maven DefaultProjectBuilder to treat those urls as > static. > >> An example: > >> > > >> > > >> > <scm> > >> > > >> > <developerConnection>staticscm:git:ssh://myserver:/..</developerConnection > >> > > >> > resulting in replacing 'staticscm' with 'scm' > and not > >> adding the child modules to the URL. > >> > Did I get this correctly? > >> > > >> > Tried that with mvn-3.0.3 and mvn-2.2.1 and a > standard > >> build works just fine. Of course a release would > only work > >> with the newer maven versions! > >> > > >> > LieGrue, > >> > strub > >> > > >> > --- On Thu, 7/28/11, Brian Fox <bri...@infinity.nu> > >> wrote: > >> > > >> >> From: Brian Fox <bri...@infinity.nu> > >> >> Subject: Re: [DISCUSS] SCM child-project > URL > >> composition > >> >> To: "Maven Developers List" <dev@maven.apache.org> > >> >> Date: Thursday, July 28, 2011, 7:23 PM > >> >> On Thu, Jul 28, 2011 at 2:59 PM, John > >> >> Casey <jdca...@commonjava.org> > >> >> wrote: > >> >> > Would it be better to have a syntax > to mark a > >> URL as > >> >> literal, not to be > >> >> > calculated or used as the basis of > >> calculation? > >> >> > > >> >> > >> >> Yes. I tried to fix this behavior for > urls back in > >> ~2.0.6/7 > >> >> ish and it > >> >> broke lots of stuff that depended upon > that > >> behavior. > >> >> > >> >> > That way, we don't have to worry > about > >> adjusting to > >> >> new SCMs or other places > >> >> > where we want to use it...new SCMs > could be > >> added via > >> >> build extension, IIRC, > >> >> > so this is particularly important > there. > >> >> > > >> >> > WDYT? > >> >> > > >> >> > On 7/28/11 12:46 PM, Mark Struberg > wrote: > >> >> >> > >> >> >> Hi! > >> >> >> > >> >> >> problem description > >> >> >> ----------- > >> >> >> > >> >> >> SCM URLs currently automatically > get > >> extended for > >> >> child modules. > >> >> >> E.g. from > >> >> >> svn://mycompany.com/myproject > >> >> >> in the parent pom, a child > module > >> 'frontend' will > >> >> result in getting a SCM > >> >> >> URL > >> >> >> > svn://mycompany.com/myproject/frontend > >> >> >> > >> >> >> This is fine for SVN and CVS, > but broken > >> for GIT, > >> >> HG, etc because the SCM > >> >> >> URL is 'static' for them. > >> >> >> > >> >> >> > >> >> >> proposal > >> >> >> ----------- > >> >> >> > >> >> >> Since we cannot put this > information into > >> the > >> >> various scm plugins (because > >> >> >> of a 'definition cycle' as > explained here > >> [1]) we > >> >> could split the URL > >> >> >> construction into > >> scmUrlAppendChild=true/false and > >> >> make it configurable. The > >> >> >> configuration could be > controlled via a > >> Modello > >> >> config, my suggestion would > >> >> >> be to just add them to > toolchains.mdo. > >> >> >> I'd just add a String property > which > >> holds a > >> >> regular expression which > >> >> >> parses the SCM URL and decides > upon this > >> whether > >> >> the appending should get > >> >> >> activated, e.g. for all SCMs > which > >> contain > >> >> 'scm:svn:' or 'scm:cvs:' or the > >> >> >> java-svn (olamy, you know the > plexus key > >> for > >> >> that?) > >> >> >> > >> >> >> If there is a better place to > put that > >> config or a > >> >> better way to get the > >> >> >> info, then please speak up now > :) > >> >> >> > >> >> >> I think this change would be > backward > >> compatible > >> >> and doesn't need any pom > >> >> >> changes. It also could easily > get > >> back-ported to > >> >> mvn2 if needed. > >> >> >> Are there other URLS which also > need a > >> similar > >> >> distinction while building > >> >> >> the model? > >> >> >> > >> >> >> WDYT? > >> >> >> > >> >> >> txs and LieGrue, > >> >> >> strub > >> >> >> > >> >> >> [1] http://markmail.org/message/npw3hp6aloa55ctf > >> >> >> > >> >> >> > >> >> > >> > --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >> >> For additional commands, e-mail: > dev-h...@maven.apache.org > >> >> >> > >> >> > > >> >> > -- > >> >> > John Casey > >> >> > Developer, PMC Chair - Apache Maven > (http://maven.apache.org) > >> >> > Blog: http://www.johnofalltrades.name/ > >> >> > > >> >> > > >> >> > >> > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> >> > > >> >> > > >> >> > >> >> > >> > --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >> For additional commands, e-mail: dev-h...@maven.apache.org > >> >> > >> >> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >> > > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org