Requirements Addons submission

[shazada]

What are the requirements of the Addons submission?
We shouldn't be keeping the requirements too high as then probably most of the addons should be rewritten.

My requirements:

1. Sourcecode: SVN or Github
2. Build: Maven or ANT
3. Distribution: Installable jar file. (I personally hate amp files, too much overhead and with the new Maven SDK coming it shouldn't be too much problem to have both.)
4. Runnable version: 4.2.f (I'd like 5.0.a, but it's a too much beta version and a couple of simple things aren't working. So I guess we'll wait till 5.0.b/c)

[AFaust]

Seems you beat me to creating this issue - started to summarize feedback on my suggestion yesterday but decided to drop it and just go ahead with issues on my way to work to work today.

First of all, I think it is - to some degree - necessary to make some distinctions for requirements on "extension addons" (installable into Alfresco) and "tooling addons" (external).

• Source code: I agree, the source should be accessible, but I don't want to require SVN or GitHub. Why would an addon be worth less for the community if it uses Mercurial?
• Build: Again, I don't want to force the use of a specific tooling. BUT if an addon is not provided as a versioned release binary, it should have build automation that is accepted within the community - which at this point primarily refers to Maven. ANT might be an accepted legacy tool.
• Distribution: Either one of the accepted / possible artefact formats for installing an addon should do. That means JAR and/or AMP. Excluding AMP would not be consistent with the status of the de-facto official standard, even if apparently most of the active / vocal community members hate it. (As always I have to state that for me personally, it is 100% the other way - so far, that I would even fork projects to move them to AMP.)
• Runnable version: Agree with 4.2.f at this point

Additional requirement suggestions:

• Documentation / How-to-start: Must be sufficient to successfully install and / or use the addon without debugging, modification or technical errors unrelated to user input
• Environment ("tooling addons"): Must clearly state the supported environment, dependencies and potentially required PATHs to execute / use
• Environment ("extension addons"): If addon adds any kind of UI (fragments), it must support at least one of the supported browsers in a recent version (the term "browsers" excludes Internet Explorer, which is only a "legacy web client")
• Environment ("extension addons"): If addon adds any kind of UI (fragments), it should support at least a recent version of the supported legacy web client. I nominate IE 10 as reference and due to lack of an allergy, would be willing to test it (not debug it).
• Licensing: An addon may not be required to be licensed under any of the official / accepted FOSS licenses, but for us to include it in any listing it must at least allow evaluation and royalty-free use for non-commercial purposes. If an addon should be included in the custom edition, it must allow royalty-free re-distribution, must not force us to place our entire edition under the same license and must not conflict with any other license of addons we include (as well as the basic license of Alfresco CE).

And before I finish, I have to apologize: I can't really keep myself short in text...

[hi-ko]

@AFaust thanks a lot for that suggestion. I totally agree.
Things I'd like to add:

• We should define something like a support version range to respect that most companies only upgrade once a year (so for now we should allow 5.0.a to be certified but expect 4..2.f for honeycomb)
• Documentation: We should expect at least a minimal documentation
  • Admin Guide / Install Guide with dependencies
  • User Guide

Our dependencies discussion should include the option to build up a public model repository. One of the disadvantages of Alfresco is the lack of best practice models for real use cases. And if there are some included in addons they often interfere with other solutions/modules (e.g. email handling). If we can build up a model repository with an apache like license we can create synergies

[shazada]

@AFaust No problem. About the AMP/JAR mechanism, I still think we should choose one. I mean developing your project as AMP is very different than a JAR. I mean it's ok that Alfresco has multiple ways to develop one, but we should still state which is the preferred one. We don't have to choose right now, but let's discuss this with Alfresco and let them state it.

So for now, we accept both: JAR & AMP.

As for Environment: I'd state it should support Firefox & Google Chrome. I understand that IE is used a lot, but to state that it works flawlessly on 3 browers is a bit too much. Even Alfresco doesn't always test everything on IE, so the product could have bugs but the Addon shouldn't.

Btw, I know a lot MAC developers, they can't even really test on IE without a VMWARE. So let's keep it light, and IE10 is a nice to have.

[AFaust]

By using "should" instead of "must" I wanted to soften the IE requirement. All in all, I wanted to express we should require support of one standards-compliant browser (either one of Firefox, Chrome or other non-IE) and encourage support of a legacy web client version.
I don't think that we will ever be able to claim / guarantee that an addon works "flawlessly" on any browser / legacy web client - as I stated in the mailing list, I don't want us to be a replacement for QA by the addon developer. But it should be simple to test it and state that our evaluation did not find issues with it.

Even as a Windows-based developer, I exclusively use VMWare images to test IE. IE relevance and difficulty for devs are just the state of things no matter how much I loathe the very existence of that product.

For now, let's consider IE 10 an encouraged "nice to have" and not a formal requirement.

[shazada]

Agreed!

[marsbard]

I believe I'm in agreement with all Axel's points above. I want to add a couple more points.

I'm not keen to track the 5.0.x series unless we can clearly show that we have enough capacity to do it. If we do then fine, but I would hate to see other tasks suffer because a lot of effort is being expended tracking bugs in 5.0.x. If some company wanted to sponsor OOTB for this effort I might be of a different opinion (although we have decidedly not come to a decision about funding the organisation commercially)

I think we should make it a requirement for addons that they have a test suite. Whether this is done by the original developer or us there should be at least some junit integration tests and if there is UI involved, some selenium tests. A bug should not be closed without the addition to the suite of a test or set of tests that show the bug being fixed. I'm not suggesting 100% coverage or anywhere near it, but enough of a basic suite that we can do automated builds from the start and then improve on those builds as we proceed.

[marsbard]

I accidentally closed this issue and I'm not sure how to reopen it >.<

Sorry!

[hi-ko]

not to change anything but please keep in mind: independant from personal preferences the modules/addons are meant to be used by end users and these guys use for > 50% IE (I would bet > 70%)
It would be a pitty if the world thinks the OOTB stuff works only on developer machines ...

[douglascrp]

Heiko, I agree with you.
That's the reality here in Brazil.

Douglas C. R. Paes

"D__one is better than perfect_"_
Zuckerberg

On Tue, Aug 26, 2014 at 10:39 AM, Heiko Robert notifications@github.com
wrote:

not to change anything but please keep in mind: independant from personal
preferences the modules/addons are meant to be used by end users and these
guys use for > 50% IE (I would bet > 70%)
It would be a pitty if the world thinks the OOTB stuff works only on
developer machines ...

—
Reply to this email directly or view it on GitHub
#2 (comment).

[angelborroy]

IE10 would be enough: it's the last supported by Microsoft and it have some kind of support for HTML5.

On the other hand, shall we propose some template for GitHub or SVN for addons? It would be nice (even for developers) to find some clear structure on every project.

Regarding JAR & AMP, I prefer to use AMP because of its better integration with other addons and modules. Shall we write some tutorial on working with Alfresco instances having both AMP and JAR modules?

[shazada]

If you google on usage browsers 2014 then every chart is different. A quick peak on the Wiki http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
You'll see (average) 1st Chrome, 2nd IE (no version stated), 3rd Firefox, etc.
The problem is with IE is the version, IE 11 will break stuff you've developed for IE 10 (look at Alfresco).

Sure the majority is maybe on IE, but that's version IE 7 till IE 11. Then we need a lot of effort to keep everything neat and clean and working on all versions. I'm sorry but I'm not going to spend my precious time to fix stuff on IE, if anyone wants to do it that's good!

We can assign testing in IE version to certain persons and everyone is happy :).