Comments (14)
Solution found. See: http://stackoverflow.com/questions/30018865/access-project-extensions-during-task-creation
We can do:
tasks.create(name: "j2objcTranslate", type: J2objcTranslateTask, dependsOn: 'j2objcCycleFinder')
and at the very end of the file:
j2objcTranslate {
description "Translates all the java source files in to Objective-C using j2objc"
srcFiles = J2objcUtils.addJavaFiles(project,
files(fileTree(dir: project.projectDir,
include: "**/*.java",
exclude: project.relativePath(buildDir))),
project.j2objcConfig.generatedSourceDirs)
destDir = file("${buildDir}/j2objc")
}
It works but currently I get 50 files less translated than in the previous solution. MAy you have an idea why.
from j2objc-gradle.
@advayDev1 - should we even have a generatedSourceDirs setting at all? Would it be better for those to be created as source sets instead?
sourceSets {
apt{
java{
srcDir 'build/source/apt'
}
}
}
Does this cover all the cases? It would be good to drop this current custom code:
tasks.create(name: 'j2objcTranslate', type: TranslateTask, dependsOn: 'j2objcCycleFinder') {
additionalSrcFiles = files(
fileTree(dir: "build/source/apt",
include: "**/*.java")
)
...
}
from j2objc-gradle.
@brunobowden good idea:
If this
sourceSets {
apt{
java{
srcDir 'build/source/apt'
}
}
}
replaces this:
generatedSourceDirs "build/source/apt"
then I am fine with it and strongly support it.
from j2objc-gradle.
@advayDev1 I am also interested in your comment here?
from j2objc-gradle.
@advayDev1 - interested in your thoughts on this
from j2objc-gradle.
sorry didn't see this... i don't think this is right. sourcesets can't just be created automatically using that kind of syntax. we would have to setup named sourcesets for each type of code that could be generated.
assuming you are using annotation processors:
isn't the right solution to have the same annotation processors that run in your standard javac run also run in the j2objc phase and then consume them the same way?
from j2objc-gradle.
@hvisser - Hugo, since you wrote the android-apt plugin, we would appreciate your insights on working with annotation processors for our J2ObjC Gradle Plugin. It takes an existing Java project and then converts it to Objective-C so that it can be built and run on iOS. It uses the J2ObjC project from Google.
Note that this is designed to work with a Java project so that the code can be used server side as well. At the same time, we'd like it to work well within Android Studio where most of the development will be. If you have some insights on this, then it would be great to hear from you.
from j2objc-gradle.
OK, I'll try. I can't fully grasp what you are trying to solve in this issue though :) I think the issue is that annotation processors can generate source code that also has to be treated by j2obc?
In essence android-apt
just adds some flags to javac
to control where the source output lives. Then it uses an API in the build tools to make sure AS will actually use that location as a valid source location. It still has to live under build/generated
because all other folders are hidden by AS. Setting the source location used to be done using source sets, but that was quite hacky since it involved modifying source sets after a specific phase in Gradle.
I don't think you can really know where these generated sources end up, because it's sort of an internal thing for javac
. It is possible to run javac
in a mode that just generates the code from annotations. Maybe you could invoke that command to generate the source in a place where you like to have it for conversion, but you'd have to keep in mind the class path and processor paths that where passed into the original java compile task. And on Android there's a new compile task incubating which is different from JavaCompile so that would need another treatment.
from j2objc-gradle.
@hvisser, please excuse me for not being clearer on this while we figure it out. The basic goal we're aiming for is that whatever project you can build with the Gradle JavaPlugin... you can build the same project as a J2ObjC converted library to run on iOS. We've got growing support for multi-project dependencies. Annotation processors is another upcoming issue.
I think it's best that we first look in to this further as to how best to do it for Java only projects. If you don't mind, please lurk on this thread and give feedback where you can. I can see that this is an area that will need more research from us.
from j2objc-gradle.
For Java only projects the same probably applies. Without any plugin, javac
will generate the .java
files in the classes dir. Configuring additional dirs with java sources like you seem to have now in the plugin sounds like the most flexible option I guess at some extra configuration costs. I'm happy to help out where I can anyway!
from j2objc-gradle.
I like @hvisser's soln from reply 1, para 3:
It is possible to run javac in a mode that just generates the code from annotations.
However, I think we should FR annotation processor running against j2objc. It would be ideal to call j2objc with the same arguments javac would be called, just like we (are supposed to) do with sourcepath and classpath. Then we don't have to coordinate work between javac and j2objc.
from j2objc-gradle.
@tomball - we're formulating some thoughts around how annotation processors work with J2ObjC. With the philosophy of keeping j2objc and javac using the same command line. What are the current limitations if any with J2ObjC's annotation processor support? I see it was initially supported in the 0.9.6 release.
from j2objc-gradle.
All j2objc does is run the batch compiler and add all generated Java
sources to its sources list. We'll certainly accept contributions that add
javac annotation flags that can be mapped directly to the Eclipse batch
compiler invocation, but we don't have the bandwidth to invest in major
changes. Developers already have the workaround of running "javac
-proc:only" and transpiling the generated sources separately, if they have
exotic processing requirements.
On Thu, Jul 16, 2015 at 11:32 AM Bruno Bowden [email protected]
wrote:
@tomball https://github.com/tomball - we're formulating some thoughts
around how annotation processors work with J2ObjC. With the philosophy of
keeping j2objc and javac using the same command line. What are the current
limitations if any with J2ObjC's annotation processor support? I see it was
initially supported in the 0.9.6 release.—
Reply to this email directly or view it on GitHub
#45 (comment)
.
from j2objc-gradle.
We've redone our annotation processor support in the 0.5 release.
It is intended to work the Gradle/Javac's default handing of annotation processors.
Check out #517 for more info.
If the new support is not working for you, please file new bugs. What is mentioned in this bug is long obsolete.
from j2objc-gradle.
Related Issues (20)
- Possible to add *junit* to *spec.libraries* in generated podspec? HOT 1
- Setting xcodeTargetsManualConfig to false for a multi-module project fails HOT 2
- Translation fails to link dependencies HOT 1
- Possible to run an Android build whilst skipping all tasks of the J2ObjC Gradle plugin?
- Extracting resources from source jars HOT 1
- Does not convert app android to Ios HOT 5
- Stripping reflection applies to and breaks tests
- Need to add Guava headers to native compile header search path HOT 2
- Latest version of the Android Plugin for Gradle (2.0.0) requires Gradle 2.10 or later HOT 2
- Test source cannot be moved from default location
- Require way to set extended podspec values HOT 1
- I wrote a few gradle tasks to generate `name.framework`, without pods, >3 votes -> pull request HOT 7
- How to verify translated objective c unit tests ran successfully? HOT 1
- Regexp does not remove zeros at the beginning
- j2objcTestDebug is stuck when prefixes specified HOT 1
- Is this project still active? HOT 3
- Could not compile Source project with createIos_arm64
- How to install or implement in Android studio ??? HOT 1
- Test issue
- rat checks fail with basic $ ./gradlew check on mac HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from j2objc-gradle.