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
