On 11/8/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
<snip/> Seems to me the first things we could do is 1. have an <ivy:topom> task to create a Pom from an ivy file, given mappings from configs to maven states.
There's already an undocumented task which does the opposite: convertpom converts a pom (well the dependency part of a pom) to an ivy file. It does not take into account all pom features, like pom inheritance and dependency management section which have no counterpart in Ivy. Converting Ivy files to pom is also limiting, because ivy configurations are not limited, nor is the configuration mapping, and there is no pom counterpart as far as I know. That's one of the main point why we still do not use poms as default format in Ivy, otherwise everything in Ivy is independent of the file format describing the dependencies, as long as you can parse it to an in memory ModuleDescriptor instance (and this is already pluggable with ModuleDescriptorParser, our of the box Ivy supports ivy files and "basic" pom files. 2. Agree on a set of default configurations for ivy artifacts (and the
new pom files) which we are all happy with . Something like compile test minimal standalone full
This seems to be a good set as default. But we also need to agree on default configuration mapping. And this is more difficult, because in maven the mapping is hard coded and a bit complex to handle in Ivy. We have an approximation for maven 2 compatibility using fancy configurations, but this is not a very good solution in my opinion. So I think we should discuss about that too. 3. Make changes to the pom files/ivy xml files that we all think
metadata should have. My suggestions are -include information about who wrote the pom, so you know who to talk to -include timestamp info.
Both are already part of ivy files specification, even if not always used: - http://www.jayasoft.org/ivy/doc/ivyfile/info (publication attribute) - http://www.jayasoft.org/ivy/doc/ivyfile/ivyauthor 4. tweak both apps to fix the assumption that published metadata is
perfect.
I agree that checking if a file is correct both grammatically and semantically is a must that we need to implement. Both systems, by default, should check for updates to the
metadata on a regular basis, because it does take a while to stabilise. I'm not sure about this point... well, I'm not opposed to the idea, but it
requires more reflexion. IMO metadata should never be modified, except in way that ensure backward compatibility, because it's the only to ensure build reproducibility over time, which is a key concept IMO. So making a check for updates a default may encourage updates. But if we find a way to ensure that an update is backward compatible, then it would make more sense to me. But maybe this is not applicable for a public repository like the one maven has. So maybe the default should simply be different for a public repository and for a private/home made one. Xavier
