Thanks Andrew, I've replied on the bug with some additonal steps we'll need
to do.
I have attached file swt-jars.txt containing
details of the third party jars which will be embedded in the SWT bundles so
the legal paperwork can commence. There are only four and they all come from
jfree.
After I forked the the SWT project, I decided to get going on
changing the SWT build to use Maven/Tycho and produce bundles. The reason is
that this allows dependencies to be organised in a logical manner. in which
both SWT and Andmore share the same base. I have made good progress and am at
the point where the "ADT" module is built using SWT bundles and imports into
Eclipse without error.
Note that I updated the Lint libraries to keep
everything in sync and the new jars are
lint-25.3.3.jar, lint-api-25.3.3.jar
and lint-checks-25.3.3.jar
Once the SWT bundles integration is complete, I need
to review the the built-in tests and fix a major bug caused by the
upgrade to the SDK Tools version 25. That is a an application under
development cannot be installed and launched onto a device. There is
an sdklib - sdkuilib - API incompatibility causing a runtime exception. I
think a quick work around is possible while the sdkuilib is under
repair.
Andrew
Dave. I
agree with what you are saying. These are the steps I plan to
make:
1. Create a
bug report for the old SWT support
libraries
3. Produce
jars for Bug 525493 using the fork and then submit pull request for same
bug.
What happens
next requires deliberation, but priority needs
to be given to defects which impact launching applications under
development.
In addition, I expect we would change the SWT build to
use Maven/Tycho and produce bundles.
I expect we will also reduce the SWT
footprint by exploiting standalone applications in the Android
SDK.
Andrew
I think we need to fork the old SWT support libraries they had done, and
maintain them as part of the Andmore project. Some of the old
tooling may make more sense to launch the new Android tooling if they have
equivalent standalone applications.
If you do fork, then I suggest creating a separate bug for that and new
plugins under the andmore project. The forked code will also need to go
through IP review, and we need to keep the original license (hopefully it is
EPL but sometimes they used Apache).
For the Integration tests that are failing go ahead an mark them as @Ignore
for now, and open separate bugs to address them.
Sequoyah is going to be another problem child, I don't know if there is an
archived update site for this or not. Eric or Wayne might know.
Dave
On 10/24/2017 12:18 AM, Andrew Bowley
wrote:
I have completed working on
the bug fix. I need guidance on whether to proceed with the pull request
given 2 issues that make the status unsatisfactory.
The first issue is that
undertook some pragmatic programming to compile SWT modules with the SDK
Tools version 25 libraries.
I have added a large number of source files
to the DDMS module from ddmuilib, uiautomator and sdkuilib AOSP projects.
In the case of sdkuilib, I pulled in an additional 156 source files from
the version 24 sdklib library, most of which were missing from version
25.
From this I suspect there is considerable effort required to get
Andmore up-to-date and therefore should be
tracked under a different bug report.
The second issue is that the
integration test now does not complete due to the workbench freezing up when
it gets to a certain point well into the test.
Unless someone can guide
me on how to investigate this problem, I will not be able to meet the
requirement that all tests must pass before submitting a pull
request.
One other issue with getting
the change to a satisfactory state is that the Sequoyah project has been
terminated and it's p2 repository is no longer online.
I have had to comment out the Sequoyah p2
repository reference in the parent pom to get Maven to
run.
Andrew
The DexWrapper is legacy code from the original ADT plugins I
believe. Why they did it that way I don't know.
Dave
On 10/20/2017 12:07 AM, Andrew Bowley
wrote:
Dave
To get dex to work, I had to apply the same
approach as Gradle, which is to launch a command shell and run "java
com.android.dx.command.Main --dex ...".
The good news is that Build Tools version will probably
not be an issue.
However, I would like to know why the DexWrapper was
employed in the first place as the command shell approach is a
natural choice.
I can now build, install and run my test
application targeting API 25 and with the bug fix. The next thing to
try is a Robolectric test on the MainActivity class.
Andrew
Andrew, go ahead and make any change that needs to be made.
We probably also need to add a check to see what version of the build
tools is required, and put a warning dialog up that can be dismissed,
saying something to the affect that they must upgrade to version 26 at
least. We can also put this out in a release document as
well, when we do the release.
When the android sdk makes these types of changes we just have to adapt
with them.
Dave
On 10/18/2017 6:27 PM, Andrew Bowley
wrote:
I have hit an important change to the build
tools which needs to be addressed. The Dex tool main class has changed
with version 26 from being totally static to just having a
static main method.
This means the DexWrapper class is no longer
needed and in fact throws an NPE when dexing with version 26
dx.jar.
How should I proceed? To jettison DexWrapper
forces everyone to use build tools version 26 and above.To leave it in
adds unwelcome complexity to Andmore.
Andrew
Dave
I have pressed on, patching the code to
avoid compilation errors, and one issue needs to be resolved from this
activity.
There is a class named
DeviceMenuListener in "adt" package
org.eclipse.andmore.internal.editors.layout.configuration which has the
following logic:
"Group the devices by manufacturer, then
put them in the menu. If we don't have anything but Nexus devices, group
them together rather than make many manufacturer
submenus."
I had to comment out the Nexus code
as it references objects in an sdk-common helper class which have been
removed. Maybe a bug report needs to be raised so the design can be
reviewed.
I am now at the stage of having set up a
test environment to proove the PR. I am hoping there are no big
surprizes so I can submit the PR shortly.
Andrew
Andrew, thanks. Can you put a pull request together that
contains all the fixes, and I'll try to get it going through the
simulataneous review process. This will allow us to merge the
change, while allowing the IP team to do their review.
In this case, it would be better to have one commit with all the
changes, so it would be easier to back out if we need to for any
reason. If you follow the format of the other commit
messages, the PR will automatically be linked back to bugzilla.
Thanks for the all the effort on this.
Dave
On 10/15/2017 4:50 PM, Andrew Bowley
wrote:
Please
find attached file containing information on dependency jars for
the CQ process.
The bug
fix requires Andriod SDK builder-2.3.3.jar which declares 34
dependencies. These include 7 other SDK artifacts which I indicate are
not expected to be deployed at this time.
Andrew
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
