2009/1/12 Hans Dockter <m...@dockter.biz>
> I have started to refactor the dependency layer. But this refactoring is
> related to the way we deal with archives. And I think it might makes sense,
> to refactor our archive handling first.
>
> What about getting rid of the libs and dists bundle stuff. Instead we would
> have one archive object which would have this responsibility. The archive
> class would have properties like baseName and defaultTaskName. It would
> offer similar archive construction methods as the libs and dists bundles.
> But it would be much more flexible. Dealing with archives would be similar
> how we deal with dependencies.
>
> archives {
> baseName = 'myGradle'
> libs jar(), jar(classifier: 'x') { ... }
> dists zip()
> otherConf tar()
> }
>
> Every configuration has a property: TaskDependency archives. We could
> provide a synthetic task to build those archives, let's say if people call
> libsArchives or otherConfArchives (for convenience we might continue to
> provided the libs and dists task).
Could we add default configurations for sources / javadoc so we can do.
This is very subjective but I would reverse the order of the configuration
and how it should be packaged, I find that it reads easier
archives {
jar sources // jar the sources configurations
jar javadoc
}
It would be nice to give the default configurations classifiers and apply
them by default so you don't need to write javadoc
jar(classifier:'sources').
>
>
> The refactoring above would make the project dependencies refactoring very
> easy.
>
> And we would play the same game for uploading. No more uploadLibs or
> uploadDists.
>
> uploads {
> dists someResolver(...)
> ...
> }
>
> We would add a property to the configuration object like 'List resolvers'.
> We could also provide a synthetic task for publishing the archives of a
> configuration.
>
> What do you think?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
