You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nicolas Lalevée <ni...@anyware-tech.com> on 2009/09/01 14:28:22 UTC

Re: pom2ivy and transitive source retrieving

On Monday 31 August 2009 17:39:57 Xavier Hanin wrote:
> 2009/8/26 Nicolas Lalevée <ni...@hibnet.org>
>
> > On Tuesday 25 August 2009 15:00:33 Xavier Hanin wrote:
> > > 2009/8/24 Nicolas Lalevée <ni...@hibnet.org>
> > >
> > > The problem with that is how people would get only the main jar of
> > > their dependencies? Using an artifact type filter? That doesn't sound
> > > good IMO.
> >
> > I thought types where meant to be used for that kind of use case.
>
> I'd say types are meant to deal with use cases where you don't have
> configurations properly setup to get only the type you want. Most of the
> time I prefer to use only conf, with no type filter. But it's only my point
> of view, maybe others think differently.

I see the configuration and types as defining two orthogonal concepts. One is 
defining in which way the dependency would be used, the types just being the 
type of artifact. An exemple I like to show is slf4j:
    <configurations>
        <conf name="default"  extends="simple" />
        <conf name="core" />
        <conf name="simple" extends="core" />
        <conf name="log4j" extends="core" />
        <conf name="nop" extends="core" />
        <conf name="jcl" extends="core" />
...
    </configurations>
    <publications>
        <artifact name="slf4j-api" type="jar" ext="jar" conf="core" />
        <artifact name="slf4j-api" type="source" ext="jar" conf="core" />
        <artifact name="slf4j-simple" type="jar" ext="jar" conf="simple" />
        <artifact name="slf4j-simple" type="source" ext="jar" conf="simple" />
        <artifact name="slf4j-nop" type="jar" ext="jar" conf="nop" />
        <artifact name="slf4j-nop" type="source" ext="jar" conf="nop" />
        <artifact name="slf4j-jcl" type="jar"  ext="jar" conf="jcl" />
        <artifact name="slf4j-jcl" type="source" ext="jar" conf="jcl" />
...
    </publications>
    <dependencies>
        <dependency org="org.apache.commons" name="commons-logging" 
rev="1.1.1" conf="jcl->default" />
        <dependency org="org.apache.log4j" name="log4j" rev="1.2.15" 
conf="log4j->default" />
    </dependencies>

Then if I want to not use type and use the configurations, it would be quite 
painfull to specify the configurations sources-api, sources-simple, 
sources-nop, etc..... But as you can see I didn't followed maven convention 
to have one descriptor per artifact.

>
> > > Another suggested solution is to add a sources->sources(*) in the
> > > dependency conf mapping, but I see 2 problems with that:
> > > - it makes the sources conf always transitive
> > > - the fallback of * doesn't really make sense
> > >
> > > So what I find would be better is to define a transitive-sources conf,
> >
> > and
> >
> > > have a conf mapping of transitive-sources->transitive-sources(*), or
> > > even better  transitive-sources->transitive-sources(none) if we define
> > > 'none'
> >
> > as
> >
> > > a special fallback conf which means no dependency conf if the required
> >
> > one
> >
> > > does not exist. Of course we would need to do that for javadoc too.
> >
> > what about transitive-sources->transitive-sources(sources) ?
>
> The problem is that it will fail if there is no "sources" conf. Not sure if
> it's a real problem, we may assume that it's mandatory to declare a sources
> conf if you override the metadata of a module on which m2 modules depend.

hum, I didn't thought of this use case...

> So I'm ok for transitive-sources->transitive-sources(sources)

I would do it as a first step.
Then effectively an implementation of a special 'none' configuration should be 
implemented.

Nicolas

>
> Xavier
>
> > Nicolas
> >
> > > WDYT?
> > >
> > > Xavier
> > >
> > > > Nicolas
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > > > For additional commands, e-mail: dev-help@ant.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: pom2ivy and transitive source retrieving

Posted by Xavier Hanin <xa...@gmail.com>.
2009/9/1 Nicolas Lalevée <ni...@anyware-tech.com>

> On Monday 31 August 2009 17:39:57 Xavier Hanin wrote:
> > 2009/8/26 Nicolas Lalevée <ni...@hibnet.org>
> >
> > > On Tuesday 25 August 2009 15:00:33 Xavier Hanin wrote:
> > > > 2009/8/24 Nicolas Lalevée <ni...@hibnet.org>
> > > >
> > > > The problem with that is how people would get only the main jar of
> > > > their dependencies? Using an artifact type filter? That doesn't sound
> > > > good IMO.
> > >
> > > I thought types where meant to be used for that kind of use case.
> >
> > I'd say types are meant to deal with use cases where you don't have
> > configurations properly setup to get only the type you want. Most of the
> > time I prefer to use only conf, with no type filter. But it's only my
> point
> > of view, maybe others think differently.
>
> I see the configuration and types as defining two orthogonal concepts. One
> is
> defining in which way the dependency would be used, the types just being
> the
> type of artifact. An exemple I like to show is slf4j:
>    <configurations>
>        <conf name="default"  extends="simple" />
>        <conf name="core" />
>        <conf name="simple" extends="core" />
>        <conf name="log4j" extends="core" />
>        <conf name="nop" extends="core" />
>        <conf name="jcl" extends="core" />
> ...
>    </configurations>
>    <publications>
>        <artifact name="slf4j-api" type="jar" ext="jar" conf="core" />
>        <artifact name="slf4j-api" type="source" ext="jar" conf="core" />
>        <artifact name="slf4j-simple" type="jar" ext="jar" conf="simple" />
>        <artifact name="slf4j-simple" type="source" ext="jar" conf="simple"
> />
>        <artifact name="slf4j-nop" type="jar" ext="jar" conf="nop" />
>        <artifact name="slf4j-nop" type="source" ext="jar" conf="nop" />
>        <artifact name="slf4j-jcl" type="jar"  ext="jar" conf="jcl" />
>        <artifact name="slf4j-jcl" type="source" ext="jar" conf="jcl" />
> ...
>    </publications>
>    <dependencies>
>        <dependency org="org.apache.commons" name="commons-logging"
> rev="1.1.1" conf="jcl->default" />
>        <dependency org="org.apache.log4j" name="log4j" rev="1.2.15"
> conf="log4j->default" />
>    </dependencies>
>
> Then if I want to not use type and use the configurations, it would be
> quite
> painfull to specify the configurations sources-api, sources-simple,
> sources-nop, etc.....

With configurations intersection introduced in latest version it's easy to
use confs for these orthogonal axes instead of relying on types. But if you
really like using types for that I don't see any problem. The question is:
do we "force" people to use types filters by having metadata artifacts in
the same confs as the main ones? I think in that case we would have to
define a default filter for the type for better out of the box experience,
and it wouldn't be backward compatible anyway. So I think we agree it's
better to stick with confs for sources and javadocs in m2 modules.

Xavier
-- 
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/