On Tuesday 30 March 2010 21:07:21, Hans Dockter wrote:
> On Mon, Mar 29, 2010 at 7:10 AM, Geronimo M. H. <[email protected]>wrote:
> > - I consider the filename of a jarfile like a value of a java Integer
> > instance - you can't never ever change that value. So changing the name
> > of a
> > jarfile is not acceptable for me - no matter whether its a foreign
> > artifact or the result of my own project. - So is there a way to ensure
> > this using gradle?
>
> I'm not completely sure about your scenario.
I had a project with about 25 sublevel projects, which I splitted into 3
top-level projects. One of the projects is a framework, that is used by the
other projects too. The framework consists of some library-subprojects, as
well as several application starter (think of it as an application server for
richclient environments).
So when I build the framework, several artifacts are created, wich will either
be used by the other projects at compiletime or at runtime.
> Where would the right name be defined and where do you want to prevent
> changing the name? Would you want to define the name in the root script or
> in a plugin and you want prevent subprojects changing it. We would like to
> understand what benefits this give you?
>
> How do you achieve this in Ant?
With my old ant-script, the user was asked for the version-number and this
property was distributed to all subprojects. Each subproject had its own
buildscript and I used a toplevel buildscript with subant, to build all.
The scripts where created for ant-1.6.x and worked fine and without errors
then. Migrating to ant-1.7x the troubles began (so ant changed support for
what I used).
My ant-buildfiles of the subprojects looked very similar to what I use now
with gradle (ignoring the different language). Here's such a buildfile:
<project name="SRJobLib" basedir=".">
<property name="prj.description" value="common classes used by conversion jobs
and editors"/>
<property name="version" value="0.0.1"/>
<import file="../srcommon.xml"/>
<path id="compile.classpath">
<fileset dir="${lib.dir}/commons-logging">
<include name="**/*.jar" />
</fileset>
<fileset dir="${lib.dir}/jgoodies$/binding">
<include name="**/*.jar" />
</fileset>
<fileset dir="${lib.dir}/junit">
<include name="**/*.jar" />
</fileset>
<fileset dir="${lib.dir}/spring">
<include name="**/*.jar" />
</fileset>
</path>
<path id="ref.classpath">
<fileset file="${prj.lib.dir}/SRDAlib.jar"/>
<fileset file="${prj.lib.dir}/SRGuiLib.jar"/>
<fileset file="${prj.lib.dir}/SRRecLib.jar"/>
<fileset file="${prj.lib.dir}/SRDVDThemeLib.jar"/>
</path>
<property name="project.type" value="${prj.lib.type}"/>
</project>
The main difference to now is, that with ant I used a static local repository
(which was checked in with subversion), with similar structure like a maven
repository, but I was not consistent respect to name/module usage.
The classpath was built from a fileset of the repository and I
used "pathconvert" to convert the real paths from filesystem to the expected
runtime-path, which I wrote into Manifest. The "compile.classpath" property
referred to my local repository, the "ref.classpath" to the builddir of the
root-project.
All artifacts where copied to the rootlevel-builddir, from where I created the
installers and which was the working directory for junit-tests (as I do lot
of dynamic jarfile loading, I need a production-like directory structure).
The jars from my ant-repository where copied for installer-creation only.
So back to the question of jarfilename-handling:
My error was definitely the version handling, with the result, that
isRelease() was always true - the code, where I checked the taskgraph was
wrong.
So based upon this error, my jarfile was created as i.e. lib-0.1.jar and not
as lib-0.1-201003310521.jar as I had expected. That error would not be a
great issue, as I did not had timestamps before.
I write the dependency classpath for each library into its Manifest - so my
problems began, when a lib-0.1.jar was copied to another place as
lib-0.1-201003310521.jar - now the Manifest-classpath pointed to non existing
jars. I have no idea, where the timestamp came from, but the root-level
artifacts had that timestamp.
So what I expect from a buildsystem is, that the (sub-)project is responsable
of the name creation for its artifacts. Any other access to existing jarfiles
should respect the filename as it is - no matter, whether it is a subproject
of the same toplevel-project or a completely different project.
I looked at the Manfest of jarfiles with timestamps and it contained the
classpath of jarfiles without timestamps - so I'm sure, the file has been
renamed. That's the only thing, I'd like to avoid.
> > That's not true at the moment for gradle - but I can't estimate, whether
> > it is
> > my fault or an error from gradle.
>
> I see your point. I can't see how we can improve the task graph approach to
> provide a result you would like.
Well, I think, there's no need to change the task graph. The version-creation
was my fault and it works fine now.
I guess, the dependency handling needs some changes/improvement. But I have no
idea, where and how.
My suspicion of wrong version-handling at dependency resolution was endorsed
yesterday by the fact, that gradle complained about a nonexisting dependency
library executing a "clean" task (by the way: why does clean have to check
dependencies outside the project?). The point is, the library was in the
repository, but had a different version than probabely expected (but I used
dynamic release numbers for the dependency declaration).
I will do further researches on that item to give you feedback in more
details.
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
