Hi Sean,
There are different approaches available. I would prefere to replace the
existing jar task provided by the java plugin with your customized one
since these obfuscated jars are your primary, productive, shipped ones,
aren't they? As you mentioned, you could add an additional jar task to
generate the unobfuscated once though.
You can replace the existing jar definition by writing your own one and
use the overwrite flag:
---------------
task jar(dependsOn:dependsOn: obfuscate, type: Jar, overwrite: true) {
...
}
---------------
When using the approach with a custom configuration like mentioned in
chapter 38 of the userguide you could introduce a new configuration
("obfuscated" in my example) and define the inter project dependencies
to use this custom configuration:
1. define a custom configuration in your build files:
---------------
configurations {
obfuscated.extends Compile
}
task obfuscate(dependsOn: classes) << {
//some interesting logic that puts obfuscated classes into
"$buildDir/obfuscated-classes"
javaexec {
main = 'ZKM'
classpath = sourceSets.main.runtimeClasspath
args "$projectDir/script.txt"
jvmArgs "-DSaveAllDir=$buildDir/obfuscated-classes"
}
}
task obfuscatedJar(dependsOn: obfuscate, type: Jar) {
baseName = 'obfuscated'
from "$buildDir/obfuscated-classes"
from project.sourceSets.main.resources
manifest.from("src/META-INF/MANIFEST.MF")
}
artifacts {
obfuscated obfuscatedJar
}
---------------
2. to reference to these obfuscated jar files in your projects
dependencies sections, you can define them as:
---------------
dependencies{
compile project(path: ':api', configuration: 'obfuscated')
}
---------------
3. your dist task would now look like this:
---------------
task dist(type: Zip) {
// as per http://www.gradle.org/tutorial_java_projects.html
dependsOn jar
from 'src/dist'
into('libs') {
from obfuscatedJar.archivePath
from configurations.obfuscated
}
}
---------------
regards,
René
Am 06.05.11 10:15, schrieb Sean Van Buggenum:
Hi Rene, and thanks for the reply,,.
I don't really see what is helpful here for my case. Though I
acknowledge that I, being not very knowledgeable in Gradle, may be
staring blank at the solution itself.
I do not want to configure all projects in one single build file, as I
think you seem to suggest, because there are many projects and there
could be
many projects which depend on other projects which are depended on by
many other projects.
To be clear, here is an example scenario;
proj1 depends on proj2, proj3
proj4 depends on proj3, proj5
proj6 depends on proj1, proj2, proj3, proj7
proj7 (no or only external dependencies)
where proj1, proj4 and proj6 themselves are ' distributable projects '
(and the others, typically not).
That is, I would be wanting to distribute
- for proj1, the build file for proj1, proj2, and proj3 plus any
external dependencies.
- for proj4, the build file for proj4, proj3, and proj5 plus any
external dependencies,
- for proj6, the build file for proj6, proj1, proj2, proj3, and proj7
plus any external dependencies;
But also, that for each and everyone of these projects, two jar files
are generated (this already works)
1. an internal non-obfuscated version
2. a distributable obfuscated version
The distribution ZIP files should only ever contain the obfuscated
versions of the files.
Now, if I didn't need the non-obfuscation versions (but I do) then I
could just overwrite the unobfuscated class files in a doFirst method
of the default jar task,
then the default jar built by the build (for all of the projects)
would contain only obfuscated files, they would be distributed, and my
job would be done.
However, I need the unobfuscated versions for testing (debugging is
quite difficult with obfuscated versions of jars, and the automated
testing tools don't like changing class names).
Again; My case is that everything works except that the distribution
ends up with unobfuscated files instead of the obfuscated ones.
Dependencies are working out fine, and I even correctly get the
external dependencies landing in the distribution zip.
I don't want to put everything in one build file, because this would
mean a pretty large build file for every project that needs to be
distributed, plus it seems it would mean a lot of redundancy .. or
repetition (if i understand correctly).
Is there anyway to clear the by-default 'from' inclusion that the java
plugin introduces so that I can manually include my own 'obfuscated'
classes?
Or, do I completely misunderstand, and there is a simple way to
include the correct (obfuscated) jars, with the build file similar to
how it is now, by a modification in my dist task?
Thanks again, and sorry for my lack of comprehension,
sean
On 6 May 2011 16:22, Rene Groeschke <[email protected]
<mailto:[email protected]>> wrote:
Hi Sean,
Have a Look at the userguide chapter 38
http://gradle.org/current/docs/userguide/userguide_single.html#sec:project_jar_dependencies
There is an example on how to declare a dependency to a custom jar
task of another project by defining another configuration. Btw,
you may need runtime dependencies in your dist Task instead of
compile dependencies.
Regards,
Rene
--
Rene Groeschke
Email: [email protected] <mailto:[email protected]>
twitter: @breskeby
Blog: http://www.breskeby.com
Am 06.05.2011 um 07:48 schrieb Sean Van Buggenum <[email protected]
<mailto:[email protected]>>:
I take it back. i am stuck.
The two ways I can think of doing this neatly are;
1. customize the main jar task so that it uses the obfuscated
classes instead of the clean classes,
and make the extra jar task use the clean ones.
or
2. get my dist task (type: Zip) to know where to pick up the
obfuscated .jar files from the other projects... (and not pick up
the non-obfuscated ones)
task dist(type: Zip) {
// as per http://www.gradle.org/tutorial_java_projects.html
dependsOn jar
into('libs') {
from jar.archivePath
from configurations.compile
exclude '*ZKM*.jar', '*junit*.jar'
}
}
1.
My problem with No.1 is that while I can get it to jar up the
obfuscated classes (by adding a from clause)
It still also includes the non-obfuscated classes. This is
because by my adding my own 'from' I am only appending to the
list of sources to jar up, not overriding.
And I can't find for the life of me how to override this... and
cause the main jar task NOT to include the clean classes..... (I
hope I am clear here).
2.
My problem with No.2 is that I can't find any documentation for
how this configurations.compile thing works....
As you can see in my 'dist' task (above) ... it uses two 'from'
clauses;
from jar.archivePath
from configurations.compile
the first gets the jar that was built for this project,
and the second seems to get all the OTHER jars built in the
multi-project build, as well as all dependencies.
So, replacing 'from jar.archivePath' seems pretty easy, just to
include my own obfuscated jar for this project.
But that does not solve the fact that I am including all the
non-obfuscated jars from my other projects.
So how does 'configurations.compile' work.... and what else in
there can I work witih?
Sorry if I am asking stupid questions, or somehow overlooking the
obvious.....
But I have been trying!
thanks for any help,
sean
--
-----------------------
regards René
rene groeschke
http://www.breskeby.com
@breskeby
