[discuss][samples] Ease of access

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[discuss][samples] Ease of access

Robert Munteanu-2
Hi,

I think that our samples could do with a little more usability. They
are fine as code samples, but sometimes fail short when trying them
out:

- missing configuration - usually loginAdmin whitelist
- extra bundle dependencies
- dependencies on SNAPSHOT/unreleased bundles

I'm not making any judgements on the usefulness or code quality, just
on how easy they are to load into a Sling launchpd.

I would like to propose some ease of access requirements for the
samples:

- build succeeds ( D'oh, but we have a sample build that's been failing
for some time )
- no SNAPSHOT dependencies ( we want users to be able to build without
adding extra repositories )
- no configuration required
- no non-default bundles required ( should deploy in the default
Launchpad )

The reason for adding these requirements is that they should be
immediately accessible and useful for our users. Asking them to chase
configurations and other bundles, especially when just starting out
with Sling, is too much in my opinion.

I'm not suggesting that we remove modules which don't satisfy these
criteria, just that we work towards that and ask more of any new
potential samples.

Thoughts?

Robert
Reply | Threaded
Open this post in threaded view
|

Re: [discuss][samples] Ease of access

chrismillar
I think this is a good start for criteria of acceptance (or moving to
attic).

I'd add a README.md with the supported version of Sling and basic build and
usage instructions. A user should be able to understand why they want to
install the sample just from the README.

It might be a good idea to look at overlap for various samples. If one
sample focuses on Sling Models, another sample should focus on OSGi,
Thymeleaf, Provisioning, or CA Configs. If samples could be cut down, they
may be easier to maintain going forward.

• It builds
• No snapshot dependencies
• No configuration
• No extra bundles
• A decent README
• Doesn't re-tread too much ground of another sample.

On Mon, Oct 2, 2017 at 2:17 PM, Robert Munteanu <[hidden email]> wrote:

> Hi,
>
> I think that our samples could do with a little more usability. They
> are fine as code samples, but sometimes fail short when trying them
> out:
>
> - missing configuration - usually loginAdmin whitelist
> - extra bundle dependencies
> - dependencies on SNAPSHOT/unreleased bundles
>
> I'm not making any judgements on the usefulness or code quality, just
> on how easy they are to load into a Sling launchpd.
>
> I would like to propose some ease of access requirements for the
> samples:
>
> - build succeeds ( D'oh, but we have a sample build that's been failing
> for some time )
> - no SNAPSHOT dependencies ( we want users to be able to build without
> adding extra repositories )
> - no configuration required
> - no non-default bundles required ( should deploy in the default
> Launchpad )
>
> The reason for adding these requirements is that they should be
> immediately accessible and useful for our users. Asking them to chase
> configurations and other bundles, especially when just starting out
> with Sling, is too much in my opinion.
>
> I'm not suggesting that we remove modules which don't satisfy these
> criteria, just that we work towards that and ask more of any new
> potential samples.
>
> Thoughts?
>
> Robert
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss][samples] Ease of access

Carsten Ziegeler
In reply to this post by Robert Munteanu-2
Samples can also use the provisioning model, like the Slingshot sample.
With the current model it's possible to create a "mar" file (a zip file
containing the prov model and the bundles) and we have an extension for
the OSGi installer to install these files. That extension is not
released yet.

But in general I agree :)

Regards

Carsten


Robert Munteanu wrote

