Roadmap for Masa

[Hugo Josefson]

Hi, it's me again!

I have identified a number of things which me and my colleagues want/
need from an Android Maven plugin project. As I have mentioned before,
my first wish is to do all Android/Maven development within Masa
because I believe it's in everyone's best interest that there is one
strong project where all effort is concentrated.

Please let me make it quite clear that I am definitively not here to
force things into Masa. If you feel this list of requirements are not
right for implementing within the Masa project, I am quite happy to
set up a different project and do all this there. My first choice
however is to give you the option of having me implement it in Masa,
if you feel all (or most of) these things fit the Masa project.

Now, please read the list with this in mind: Item number 1 is the only
item which requires initial direct action from Shane Isbel, because he
owns the m2-repo.googlecode.com project. I will be happy to take care
of all the other ones.

To be able to do this within Masa, I need both these two things:
* Item number 1 solved.
* An "OK" to go ahead with all of the rest within Masa.

Please let me know if you think I should go ahead with implementing
this list inside or outside of Masa. Even though I _need_ a response
from Shane Isbell, I will be very happy for any comments from the
other developers and users of Masa!

/Hugo

===================================================================
PROPOSED IMPROVEMENTS FOR MASA
(please read with a proportional font)
(also, I am not angry; it's just the way I sometimes sound when I
write specifications :))
===================================================================

-------------------------------------------------------------------
EFFICIENT RELEASE MANAGEMENT
-------------------------------------------------------------------

(0. Suggested release numbering:)
Major releases (1.0.0 -> 2.0.0) are for big things which
are allowed to break backward compatibility.
Minor releases (1.0.0 -> 1.1.0) are for new functionality
which does not break backward compatibility.
Point releases (1.0.0 -> 1.0.1) are for bug fixes.

1. Make sure there is at least one person available who can
perform releases on short notice to Masa's official Maven repo.
Optionally, give me permission to perform such releases.
Rationale: As soon as a fix or feature is done, it should be
made available to users. Users should not have to wait for fixes to
become available, and they should not have to download Masa sources
and build for themselves.

2. Release Masa 1.0.1 now(!) with current fixes included.
Rationale: Users have been waiting for this release.
Saves the current state of Masa version 1.0, before
continuing with new features for version 1.1 or major refactorings for
version 2.0.


-------------------------------------------------------------------
REFACTOR FOR CLARITY AND MAINTAINABILITY
-------------------------------------------------------------------

3. Share common settings and code between mojos.
Rationale: "DRY / Don't Repeat Yourself" - less copies of
similar/same code to maintain in different mojos.

4. Unless there are reasons to keep every goal in its own plugin:
Collect all goals in one (1) plugin.
Rationale: Easier for users to get an overview and understand.
Documentation becomes more concise and more like
other Maven plugins.


-------------------------------------------------------------------
SMARTER DEFAULTS and MORE CLEAR CONFIGURATION
-------------------------------------------------------------------

5. Remove the -Dmasa.debug parameter.
Rationale: It's confusing. See also Issue 20.

6. Make DeviceInstallerMojo not run by default when building a
<packaging>android:apk</packaging> project. If user wants to install
the apk to device, they should run something like "mvn install
adb:install" instead.
Rationale: Installing an apk file to device should not be a
side-effect of other actions (goals) in combination with a parameter (-
Dmasa.debug). It is a specific action, and should be treated as such.

7. Make DeviceInstallerMojo install the platformTest apk by
default on pre-integration-test for any
<packaging>android:apk:platformTests</packaging> project.
Rationale: When running the platformTests, the most common use
case by far is likely to be that the user wants to actually run the
tests. Since the platformTest apk was just built, it should be
installed to the device by default.

8. Add configuration parameter to PlatformTesterMojo for defining
target apk artifact.
Rationale: The PlatformTesterMojo should know which Maven
artifact of <type>android:apk</type> is its target. This is so that it
can pull it from the local or remote Maven repo, and install it to the
device before installing and executing the platformTest apk on the
device.

9. To summarize: Before running platformTests,
depend on the target apk (so target's apk is
pulled from local/remote maven repo),
deploy target apk to the device,
deploy platformTest apk to the device.
Rationale: This will be a smart default for what to do when a
Maven module of <packaging>android:apk:platformTests</packaging> is
run with "mvn integration-test".


-------------------------------------------------------------------
(almost) EVERYTHING CONFIGURABLE
-------------------------------------------------------------------

10. Introduce many more configuration parameters. For example
source directories and paths for res, assets, src and more. Review
naming of current and new parameters, so that they are consistent and
easy to understand.
Rationale: Users should be able to configure as many things
regarding how the plugin works with the android sdk tools as possible
directly in the pom, without having to file issues and waiting for us
to implement specific features.


-------------------------------------------------------------------
EFFICIENT DOCUMENTATION MAINTENANCE
-------------------------------------------------------------------

11. Combine documentation to one (1) place, and refer to the
central place from any other places.
Current documentation can be found at:
http://code.google.com/p/masa/wiki/GettingStarted
http://code.google.com/p/masa/source/browse/trunk/README.txt
Rationale: "DRY / Don't Repeat Yourself" - less documentation
copies to maintain.

[Vlad Skarzhevskyy]

As to EFFICIENT RELEASE MANAGEMENT I can offer to build masa maven
plugins using cruisecontrol and publish the SNAPSHOT as we do with
http://snapshot.microemu.org/ repository here http://repository.pyx4j.com/maven2-snapshot
for url we can select a different one if you own jvending.org.

I am already maintaining the build of j2me-maven-plugin, bluecove and
other projects that I'm participating in on my server see
http://pyx4j.com/cruisecontrol-public/.
I hope that traffic would not be overwhelming after addition of masa.

Also why don't you publish the plugins in central maven repository?
You probably need to own a domain jvending.org for this. As the
alternative you can always fallback to <groupId>com.google.code.masa</
groupId>
I can also offer my help with setting up the rsync for the masa group
once the groupId is clarified.

Regards
Vlad