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