> Hi,
>
> I think that our samples could do with a little more usability. They
> are fine as code samples, but sometimes fail short when trying them
> out:
>
> - missing configuration - usually loginAdmin whitelist
> - extra bundle dependencies
> - dependencies on SNAPSHOT/unreleased bundles
>
> I'm not making any judgements on the usefulness or code quality, just
> on how easy they are to load into a Sling launchpd.
>
> I would like to propose some ease of access requirements for the
> samples:
>
> - build succeeds ( D'oh, but we have a sample build that's been failing
> for some time )
> - no SNAPSHOT dependencies ( we want users to be able to build without
> adding extra repositories )
> - no configuration required
> - no non-default bundles required ( should deploy in the default
> Launchpad )
>
> The reason for adding these requirements is that they should be
> immediately accessible and useful for our users. Asking them to chase
> configurations and other bundles, especially when just starting out
> with Sling, is too much in my opinion.
>
> I'm not suggesting that we remove modules which don't satisfy these
> criteria, just that we work towards that and ask more of any new
> potential samples.
>
> Thoughts?
>
> Robert
>
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [discuss][samples] Ease of access

Karl Pauls
In reply to this post by Robert Munteanu-2
On Mon, Oct 2, 2017 at 10:17 PM, Robert Munteanu <[hidden email]> wrote:

> Hi,
>
> I think that our samples could do with a little more usability. They
> are fine as code samples, but sometimes fail short when trying them
> out:
>
> - missing configuration - usually loginAdmin whitelist
> - extra bundle dependencies
> - dependencies on SNAPSHOT/unreleased bundles
>
> I'm not making any judgements on the usefulness or code quality, just
> on how easy they are to load into a Sling launchpd.
>
> I would like to propose some ease of access requirements for the
> samples:
>
> - build succeeds ( D'oh, but we have a sample build that's been failing
> for some time )
> - no SNAPSHOT dependencies ( we want users to be able to build without
> adding extra repositories )
> - no configuration required
> - no non-default bundles required ( should deploy in the default
> Launchpad )
>
> The reason for adding these requirements is that they should be
> immediately accessible and useful for our users. Asking them to chase
> configurations and other bundles, especially when just starting out
> with Sling, is too much in my opinion.
>
> I'm not suggesting that we remove modules which don't satisfy these
> criteria, just that we work towards that and ask more of any new
> potential samples.
>
> Thoughts?

+1

Maybe we should require some kind of reasonable time/version note
along the lines of "This example has been developed for Sling 9" -
that way, users would have at least a rough handle on whether they are
looking at something that might be outdated. Just a thought...

regards,

Karl

> Robert



--
Karl Pauls
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [discuss][samples] Ease of access

Robert Munteanu-2
On Wed, 2017-10-04 at 00:53 +0200, Karl Pauls wrote:

> On Mon, Oct 2, 2017 at 10:17 PM, Robert Munteanu <[hidden email]>
> wrote:
> > Hi,
> >
> > I think that our samples could do with a little more usability.
> > They
> > are fine as code samples, but sometimes fail short when trying them
> > out:
> >
> > - missing configuration - usually loginAdmin whitelist
> > - extra bundle dependencies
> > - dependencies on SNAPSHOT/unreleased bundles
> >
> > I'm not making any judgements on the usefulness or code quality,
> > just
> > on how easy they are to load into a Sling launchpd.
> >
> > I would like to propose some ease of access requirements for the
> > samples:
> >
> > - build succeeds ( D'oh, but we have a sample build that's been
> > failing
> > for some time )
> > - no SNAPSHOT dependencies ( we want users to be able to build
> > without
> > adding extra repositories )
> > - no configuration required
> > - no non-default bundles required ( should deploy in the default
> > Launchpad )
> >
> > The reason for adding these requirements is that they should be
> > immediately accessible and useful for our users. Asking them to
> > chase
> > configurations and other bundles, especially when just starting out
> > with Sling, is too much in my opinion.
> >
> > I'm not suggesting that we remove modules which don't satisfy these
> > criteria, just that we work towards that and ask more of any new
> > potential samples.
> >
> > Thoughts?
>
> +1
>
> Maybe we should require some kind of reasonable time/version note
> along the lines of "This example has been developed for Sling 9" -
> that way, users would have at least a rough handle on whether they
> are
> looking at something that might be outdated. Just a thought...

Sounds good, and not too much effort.

Robert