ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: sources as conf or type
Date Mon, 02 Nov 2009 15:54:04 GMT
Question for Nicolas Lalevée. And Nicolas, please forgive me for putting you
on the spot. (Actually, there's nothing stopping anyone else from taking a
shot at this.)

Set aside the whole matter of translating a POM. Nicolas, I know you're an
advocate of the "source as type" approach in general as opposed to "source
as conf"--having written in the past:
"Rather than choosing the configuration to select or not the javadocs and
the sources, you should use the types. Configurations and types are
orthogonal concepts, you should try to not mix them."
http://old.nabble.com/Re%3A-IvyDE-automatically-include-javadoc-and-source-p25081870.html

What's your best argument as to why they *should be *considered orthogonal
concepts?

On Sun, Nov 1, 2009 at 7:14 AM, Stephen Haberman
<stephen@exigencecorp.com>wrote:

>
>
>
> Nicolas Lalevée wrote:
> >
> > Sorry I didn't have time to reply to this interesting discussion.
> > Actually I already have that discussion around the same issue in pom /
> > ivy mapping there:
> >
> http://old.nabble.com/pom2ivy-and-transitive-source-retrieving-to25112985.html#a25112985
> >
> > I "just" (shame on me) forgot to actually implement the solution we
> > agreed on. I'll do soon.
> >
>
> Ah, no, shame on me for not finding an existing discussion /and/ bug about
> this from only a few months ago.
>
> Thanks for pointing that thread out--though I'm disappointed Xavier didn't
> like jars+sources in the same conf. :-)
>
> I suppose if its gets the job done, I'll be fine, but the
> transitive-sources
> conf seems even uglier than the existing sources conf. Granted, it does
> gain
> the requested behavior with backwards compatibility.
>
> I wonder if there is an another thing lurking here--e.g. something like
> "primary" vs. "secondary" artifacts, where the primary artifacts are those
> you want downloaded with a "*" type pattern, but secondary artifacts need
> explicitly opted-in to a download, e.g. with a type=source (or whatever
> their type may be).
>
> That being said, I usually prefer minimalist solutions (hence not liking
> the
> extra "sources" conf), and adding yet another attribute just for this one
> use case is not exactly minimalist.
>
> But I like the conceptual integrity (to me anyway) of jars+sources being in
> the same conf that I suppose I'm reaching a little bit to see if it could
> swing that way.
>
> (...ah, well, even if you set foo=secondary on the source artifacts, and
> put
> them in the master conf, they wouldn't get downloaded without a type filter
> for master conf, but then they also wouldn't get downloaded without a type
> filter for the sources conf. So my attempt at backwards compatibility
> failed.)
>
> Thanks,
> Stephen
>
>
>
>
> --
> View this message in context:
> http://old.nabble.com/sources-as-conf-or-type-tp26028446p26148902.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message