Combined resources conflict with IntelliJ autodetection
cbauer
The first problem I'm seeing is the /target/generated-resources/
combined-resources/ directory.
The way the Maven support in IntelliJ works is that it automatically
detects source and output paths. There is no way to disable this or
exclude anything, it's magic. You define a phase (e.g. 'generate-
sources' or 'process-resources') which IntelliJ will listen to, and
after a Maven goal runs through that phase, IntelliJ will compare the
directories before/after. (This is my assumption how this works
internally, like I said: magic).
So when the combined-resources directory is generated and populated
during the Android application build, IntelliJ will immediately add
the combined-resources directory as a Java source directory. At this
point you can no longer build/use the application in IntelliJ until
you manually remove the source path from the project settings. It will
be back after the next Maven goal execution.
Looking at the GenerateSourcesMojo.java source code I don't see an
easy way to avoid/configure or even customize the combined-resources
processing.
Malachi de Ælfweald
I have mine setup to do a android:deploy on mvn install... So I create my project using the archetype, do an initial mvn install, then open the project in IntelliJ. That ensures that the 'R' stuff is detected and setup properly. If I open it before the initial install it sometimes makes me set it up manually. When I open the project, it tries to autodetect the android facet, and I ignore that. If I let it see the android facet, it assumes eclipse-style android paths. At that point, the mvn plugin seems to work just fine (I can right-click on "install" for example).
Malachi de Ælfweald
http://www.google.com/profiles/malachid
--
You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.
To post to this group, send email to maven-androi...@googlegroups.com.
To unsubscribe from this group, send email to maven-android-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maven-android-developers?hl=en.
Christian Bauer
On Jun 25, 2010, at 14:14 , Malachi de Ælfweald wrote:
> I have mine setup to do a android:deploy on mvn install... So I create my project using the archetype, do an initial mvn install, then open the project in IntelliJ. That ensures that the 'R' stuff is detected and setup properly. If I open it before the initial install it sometimes makes me set it up manually. When I open the project, it tries to autodetect the android facet, and I ignore that. If I let it see the android facet, it assumes eclipse-style android paths. At that point, the mvn plugin seems to work just fine (I can right-click on "install" for example).
Well, how do you access LogCat, the remote debugger, resource code completion, the deployment selector, etc? It seems you are only using IntelliJ as a Maven goal-starter if you do not configure an Android facet. Does anyone use an IntelliJ Android project module with the Maven plugin?
Malachi de Ælfweald
--
Hugo Josefson (Jayway)
I usually run ddms separately, for example by launching it from ALT+F2
in Ubuntu, or type ddms at the command line. It's located in the
Android SDK's tools directory, and includes logcat and more.
/Hugo
Christian Bauer
On Jun 25, 2010, at 16:28 , Malachi de Ælfweald wrote:
> Resource code completion works.
I've tried your archetype and I can see how it configures the paths. However, without an IntelliJ Android facet, I do not get code completion in the resource XML files. The schema http://schemas.android.com/apk/res/android is only available when I have an Android facet.
Malachi de Ælfweald
--
Christian Bauer
On Jun 25, 2010, at 17:14 , Malachi de Ælfweald wrote:
> If you create layouts, strings, etc and compile it does autocomplete from within Java.
I don't even get that working without an Android facet.
> To autocomplete from within the XML, we'd need to actually have the schema. Anyone know where the XSD actually is?
There is an org.jetbrains.android/android.xsd in the IntelliJ plugin library but its contents are "<x xmlns="http://schemas.android.com/apk/res/android"/>" which looks like a stub. So I'm assuming the actual validation/completion done by the Android IntelliJ plugin is all internal within code.
I think this is not the right way to go, we should look into making the Android facet compatible with a Maven lifecycle/build and find out what needs to be done there. Then probably open bug reports with Jetbrains to get it fixed.
Christian Bauer
> I think this is not the right way to go, we should look into making the Android facet compatible with a Maven lifecycle/build and find out what needs to be done there. Then probably open bug reports with Jetbrains to get it fixed.
Malachi de Ælfweald
http://youtrack.jetbrains.net/issue/IDEA-56050
> I think this is not the right way to go, we should look into making the Android facet compatible with a Maven lifecycle/build and find out what needs to be done there. Then probably open bug reports with Jetbrains to get it fixed.
Manfred Moser (simpligility)
please vote, watch and star the issue?
http://youtrack.jetbrains.net/issue/IDEA-56050?projectKey=IDEA
Thanks
manfred
On Jun 25, 5:14 am, Malachi de Ælfweald <malac...@gmail.com> wrote:
> Hi Christian,
>
> I have mine setup to do a android:deploy on mvn install... So I create my
> project using the archetype, do an initial mvn install, then open the
> project in IntelliJ. That ensures that the 'R' stuff is detected and setup
> properly. If I open it before the initial install it sometimes makes me set
> it up manually. When I open the project, it tries to autodetect the android
> facet, and I ignore that. If I let it see the android facet, it assumes
> eclipse-style android paths. At that point, the mvn plugin seems to work
> just fine (I can right-click on "install" for example).
>
> > .
Manfred Moser (simpligility)
basically use the eclipse based paths in the project. I do however
still get the full maven defined dependencies and that all works
fine.
Whenever I change the pom IntelliJ will reload the project and add two
folders in target that are the replacement for /gen . That leads to
duplicate classes and stops the project from working. I then just
delete the two entries leaving gen active and things work again.
This is not ideal but at least that way I get command completion in
drawables, android manifest and so on.
Sure beats working in Eclipse imho anyway...
>
> I have mine setup to do a android:deploy on mvn install... So I create my
> project using the archetype, do an initial mvn install, then open the
> project in IntelliJ. That ensures that the 'R' stuff is detected and setup
> properly. If I open it before the initial install it sometimes makes me set
> it up manually. When I open the project, it tries to autodetect the android
> facet, and I ignore that. If I let it see the android facet, it assumes
> eclipse-style android paths. At that point, the mvn plugin seems to work
> just fine (I can right-click on "install" for example).
>
> > .
Christian Bauer
> easy way to avoid/configure or even customize the combined-resources
> processing.
Coming back to this, it really seems to be the blocking issue. (Manfred just posted about it as well, the current solution is to delete the directories or paths in the module settings after every Maven project import/run so the Android facet can continue doing its own thing.)
Looking at _why_ the combined-resources directory in the /target/generated-sources/ is populated, I don't fully understand that. I think we have to show why this is necessary so the Jetbrains guys can adapt their plugin accordingly.
Can anyone explain the purpose and procedure in GenerateSourcesMojo.java#extractSourceDependencies() please? I will then summarize it and suggest solutions on the IntelliJ issue report.
P.S. Yes, I'm new to Android development ;)
Malachi de Ælfweald
Actually, I just opened my project (again, remember I am not using the facet) and I do get completion in both java and xml (tested both AndroidManifest.xml and main.xml). The only thing I am really lacking IMHO is the debugger.
Malachi de Ælfweald
http://www.google.com/profiles/malachid
--
You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.
To post to this group, send email to maven-androi...@googlegroups.com.
To unsubscribe from this group, send email to maven-android-deve...@googlegroups.com.
Manfred Moser
>> schema. Anyone know where the XSD actually is?
>
> There is an org.jetbrains.android/android.xsd in the IntelliJ plugin
> library but its contents are "<x
> xmlns="http://schemas.android.com/apk/res/android"/>" which looks like a
> stub. So I'm assuming the actual validation/completion done by the Android
> IntelliJ plugin is all internal within code.
Not sure where it is but at least I cant find it in the android jar at
first glance..
> Android facet compatible with a Maven lifecycle/build and find out what
> needs to be done there. Then probably open bug reports with Jetbrains to
> get it fixed.
Well.. the plugin is defining its own lifecycle, which it has to do
because of how android builds work. If the android facet can understand
the custom lifecycle it should be able to understand the rest.
I think if Jetbrains looks at this and reads some of the config in the pom
for use with the facet it should work fine..
manfred
Manfred Moser
Anyway.. the issue just got assigned to a developer!
manfred
> I'm not sure I completely understand. I never have to delete anything.
>
> Actually, I just opened my project (again, remember I am not using the
> facet) and I do get completion in both java and xml (tested both
> AndroidManifest.xml and main.xml). The only thing I am really lacking
> IMHO
> is the debugger.
>
>
> Malachi de �lfweald
>> maven-android-deve...@googlegroups.com<maven-android-developers%2Bunsu...@googlegroups.com>
Manfred Moser (simpligility)
Christian Bauer
> Can anyone explain the purpose and procedure in GenerateSourcesMojo.java#extractSourceDependencies() please? I will then summarize it and suggest solutions on the IntelliJ issue report.
I missed http://code.google.com/p/maven-android-plugin/wiki/ApkSourcesDependency before so now I understand why the /combined-resources/ directory exists. I've added a comment to the Jetbrains ticket, please correct me if I'm wrong about this.
Unfortunately, the only short-term solution I see is:
- The maven-android-plugin should not use the target/../combined-resources/ directory at all for a single-module Maven project (no dependency of type "apksources" exists).
- Such a project will work with the current IntelliJ Android facet.
- Multi-module projects and "apksources" dependencies, where a target/.../combined-resources/ directory and the inheritance/copying procedure is necessary, will just not work with the Android facet.
I suggest we wait and see what the Jetbrains guys think about this and if they want to add the "apksources" procedure to the facet. If they don't, the maven-android-plugin should be changed accordingly so we get at least single-module non-apksources integration.
Malachi de Ælfweald
mine is under target/generated-sources/combined-resources
nothing should be getting dropped into target/..
Christian Bauer
On Jun 27, 2010, at 10:30 , Malachi de Ælfweald wrote:
> target/../combined-resources/?
>
> mine is under target/generated-sources/combined-resources
>
> nothing should be getting dropped into target/..
Sorry, make that ... three dots. I was getting tired of repeating the whole path :)
Malachi de Ælfweald
--
Albin Theander
how I'd like to see it done in the future.
-- What happens --
1. For all dependencies with type apksources, the source code and
android resources are unpacked. The destination is configurable, but
defaults to target/generated-sources/extracted-dependencies.
2. All resources are copied from target/generated-sources/extracted-
dependencies to target/generated-sources/combined-resources
3. All resources are copied from the projects Android resource folder
to target/generated-sources/combined-resources
4. The R file is generated from target/generated-sources/combined-
resources. It ends up in target/generated-sources/r
5. target/generated-sources/r and target/generated-sources/extracted-
dependencies/src/main/java are added as source folders.
In short, it means two things.
1. Dependencies of type apksources are source code dependencies. Not
compiled class dependencies.
2. Resources are combined from apksources project and the current
project with the current project's resource files taking precedence if
there is a collision.
-- Why do it like that? --
1. Why you need to use the source code - Since there could be
resources in both the main project and the project you depend on
(let's call it the lib project), the R file needs to be regenerated to
include all resources. Unfortunately, this means that the code in the
lib project needs to be recompiled to get the new values in the R
file.
2. Why you need to combine all resources - aapt has support for using
several resource folders. However, before SDK r06 was released (with
Android 2.1) there could be only one _main_ resource folder. All other
resource folders could only replace resources, not add them. (Don't
ask me why!) This means that you need to mash all resources together
before generating the R file. (In Android SDK r06, there is a flag to
aapt to allow all resource folders to contain new resources)
-- What's in the future? --
There are a few drawbacks with the way things are working now. The
major problem is that the lib project and the main project must both
use the same Android base package. Things should probably work more
like the new Android eclipse plugin. This means the following changes:
1. Stand-alone projects should not need to use generated-sources at
all.
2. Each apksources dependency should be extracted to its own folder
under generated-sources
3. There will be no need to combine all resources.
4. If the apksources dependencies have different Android base package
names, there will be one R file for each base package. All R files
will look exactly the same.
All this may seem overly complicated, but most of it makes sense. I'll
try to keep up with the discussion if there are more questions or
suggestions regarding this.
Manfred Moser
Great explanation and suggestions for improvement. I am fine with your
suggestions. Going forward I would also like to see more optional smarts
being built into the plugin.
E.g. version, package and name in android manifest from pom
and especially in terms of modules it would be great if e.g. strings.xml
and all other resource files from multiple projects could be merged
smartly. That might be a bigger undertaking though...
manfred
Albin Theander
filtering?
> and especially in terms of modules it would be great if e.g. strings.xml
> and all other resource files from multiple projects could be merged
> smartly. That might be a bigger undertaking though...
I described above. If you pass each resource folder to aapt
individually (instead of combining all the files in one folder, like
today) aapt will merge the resources, not the files. Each string in
strings.xml is a resource of its own. Thus, all strings from all
strings.xml will be included. If the same string is defined in several
strings.xml the main project will take precedence.
Manfred Moser
>
> Yep, this would be great. But isn't this more a matter of resource
> filtering?
The problem with using resource filtering is that ADT wont have a clue
then. If we leave it intact and just use e.g. the plugin code base or a
groovy script to keep the files in sync it might cause less integration
issues..
>> and especially in terms of modules it would be great if e.g. strings.xml
>> and all other resource files from multiple projects could be merged
>> smartly. That might be a bigger undertaking though...
>
>
> This will actually be a bonus feature with the new library function as
> I described above. If you pass each resource folder to aapt
> individually (instead of combining all the files in one folder, like
> today) aapt will merge the resources, not the files. Each string in
> strings.xml is a resource of its own. Thus, all strings from all
> strings.xml will be included. If the same string is defined in several
> strings.xml the main project will take precedence.
That sounds awesome. i take it you are working on it ;-)