Community
Participate
Working Groups
I imported a project that I had previously been working on in ADT into Andmore; it resulted in a lot of red. After some effort, I sorted out that the nature and builder IDs were changed. I agree that these need to be changed. But if--in the meantime--everybody has trouble importing their existing projects into Andmore, it's not going to be good for adoption. Further, changing these makes Andmore fundamentally incompatible with ADT. At least for the time-being both exist and we should try to be as harmonious as possible. It is entirely possible that somebody might try to load both ADT and Andmore into their Eclipse. What happens in this case? Is this even possible? I recommend that you revert the ids to their original values in the short term and perhaps consider writing some sort of migration utility in the longer term (especially when the implementation of Andmore starts to diverge significantly from ADT).
(In reply to Wayne Beaton from comment #0) > I imported a project that I had previously been working on in ADT into > Andmore; it resulted in a lot of red. > > After some effort, I sorted out that the nature and builder IDs were > changed. I agree that these need to be changed. But if--in the > meantime--everybody has trouble importing their existing projects into > Andmore, it's not going to be good for adoption. > > Further, changing these makes Andmore fundamentally incompatible with ADT. > At least for the time-being both exist and we should try to be as harmonious > as possible. > > It is entirely possible that somebody might try to load both ADT and Andmore > into their Eclipse. What happens in this case? Is this even possible? > > I recommend that you revert the ids to their original values in the short > term and perhaps consider writing some sort of migration utility in the > longer term (especially when the implementation of Andmore starts to diverge > significantly from ADT). I don't think we can safely use the same nature ids. I do agree that we need at the minium a migration guide to manually bring things over. In the mean time, you may be able to use the Import Existing Android Source wizard, which should bring in an existing project with the correct ids. This would be a nice integration test to have for the project to make sure that this section of code works as expected. We'll need to at least write up a FAQ on the Andmore projects wiki. As for having ADT and Andmore installed together, that is not recommended especially if we were to use the same nature ids as they would end up fighting each other as to who has control. Let me know if you think this is a stopper for 0.5-M1 as I'm tentatively targeting that for a release later in the week. If we can come up with a documented work around for getting existing Android projects imported correctly I'd like that and then provide a wizard in 0.5-M2.
My primary concern is that we avoid confusing the community. Secondary to that is that we avoid making you have to do a whole lot of extra work to avoid confusing the community. I'll try the import option. If that works, then I think that we need to position Andmore as a "new" set of tools for doing Android development that you can import your existing ADT projects into. Even with that sort of positioning, I figure that there's going to be a lot of people who will expect to be able to just import their existing projects. It's been a while since I looked at such things, but it may be a relatively easy thing to install a resource listener that notices that you've imported an ADT project and provides a means to convert it to an Andmore project. I might take a stab at implementing something like this... I noticed, BTW, that--in the process of creating a new Android App--Andmore created an "appcompat_v7" project using the ADT nature and builder IDs.
(In reply to Wayne Beaton from comment #2) > > I'll try the import option. If that works, then I think that we need to > position Andmore as a "new" set of tools for doing Android development that > you can import your existing ADT projects into. > > Even with that sort of positioning, I figure that there's going to be a lot > of people who will expect to be able to just import their existing projects. To import and existing ADT or Android Studio project using Andmore please try the following: 1. File->Import->Android->Existing Android Code into Workspace 2. Navigate to where you have your Android source code, and point the wizard to the source code you want to import. 3. If you want to copy the project into the existing workspace, you can. As long as the project is in the legacy format for ADT, it will copy in the project, and set it up with the new project nature and location of the gen folders. You can test this out by installing the Android Samples, and pointing the wizard to: ANROID_HOME/samples/android-18/BluetoothChat Projects that are in the Android Studio/Gradle format will need some manual help to setup the directory structure correctly. In this case, it is best to use something like the Andmore fork of the m2e-android plugin and have a maven project setup. We need to be able to better handle the different structure that Android Studio and Gradle introduced, but it should get you at least going with existing ADT code. > > It's been a while since I looked at such things, but it may be a relatively > easy thing to install a resource listener that notices that you've imported > an ADT project and provides a means to convert it to an Andmore project. I > might take a stab at implementing something like this... > > I noticed, BTW, that--in the process of creating a new Android App--Andmore > created an "appcompat_v7" project using the ADT nature and builder IDs. The appcompat_v7 items are a bug that will need to be addressed.
Added a FAQ to the Andmore Wiki: https://github.com/eclipse/andmore/wiki/FAQ#how-do-i-importconvert-an-existing-adt-project-to-work-with-andmore
Created a bug for the appcompat_v7. Really any of the appcompat libraries are going to have problems. https://bugs.eclipse.org/bugs/show_bug.cgi?id=463612
As a user, I expect that I can open an existing ADT workspace and continue working with Andmore. That's why as a developer I would suggest to have Andmore create a warning marker for every project that has the ADT nature, and a quickfix for converting that project _in place_ (i.e. adding the Andmore nature or replacing the ADT with the Andmore nature). The basic idea is that markers are seen by every developer automatically, while only a minority will find the import wizard. This is probably the same that Wayne imagined in comment 2.
(In reply to Michael Keppler from comment #6) > As a user, I expect that I can open an existing ADT workspace and continue > working with Andmore. > > That's why as a developer I would suggest to have Andmore create a warning > marker for every project that has the ADT nature, and a quickfix for > converting that project _in place_ (i.e. adding the Andmore nature or > replacing the ADT with the Andmore nature). > > The basic idea is that markers are seen by every developer automatically, > while only a minority will find the import wizard. > > This is probably the same that Wayne imagined in comment 2. One thing we could probably do, is leverage the Convert contenxt menu option. So if you open an existing workspace that has ADT items in it, you could right click on the project, and then select Configure->Convert to Andmore Android Project. Currently several plugins use this option to allow configuration PDE and M2E come in mind. The probablem with keeping existing nature ids is that if ADT is installed, then you have Andmore and ADT both fighting on trying to build and control a project.
Took a bit of time this morning and hacked a Command together that should at least be a starting point to convert existing ADT projects to use the Andmore nature and builder ids. https://github.com/eclipse/andmore/pull/87 I haven't tied it yet into the UI, or even tested it yet, but the idea is to find the existing ADT projects, update the project descriptions for natures and build configs, and rewrite the classpath entries with the new ids. Since it only looks for projects that have the old Nature Ids it should ignore everything else and won't convert a plain java project. I'll work on it some more.
Okay I have the basics for this working. Basically, there is a command that is contributed to the Configure popup menu. It is only visible for projects that have the ADT Project Nature, it does not show up for any other project, and can convert multiple projects. I have tested this using the android sdk extras projects. In particular the appcompat-v7. To do this, use the General Import wizard to import and existing eclipse project. This will bring in the project with the ADT settings still intact. Once that is done, you can right mouse click on the project, select Configure->Convert to Andmore Project. This will run the command, and update the project natures and classpath containers to the new ids. What is left to do: 1. The old buildCommands are left in the project file. Need to remove these. I'll go ahead and merge this in after I verify the pr so that you can try it in a nightly build or pull in the code from develop.
(In reply to David Carver from comment #9) > What is left to do: > > 1. The old buildCommands are left in the project file. Need to remove these. This is now working as well.
Code merged, give it about an hour and you should have an nightly build you can try from: http://download.eclipse.org/andmore/nightly That is the p2 repo. Or pull in the latest changes from develop and build yourself. It should handle m2e-android projects as well as plain ADT projects. Basically anything that has the old ADT nature.
The code for this is merged, and I've tried with a variety of projects for the android sdk/extras/android folder. appcompat-v7 leanback-v17 And a variety of sample projects work as they were created with ADT. Any project that was created using Android Studio will not work with this conversion command as the necessary .project and .classpath files don't exist. This includes the newer RecyclerView, CardView, etc that came out with Android 21 and Android L.
