On 3/25/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
2007/3/25, Xavier Hanin <[EMAIL PROTECTED]>:
>
> It sounds like a good idea. One thing to remember, Ivy core doesn't
depend
> on Ant, so make sure you don't introduce a dependency on Ant outside the
> org.apache.ivy.ant package.
>
I will define a generic interface inside Ivy core (with a simple
implementation using an hashmap), and implement the ant version in the
ant package.
> Also, I wonder what to do with the variable defined with the task or
> > inside the settings file. I guess I should not propagate them into
> > the ant properties, and keep them local to ivy. What do you think?
>
>
> I think they were not propagated before, so they don't need to be
> propagated. But I'm not absolutely sure, so if you find something
strange,
> please report it here.
>
> - Xavier
They were not. However, I think that the properties defined in
ivy.properties ressource are exported to the project by the first call
to configure.
Yes, you're right. Actually this is not really an export to ant, but simply
that those properties are loaded in ant, and then exported to ivy. I know
that at least some of them are used by some users in Ant, so we need to make
them visible in Ant, at least by default. Since it's always the same file
that is loaded, there is no overwrite problem even if we load different
settings in the same build. The design issue with that (I mean, with the
existing loading of these properties) is that you can overwrite their values
in Ivy, and Ant will still see their value set in Ant.
So I'm still wondering what's the best option here. I think we have to
provide a way to maintain backward compatibility, and thus make sure their
values are visisble in Ant. Then if we find a cleaner solution breaking
backward compatibility, we can activate it with a flag on the task/datatype,
and make the default value of the flag different for the two (backward
compatible with the deprecated configure task, new behavior with the
datatype.
WDYT?
- Xavier
Here is the list (I'm not sure they were all designed
to be exported) :
ivy.project.dir = ${basedir}
ivy.lib.dir = ${ivy.project.dir}/lib
ivy.build.artifacts.dir = ${ivy.project.dir}/build/artifacts
ivy.distrib.dir = ${ivy.project.dir}/distrib
ivy.resolver.default.check.modified = false
ivy.default.always.check.exact.revision = true
ivy.configurations = *
ivy.resolve.default.type.filter = *
ivy.status = integration
ivy.dep.file = ivy.xml
ivy.settings.file = ivysettings.xml
ivy.retrieve.pattern = ${ivy.lib.dir}/[artifact]-[revision].[ext]
ivy.deliver.ivy.pattern = ${ivy.distrib.dir
}/[type]s/[artifact]-[revision].[ext]
ivy.publish.src.artifacts.pattern =
${ivy.distrib.dir}/[type]s/[artifact]-[revision].[ext]
ivy.report.output.pattern = [organisation]-[module]-[conf].[ext]
ivy.buildlist.ivyfilepath = ivy.xml
ivy.checksums=sha1,md5
ivy.log.modules.in.use=false
--
Gilles SCOKART
