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
