Re: [site] Simplifying publishing process

[Robert Munteanu]

On Wed, 2017-10-04 at 18:28 +0200, Konrad Windszus wrote:
> Sorry, I missed the point that web sites can only be published if the
> source files are in Git [1].
> If I understand correctly the only thing that the maven-scm-publish-
> plugin would do is committing the target site to the asf-branch (what
> we currently need to do manually).

Yes, that's what I'm working on.

> So for me 1 & 2 are not mutually exclusive options, but 2 makes 1
> actually a lot easier, because then 1 is only a simple Maven goal.

Exactly.

Robert

> 
> Otherwise the Jenkins job would need to do those SCM operations
> manually.
> 
> [1] - https://blogs.apache.org/infra/entry/git_based_websites_availab
> le
> 
> > Am 04.10.2017 um 16:26 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > On Wed, 2017-10-04 at 12:16 +0200, Konrad Windszus wrote:
> > > > On 4. Oct 2017, at 12:11, Bertrand Delacretaz <bdelacretaz@apac
> > > > he.o
> > > > rg> wrote:
> > > > 
> > > > On Wed, Oct 4, 2017 at 12:07 PM, Konrad Windszus <konrad_w@gmx.
> > > > de>
> > > > wrote:
> > > > > ...I prefer 2 to not pollute the Sling Site Git repo with
> > > > > generated artifacts...
> > > > 
> > > > But it's *very* useful to be able to see the diffs of the
> > > > published
> > > > content before pushing them live.
> > > 
> > > Once we fixed all bugs in our templates, the diff on the MD
> > > source
> > > files is IMHO enough.
> > 
> > 
> > I am not sure how 1 would pollute the git repo ... The process
> > right
> > now is to build the HTML files and resync the asf-site branch with
> > the
> > output.
> > 
> > But anyway I think that having a Jenkins job that pushes every
> > change
> > on the master branch automatically using the maven-scm-publish
> > plugin
> > would be nice.
> > 
> > So I would first implement 2) and then 1). And of course we can
> > still
> > preview changes locally, for larger changes.
> > 
> > How does that sound?
> > 
> > Robert
> 
> 

Re: [Site] OId /site redirects missing

[Robert Munteanu]

On Fri, 2017-10-06 at 15:37 +0200, Konrad Windszus wrote:
> The very old Sling site was at .../site/ A list of permanent
> redirects to the new pages was maintained at http://svn.apache.org/vi
> ewvc/sling/site/trunk/content/site/.htaccess?view=markup. With the
> migration to JBake that redirect list was not taken over, although
> the redirect URLs should still work. Is that an oversight or
> deliberately done? I would be in favour of including that .htaccess
> file even in our new website as it doesn't do any harm and might
> still help some users working with very old links. WDYT?
> 
> Konrad

Fixed in https://github.com/apache/sling-site/commit/b6aaf0c681ce5f2496
1bafd0af50f933bca961f7 , publish in progress.

Robert

Re: [01/56] [partial] sling-site git commit: Whitespace changes, not sure where those come from but I think there's no actual content changes

[Robert Munteanu]

Hi Bertrand,

On Fri, 2017-10-06 at 09:26 +, bdelacre...@apache.org wrote:
> -
> \ No newline at end of file
> +

I introduced these changes when deploying via the Maven plugin. I
assumed that they are no big deal since when deploying with the plugin
they did not change anymore.

Might need some tweaking in terms of the maven plugin or in a local
config, not sure about that, see also [1].


[1]: https://help.github.com/articles/dealing-with-line-endings/

[NOTICE] Getting ready to start the SVN → Git migration (was: Git migration - final checks)

[Robert Munteanu]

On Fri, 2017-09-29 at 09:37 +0200, Robert Munteanu wrote:
> Unless we have objections or open issues, I will start the migration
> on
> Monday October the 9th ( not sure of the time, but as soon as
> possible
> in the GMT+2 time zone ).

Given that infra has just enabled the gitbox setup for Apache I'm going
to start the migration process in the next couple of hours.

I will start with bulk creating the repositories, but please hold off
all SVN commits unless they are urgent.

As a heads-up, github pushes require you to link your ASF and Github
IDs as well as enable 2FA on Github before you can commit https://gitbo
x.apache.org/setup/ .

Thanks,

Robert

Re: [NOTICE] Getting ready to start the SVN → Git migration (was: Git migration - final checks)

[Robert Munteanu]

On Sun, 2017-10-08 at 20:13 +0300, Robert Munteanu wrote:
> On Fri, 2017-09-29 at 09:37 +0200, Robert Munteanu wrote:
> > Unless we have objections or open issues, I will start the
> > migration
> > on
> > Monday October the 9th ( not sure of the time, but as soon as
> > possible
> > in the GMT+2 time zone ).
> 
> Given that infra has just enabled the gitbox setup for Apache I'm
> going
> to start the migration process in the next couple of hours.
> 
> I will start with bulk creating the repositories, but please hold off
> all SVN commits unless they are urgent.
> 
> As a heads-up, github pushes require you to link your ASF and Github
> IDs as well as enable 2FA on Github before you can commit https://git
> bo
> x.apache.org/setup/ .

A side effect is that pushes via HTTPs now need to use a personal
access token instead of your github password.

See [1] for details. But hey, first direct push to Github :-)

  https://github.com/apache/sling-site/commit/1f6b3275bbece669b3b62ea8b
8dbed235649c057

(Yes, I also made a typo. But that doesn't matter much)

Robert


[1]: https://help.github.com/articles/providing-your-2fa-authentication
-code/#when-youll-be-asked-for-a-personal-access-token-as-a-password

Re: [VOTE] Release Apache Sling Context-Aware Configuration Impl 1.4.6

[Robert Munteanu]

On Wed, 2017-10-04 at 09:57 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [NOTICE] Getting ready to start the SVN → Git migration (was: Git migration - final checks)

[Robert Munteanu]

On Sun, 2017-10-08 at 23:27 +0200, Konrad Windszus wrote:
> Thanks Robert for the effort. The ticket with Infra [0] is still in
> the wrong status though (waiting for user). Can you put it back to
> status „waiting for infra“?
> Hopefully this will speed up things.

Thanks for noticing, did that now.

Robert

Re: [NOTICE] Getting ready to start the SVN → Git migration (was: Git migration - final checks)

[Robert Munteanu]

The migration is _suspended_ until further notice. We hit a minor issue
where the dot ('.') character is filtered out from the repository name.
  
Since this breaks our naming convention I've chosen not to perform the
migration now and wait until infra (hopefully) relaxes the repository
name checks. More details at [1] if you're interested.

The good news is that I got the repo creation script right and only
created 3 incorrect repositories, which is kind of ok I guess :-)

As soon as the repository name checks are corrected I will re-run the
migration scripts. I plan to do this after 21:00 in the
Europe/Bucharest time zone, please complain is this gets in your way
somehow.

Thanks,

Robert

[1]: https://issues.apache.org/jira/browse/INFRA-15229

[samples] Moving some samples to attic

[Robert Munteanu]

Hi,

I did a quick pass over the existing samples. I think these samples
should be relevant to our users, and they are a whole category of
learning tools.

I think some are not as useful as they were when first included
I am not too familiar with all of them, so I could use others double-
checking my findings.

I've created a wiki page with a proposal to move some modules to the
attic, following the template of the first attic move.

  https://cwiki.apache.org/confluence/display/SLING/Sample+projects+rev
iew+and+move+to+attic+-+October+2017

Please review the modules and mention if you see any modules that
should not be moved or if you have more modules that should be moved.

I plan to make the move to attic at the end of the week, before
starting the Git migration.

Thanks,

Robert

[discuss][samples] Ease of access

[Robert Munteanu]

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

Re: [RT] Updates to the provisioning model

[Robert Munteanu]

On Tue, 2017-10-03 at 11:52 +0200, Carsten Ziegeler wrote:
> > 2. Reading the section on configuration merging, it is not clear to
> > me
> > if merging is merging of values or overriding of values.
> > 
> > Consider
> > 
> > 
> > feature 1:
> > 
> > com.foo.bar.Service
> >prop1="A"
> >prop2="B"
> > 
> > feature 2:
> > 
> > com.foo.bar.Service
> >prop1="C"
> > 
> > 
> > After the merge, will the configuration define the prop2 property? 
> 
> Yes, values get overwritten.

Is there any way of removing a configuration property once it's defined
in a feature?

Robert

Re: Bundle Documentation: Readme in Bundle Repo vs MD in Site Repo

[Robert Munteanu]

On Wed, 2017-10-04 at 10:01 +0200, Konrad Windszus wrote:
> > On 4. Oct 2017, at 09:57, Robert Munteanu <romb...@apache.org>
> > wrote:
> > 
> > On Tue, 2017-10-03 at 17:03 +0200, Konrad Windszus wrote:
> > > > On 3. Oct 2017, at 16:35, Bertrand Delacretaz <bdelacretaz@apac
> > > > he.o
> > > > rg> wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On Tue, Oct 3, 2017 at 3:50 PM, Konrad Windszus <konrad_w@gmx.d
> > > > e>
> > > > wrote:
> > > > > ...I think we also once discussed on the mailing list where
> > > > > to
> > > > > put bundle documentation: either in the readme or in the site
> > > > > itself...
> > > > 
> > > > Now that we have complete control over the website we might
> > > > generate
> > > > http://sling.apache.org/documentation/bundles.html (or part of
> > > > it)
> > > > using the GitHub API, or the module list that we use for
> > > > Jenkins,
> > > > and
> > > > mostly use the module's README.md from now on.
> > > 
> > > That sounds really good.
> > > @Robert: Would it be possible to maintain the module list as
> > > separate
> > > JSON file (currently contained in
> > > https://svn.apache.org/repos/asf/sling/trunk/tooling/jenkins/crea
> > > te_j
> > > obs.groovy).
> > 
> > My plan is to access the repositories using the Sling API rather
> > than
> > define a big list which can get out of date.
> 
> I guess you mean GitHub API, right :-)?

Right :-)

Re: [RT] Updates to the provisioning model

[Robert Munteanu]

On Wed, 2017-10-04 at 10:01 +0200, Carsten Ziegeler wrote:
> Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten
> Ziegeler wrote:
> 
> > > > 2. Reading the section on configuration merging, it is not
> > > > clear to
> > > > me
> > > > if merging is merging of values or overriding of values.
> > > > 
> > > > Consider
> > > > 
> > > > 
> > > > feature 1:
> > > > 
> > > > com.foo.bar.Service
> > > >prop1="A"
> > > >prop2="B"
> > > > 
> > > > feature 2:
> > > > 
> > > > com.foo.bar.Service
> > > >prop1="C"
> > > > 
> > > > 
> > > > After the merge, will the configuration define the prop2
> > > > property? 
> > > 
> > > Yes, values get overwritten.
> > 
> > Is there any way of removing a configuration property once it's
> > defined
> > in a feature?
> > 
> 
> Yes, if a feature is includes other features, the include instruction
> can have any number of removals.
> So you can remove properties before, bundles etc.


So I guess we have most (or even all) annoyances from the provisioning
model covered, which is great.

Thanks,

Robert

Re: Bundle Documentation: Readme in Bundle Repo vs MD in Site Repo

[Robert Munteanu]

On Tue, 2017-10-03 at 17:03 +0200, Konrad Windszus wrote:
> > On 3. Oct 2017, at 16:35, Bertrand Delacretaz  > rg> wrote:
> > 
> > Hi,
> > 
> > On Tue, Oct 3, 2017 at 3:50 PM, Konrad Windszus 
> > wrote:
> > > ...I think we also once discussed on the mailing list where to
> > > put bundle documentation: either in the readme or in the site
> > > itself...
> > 
> > Now that we have complete control over the website we might
> > generate
> > http://sling.apache.org/documentation/bundles.html (or part of it)
> > using the GitHub API, or the module list that we use for Jenkins,
> > and
> > mostly use the module's README.md from now on.
> 
> That sounds really good.
> @Robert: Would it be possible to maintain the module list as separate
> JSON file (currently contained in
> https://svn.apache.org/repos/asf/sling/trunk/tooling/jenkins/create_j
> obs.groovy).

My plan is to access the repositories using the Sling API rather than
define a big list which can get out of date.

The 'canonical' way of doing this is by accessing https://api.github.co
m/orgs/${github_org}/repos and filtering based on the repo name.

> 
> Then we could easily use it for this purpose as well.
> The only question would be, when and how to trigger the update.
> 
> Also we would have two different possibilities here:
> 1. Just link towards the readme.md (we must link to Github though, as
> Apache's Gitbox doesn't seem to be able to render the HTML from the
> MD, compare with https://gitbox.apache.org/repos/asf?p=nutch.git;a=bl
> ob;f=README.md;h=3aed205beb13d5b76c257d192d6c23d94669be35;hb=HEAD)
> 2. Generate the HTML page within the Sling site for each found
> readme.
> 
> I would rather be in favour of option 2 though, as otherwise the
> readme link would only point towards Github, but of course then the
> updating issue is even more interesting...

Option 2 sounds good to me as well. I am not sure though, as Bertrand
already mentioned, that we can rely on the README.md format rendering
100% as expected in a different context.

What we could do is:

- always keep the documentation in sling.apache.org
- add a deep link from the README.md to the specific documentation page
on sling.apache.org .

Thanks,

Robert

Re: [discuss] Launchpad user experience

[Robert Munteanu]

On Wed, 2017-10-04 at 00:43 +0200, Karl Pauls wrote:
> On Tue, Oct 3, 2017 at 4:37 PM, Bertrand Delacretaz
>  wrote:
> > On Tue, Oct 3, 2017 at 3:58 PM, Konrad Windszus 
> > wrote:
> > > ..."Sling Reference Distribution"
> > 
> > I like that, and the frontpage of that distribution can specify
> > that
> > for most uses people will want to customize the provisioning model.
> 
> Hm, in that case, wouldn't it be better to just call it:
> 
> "Sling Base" (or possibly, "Sling Base Distribution")
> 
> I'm terrible with naming so YMMV - but, to me that would make it
> clear
> that I'm getting the minimum and are supposed to extend it...

We already have 'Sling Distribution' [1] and this would make things
confusing IMO.

I think Eugen made some good suggestions in his reply:

- bootstrap ( although also a bit overloaded due to [2] )
- loader
- starter 

Out of these starter looks good to me - it really is a 'starter' as it
both:

- works as an appetizer for all things Sling, before you really get
your hands dirty
- allows you to start quickly with Sling

I would even suggest Sling Quick-Start, but that's again overloaded due
to AEM.

Robert

[1]: https://sling.apache.org/documentation/bundles/content-distributio
n.html
[2]: http://getbootstrap.com/

Re: Bundle Documentation: Readme in Bundle Repo vs MD in Site Repo

[Robert Munteanu]

On Wed, 2017-10-04 at 11:49 +0200, Bertrand Delacretaz wrote:
> Hi,
> 
> On Wed, Oct 4, 2017 at 9:57 AM, Robert Munteanu <romb...@apache.org>
> wrote:
> > ...The 'canonical' way of doing this is by accessing https://api.gi
> > thub.co
> > m/orgs/${github_org}/repos and filtering based on the repo name...
> 
> Note that this would require handling multiple pages, it looks like
> the max number of results is 200:
> 
> $ curl -s "https://api.github.com/orgs/apache/repos?page=1_page=2
> 00"
> > grep html_url | wc -l
> 
>  200
> $ curl -s "https://api.github.com/orgs/apache/repos?page=1_page=2
> 10"
> > grep html_url | wc -l
> 
>  200
> $ curl -s "https://api.github.com/orgs/apache/repos?page=2_page=2
> 10"
> > grep html_url | wc -l
> 
>  200
> 
> But otherwise grabbing that is easy in our Groovy templates,
> something like:
> 
> URL url = new URL("https://api.github.com/orgs/apache/repos?page=1
> r_page=100")
> def json = new groovy.json.JsonSlurper().parseText(url.text)
> json.each ( {
> it ->
> if(it.full_name.contains("struts")) {
> println it.html_url
> }
> })

I'll just paste here the chunks script I've used so far. I won't link
to it since it's in the 'not-sling' org which will go away next week.

github_org="not-sling"
project_prefix="sling-"
curl_args="$1"

page_count=$(curl ${curl_args} -sI https://api.github.com/orgs/${github
_org}/repos | grep 'Link: ' | tr ',' '\n' | grep 'rel="last"' |
sed  's/.*page=\([0-9][0-9]*\).*/\1/')

for page in $(seq 1 ${page_count}); do
for repo in $(curl ${curl_args} -s https://api.github.com/orgs/${gi
thub_org}/repos?page=${page} \
   | jq ".[] |  .name | match (\"${project_prefix}.*\") | .string"
| tr -d '"' | sort); do
# your processing here
done
done

We can consider either creating a shared script for it or have a single
job which periodically regenerates a JSON file with all the projects.

Robert

Re: [Site] Improving the main site

[Robert Munteanu]

On Wed, 2017-10-04 at 08:34 +0200, Bertrand Delacretaz wrote:
> Hi,
> 
> On Sat, Sep 30, 2017 at 12:09 PM, Carsten Ziegeler  org> wrote:
> > ...This would keep our main page fairly short and we just need to
> > improve
> > the introduction "Sling in 100 words"..
> 
> Here's my draft, feel free to tweak:
> 
> Apache Sling is a REST-based Web framework based on a hierarchical
> content tree. It maps incoming URLs to content resources in a simple
> and powerful way, based on the request's path, extension and optional
> selectors, fostering clean and meaningful URLs. Request processing is
> based on dynamically loaded scripts or Java servlets, with convention
> over configuration making it very simple to start with generic
> processing and gradually refine it during development. The very
> modular nature of Sling means you can replace most of its
> functionality by your own variants as needed, and easily build
> specialized server instances with just what you need.
> 
> Sling is used as the basis for some industrial strength content
> management systems, where the simplicity and robustness of its core
> shine.

Looks good to me.

Robert

Re: [discuss][samples] Ease of access

[Robert Munteanu]

On Wed, 2017-10-04 at 00:53 +0200, Karl Pauls wrote:
> On Mon, Oct 2, 2017 at 10:17 PM, Robert Munteanu <romb...@apache.org>
> 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

Re: [website] tag support added

[Robert Munteanu]

On Wed, 2017-10-04 at 12:34 +0200, Carsten Ziegeler wrote:
>  That's a great idea, thanks Bertrand
> 
> But :) can we maybe display the tags at some other place? At the top
> they move the real content some lines further down. Leaving less room
> for the page content.

We could add them at the bottom of the page for now. I was sort of used
to that from Wikipedia.

Robert

Misc Sling questions ( was: [discuss] Launchpad user experience)

[Robert Munteanu]

Hi Eugen,

On Tue, 2017-10-03 at 16:38 +0300, Ioan Eugen Stan wrote:
> Hi,
> 
> Great idea. How about Sling Starter/ Loader / Bootstrap ?
> 
> 
> Regarding building a real app with Spring I would like to go through

Ahem

s/Spring/Sling/ I assume :-)

> that process (be a guinee pig). We would like to use the content
> repository in a Saas like app using micro services.

(snip)

You might also be interested in the  'Internet Scale Content Management
with Apache Oak on Kubernetes' adaptTo talk [1] which looks relatively
close to your scenario.

> Some things that I would like to make test/know before going into
> production:
> 
> - reading and writing from multiple services works ok - check delay,
> caching, etc

You'll have to be more explicit about that. The DocumentNodeStore
documentation in Oak [2] should contain most of what you need to know.

You are probably interested in 'Background read' - DocumentMK
periodically picks up changes from other DocumentMK instances by
polling the root node for changes of _lastRev. This happens once every
second. That means that if something is changed on Instance A, Instance
B will see it in at most one second.

> - editing content via Composum works properly

To my knowledge, yes.

> - procedures on how to deploy content updates to production
> (FileVault
> maybe)
> - how to get content from production to staging to facilitate testing

Content packages are one way of doing that. Changes can either be
performed using Sling content distribution [3] or by using the Package
Manager APIs. As a package manager you can use the Composum one [4]
coupled with the wcm.io content-package-maven-plugin [5].

> - how to deploy and update our single page applications that consume
> our
> API

Again, you need to more specific here. Is a SPA deployed in Sling? Or
deployed externally and consuming Sling output?

At any rate, peregrine CMS [6] is a SPA built with vue.js on top of
Sling so you might want to check that out.

> - how to deploy/update translations for content

Everything is content, including translations :-) So what I wrote above
related to content deployments still stands. Also, just in case you
missed the reference page, the documentation for i18n support is at
[7].

> 
> I know I have quite specific needs that might not fit into general
> norms, but the needs are real and I am willing to document and share
> the
> process and all the code samples. All I need in return is some
> guidance.

Hopefully that gets you started. Feel free to come back with more
questions if needed.

Thanks,

Robert


[1]: https://adapt.to/2017/en/schedule/internet-scale-content-managemen
t-with-apache-oak-on-kubernetes.html
[2]: https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html
[3]: https://sling.apache.org/documentation/bundles/content-distributio
n.html
[4]: https://ist-software.atlassian.net/wiki/spaces/CMP/pages/46140125/
Package+Manager
[5]: http://wcm.io/tooling/maven/plugins/wcmio-content-package-maven-pl
ugin/
[6]: https://github.com/headwirecom/peregrine-cms
[7]: https://sling.apache.org/documentation/bundles/internationalizatio
n-support-i18n.html

Re: Canonical URL for Git

[Robert Munteanu]

On Mon, 2017-10-09 at 11:22 +0200, Oliver Lietz wrote:
> > Also, pushing to github is a supported setup, this was why we
> > decided
> > to go with gitbox in the first place [1]. Pushing to the ASF repos
> > sort
> > of defeats the purpose of that.
> 
> why is making GitBox URLs the canonical ones (IMHO those URLs *are*
> the 
> canonical ones) defeating anything?

I am wary of pushing to different repositories since I am not 100%
certain of the stability of the dual master setup. If we push to just
one repo - github or gitbox - then we will not have any issues with
repositories getting out of sync.

Following that reasoning, we should only push to gitbox if we make that
the canonical URL, therefore we should discourage using Github as a
remote, including merging pull requests and any automation around
Github as a remote.

If we do that, then it makes no sense to move to gitbox and instead
move to read-only mirrors on Github and use git-wip as a system.

Thanks,

Robert

Re: [discuss][git] Repository names cannot contain dots

[Robert Munteanu]

On Mon, 2017-10-09 at 14:25 +, Stefan Seifert wrote:
> if the git repo names are still based on artifact id with only "."
> replaced by "-" i suppose this would be ok from my side.
> we mainly wanted to avoid to choose completely different naming
> schema which may be hard to guess if you have only the artifact id of
> a given bundle.

Right. Infra indicates that they can't support dots in repostiory
names:

> On our side, since we don't have any repos with periods, the overhead
for making sure it won't break things is a bit prohibitive.So for the
time being I don't think we can allow it.

This is from the hipchat room, don't know if there are any archives
available for it, pasting it here for completeness.

So it seems that we need to replace the dot with something. The dash (
'-' ) is a good option, unless someone else things otherwise I'm going
to go with the dash name.

E.g. instead of sling-org.apache.sling.api we'd have sling-org-apache-
sling-api .

Thanks,

Robert

Re: [discuss][git] Repository names cannot contain dots

[Robert Munteanu]

On Mon, 2017-10-09 at 14:54 +, Stefan Seifert wrote:
> > E.g. instead of sling-org.apache.sling.api we'd have sling-org-
> > apache-sling-api .
> 
> reading this we might also decide to omit the "org-apache-sling" part
> in here. otherwise all and every repo would start with "sling-org-
> apache-sling-".
> and it's still a clear rule.

We have some repos which don't follow that convention

- Maven toooling ( artifactId does not start with org.apache.sling )
- Various tools and scripts ( migrated as sling-tooling-scm and sling-
tooling-jenkins )
- Samples ( sling-samples )

So maybe it would be simpler to keep the artifactId where dots are
replaced by dashes.

Robert

[discuss][git] Repository names cannot contain dots

[Robert Munteanu]

Hi,

Well, word came back from infra that we can't use dots in the
repository names [1]. I asked about the reasoning for that but did not
yet get an answer.

The question is - what do we do now? Do we want to replace dots with
something else and live with a discrepancy between artifact ids and
repository names? Do we wait until we have better solution?

Thanks,

Robert


[1]: https://issues.apache.org/jira/browse/INFRA-15229?focusedCommentId
=16197034=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#comment-16197034

Re: Canonical URL for Git

[Robert Munteanu]

On Mon, 2017-10-09 at 11:21 +0200, Konrad Windszus wrote:
> > - account linking and personal access token generation are one-time
> > actions that take little time to perform
> 
> right, but at least for the sling-site case committing to gitbox is
> even less effort, because every committer already has HTTPS write
> access to that repo. I had some troubles with the linking because it
> seems that after enabling 2fa on Github there is a delay of up to 30
> minutes until the daemon picks up the change on ASF side.

Yes, that is documented at https://gitbox.apache.org/setup/ .

> > - making github the preferred push repository makes me more
> > confident
> > that we won't have any conflicts due to merging pull requests
> 
> not sure how ASF gitbox and Github are syncing exactly and what
> happens in case of conflicts. Do you have any source available which
> explains the process more in detail? Also to me it is not clear which
> URL to include there: SSH based or HTTPS based?

Unfortunately no, that this is part of why I support one definite
'master' git repo to use.

I would favour HTTPS as it's probably not filtered anywhere, whereas
SSH is sometimes blocked by firewalls.

> > - automation is more readily available with github rather than
> > gitbox
> > and we may choose to add more automation in the future
> 
> you are probably referring to the Github API for which there is no
> alternative on the ASF side. I agree with that as well. Also having
> SSH authentication available at Github is a big pro (but should not
> be required for publishing the sling site though)

Yes, agreed, we should not require SSH for publishing.

> 
> But please also consider the other points:
> > 
> > Also, pushing to github is a supported setup, this was why we
> > decided
> > to go with gitbox in the first place [1]. Pushing to the ASF repos
> > sort
> > of defeats the purpose of that.
> 
> Don't agree with that. Pushing to ASF repos does not prevent anyone
> from using the Github repos.
> It is just less obvious that you can also use Github.

That circles back to how stable we think the dual-master setup is. Yes,
we can try and use gitbox as a canonical repository and use Github as a
remote only when needed.

> 
> The main question to me is: how stable do we consider each of the two
> repos?
> IMHO the gitbox repo URL is much more stable as Github could
> theoretically end at any point in time the collaboration with the ASF
> and just would no longer provide that service for free. Modifying the
> documentation and poms afterwards would be a big hassle.
> 
> I guess providing Maven artifacts not only via Maven Central but
> primarily through the ASF dist server is a very similar requirement (
> http://www.apache.org/dev/release-publishing.html#distribution).
> What do others think?

My recollection is that the dual system is approved since a push to
Github is automatically replicated to ASF servers - the source still
lives on the ASF repos.

-

Anyway, my understanding of what we aim to do might be wrong and since
no one else seems to desire a canonical Github URL I'll switch the
sling-site repo to publish via gitbox later today or early tomorrow.

Robert

Re: Canonical URL for Git

[Robert Munteanu]

On Tue, 2017-10-10 at 12:31 +0200, Bertrand Delacretaz wrote:
> On Tue, Oct 10, 2017 at 12:26 PM, Robert Munteanu <romb...@apache.org
> > wrote:
> > ...Together with Konrad's notes on the Maven release plugin this
> > makes a
> > pretty strong case for using gitbox as the canonical URL
> > everywhere...
> 
> But we do other things much more often than releases, so it's hard to
> give up the convenience...
> 
> I don't have a better suggestion right now but I'm sure we can find a
> convenient way to use GitHub for day-to-day work and gitbox for
> releases. A Maven profile maybe?
> 
> -Bertrand

It should be fine to clone from and push to GitHub, but release from
GitBox. After all, the commit hashes are the same and tags will be
propagated to GitBox instantaneously.

Or at least we'll know once we run the first release :-)

Robert

Re: Canonical URL for Git

[Robert Munteanu]

On Tue, 2017-10-10 at 12:09 +0200, Bertrand Delacretaz wrote:
> Hi,
> 
> On Tue, Oct 10, 2017 at 12:06 PM, Konrad Windszus 
> wrote:
> > ...I think as long as the ASF is fine with this I would also rather
> > promote the usage of Github instead
> > of gitbox (because of its richer feature set) and therefore I am
> > finally convinced that entering the Github
> > SCM URL is fine there
> 
> I'm fine with that in general but cutting releases from ASF
> repositories is a strong requirement.
> 
> Worst case we could add instructions to our release process, using
> git
> diff to compare the ASF and GitHub repositories before cutting a
> release.

Hm, you're right and we should cut releases from the gitbox urls.

Together with Konrad's notes on the Maven release plugin this makes a
pretty strong case for using gitbox as the canonical URL everywhere.

Thanks,

Robert

Re: [git] Move testing/samples to samples?

[Robert Munteanu]

On Tue, 2017-10-10 at 09:53 +0200, Oliver Lietz wrote:
> On Monday 09 October 2017 21:57:34 Robert Munteanu wrote:
> > Hi,
> 
> Hi,
> 
> > Given that we're going to have a single samples repository, would
> > it
> > make sense to move the modules from under testing/samples under
> > samples/testing?
> > 
> > testing/samples/
> > 
> > > -- bundle-with-it
> > 
> > `-- module-with-it
> > 
> > I would also rename the artifact ids from
> > org.apache.sling.testing.samples.FOO to
> > org.apache.sling.samples.testing.FOO .
> 
> can we agree on common group id and package name for samples – at
> least for 
> unreleased and new samples?

I would suggest org.apache.sling.samples . We can also use
org.apache.sling.samples.testing for testing samples, but that's
optional for me, we can stick with one group id.


> Btw, why do we not create one repo per sample?

As noted at [1]: "having samples spread over multiple repositories will
make it harder for users to discover all of them"

Robert

[1]: https://cwiki.apache.org/confluence/display/SLING/Move+from+Subver
sion+to+Git

Re: [git] Move testing/samples to samples?

[Robert Munteanu]

On Tue, 2017-10-10 at 11:11 +0200, Oliver Lietz wrote:
> On Tuesday 10 October 2017 11:39:11 Robert Munteanu wrote:
> > On Tue, 2017-10-10 at 09:53 +0200, Oliver Lietz wrote:
> > > On Monday 09 October 2017 21:57:34 Robert Munteanu wrote:
> > > > Hi,
> > > 
> > > Hi,
> > > 
> > > > Given that we're going to have a single samples repository,
> > > > would
> > > > it
> > > > make sense to move the modules from under testing/samples under
> > > > samples/testing?
> > > > 
> > > > testing/samples/
> > > > 
> > > > > -- bundle-with-it
> > > > 
> > > > `-- module-with-it
> > > > 
> > > > I would also rename the artifact ids from
> > > > org.apache.sling.testing.samples.FOO to
> > > > org.apache.sling.samples.testing.FOO .
> > > 
> > > can we agree on common group id and package name for samples – at
> > > least for
> > > unreleased and new samples?
> > 
> > I would suggest org.apache.sling.samples . We can also use
> > org.apache.sling.samples.testing for testing samples, but that's
> > optional for me, we can stick with one group id.
> 
> +1
> 
> > > Btw, why do we not create one repo per sample?
> > 
> > As noted at [1]: "having samples spread over multiple repositories
> > will
> > make it harder for users to discover all of them"
> 
> I see – thanks, Robert (would have added a reactor and repo manifest
> for 
> samples instead).

The reasoning was be to not ask casual contributors to set up repo -
just check out the samples repo and be done with it.

Since we rarely ever release samples, multiple projects in one repo for
this particular case seems fine.

Robert

Re: Git migration - handling commits and PRs across multiple modules

[Robert Munteanu]

Hi Andrei,

On Mon, 2017-10-09 at 14:58 +, Andrei Dulvac wrote:
> Hi,
> 
> Sorry I'm asking this so late, I wasn't available when this
> discussion was
> at its peak.

Welcome to the discussion :-)

> 
> With the git extreme repo split, how will commits that touch two
> repos be
> handled? Or pull-requests? Would I have to open two PRs for a
> functionally-atomic change?

Well, a functionally atomic change should not IMO touch multiple
modules.

If you need to touch multiple modules then you perform multiple commits
or open multiple pull requests.

> How are projects that have reactors and SNAPSHOT dependencies going
> to work?

Just like they do before - the CI always builds and deploys snapshots
so each project will be independently buildable. It's been this way
since we switched to per-module Jenkins jobs.

> It feels to me that this strict one maven module per repo would
> introduce
> some artificial problems and besides git tags, I see no tangible
> advantage
> to doing so.

When working with 280 modules, simplicity is a great advantage :-) With
the (IMO rare) situation of needing to touch multiple modules in one
go, what other problems do you see with this approach?

Note that we will introduce a way of locally checking out all
repositories in a single directory so you will be able to work on a
single filesystem view.

> If it's a question of two-way referencing, the  tag in the pom
> file
> should be enough for anybody or any tooling.

Not sure what you mean by two-way referencing, can you elaborate on
that?

Thanks,

Robert

Re: Git migration - handling commits and PRs across multiple modules

[Robert Munteanu]

Hi Andrei,

On Mon, 2017-10-09 at 17:18 +, Andrei Dulvac wrote:
> On Mon, Oct 9, 2017 at 5:03 PM Robert Munteanu <romb...@apache.org>
> wrote:
> > 
> > > 
> > > With the git extreme repo split, how will commits that touch two
> > > repos be
> > > handled? Or pull-requests? Would I have to open two PRs for a
> > > functionally-atomic change?
> > 
> > Well, a functionally atomic change should not IMO touch multiple
> > modules.
> > 
> 
> What about coding in a feature that requires new API in a new module?
> Technically, yes, a "functionally-atomic" change can be broken down
> into
> two commits that justify themselves as self-standing, but it smells a
> bit
> like over-engineering. Would you create two PRs for such a change? Or
> add
> the API first, merge the PR, release the API module and then open a
> PR for
> the impl? Anyways, I really think what you mean makes sense, but
> sometimes
> it's not the reality, especially in modules that are not in
> maintenance
> mode.

You make one commit for the API module, one commit for the impl module.
You need to change the impl → api dependency to SNAPSHOT in either
scenario.

I may be biased by the fact that I have never encountered such a
situation while working on Sling, although I know they do exist :-) I
just don't see it as a scenario to optimize for.

> 
> > 
> > If you need to touch multiple modules then you perform multiple
> > commits
> > or open multiple pull requests.
> > 
> 
> But the PRs would share the jira issue description, would not be
> reviewable
> or testable separately and would have to be merged at the same
> time...

Yes, they would share Jira description. But yes, they would be
reviewable separately - APIs changes can be reviewed without looking at
the impl. One might argue that it's even healthier to do so to prevent
bikeshedding about implementation details but that's another issue :-)

And implementations + corresponding tests can be reviewed separately of
the API change, I don't see why not.

And since we only deploy releases to the launchpad this does not break
anything.

> > 
> > > How are projects that have reactors and SNAPSHOT dependencies
> > > going
> > > to work?
> > 
> > Just like they do before - the CI always builds and deploys
> > snapshots
> > so each project will be independently buildable. It's been this way
> > since we switched to per-module Jenkins jobs.
> > 
> 
> Got it. But wouldn't that make it very hard for local development?

Why would being able to build a single module be harder than having to
build multiple projects? Of course you can build multiple projects if
you want to, but that's not required by any means.

We plan to generate checkouts using google repo, as mentioned before.
There is a "groups" functionality which should allow you to only check
out some modules.

In the same way we generate this repo file, we can generate reactor
POMs. These poms can be inferred from naming conventions or from
predefined rules. However, it's best to keep the repos consistent - one
module per repository if we want to have such global approaches rather
than special-casing here and there.

> 
> > 
> > > It feels to me that this strict one maven module per repo would
> > > introduce
> > > some artificial problems and besides git tags, I see no tangible
> > > advantage
> > > to doing so.
> > 
> > When working with 280 modules, simplicity is a great advantage :-)
> > With
> > the (IMO rare) situation of needing to touch multiple modules in
> > one
> > go, what other problems do you see with this approach?
> > 
> 
> Local development (keeping track of logs, N number of the same
> operations
> to e.g. checkout branches, revert changes, etc.), github events. But
> they're all sort of related to the need to build/ deploy/ test more
> than
> one maven module at a time. Is it really that rare?

We have that scenario for Sling-wide changes, e.g. parent pom updates.
The good part i

> 
> 
> > Note that we will introduce a way of locally checking out all
> > repositories in a single directory so you will be able to work on a
> > single filesystem view.
> > 
> 
> I didn't expect anything less :) But that's extra tooling that would
> have
> to be maintained. But I guess you use something like gitslave or
> submodules, in which case it comes for free.

google repo is what we prototyped so far. Since we autogenerate them we
can autogenerate everything :-)

> > > If it's a question of two-way referencing, the  tag in the
> > > pom
> > > file
> > > should be enough for an

[git] Move testing/samples to samples?

[Robert Munteanu]

Hi,

Given that we're going to have a single samples repository, would it
make sense to move the modules from under testing/samples under
samples/testing?

testing/samples/
|-- bundle-with-it
`-- module-with-it

I would also rename the artifact ids from
org.apache.sling.testing.samples.FOO to
org.apache.sling.samples.testing.FOO .

Thanks,

Robert

Re: [NOTICE] Getting ready to start the SVN → Git migration

[Robert Munteanu]

On Fri, 2017-10-13 at 09:30 +, Stefan Seifert wrote:
> > > What I see is that when I try to go to
> > > https://lists.apache.org/list.html?us...@infra.apache.org, after
> > > authenticating, I end up on
> > > https://lists.apache.org/list.html?iss...@infra.apache.org
> > 
> > Just to make sure - did you authenticate with your ASF credentials?
> 
> yes, i did!
> (but i did not try to subscribe to the users@ list)
> 
> stefan
> 

I am not sure that is required - I am not subscribed. Maybe it's best
to ask infra :-) ? Quickest I guess woudl be http://infra.chat/ .

Robert

Re: Upgrade to Oak 1.7.9

[Robert Munteanu]

Hi Ian,

On Fri, 2017-10-13 at 10:51 +0100, Ian Boston wrote:
> Hi,
> I would like to upgrade Sling to depend on Oak 1.7.9 as it was just
> released. The patch be the same as [1] with 1.7.8 replaced by 1.7.9.
> 
> Any objections ?

No objections here.

Related to the pull request - is it required for bundles consuming
testing.paxexam to bump up their dependency version? I think they can
run their tests just fine on the old dependencies and in case of a
release of that module we don't need to wait for a release of
testing.paxexam.

I'm looking at 

- bundles/commons/contentdetection
- bundles/commons/metrics
- bundles/extensions/org.apache.sling.resource.presence
- bundles/scripting/core
- contrib/extensions/rewriter
- contrib/extensions/sling
- contrib/scripting/freemarker
- contrib/scripting/org.apache.sling.scripting.thymeleaf

Thanks,

Robert

Re: [VOTE] Release Apache Sling Bundle Resource 2.3.0

[Robert Munteanu]

On Fri, 2017-10-06 at 08:51 +0200, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release Apache Sling Starter Startup 1.0.0

[Robert Munteanu]

Hi,

On Fri, 2017-10-06 at 08:51 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> this is the first release of the Starter Startup Module for improved
> user experience of our Starter application.

When building I get the following bnd warning

[WARNING] Bundle
org.apache.sling:org.apache.sling.starter.startup:bundle:1.0.0 :
Bundle-Activator org.apache.sling.demo.startup.impl.Activator is being
imported into the bundle rather than being contained inside it. This is
usually a bundle packaging error

Which seems to be correct, as the Bundle-Activator is defined as
org.apache.sling.demo.startup.impl.Activator but is found in the bundle
at org.apache.sling.starter.startup.impl.Activator

Is this intended?

Thanks,

Robert

Should the maven-sling-plugin check if the bundle deployment was successful?

[Robert Munteanu]

Hi,

I was just wondering whether deploying a bundle with the Maven plugin
should also check if the bundle could be started. It would definitely
be helpful.

We technically have access to the bundle name and version from the jar
file and can use the the OSGi console REST APIs to poll for the bundle
state, for a bounded period of time.

Thoughts?

Robert

Re: [NOTICE] Getting ready to start the SVN → Git migration (was: Git migration - final checks)

[Robert Munteanu]

On Tue, 2017-10-17 at 08:47 +0200, Bertrand Delacretaz wrote:
> On Sun, Oct 8, 2017 at 7:13 PM, Robert Munteanu <romb...@apache.org>
> wrote:
> > ...I will start with bulk creating the repositories,..
> 
> I know this has been delayed, but when you do it, are you planning to
> add default tags on the repositories? If possible I suggest "apache,
> sling, apache-sling" as tags.

I didn't see any option to add tags so far at [1]. I would assume it's
not implemented, but that's something that needs to be clarified with
infra. 

I mentioned it in the users@infra discussion, but got no confirmation.
If it is not, we probably need to see how/if we can work on adding it.

[1]: https://gitbox.apache.org/setup/newrepo.html

Re: [VOTE] Release Apache Sling Scripting Core 2.0.50

[Robert Munteanu]

On Tue, 2017-10-17 at 07:53 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: Depending on Oak 1.7.x

[Robert Munteanu]

; > 
> > > > > closer
> > > > > > > to
> > > > > > > > > > 1.12.x the less the risk.
> > > > > > > > > > 
> > > > > > > > > > IIUC Oak have started to discuss the possibility of
> > > > > > > > > > branching
> > > > > 
> > > > > 1.8.x,
> > > > > > > > > which
> > > > > > > > > > makes 1.7.9 relatively close to that branch. That
> > > > > > > > > > said, I made
> > > 
> > > an
> > > > > API
> > > > > > > > > > change that appeared in 1.7.9 ;). It all depends on
> > > > > > > > > > the detail
> > > 
> > > in
> > > > > > > every
> > > > > > > > > > case. There are no rules that always work.
> > > > > > > > > > 
> > > > > > > > > > Best Regards
> > > > > > > > > > Ian
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 12 October 2017 at 16:28, Matt Ryan <oss@mvryan.
> > > > > > > > > > org> wrote:
> > > > > > > > > > 
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > > I’m curious to explore the reasoning behind the
> > > > > > > > > > > general
> > > 
> > > principle
> > > > > of
> > > > > > > > > only
> > > > > > > > > > > having dependencies on stable Oak releases.  Of
> > > > > > > > > > > course I
> > > > > 
> > > > > understand
> > > > > > > the
> > > > > > > > > > > importance of keeping the codebase on a solid
> > > > > > > > > > > foundation and
> > > 
> > > thus
> > > > > to
> > > > > > > > > want
> > > > > > > > > > > stable releases for dependencies.  My question
> > > > > > > > > > > is, what
> > > 
> > > exactly is
> > > > > > > > > meant by
> > > > > > > > > > > “stable”?
> > > > > > > > > > > 
> > > > > > > > > > > I expect we regard even-numbered minor versions
> > > > > > > > > > > in Oak as
> > > 
> > > stable
> > > > > > > > > releases
> > > > > > > > > > > because that’s how the Oak project refers to such
> > > > > > > > > > > releases.
> > > > > 
> > > > > Based on
> > > > > > > > > that
> > > > > > > > > > > reasoning, Oak 1.7.8 is unstable by
> > > > > > > > > > > definition.  I’d then argue
> > > > > 
> > > > > that
> > > > > > > if
> > > > > > > > > Oak
> > > > > > > > > > > were to change their versioning model (which I’m
> > > > > > > > > > > not proposing
> > > 
> > > -
> > > > > and
> > > > > > > I
> > > > > > > > > > > wouldn’t propose it here if I was proposing such
> > > > > > > > > > > a thing
> > > 
> > > anyway)
> > > > > such
> > > > > > > > > that
> > > > > > > > > > > a “stable” Oak release is defined by some other
> > > > > > > > > > > means (say, any
> > > > > > > 
> > > > > > > version
> > > > > > > > > > > that passes the entire test suite), Oak 1.7.10
> > > > > > > > > > > may be
> > > 
> > > considered
> > > > > > > stable
> > > > > > > > > -
> > > > > > > > > > > in which case the concern to rely

[git] Migration scheduled for 18 Oct, 22:00 CEST and final notes

[Robert Munteanu]

Hi,

The discussions with infra are settling and I would like to schedule
the migration for tomorrow evening at 22:00 CEST. I am not sure of the
"downtime", but hopefully it won't be more than a couple of hours.

Some final notes:

- there is no access to features that require administrative access to
the repos. That includes, but not limited to: travis integration,
setting descriptions, tags, certain kinds of bots.
- infra is ok with this migration, but is likely to be overwhelmed if
we are going to have requests that require manual intervention to our
200+ repositories. We are expected to assist ( e.g. by providing
scripts ) should too many repositories need attention or break
- there is at least one project that is scaling down its number of git
repositories (couchdb), mainly due to (quoting):

a) PRs on different repos for the same semantic change need unusual
   coordination to land, intermittent CI will break, or needs
   extra tooling.
b) Keeping main dependency list updated by hand is tedious (can be
   automated tho).
c) Doing branches/tags/releases synchronised across all repos is a
   pain (can be automated, but is an extra layer of hassle either way).

For me personally all of these are fine, and I expect that the
improvements brought by Git will offset the downsides. I want to make
sure though that everyone is aware of these and and considers that the
SVN to Git migration can proceed.

Please speak up if you find something of concern.

Thanks,

Robert

Re: Prototype of building github pull requests with Jenkins

[Robert Munteanu]

On Tue, 2017-10-17 at 12:28 +0100, Ian Boston wrote:
> Hi,
> 
> On 17 October 2017 at 12:12, Robert Munteanu <romb...@apache.org>
> wrote:
> 
> > On Tue, 2017-10-17 at 12:08 +0100, Ian Boston wrote:
> > > Hi,
> > > Could travis be used ?
> > > 
> > > https://github.com/apache/sling/blob/trunk/.travis.yml
> > > 
> > > I dont think that need personal access tokens or  a special
> > > technical
> > > uses
> > > as it uses OAuth.
> > > 
> > > From memory the main problem with Travis + Sling is a) the size
> > > of
> > > the log
> > > file (fixed for Sling see yml file) and b) the time taken to
> > > build.
> > > Other
> > > than that it works well for small repos that build fast.
> > 
> > Travis requires administrative access to Github, which we don't
> > have.
> > 
> 
> https://travis-ci.org/apache/sling/builds/288988140?utm_source=github
> _status_medium=notification
> 
> It seems to be active and working on apache/sling trunk
> I don't remember having administrative access to GitHub when making
> that
> work, but I guess perhaps, Infra had already enabled it.

Apparently it was me asking for it :-) I have a short memory [1]

> Enabling once per repo might be more attractive to Infra than having
> to
> manage 380+ special users, or perhaps thats the same thing.

We should be able to work with one 'sling-bot' special user for our
Jenkins needs. Or just stick with a committer as a special user.

> 
> > We would need to ask infra to do this, and since they do it
> > manually I
> > don't think it will be too high on their priority list.
> > 
> > Are we missing features from Travis or is it just the ease of
> > configuration?
> > 
> 
> Ease of configuration (once you get past its output limits)
> Good integration with GitHub, especially pull requests.
> Doesn't consume Apache resources. (I assume)
> 
> I've used both on other projects and generally found Travis less
> hassle
> than Jenkins, but thats only my experience.
> This has been especially true where I wanted to do a little more PR
> validation than a simple build.

I think Jenkins pipeline builds are a lot more flexible that 'classic'
freestyle of maven builds. I am not a big fan, but they do allow more
exotic scenarios.

Pull request integration is there with Jenkins as well.

As for Apache resources, the ASF currently pays for Travis credits
IIUC, see [2],[3],[4] so either way we're consuming something.

Anyway, bottom line is that our goal should be 'CI feedback on pull
requests', not 'Use Jenkins to validate pull requests'. I did this to
make sure we are not making an unwise move in migrating to Github with
280 repos and then finding out we can't easily add validation to pull
requests.

I am open to either tool and we should definitely evaluate after the
git migration has settled down.

We should definitely start with "what do we want to validate on a CI"
and find out the best tool. One example that would be more interesting
to set up is building and testing a bundle and the deploying it in the
current Sling launchpad and running the integration tests.

Thanks,

Robert

[1]: https://issues.apache.org/jira/browse/INFRA-6643?jql=project%20%3D
%20INFRA%20AND%20text%20~%20travis%20%20AND%20text%20~%20sling
[2]: https://issues.apache.org/jira/browse/INFRA-11121
[3]: https://issues.apache.org/jira/browse/INFRA-13634
[4]: https://blogs.apache.org/infra/entry/apache_gains_additional_travi
s_ci

Prototype of building github pull requests with Jenkins

[Robert Munteanu]

Hi,

In order to validate that we are able to validate pull requests without
nagging infra I added experimental pull request validation to the sling
site repo.

The results are visible in the jenkins job [1] and in an example pull
request [2].

The Jenkins job is multi-branch pipeline and it's using a personal
access token under my account to communicate with Github. That's why my
face is next to the check, but once we are migrated we can request a
technical user from infra for this.

Robert

[1]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-site/
[2]: https://github.com/apache/sling-site/pull/3

Re: Prototype of building github pull requests with Jenkins

[Robert Munteanu]

On Tue, 2017-10-17 at 12:08 +0100, Ian Boston wrote:
> Hi,
> Could travis be used ?
> 
> https://github.com/apache/sling/blob/trunk/.travis.yml
> 
> I dont think that need personal access tokens or  a special technical
> uses
> as it uses OAuth.
> 
> From memory the main problem with Travis + Sling is a) the size of
> the log
> file (fixed for Sling see yml file) and b) the time taken to build.
> Other
> than that it works well for small repos that build fast.

Travis requires administrative access to Github, which we don't have.
We would need to ask infra to do this, and since they do it manually I
don't think it will be too high on their priority list.

Are we missing features from Travis or is it just the ease of
configuration?

Thanks,

Robert

Re: Prototype of building github pull requests with Jenkins

[Robert Munteanu]

On Tue, 2017-10-17 at 13:15 +0200, Konrad Windszus wrote:
> Great, thanks for that. Is it possible to directly expose the last
> build result in the Github PR though? I guess the according Jenkins
> Plugin should support that Ootb.

The result is exposed, but for merged pull requests it's a bit hidden.
In https://github.com/apache/sling-site/pull/3 click the 'View details'
button to expose the checks, including the Jenkins one.

In https://github.com/apache/sling-site/pull/2, which is not merged
yet, you will see a 'Checks' container at the bottom, including one
which says 'All checks have passed'. Click on 'Show all checks' to see
the Jenkins status.

Thanks,

Robert

> 
> Konrad
> 
> > Am 17.10.2017 um 13:00 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > Hi,
> > 
> > In order to validate that we are able to validate pull requests
> > without
> > nagging infra I added experimental pull request validation to the
> > sling
> > site repo.
> > 
> > The results are visible in the jenkins job [1] and in an example
> > pull
> > request [2].
> > 
> > The Jenkins job is multi-branch pipeline and it's using a personal
> > access token under my account to communicate with Github. That's
> > why my
> > face is next to the check, but once we are migrated we can request
> > a
> > technical user from infra for this.
> > 
> > Robert
> > 
> > [1]: https://builds.apache.org/view/S-Z/view/Sling/job/sling-site/
> > [2]: https://github.com/apache/sling-site/pull/3
> 
> 

Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes

[Robert Munteanu]

Hi Christian,

Thanks for bringing this to the dev list. I have seen part of this
argument from various people, but until now no one has decided to
actually write about it :-)

On Tue, 2017-10-17 at 13:49 +0200, Christian Schneider wrote:
> I am bit concerned about the number of repositories we are about to
> create
> on git and the relation between them.
> 
> Lets take an extension as an example:
> 
> validation
> - reactor
> - api
> - core
> - examples
> - test-services
> 
> If I understand correctly then we plan to create one git repo for
> each
> module above. So it would be 5 repos for the validation extension.
> 
> I think this is quite problematic for several reasons.
> - If you change something in validation you often will change more
> than one
> of the modules above.
> - Like in svn today you can easily forget to update dependencies
> after a
> release. This results in the build not working anymore after the old
> snapshots are discarded by nexus. Addtionally you build with a
> potentially
> wrong set of dependencies in the meantime. In git this is even more
> problematic as you need to update several repos then to make changes
> instead just several directories in one svn tree.
> - It is difficult to do a build of the whole validation extension

Well, these are 4 repositories, there will not be a validation.reactor
modules. I don't think the examples change a lot, and we should
probably move all examples/samples to the 'sling-samples' repo, where
they are more visible ( personal opinion, nothing discussed/decided yet
). So I would not count examples as a repository that creates overhead.

Indeed, there can be scenarios where api + impl or api + impl + tests
need to change together. My gut feeling though is that they don't
happen that often. And many of our modules have 'in-module' integration
tests, where there is no test content outside of the bundle.

For checking out and building multiple grouped projects we would like
to use a tool such as google repo. See [1] and [2] for some rough
ideas. In the same way we can generate one of more aggregator poms.

What does remain mostly uncovered is commits and pushes to multiple
repositories. There you indeed have to perform multiple commits. But
I'd argue that either:

- impl changes frequently, api does not ; not a problem for us
- impl changes frequently, api changes as well; looks like api and impl
are really tied together so should they really be separate bundles?


> So I propose to rather use one repository per extension. Additionally
> I
> would also version and release the whole extension together.
> - This makes it easy to do and test changes that reach over more than
> one
> module
> - The release process is much easier and you can not forget to update
> dependencies
> 
> Of course such a model creates some unnecessary artifacts in a
> release. For
> example you would get a new api bundle even when there are no changes
> in
> it. This is not very problematic though as we already version APIs on
> package level. So the user would still have full backwards
> compatibility.
> 
> The difficult task in this model is of course which modules to bundle
> together in a repo. I think for extensions this is obvious but for
> other
> parts of sling it is less clear.
> 
> As a good example that this approach can work see the apache aries
> project.
> In Aries we used to release each bundle individually. This created
> the same
> problems as in sling. We moved some projects to git but on a coarse
> grained
> level and it seems to work quite well.
> 
> See these projects as examples:
> https://github.com/apache/aries-rsa
> https://github.com/apache/aries-jpa

The problems we can encounter are mostly build related, and not
affected by releases. If this model is working for Aries we can
consider it. I do not oppose it, even though my preference is
different.

Perhaps the people that actually work with these multi-project
extensions would like to comment? By a quick check we have:

- caconfig
- healthchek
- models
- sightly
- validation

as reactor poms with more than 2 modules in the /bundles subtree.

Thanks,

Robert

> 
> Each of those projects can be built in one step and the build is
> always
> consistently using the correct versions. A release can be done on top
> level
> in one step. Still for example the Aries RSA spi is still at package
> version 1.0.0. So external projects that build on it will still be
> compatible with the newest Aries RSA release.
> 
> I know I am a it late to the party with my proposal but Robert
> encouraged
> me to still come up with it as after the move to git it will be too
> late.

[1]: https://cwiki.apache.org/confluence/display/SLING/Move+from+Subver
sion+to+Git
[2]: https://issues.apache.org/jira/browse/SLING-7164

Re: [git] Migration scheduled for 18 Oct, 22:00 CEST and final notes

[Robert Munteanu]

On Tue, 2017-10-17 at 13:03 +, Justin Edelson wrote:
> On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <romb...@apache.org>
> wrote:
> 
> > 
> > 
> > Perhaps the people that actually work with these multi-project
> > extensions would like to comment? By a quick check we have:
> > 
> > - models
> > 
> > 
> 
> The models bundles can be released independently, i.e. I've done a
> number
> of releases of the implementation bundle without touching the API
> bundle.
> 
> While Konrad is correct that ITs are an issue, my strong preference
> with
> Sling Models is to minimize the use of ITs, i.e. use them only for
> code
> paths which are difficult to test via a unit test, so I don't really
> see
> that as an issue.

+1, ideally most changes would be covered by an unit test, not an
integration test. Even so, validation has its pax-exam ITs in the core
bundle, only the test content is outside of the bundle.

Robert

Re: Depending on Oak 1.7.x

[Robert Munteanu]

On Wed, 2017-10-11 at 11:16 +0100, Ian Boston wrote:
> Hi,
> Switching to depend on Oak 1.7 requires upgrading oak-server to use
> 1.7 or
> later.
> There has been some incompatible changes at a bundle level and
> package
> level between 1.6 and 1.7 so its not as simple has changing the
> versions.
> For instance oak-api bundle didnt existi in 1.6 and NodeAggregator
> class
> doesn't appear to exist in 1.7. oak-server wont build without a
> patch.
> 
> Obviously, if you have an oak-server or equivalent that already
> depends on
> 1.7 or later, then its trivial, but Sling doesn't.

So we need need to make oak-server and jcr.resource dependent on Oak
1.7, right?

I would guess that oak-server is not such a big issue. Is it possible
to make the dependency from jcr.resource to the newer oak api optional?
If the bundle would also run on Oak 1.6 I guess there would be no
issue.

Thanks,

Robert

> Best Regards
> Ian
> 
> On 11 October 2017 at 11:07, Stefan Egli 
> wrote:
> 
> > Having said that, the only bullet to bite when switching to Oak
> > 1.7.x is
> > increased maintenance effort: the affected bundles will become
> > backwards
> > incompatible wrt Oak 1.6.x and if they need to be patched it would
> > not be
> > possible to do so in trunk anymore.
> > 
> > Cheers,
> > Stefan
> > 
> > On 11/10/17 12:03, "Stefan Egli"  wrote:
> > 
> > > Hi Ian,
> > > 
> > > I don't see a problem with having a dependency on an unstable Oak
> > > 1.7.x in
> > > Sling.
> > > 
> > > Actual deployments can still, independent of this, make a call
> > > whether or
> > > not they want to actually run on Oak 1.7.x or wait for Oak 1.8
> > > (which is
> > > advisable). IMO having this dependency doesn't imply on which
> > > version it
> > > will ultimately run.
> > > 
> > > Cheers,
> > > Stefan
> > > 
> > > On 11/10/17 11:54, "Ian Boston"  > > i...@tfd.co.uk> wrote:
> > > 
> > > > Hi,
> > > > Oak 1.7.x is Oak unstable release branch working towards 1.8.
> > > > I have a feature in SLING-7140 that is blocked by an API change
> > > > in Oak
> > > > present in 1.8-SNAPSHOT and available as an unmerged but tested
> > > > patch to
> > > > Oak 1.6.x.
> > > > 
> > > > The Oak team are unwilling merge the patch to 1.6 and have
> > > > asked that
> > > > Sling
> > > > depend on the latest release of Oak 1.7.
> > > > 
> > > > How does the Sling team feel about this ?
> > > > 
> > > > The patch for SLING-7140 cant be merged until the API is
> > > > available in Oak
> > > > in some form and I don't want to depend on Oak 1.8-SNAPSHOT as
> > > > this will
> > > > block Sling releases of the bundles involved.
> > > > Best Regards
> > > > Ian
> > > 
> > > 
> > 
> > 
> > 

Re: Sling build broken for me.

[Robert Munteanu]

Hi Ian,

On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
> Hi,
> Could be me.
> I do mvn clean install on a clean Sling checkout with a clean maven
> repo
> and I get failiures to download slingfeature:9-SNAPSHOT required by
> an IT
> test sample. This happens before the reactor starts.

Fixed in http://svn.apache.org/viewvc?rev=1811803=rev .

> 
> If I fix that by using slingfeature:9 I then get 11 test failures in
> commons.log related to the format of the logging output.
> 
> Is this just me ?
> 
> If it is just me, I can disable tests there to move on.

I am not sure anyone is building the full reactor anymore - we are
building individual modules on Jenkins [1].

commons.log builds fine for me as an individual module and I don't see
it failing on Jenkins either.

If there's a consistent failure at your end, please file a bug. But for
getting the launchpad up and running only need to build
launchpad/builder/ - all depenendencies are releases therefore the
reactor build is not used.

Thanks,

Robert


[1]: https://builds.apache.org/view/S-Z/view/Sling/

Re: [VOTE] Release Apache Sling Maven Sling Plugin 2.3.4

[Robert Munteanu]

On Wed, 2017-10-11 at 19:23 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: Sling build broken for me.

[Robert Munteanu]

On Thu, 2017-10-12 at 12:54 +0100, Ian Boston wrote:
> > I'll set the Jenkins jobs to also build regularly. Note that a full
> > reactor build is not something I am keen on doing since:
> >
> > - it takes a long time
> > - if one module in the reactor fails the build is aborted
> >
> 
> Would --fail-at-end work ?
> Best Regards
> Ian

It would work in a limited manner. If a module that is a dependency for
other modules fails, the dependant modules would be banned from the
reactor.

Robert

Re: Sling build broken for me.

[Robert Munteanu]

On Wed, 2017-10-11 at 21:56 +0200, Karl Pauls wrote:
> > Would it help if we added weekly builds for all modules,
> > irrespective
> > if any changes are present?
> 
> Yes, I think that would be a good start. Ultimately, I still think we
> should get this "run integration tests with all bundles set to
> SNAPSHOT build" working but until we have that we might as well make
> sure we run the reactor every once in a while. Would that be hard to
> do?

Well, run all ITs with bundles set to snapshots will only affect
bundles that are present in the launchpad - and not all of them are.

Not sure how hard that would be to do, last time I got lost in
dependency resolution in the plugin :-) I don't have any plans to look
into it in the short term.

Robert

Re: Sling build broken for me.

[Robert Munteanu]

Hi Ian,

On Thu, 2017-10-12 at 11:26 +0100, Ian Boston wrote:
> Hi,
> 2 observations going through the upgrade process from Oak 1.6 to Oak
> 1.7/1.8 using the full build to verify.
> 
> Most of the build breakages are due to a bundle being release but its
> reference not being updated, some are subtle.
> 
> The 9-SNAPSHOT that started this thread is obvious but hard to find.
> 
> I just fixed the Healthcare IT build because the a bundle included in
> the
> Pax exam now needed a different set of imports so the PaxExam startup
> failed. That indicates the last release of HC might have been done
> without
> running the ITs.
> 
> Oak Server also uses PaxExam, for ITs but it includes the version of
> Oak
> using the org.apache.sling.testing.paxexam bundle. Once updated, any
> bundle
> that builds using an older version of that bundle wont be testing
> against
> the current version of Oak being used by Sling. You could argue, so
> what,
> its behind an API, but the point of an IT is to catch the out of band
> issues not represented in the API.  I am tempted to upgrade
> everything to
> perform ITs against the current version of Oak (1.7/1.8) in the work
> I am
> doing.
> 
> To recap: IMHO, Sling should be running full builds with all ITs at
> regular
> intervals. Ideally anyone doing a release should do the same before
> and
> after the release to ensure the released bundle isn't broken and the
> build
> is buildable after the release.

I'll set the Jenkins jobs to also build regularly. Note that a full
reactor build is not something I am keen on doing since:

- it takes a long time
- if one module in the reactor fails the build is aborted

Therefore I think it's best to keep the individual builds, but
configure them to build periodically as well as on changes.

https://issues.apache.org/jira/browse/SLING-7191

If you think this is not enough or we find scenarios that it does not
cover we can revisit the change.

Thanks,

Robert

> 
> Best Regards
> Ian
> 
> 
> On 11 October 2017 at 20:56, Karl Pauls <karlpa...@gmail.com> wrote:
> 
> > On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu <romb...@apache.or
> > g>
> > wrote:
> > > On Wed, 2017-10-11 at 16:04 +0200, Karl Pauls wrote:
> > > > On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston <i...@tfd.co.uk>
> > > > wrote:
> > > > > Hi,
> > > > > 
> > > > > On 11 October 2017 at 11:21, Robert Munteanu <rombert@apache.
> > > > > org>
> > > > > wrote:
> > > > > 
> > > > > > Hi Ian,
> > > > > > 
> > > > > > On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
> > > > > > > Hi,
> > > > > > > Could be me.
> > > > > > > I do mvn clean install on a clean Sling checkout with a
> > > > > > > clean
> > > > > > > maven
> > > > > > > repo
> > > > > > > and I get failiures to download slingfeature:9-SNAPSHOT
> > > > > > > required by
> > > > > > > an IT
> > > > > > > test sample. This happens before the reactor starts.
> > > > > > 
> > > > > > Fixed in http://svn.apache.org/viewvc?rev=1811803=reve
> > > > > > v .
> > > > > > 
> > > > > > > 
> > > > > > > If I fix that by using slingfeature:9 I then get 11 test
> > > > > > > failures in
> > > > > > > commons.log related to the format of the logging output.
> > > > > > > 
> > > > > > > Is this just me ?
> > > > > > > 
> > > > > > > If it is just me, I can disable tests there to move on.
> > > > > > 
> > > > > > I am not sure anyone is building the full reactor anymore
> > > > > 
> > > > > 
> > > > > 
> > > > > Isnt that a bit dangerous ?
> > > > > Not being able to reliably build Sling could allow a failure
> > > > > to go
> > > > > for
> > > > > months without being noticed using old snapshot builds from
> > > > > other
> > > > > modules.
> > > > > 
> > > > > I assume no one is building all of Sling because it takes too
> > > > > long
> > > > > now ?
> > > > 
> > > > 
> > > > Carsten and I did sit down semi-regularly and got it back
> > > > building.
> > > > Not sure when we did that last but it can't be more than a
> > > > month or
> > > > two.
> > > > 
> > > > I agree that this is not a good state to be in.
> > > > 
> > > > regards,
> > > > 
> > > > Karl
> > > 
> > > Would it help if we added weekly builds for all modules,
> > > irrespective
> > > if any changes are present?
> > 
> > Yes, I think that would be a good start. Ultimately, I still think
> > we
> > should get this "run integration tests with all bundles set to
> > SNAPSHOT build" working but until we have that we might as well
> > make
> > sure we run the reactor every once in a while. Would that be hard
> > to
> > do?
> > 
> > regards,
> > 
> > Karl
> > 
> > > Robert
> > 
> > 
> > 
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> > 

Re: [VOTE] Release Apache Sling Servlet Helpers 1.0.2, Servlet Helpers 1.1.2, JCR Mock 1.3.2, ResourceResolver Mock 1.1.20, OSGi Mock 1.9.8, OSGi Mock 2.3.4, Sling Mock 1.9.10, Sling Mock 2.2.14

[Robert Munteanu]

On Thu, 2017-10-12 at 20:33 +, Stefan Seifert wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [NOTICE] Getting ready to start the SVN → Git migration

[Robert Munteanu]

On Thu, 2017-10-12 at 20:55 +, Justin Edelson wrote:
> On Thu, Oct 12, 2017 at 4:42 PM Stefan Seifert  e>
> wrote:
> 
> > > BTW, not sure what the access rule for users@infra are, but you
> > > should
> > > be able to access https://lists.apache.org/list.html?users@infra.
> > > apache
> > > .org and then log in with your ASF credentials. I think it works
> > > for
> > > committers.
> > 
> > even if i login:
> > i cannot access https://lists.apache.org/list.html?us...@infra.apac
> > he.org
> > i can access https://lists.apache.org/list.html?issues@infra.apache
> > .org
> > 
> > stefan
> > 
> 
> What I see is that when I try to go to
> https://lists.apache.org/list.html?us...@infra.apache.org, after
> authenticating, I end up on
> https://lists.apache.org/list.html?iss...@infra.apache.org

Just to make sure - did you authenticate with your ASF credentials?

I am not sure whether the archive is open just to members or just
committers. Since [1] states that "The infra@ mailing list should be
considered a semipublic list as many Apache committers --- not only
Team members --- are subscribed" I guess it should be open to
committers that are not members.

Thanks,

Robert


[1]: https://www.apache.org/dev/infra-contact

[git] Naming of git repositories

[Robert Munteanu]

Hi,

I've started thinking a bit about the Git migration process. I don't
think we've discussed naming individual Sling modules after being
extracted from SVN.

ASF mandates that we use a pattern of 'TLP-module' for the git
repositories, so the modules must be name sling-${something}.

As for that ${something}, it can be one of

1. artifactId / Bundle-SymbolicName
2. short name ( as currently used in the SVN repo )

I would favour option 2, as I think option 1 has too much redundancy:

  sling-org.apache.sling.auth.core

is too verbose compared to

  sling-auth-core


Refining option #2, we should remove some commons prefixes, such as:

- bundles
- contrib/bundles
- bundles/extensions
- contrib
- contrib/extensions
- karaf
- tooling/maven

Thoughts?

Robert

Re: Sling Testing Client's ComponentsInfo class findBy() method does not work

[Robert Munteanu]

Hi Andy.

On Fri, 2017-09-01 at 12:43 -0700, Andreas Schaefer wrote:
> Hi
> 
> I just noticed that the
> org.apache.sling.testing.clients.osgi.ComponentsInfo.findBy() does
> not honor the value parameter and just returns the first value found.
> 
> It works in BundleInfo though.

I am not familiar with that piece of code, but that sounds like a bug.
A Jira issues, and ideally a patch with a test will get this fixed soon
:-)

Thanks,

Robert

Java 9 ITs active - and action items

[Robert Munteanu]

Hi,

I've set up an additonal set of testing jobs for Java 9, using the RC
build ( Java 9 b181 )

- https://builds.apache.org/view/S-Z/view/Sling/job/sling-launchpad-tes
ting-9
- https://builds.apache.org/view/S-Z/view/Sling/job/sling-launchpad-tes
ting-war-9

The test results are not _that_ bad:

  Tests run: 561, Failures: 13, Errors: 36, Skipped: 1

I've done a first triage pass over the test results and created
blockers for SLING-7046 [1]. There are failures related to JSPs, JAXB,
teleporter, indexing and some more :-)

If anyone wants to take a stab at an issue, feel free to pick them up -
I'm not going to make work on the fixes immediately myself, but I'd
still like to have a Sling 10 release ready by September 21st.

Thanks,

Robert


[1]: https://issues.apache.org/jira/browse/SLING-7046

Re: [VOTE] Release Apache Sling Commons Java Compiler version 2.3.4

[Robert Munteanu]

On Tue, 2017-09-12 at 23:04 +0300, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

[VOTE] Release Apache Sling Commons Java Compiler version 2.3.4

[Robert Munteanu]

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12341614

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1783

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1783 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Thanks,

Robert

Re: Ok to replace sling.apache.org with the new JBake-generated site ?

[Robert Munteanu]

Hi,

On Tue, 2017-09-26 at 17:54 +0200, Bertrand Delacretaz wrote:
> Is anyone opposed to putting this online instead of the current
> http://sling.apache.org// site?

Not me, I'd like to see this live sooner rather than later. And the
first step towards moving everything to Git :-)

Robert

Re: [VOTE] Release Apache Sling Thread Support 3.2.10

[Robert Munteanu]

On Thu, 2017-09-28 at 23:20 +0200, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tests Teleporter 1.0.16, Apache Sling

[Robert Munteanu]

Anyone else?

Robert

On Mon, 2017-09-25 at 13:50 +0200, Robert Munteanu wrote:
> Hi,
> 
> This is a catch-all release vote for some modules I saw had changes
> but
> no releases. Due to a network hiccup they are split into 2 release
> repositories.
> 
> Note that we dropped Commons Threads 3.2.8 due to incomplete fix for
> SLING-6261 .
> 
> There are 15 fixes included in these releases
> 
> - https://issues.apache.org/jira/projects/SLING/versions/12339953 ( 6
> issues )
> - https://issues.apache.org/jira/projects/SLING/versions/12341057 ( 2
> issues )
> - https://issues.apache.org/jira/projects/SLING/versions/12341406 ( 2
> issues )
> - https://issues.apache.org/jira/projects/SLING/versions/12341562 ( 1
> issue )
> - https://issues.apache.org/jira/projects/SLING/versions/12339140 ( 4
> issues )
> 
> 
> Staging repositories:
>   - https://repository.apache.org/content/repositories/orgapachesling
> -1
> 789
>   -   - https://repository.apache.org/content/repositories/orgapaches
> li
> ng-1790
> 
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1789 /tmp/sling-staging
> sh check_staged_release.sh 1790 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
> 
> This majority vote is open for at least 72 hours.
> 
> Thanks,
> 
> Robert

Re: [VOTE] Release Apache Sling Thread Support 3.2.8, Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tes

[Robert Munteanu]

Passes 10 times in a row on my Windows VM.

Thanks for looking into this, I'll start a new release vote.

Robert

On Tue, 2017-09-26 at 19:14 +0200, Konrad Windszus wrote:
> I fixed this issue now in r1809761. Could you please check again?
> For me the IT now reliably passes even on Windows.
> Thanks again for reporting,
> Konrad
> > On 21. Sep 2017, at 12:43, Robert Munteanu <romb...@apache.org>
> > wrote:
> > 
> > On Thu, 2017-09-21 at 10:23 +, Stefan Seifert wrote:
> > > mine is:
> > > 
> > > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> > > 2015-
> > > 11-10T17:41:47+01:00)
> > > Maven home: C:\java\apache-maven-3.3.9
> > > Java version: 1.8.0_121, vendor: Oracle Corporation
> > > Java home: C:\java\jdk1.8.0_121\jre
> > > Default locale: de_DE, platform encoding: Cp1252
> > > OS name: "windows 10", version: "10.0", arch: "amd64", family:
> > > "dos"
> > 
> > While I don't get the failures on my main machine, on a Windows VM
> > I
> > always get this failure.
> > 
> > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-
> > 04-
> > 03T22:39:06+03:00)
> > Maven home: C:\work\maven\bin\..
> > Java version: 1.8.0_60, vendor: Oracle Corporation
> > Java home: C:\Program Files\Java\jdk1.8.0_60\jre
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 7", version: "6.1", arch: "x86", family:
> > "windows"
> > ~  
> > 
> > 
> > Thanks for catching this.
> > 
> > Robert
> > > 
> > > stefan
> > > 
> > > > -Original Message-
> > > > From: Robert Munteanu [mailto:romb...@apache.org]
> > > > Sent: Thursday, September 21, 2017 12:19 PM
> > > > To: dev@sling.apache.org
> > > > Subject: Re: [VOTE] Release Apache Sling Thread Support 3.2.8,
> > > > Apache Sling
> > > > Scripting Core implementation 2.0.48, Apache Event Support
> > > > 4.2.8,
> > > > Apache
> > > > Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tests
> > > > Teleporter
> > > > 1.0.16, Apache Sling Testing Utilities 2.
> > > > 
> > > > On Thu, 2017-09-21 at 08:48 +, Stefan Seifert wrote:
> > > > > Apache Sling Thread Support 3.2.8
> > > > > -> i've a problem running the unit tests. the run fine, up to
> > > > > rev.
> > > > > 1790774, but fail from rev. 1791091 (SLING-6261). is it only
> > > > > on
> > > > > my
> > > > > machine? see below
> > > > 
> > > > What is the output of mvn -v? I get no issues with
> > > > 
> > > > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> > > > 2017-
> > > > 04-
> > > > 03T22:39:06+03:00)
> > > > Maven home: /usr/share/java/maven
> > > > Java version: 1.8.0_144, vendor: Oracle Corporation
> > > > Java home: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre
> > > > Default locale: en_US, platform encoding: UTF-8
> > > > OS name: "linux", version: "4.12.9-0-default", arch: "amd64",
> > > > family:
> > > > "unix"
> > > > 
> > > > Thanks,
> > > > 
> > > > Robert
> > > 
> > > 
> 
> 

[VOTE] Release Apache Sling Thread Support 3.2.10

[Robert Munteanu]

Hi, 

We solved 6 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12335535

1 issue in this version is still open as it affects other modules as
well, but for Commons Threads the fix has been applied.

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1793

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1793 /tmp/sling-staging

Please vote to approve this release:

 [ ] +1 Approve the release
 [ ] 0 Don't care
 [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Re: Git migration - final checks

[Robert Munteanu]

Hi Konrad.

On Fri, 2017-09-29 at 10:06 +0200, Konrad Windszus wrote:
> Just one thing: I am wondering why commits which I have done do not
> have a clickable author information, in contrast to the ones from
> Karl or from Oli (can be observed in https://github.com/not-sling/sli
> ng-org.apache.sling.validation.core/commits/master)
> Where is the author information coming from?
> My author ID is kwin in the Apache SVN and I have an account at
> github with the same id.
> Do you have in idea?

I think you should add your apache.org email address to your Github
profile. There is no mapping at the ASF level that I'm aware of.

Thanks,

Robert

> 
> Otherwise it looks really good and thanks a lot for your effort up
> till now.
> Konrad
> 
> > Am 29.09.2017 um 09:37 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > Hi,
> > 
> >  tldr: please test the test-migrated git repos, we'll migrate soon
> > 
> > The git migration is almost ready to go. We're waiting for infra to
> > reply on how to activate the transition but otherwise we're
> > basically
> > good to go.
> > 
> > I'd like to point you again to our wiki page where the transition
> > is
> > documented
> > 
> >  https://cwiki.apache.org/confluence/display/SLING/Move+from+Subver
> > sio
> > n+to+Git
> > 
> > I've also performed a dry-run migration of all modules to a Github
> > org,
> > to allow everyone to inspect how such a migration would look like.
> > 
> >  https://github.com/not-sling/
> > 
> > The 'sling' repository also contains a repo manifest file which
> > allows
> > you to checkout all the sling projects in one go. This is not
> > necessarily the final format and we may iterate on that a bit more.
> > Just wanted to show that there is a way of getting the repositories
> > in
> > one go.
> > 
> > So please read the wiki page, take a look at the migrated
> > repositories,
> > especially the ones you usually work with, and make sure that
> > everything is put into place.
> > 
> > Unless we have objections or open issues, I will start the
> > migration on
> > Monday October the 9th ( not sure of the time, but as soon as
> > possible
> > in the GMT+2 time zone ).
> > 
> > Thanks,
> > 
> > Robert
> 
> 

[RESULT] [VOTE] Release Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tests Teleporter 1.0.16, Apache S

[Robert Munteanu]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Seifert, Carsten Ziegeler, Robert Munteanu

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Thanks all for voting.

Robert

Git migration - final checks

[Robert Munteanu]

Hi,

  tldr: please test the test-migrated git repos, we'll migrate soon

The git migration is almost ready to go. We're waiting for infra to
reply on how to activate the transition but otherwise we're basically
good to go.

I'd like to point you again to our wiki page where the transition is
documented

  https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversio
n+to+Git

I've also performed a dry-run migration of all modules to a Github org,
to allow everyone to inspect how such a migration would look like.

  https://github.com/not-sling/

The 'sling' repository also contains a repo manifest file which allows
you to checkout all the sling projects in one go. This is not
necessarily the final format and we may iterate on that a bit more.
Just wanted to show that there is a way of getting the repositories in
one go.

So please read the wiki page, take a look at the migrated repositories,
especially the ones you usually work with, and make sure that
everything is put into place.

Unless we have objections or open issues, I will start the migration on
Monday October the 9th ( not sure of the time, but as soon as possible
in the GMT+2 time zone ).

Thanks,

Robert

Re: Website ToC considers only h2 and h3

[Robert Munteanu]

On Fri, 2017-09-29 at 11:38 +0200, Bertrand Delacretaz wrote:
> On Fri, Sep 29, 2017 at 11:30 AM, Konrad Windszus 
> wrote:
> > ... Do you want me to propose something or are you planning to
> > migrate the Git repo to gitbox soon?..
> 
> If you can implement what you suggest that would be great. A CSS
> class
> on the main title sounds great.
> 
> Commit to https://git-wip-us.apache.org/repos/asf?p=sling-site.git
> for
> now and when we move to gitbox we'll take care of that.
> 
> I'll work on the publishing instructions today but it looks like
> Robert has been able to publish already so the README is not totally
> off ;-)

Yup, it's good enough for me :-)

>From memory, the steps are something like

$ mvn clean package
$ git checkout asf-site
$ rsync -av target/site/ ./

Robert

[RESULT] [VOTE] Release Apache Sling Thread Support 3.2.10

[Robert Munteanu]

Hi,

The vote has passed with the following result:

+1 (binding): Stefan Seifert, Carsten Ziegeler, Robert Munteanu

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Re: [SLING-7167] Adjust READMEs

[Robert Munteanu]

On Mon, 2017-10-02 at 13:26 +0200, Oliver Lietz wrote:
> hi all,
> 
> do we want to use the artifactId or the name for the title in all
> READMEs, 
> e.g. Apache Sling Auth Core vs Apache Sling Authentication Service
> (we have 
> both uncommon ids and names)?
> 
> https://issues.apache.org/jira/browse/SLING-7167
> 
> Thanks,
> O.
> 

I'd go with artifact name in the README, it's more human readable
compared to an artifact id.

Also if you think that some artifact names are out of place when
compared to others, feel free to change - or just create a list for
discussion if you don't feel like changing directly.

Thanks,

Robert

Re: [Site] Improving the main site

[Robert Munteanu]

Hi,

On Sat, 2017-09-30 at 12:09 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> we discussed last week at the hackathon a little bit on how to
> improve
> our site. With the move to git and the new system it should be
> easier.
> 
> Looking at the main site, there is a lot of stuff there which we
> probably shouldn't have.
> 
> News/Releases
> 
> The "news" section is more or less just listing releases, so we can
> move
> this to a separate "releases" page. We can then decide whether we can
> come up with real news like once or twice a month. For example we
> could
> have mentioned adaptTo there etc.

+1, not sure how relevant this is for site visitors.

> 
> History
> 
> The history section is nice for us, but I guess everyone new to Sling
> does not find any value in this. So we should move this to a separate
> history page, and maybe add a little bit there. Or we add this simply
> as
> the oldest entries of the news page and avoid having a new page no
> one
> really looks at.

+1 for moving out of the main page. People curious about history will
look for it.
> 
> Use Cases
> 
> Again I'm not sure about the value for new users. So rather removing
> it
> or moving it to a use cases page.

I'd say drop it completely and link to a page of applications built on
top of Sling - commercial and open source. Rather than tell our users
what they can do, let's show them :-)

Maybe also include the Sling samples here.

> 
> References
> 
> I think we confuse people with listing all this different parts on
> the
> front page. So removing it and moving it to a references page might
> be
> better.

+1

> 
> This would keep our main page fairly short and we just need to
> improve
> the introduction "Sling in 100 words"

+1. Let's just find a volunteer :-)

Robert

> 
> Regards
> Carsten

Re: [Site] Placeholders?

[Robert Munteanu]

On Sat, 2017-09-30 at 12:03 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> with the migration of the website, I'm wondering if we can have
> placeholders in pages?
> 
> For example, the version number of the latest Launchpad release, the
> minimun java version to use, the minimum Maven version for building
> etc.
> These things are spread across so many pages and many of them are
> outdated - so having placeholders and simply changing them in one
> place
> could make this easier.

That's a good idea. I gave this a quick shot but failed to find a
solution in ~10 minutes.

By reading the discussion at [1] it seems that we have to implement
this ourselves in our templates - there is no placeholder support for
articles.

Robert


[1]: https://groups.google.com/forum/#!topic/jbake-user/-vioxApSJ5A

[site] Simplifying publishing process

[Robert Munteanu]

Hi,

I think we can simplify the site publishing setup and it should be
enough to work only on the master branch.

I see two possible options:

1) Set up a Jenkins job to rebuild the site and push automatically .
This _should_ be possible based on [1]

2) Configure the maven-scm-publish-plugin to publish changes. This is
done for instance for Oak [2]

Preferences?

Thanks,

Robert

[1]: https://issues.apache.org/jira/browse/INFRA-12425
[2]: https://github.com/apache/jackrabbit-oak/blob/fbc23b57f24576352cc2
04a52b90d852d2be7a6a/oak-doc/pom.xml#L46-L80

Re: Deprecate Commons Testing?

[Robert Munteanu]

Hi,

On Thu, 2017-09-28 at 13:03 +0200, Konrad Windszus wrote:
> Currently Commons Testing can be found in bundles/commons/testing (ht
> tps://github.com/apache/sling/tree/trunk/bundles/commons/testing)
> although I would rather expect it below testing (https://github.com/a
> pache/sling/tree/trunk/testing) in SVN.
> Apart from that library seems to be rather old and not too actively
> maintained. For most of its classes there are nowadays better
> replacements:
> 
> Package
> 1. o.a.s.commons.testing.integration: Rather either Teleporter or the
> org.apache.sling.testing.clients should be used
> 2. o.a.s.commons.testing.jcr: jcr-mock should be used instead
> 3. o.a.s.commons.testing.junit: should be converted to rules
> (org.apache.sling.testing.rules)
> 4. o.a.s.commons.testing.osgi: osgi-mock should be used instead
> 5. o.a.s.commons.testing.sling: sling-mock should be used instead
> 6. org.apache.sling.commons.testing.util: if really useful can maybe
> moved to sling-mock as well
> 
> Apart from that there are IMHO better alternatives for all those
> classes available, there are certain limitations which are IMHO not
> easy to fix:
> 
> 1. o.a.s.commons.testing.jcr uses Jackrabbit 2 only and never Oak,
> that means that the ITs are pretty far away from what we ship now in
> Sling.
> 2. o.a.s.commons.testing.jcr is currently not compatible with Java 9
> (https://issues.apache.org/jira/browse/SLING-7159)
> 
> WDYT?
> Should we add deprecation hints to all those classes pointing to the
> better alternatives and spin a last release?
> 
> Currently we have way too many alternatives when it comes to testing
> support and focusing only on one way of doing things certainly helps
> to reduce the maintenance effort.

+1

I suggest to also create tasks for:

- removing usages from within Sling
- updating the documentation to reflect this status

Of course, reviewing the modules that use this library would also
reveal if we have any gaps that the other libraries don't cover.

Thanks,

Robert

Re: [adaptTo-CRT] Sling git migration

[Robert Munteanu]

On Wed, 2017-09-27 at 22:00 +, Stefan Seifert wrote:
> github project settings - open questions
> - the github projects are automatically created by the INFRA tooling
> - we do not have administrative access on the github repos. but we
> may need to tweak some settings - is this possible for us to control
> this somehow in the repo creation process or later? examples:
> - switch off "issues", "projects", "wiki" in the github repos - in
> favor of our JIRA, confluence
> - set "tags" on the github repos which may be helpful to filter e.g.
> all sling repos, perhaps more finegrained as well like all "contrib"
> modules, all "models" repos etc.?

Asked infra about this

https://lists.apache.org/thread.html/fde9aa578265fc95bedc7417037cbc88c0
99d5567a3db4913bb62e3d@%3Cusers.infra.apache.org%3E

Note that list is private, you may need to log in to lists.apache.org
to view.

Thanks,

Robert

Re: [RT] Updates to the provisioning model

[Robert Munteanu]

Hi Carsten,

Thanks for the extensive write-up, it took some time to digest :-)

I have a couple of questions based on who we currenly can (or can't)
use the provisioning model.

1. How can we add comments to a feature or application json file? AFAIK
JSON does not allow comments

2. Reading the section on configuration merging, it is not clear to me
if merging is merging of values or overriding of values.

Consider


feature 1:

com.foo.bar.Service
  prop1="A"
  prop2="B"

feature 2:

com.foo.bar.Service
  prop1="C"


After the merge, will the configuration define the prop2 property? 


3. How are floating-point values represented? We had some issues with
the provisioning model, see https://issues.apache.org/jira/browse/SLING
-5914 .

Ideally we'd be able to specify a value of "5.5" have have it work
instead of the internal config admin formats.

Thanks,

Robert

Re: Build failed in Jenkins: sling-ide #115

[Robert Munteanu]

On Tue, 2017-10-03 at 12:06 +, Apache Jenkins Server wrote:
> [ERROR] Failed to execute goal org.apache.rat:apache-rat-
> plugin:0.10:check (default) on project sling-ide-tooling: Too many
> files with unapproved license: 1 See RAT report in:  pache.org/job/sling-ide/ws/target/rat.txt> -> [Help 1]

I suspect the build failure is due to the rat check on the new README
files.

Olli, can you double-check?

Thanks,

Robert

Re: Bundle Documentation: Readme in Bundle Repo vs MD in Site Repo

[Robert Munteanu]

On Tue, 2017-10-03 at 15:50 +0200, Konrad Windszus wrote:
> I think we also once discussed on the mailing list where to put
> bundle documentation: either in the readme or in the site itself.
> Unfortunately I couldn't find the according thread. Please help me
> with the link if you have it handy.

https://lists.apache.org/thread.html/b7523b72d99b68f96313bbe0622fda77ce
afc26351caa790a55b67dc@%3Cdev.sling.apache.org%3E

Robert

Re: Build failed in Jenkins: sling-ide #115

[Robert Munteanu]

On Tue, 2017-10-03 at 15:10 +0200, Oliver Lietz wrote:
> On Tuesday 03 October 2017 15:42:51 Robert Munteanu wrote:
> > On Tue, 2017-10-03 at 12:06 +, Apache Jenkins Server wrote:
> > > [ERROR] Failed to execute goal org.apache.rat:apache-rat-
> > > plugin:0.10:check (default) on project sling-ide-tooling: Too
> > > many
> > > files with unapproved license: 1 See RAT report in: <https://buil
> > > ds.a
> > > pache.org/job/sling-ide/ws/target/rat.txt> -> [Help 1]
> 
> Hi Robert,
> 
> > I suspect the build failure is due to the rat check on the new
> > README
> > files.
> > 
> > Olli, can you double-check?
> 
> why is sling-ide not using Sling Parent where we exclude READMEs from
> Rat?

The tycho build, although driven by Maven, is not 100% identical to
regular Java builds. I don't recall exactly what happened when I set
this up, but I think I had some conflicts which I could not solve
easily.

Thanks,

Robert

Re: [VOTE] Release Apache Sling Query version 4.0.0

[Robert Munteanu]

On Mon, 2017-09-25 at 12:47 +, Tomek Rekawek wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

[VOTE] [CANCELLED] Release Apache Sling Thread Support 3.2.8, Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling J

[Robert Munteanu]

Vote is cancelled due to incomplete fix for https://issues.apache.org/j
ira/browse/SLING-6261. 

Thanks,

Robert

On Mon, 2017-09-25 at 13:41 +0200, Robert Munteanu wrote:
> To be on the safe side, I'll restart the vote since we changed the
> set
> of artifacts.
> 
> Thanks,
> 
> Robert
> 
> On Sun, 2017-09-24 at 00:13 +0200, Konrad Windszus wrote:
> > Please cancel only the vote for Thread Support, I am hoping to come
> > up with a fix next week.
> > Konrad 
> > 
> > 
> > Von meinem iPhone gesendet
> > 
> > > Am 23.09.2017 um 22:19 schrieb Robert Munteanu <romb...@apache.or
> > > g>
> > > :
> > > 
> > > Konrad, Stefan,
> > > 
> > > What's your take on this? Should I cancel the vote and wait for a
> > > fix
> > > or go through with the release and fire off another release vote
> > > for
> > > the commons.threads bundles once we have a fix?
> > > 
> > > Robert
> > > 
> > > > On Thu, 2017-09-21 at 12:25 +0200, Konrad Windszus wrote:
> > > > For me the test runs fine with both Java 7 and Java 8.
> > > > But according to your stack traces it seems that the table
> > > > array
> > > > within ThreadLocalMap contains some null entries (compare with
> > > > https:
> > > > //doanduyhai.wordpress.com/2011/12/04/threadlocal-explained/).
> > > > The entry objects within the table are WeakReferences
> > > > themselves,
> > > > i.e. can become null if the key = the threadLocal object bound
> > > > to
> > > > the
> > > > thread is no longer referenced.
> > > > 
> > > > Currently the diff method does not correctly deal with it.
> > > > I will first try to make an IT which does reliably fail for
> > > > everyone
> > > > and then try to come up with a fix.
> > > > Thanks for reporting.
> > > > Konrad
> > > > 
> > > > > On 21. Sep 2017, at 10:48, Stefan Seifert <sseifert@pro-visio
> > > > > n.
> > > > > de>
> > > > > wrote:
> > > > > 
> > > > > Apache Sling Thread Support 3.2.8
> > > > > -> i've a problem running the unit tests. the run fine, up to
> > > > > rev.
> > > > > 1790774, but fail from rev. 1791091 (SLING-6261). is it only
> > > > > on
> > > > > my
> > > > > machine? see below
> > > > > 
> > > > > Apache Sling Scripting Core implementation 2.0.48
> > > > > +1
> > > > > 
> > > > > Apache Event Support 4.2.8
> > > > > +1
> > > > > 
> > > > > Apache Sling SlingStart Maven Plugin 1.7.10
> > > > > +1
> > > > > 
> > > > > Apache Sling JUnit Tests Teleporter 1.0.16
> > > > > +1
> > > > > 
> > > > > Apache Sling Testing Utilities 2.1.2
> > > > > +1
> > > > > 
> > > > > stefan
> > > > > 
> > > > > 
> > > > > unit test errors in thread support 3.2.8:
> > > > > 
> > > > > ---
> > > > > T E S T S
> > > > > ---
> > > > > Running
> > > > > org.apache.sling.commons.threads.impl.ExtendedThreadFactoryTe
> > > > > st
> > > > > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time
> > > > > elapsed:
> > > > > 0.002 sec - in
> > > > > org.apache.sling.commons.threads.impl.ExtendedThreadFactoryTe
> > > > > st
> > > > > Running
> > > > > org.apache.sling.commons.threads.impl.ThreadPoolExecutorClean
> > > > > in
> > > > > gThr
> > > > > eadLocalsTest
> > > > > Exception in thread "pool-9-thread-1"
> > > > > java.lang.NullPointerException
> > > > >   at
> > > > > org.apache.sling.commons.threads.impl.ThreadLocalCleaner.chan
> > > > > ge
> > > > > d(Th
> > > > > readLocalCleaner.java:140)
> > > > >   at
> > > > > org.apache.sling.commons.threads.impl.ThreadLocalCleaner.diff
> > > > > (T
> > > > > hrea
> > > > > dLocalCleaner.java:104)
> > >

[VOTE] Release Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tests Teleporter 1.0.16, Apache Sling Test

[Robert Munteanu]

Hi,

This is a catch-all release vote for some modules I saw had changes but
no releases. Due to a network hiccup they are split into 2 release
repositories.

Note that we dropped Commons Threads 3.2.8 due to incomplete fix for
SLING-6261 .

There are 15 fixes included in these releases

- https://issues.apache.org/jira/projects/SLING/versions/12339953 ( 6
issues )
- https://issues.apache.org/jira/projects/SLING/versions/12341057 ( 2
issues )
- https://issues.apache.org/jira/projects/SLING/versions/12341406 ( 2
issues )
- https://issues.apache.org/jira/projects/SLING/versions/12341562 ( 1
issue )
- https://issues.apache.org/jira/projects/SLING/versions/12339140 ( 4
issues )


Staging repositories:
  - https://repository.apache.org/content/repositories/orgapachesling-1
789
  -   - https://repository.apache.org/content/repositories/orgapachesli
ng-1790


You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1789 /tmp/sling-staging
sh check_staged_release.sh 1790 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Thanks,

Robert

Re: [VOTE] Release Apache Sling Thread Support 3.2.8, Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tes

[Robert Munteanu]

To be on the safe side, I'll restart the vote since we changed the set
of artifacts.

Thanks,

Robert

On Sun, 2017-09-24 at 00:13 +0200, Konrad Windszus wrote:
> Please cancel only the vote for Thread Support, I am hoping to come
> up with a fix next week.
> Konrad 
> 
> 
> Von meinem iPhone gesendet
> 
> > Am 23.09.2017 um 22:19 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > Konrad, Stefan,
> > 
> > What's your take on this? Should I cancel the vote and wait for a
> > fix
> > or go through with the release and fire off another release vote
> > for
> > the commons.threads bundles once we have a fix?
> > 
> > Robert
> > 
> > > On Thu, 2017-09-21 at 12:25 +0200, Konrad Windszus wrote:
> > > For me the test runs fine with both Java 7 and Java 8.
> > > But according to your stack traces it seems that the table array
> > > within ThreadLocalMap contains some null entries (compare with
> > > https:
> > > //doanduyhai.wordpress.com/2011/12/04/threadlocal-explained/).
> > > The entry objects within the table are WeakReferences themselves,
> > > i.e. can become null if the key = the threadLocal object bound to
> > > the
> > > thread is no longer referenced.
> > > 
> > > Currently the diff method does not correctly deal with it.
> > > I will first try to make an IT which does reliably fail for
> > > everyone
> > > and then try to come up with a fix.
> > > Thanks for reporting.
> > > Konrad
> > > 
> > > > On 21. Sep 2017, at 10:48, Stefan Seifert <sseifert@pro-vision.
> > > > de>
> > > > wrote:
> > > > 
> > > > Apache Sling Thread Support 3.2.8
> > > > -> i've a problem running the unit tests. the run fine, up to
> > > > rev.
> > > > 1790774, but fail from rev. 1791091 (SLING-6261). is it only on
> > > > my
> > > > machine? see below
> > > > 
> > > > Apache Sling Scripting Core implementation 2.0.48
> > > > +1
> > > > 
> > > > Apache Event Support 4.2.8
> > > > +1
> > > > 
> > > > Apache Sling SlingStart Maven Plugin 1.7.10
> > > > +1
> > > > 
> > > > Apache Sling JUnit Tests Teleporter 1.0.16
> > > > +1
> > > > 
> > > > Apache Sling Testing Utilities 2.1.2
> > > > +1
> > > > 
> > > > stefan
> > > > 
> > > > 
> > > > unit test errors in thread support 3.2.8:
> > > > 
> > > > ---
> > > > T E S T S
> > > > ---
> > > > Running
> > > > org.apache.sling.commons.threads.impl.ExtendedThreadFactoryTest
> > > > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> > > > 0.002 sec - in
> > > > org.apache.sling.commons.threads.impl.ExtendedThreadFactoryTest
> > > > Running
> > > > org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleanin
> > > > gThr
> > > > eadLocalsTest
> > > > Exception in thread "pool-9-thread-1"
> > > > java.lang.NullPointerException
> > > >   at
> > > > org.apache.sling.commons.threads.impl.ThreadLocalCleaner.change
> > > > d(Th
> > > > readLocalCleaner.java:140)
> > > >   at
> > > > org.apache.sling.commons.threads.impl.ThreadLocalCleaner.diff(T
> > > > hrea
> > > > dLocalCleaner.java:104)
> > > >   at
> > > > org.apache.sling.commons.threads.impl.ThreadLocalCleaner.cleanu
> > > > p(Th
> > > > readLocalCleaner.java:79)
> > > >   at
> > > > org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleanin
> > > > gThr
> > > > eadLocals.afterExecute(ThreadPoolExecutorCleaningThreadLocals.j
> > > > ava:
> > > > 63)
> > > >   at
> > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExe
> > > > cuto
> > > > r.java:1150)
> > > >   at
> > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolEx
> > > > ecut
> > > > or.java:617)
> > > >   at java.lang.Thread.run(Thread.java:745)
> > > > Exception in thread "pool-9-thread-2"
> > > > java.l

Re: [VOTE] Release Apache Sling Scripting Core implementation 2.0.48, Apache Event Support 4.2.8, Apache Sling SlingStart Maven Plugin 1.7.10, Apache Sling JUnit Tests Teleporter 1.0.16, Apache Sling

[Robert Munteanu]

On Mon, 2017-09-25 at 13:50 +0200, Robert Munteanu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [RT] Drop port 8888?

[Robert Munteanu]

On Thu, 2017-08-24 at 13:19 +0200, Oliver Lietz wrote:
> I guess  was chosen to prevent clashes with other servers running
> on the 
> same machine and bound to 8080, e.g. Jenkins or regular Sling. Why
> not use 
> dynamic ports when running tests?

Integration tests are using dynamic ports as far as I know. So there
would be no clashes there.

Robert

Re: [RESULT] [VOTE] Release Apache Sling Provisioning Model 1.8.4

[Robert Munteanu]

On Tue, 2017-08-22 at 10:04 +0200, Robert Munteanu wrote:
> On Tue, 2017-08-22 at 07:20 +, Tomek Rekawek wrote:
> > Hi,
> > 
> > The vote has passed with the following result :
> > 
> > +1 (binding): Robert Munteanu, Carsten Ziegeler, Justin Edelson
> > 
> > I will promote the artifacts to the central Maven repository.
> > 
> > May I ask a PMC member to copy this release to the Sling dist
> > directory?
> 
> Done in r21255.

Actually in r21258, previous commit was a mix-up.

Robert

Re: Release Sling 10?

[Robert Munteanu]

On Mon, 2017-08-14 at 15:55 +0200, Carsten Ziegeler wrote:
> Robert Munteanu wrote
> > Hi,
> > 
> > I'd like to do a "small" launchpad release for Java 9 support.
> > Sling
> > starts up and seems to be working fine with Java 9. I'd like to
> > also
> > set up Jenkins to run the ITs with Java 9, and then we can start a
> > release vote.
> > 
> > Does anyone have any comments on this or maybe any inclusions we
> > should
> > wait for with Sling 10?
> > 
> 
> I think we should make sure that we include the latest versions of
> our
> own bundles.
> And maybe we can also update some of the other bundles (like some
> Apache
> Felix  modules) to the latest version.
> 
> But other than that, big +1 for Sling 10

Good point, added a sub-task to https://issues.apache.org/jira/browse/S
LING-6952 .

Robert

Re: Release Sling 10?

[Robert Munteanu]

On Mon, 2017-08-14 at 18:31 +0200, Karl Pauls wrote:
> I was thinking about doing another framework release soon-ish (eta
> next
> week). Maybe we could include that one as well (it might bring some
> performance benefit and fixes some lifecycle bugs).

Ack, will definitely wait for that - the Java 9 story seems to be a bit
more involved - see dependency chain of SLING-7046 [1] for details.

Robert

[1]: https://issues.apache.org/jira/browse/SLING-7046

Re: Restricting sling health checks

[Robert Munteanu]

Hi Andrei,

On Mon, 2017-08-21 at 11:55 +, Andrei Kalfas wrote:
> Hi,
> 
> Well, as far as I can tell, out of the box that URL can be called
> from anywhere. Thing is that I don’t quite care what would be the
> means to restrict access to the health check url as long as I don’t
> have to configure proxies. 


I don't think you have something like that in Sling.

It's a good idea to restrict access to the whole /system when running
Sling apps. In the AEM world you would use the dispatcher. In the Sling
world, ... well anything else than the dispatcher :-)

Hope this helps,

Robert

Re: [VOTE] Release Apache Sling Scripting JSP 2.3.2

[Robert Munteanu]

On Mon, 2017-08-21 at 11:47 +0200, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release Apache Sling Commons Scheduler 2.7.0

[Robert Munteanu]

On Tue, 2017-08-22 at 11:35 +0200, Carsten Ziegeler wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release Apache Sling Slingstart Maven Plugin 1.7.8

[Robert Munteanu]

On Tue, 2017-08-22 at 07:45 +, Tomek Rekawek wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: [RESULT] [VOTE] Release Apache Sling Provisioning Model 1.8.4

[Robert Munteanu]

On Tue, 2017-08-22 at 07:20 +, Tomek Rekawek wrote:
> Hi,
> 
> The vote has passed with the following result :
> 
> +1 (binding): Robert Munteanu, Carsten Ziegeler, Justin Edelson
> 
> I will promote the artifacts to the central Maven repository.
> 
> May I ask a PMC member to copy this release to the Sling dist
> directory?

Done in r21255.

Robert

[RT] Drop port 8888?

[Robert Munteanu]

Hi,

We are using two main ports when dealing with Sling:

- 8080 for 'regular' instances
-  for 'testing' instances - mainly used in the integration tests

I usually notice this when I want to try running an IT from my IDE
against a running Sling instance and it times out looking for something
on port  .

I am not familiar with the reasons for using port , but would it be
worth dropping this port and using 8080 from now on? It would IMO make
development with Sling simpler.

The changes would be quite localised:

- code change in
bundles/commons/testing/src/main/java/org/apache/sling/commons/testing/
integration/HttpTestBase.java
- documentation changes in launchpad and contrib/launchpad

Thoughts?

Robert

Re: [VOTE] Release Apache Sling Launchpad Base 5.6.8-2.6.24

[Robert Munteanu]

On Mon, 2017-08-28 at 17:29 +0200, Karl Pauls wrote:
> Please vote to approve these releases:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Re: Java 9, parent pom and maven-antrun-plugin removal

[Robert Munteanu]

Ack. FWIW this level of scrutiny is always desirable in my opinion,
even if sometimes it does not leads to a change.

Thanks,

Robert

On Mon, 2017-09-04 at 16:22 +0200, Konrad Windszus wrote:
> Ok, I retract my -1 vote. I will investigate further once I am back
> from vacation.
> Sorry, I really assumed that the BREE header would be the same
> format.
> 
> Von meinem iPhone gesendet
> 
> > Am 04.09.2017 um 14:01 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > On Mon, 2017-09-04 at 13:06 +0200, Konrad Windszus wrote:
> > > > Am 04.09.2017 um 11:30 schrieb Robert Munteanu <rombert@apache.
> > > > org>
> > > > :
> > > > 
> > > > > On Mon, 2017-09-04 at 08:55 +0200, Konrad Windszus wrote:
> > > > > If I understand correctly we only need to extract the
> > > > > relevant
> > > > > version from the sling java property and use that then in the
> > > > > configuration of other plugins (like animal sniffer or m-c-
> > > > > p).
> > > > > That
> > > > > is totally possible with the mentioned buildhelper plugin. 
> > > > 
> > > > Agreed.
> > > > 
> > > > > There is no need for a dedicated plugin. The BREE header is
> > > > > mostly
> > > > > static and must be set in the m-b-p configuration. The
> > > > > dynamic
> > > > > part
> > > > > can also be retrieved via the buildhelper plugin. I hope this
> > > > > makes
> > > > > things clearer.
> > > > 
> > > > The BREE header is set following the sling.java.version
> > > > property.
> > > > Yes,
> > > > it is mostly static but does not directly follow the Java
> > > > version (
> > > > see
> > > > [1] for more details). Here is a mapping of sling.java.version
> > > > to
> > > > BREE
> > > > headers:
> > > > 
> > > > 5  - J2SE-1.5
> > > > 6  - JavaSE-1.6
> > > > 7  - JavaSE-1.7
> > > > 8  - JavaSE-1.8
> > > > 9  - JavaSE-9
> > > > 
> > > > This is something that we mapped with the antrun plugin stuff.
> > > > Now
> > > > I
> > > > propose switching to a custom plugin due to Java 9 issues.
> > > > 
> > > > I still don't see how the BREE header can be configured using
> > > > the
> > > > buildhelper plugin. Can you add a small config snippet or link
> > > > to
> > > > an
> > > > example?
> > > > 
> > > 
> > > Supporting Java5 is probably not necessary and even for Java 9
> > > JavaSE-1.9 seems valid. 
> > 
> > Seems, but it is not :-)
> > 
> > I started the Sling launchpad with Java 9 and the system bundle
> > provides the following capabilities:
> > 
> > osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 1.1, 1.2",
> > osgi.ee;
> > osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6,
> > 1.7,
> > 1.8, 9", 
> > osgi.ee; osgi.ee="JavaSE/compact1"; version:List="1.8, 9",
> > osgi.ee; osgi.ee="JavaSE/compact2"; version:List="1.8, 9",
> > osgi.ee; osgi.ee="JavaSE/compact3"; version:List="1.8, 9"
> > 
> > Note the 9 everywhere, following the version change in Java:
> > 
> > $ /opt/jdk-9/bin/java -version
> > java version "9"
> > (snip)
> > 
> > > I think you can generate the header then with the following bnd
> > > instruction: http://bnd.bndtools.org/instructions/runee.html
> > 
> > The way I read it, this instruction parses a string argument into
> > an EE
> > enum. That does not help us as we are using a 'plain' java version
> > string, not a legal execution environment value.
> > 
> > -
> > 
> > I understand the desire to not reinvent the wheel, especially with
> > infrastructure code. However, releasing this plugin unblocks us
> > with
> > testing for Java 9, which has further issues once we run the ITs.
> > 
> > Releasing a version of this plugin does not mean we'll never
> > revisit
> > the solution. If there is something better, I'm happy to remove the
> > plugin from our parent pom. But given that the code is there, it's
> > small and self-contained I'm inclined just to use it for now, and
> > when
> > we have a bet

[RESULT] [VOTE] Release Apache Sling Parent 32, Apache Sling Java Version Maven Plugin 1.0.0

[Robert Munteanu]

Hi,

The vote has passed with the following result :

+1 (binding): Carsten Ziegeler, Karl Pauls, Robert Munteanu


I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Thanks,

Robert

Re: Java 9, parent pom and maven-antrun-plugin removal

[Robert Munteanu]

On Mon, 2017-09-04 at 08:55 +0200, Konrad Windszus wrote:
> If I understand correctly we only need to extract the relevant
> version from the sling java property and use that then in the
> configuration of other plugins (like animal sniffer or m-c-p). That
> is totally possible with the mentioned buildhelper plugin. 

Agreed.

> There is no need for a dedicated plugin. The BREE header is mostly
> static and must be set in the m-b-p configuration. The dynamic part
> can also be retrieved via the buildhelper plugin. I hope this makes
> things clearer.

The BREE header is set following the sling.java.version property. Yes,
it is mostly static but does not directly follow the Java version ( see
[1] for more details). Here is a mapping of sling.java.version to BREE
headers:

5  - J2SE-1.5
6  - JavaSE-1.6
7  - JavaSE-1.7
8  - JavaSE-1.8
9  - JavaSE-9

This is something that we mapped with the antrun plugin stuff. Now I
propose switching to a custom plugin due to Java 9 issues.

I still don't see how the BREE header can be configured using the
buildhelper plugin. Can you add a small config snippet or link to an
example?

Thanks,

Robert


[1]: https://www.osgi.org/developer/specifications/reference/
> 
> Von meinem iPhone gesendet
> 
> > Am 03.09.2017 um 23:01 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > Hi Konrad,
> > 
> > > On Sat, 2017-09-02 at 10:38 +0200, Konrad Windszus wrote:
> > > Sorry for answering late, but wouldn't the buildhelper plugin
> > > with
> > > its parse-version fulfill our needs: http://www.mojohaus.org/buil
> > > d-he
> > > lper-maven-plugin/parse-version-mojo.html
> > > 
> > > That should be able to generate all version strings in the
> > > required
> > > formats from one source property.
> > 
> > The functionality is not about setting the project's version, but
> > about
> > generating the 'minimum supported java' version for various
> > plugins.
> > For javac and animal-sniffer it's usually the Java version number.
> > For
> > the maven-bundle-plugin it's the Bundle-
> > RequiredExecutionEnvironment
> > header.
> > 
> > I don't see how the build helper plugin can generate the Bundle-
> > RequiredExecutionEnvironment header. Is there such an option?
> > 
> > Thanks,
> > 
> > Robert
> > 
> > > 
> > > Von meinem iPhone gesendet
> > > 
> > > > Am 01.09.2017 um 10:10 schrieb Karl Pauls <karlpa...@gmail.com>
> > > > :
> > > > 
> > > > +1
> > > > 
> > > > regards,
> > > > 
> > > > Karl
> > > > 
> > > > > On Fri, Sep 1, 2017 at 8:35 AM, Carsten Ziegeler <cziegeler@a
> > > > > pach
> > > > > e.org> wrote:
> > > > > Sounds good to me, thanks Robert
> > > > > 
> > > > > Carsten
> > > > > 
> > > > > Robert Munteanu wrote
> > > > > > Hi,
> > > > > > 
> > > > > > As you might know, running the Sling ITs with Java 9 is
> > > > > > blocked
> > > > > > by an
> > > > > > incompatibility of the maven-antrun-plugin with Java 9
> > > > > > ([1],
> > > > > > [2]).
> > > > > > 
> > > > > > It seems that a solution is not yet agreed on and I'd like
> > > > > > to
> > > > > > start
> > > > > > running the ITs on Java 9 sooner rather than later.
> > > > > > 
> > > > > > To that end, I've written a tiny Maven plugin which does
> > > > > > exactly what
> > > > > > the maven-antrun-plugin snippet did [3]. TBH, I never
> > > > > > really
> > > > > > liked
> > > > > > scripting in the pom but that's another issue :-)
> > > > > > 
> > > > > > Anyway, my proposal is to drop the maven-antrun-plugin
> > > > > > _only_
> > > > > > for
> > > > > > setting the project properties in the parent pom. Bertrand
> > > > > > rightly
> > > > > > mentioned that we have other usages all over Sling, but
> > > > > > those
> > > > > > do not
> > > > > > affect running the ITs and I won't touch them.
> > > > > > 
> > > > > > Thoughts?
> > > > > > 
> > > > > > Robert
> > > > > > 
> > > > > > [1]: https://issues.apache.org/jira/browse/SLING-7072
> > > > > > [2]: https://issues.apache.org/jira/browse/MNG-6275
> > > > > > [3]: http://svn.apache.org/viewvc?rev=1806875=rev
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Carsten Ziegeler
> > > > > Adobe Research Switzerland
> > > > > cziege...@apache.org
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Karl Pauls
> > > > karlpa...@gmail.com
> 
> 

Re: Java 9, parent pom and maven-antrun-plugin removal

[Robert Munteanu]

On Mon, 2017-09-04 at 13:06 +0200, Konrad Windszus wrote:
> > Am 04.09.2017 um 11:30 schrieb Robert Munteanu <romb...@apache.org>
> > :
> > 
> > > On Mon, 2017-09-04 at 08:55 +0200, Konrad Windszus wrote:
> > > If I understand correctly we only need to extract the relevant
> > > version from the sling java property and use that then in the
> > > configuration of other plugins (like animal sniffer or m-c-p).
> > > That
> > > is totally possible with the mentioned buildhelper plugin. 
> > 
> > Agreed.
> > 
> > > There is no need for a dedicated plugin. The BREE header is
> > > mostly
> > > static and must be set in the m-b-p configuration. The dynamic
> > > part
> > > can also be retrieved via the buildhelper plugin. I hope this
> > > makes
> > > things clearer.
> > 
> > The BREE header is set following the sling.java.version property.
> > Yes,
> > it is mostly static but does not directly follow the Java version (
> > see
> > [1] for more details). Here is a mapping of sling.java.version to
> > BREE
> > headers:
> > 
> > 5  - J2SE-1.5
> > 6  - JavaSE-1.6
> > 7  - JavaSE-1.7
> > 8  - JavaSE-1.8
> > 9  - JavaSE-9
> > 
> > This is something that we mapped with the antrun plugin stuff. Now
> > I
> > propose switching to a custom plugin due to Java 9 issues.
> > 
> > I still don't see how the BREE header can be configured using the
> > buildhelper plugin. Can you add a small config snippet or link to
> > an
> > example?
> > 
> 
> Supporting Java5 is probably not necessary and even for Java 9
> JavaSE-1.9 seems valid. 

Seems, but it is not :-)

I started the Sling launchpad with Java 9 and the system bundle
provides the following capabilities:

osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 1.1, 1.2", osgi.ee;
osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7,
1.8, 9", 
osgi.ee; osgi.ee="JavaSE/compact1"; version:List="1.8, 9",
osgi.ee; osgi.ee="JavaSE/compact2"; version:List="1.8, 9",
osgi.ee; osgi.ee="JavaSE/compact3"; version:List="1.8, 9"

Note the 9 everywhere, following the version change in Java:

$ /opt/jdk-9/bin/java -version
java version "9"
(snip)

> I think you can generate the header then with the following bnd
> instruction: http://bnd.bndtools.org/instructions/runee.html

The way I read it, this instruction parses a string argument into an EE
enum. That does not help us as we are using a 'plain' java version
string, not a legal execution environment value.

-

I understand the desire to not reinvent the wheel, especially with
infrastructure code. However, releasing this plugin unblocks us with
testing for Java 9, which has further issues once we run the ITs.

Releasing a version of this plugin does not mean we'll never revisit
the solution. If there is something better, I'm happy to remove the
plugin from our parent pom. But given that the code is there, it's
small and self-contained I'm inclined just to use it for now, and when
we have a better solution retire it.

Thanks,

Robert

> 
> > Thanks,
> > 
> > Robert
> > 
> > 
> > [1]: https://www.osgi.org/developer/specifications/reference/
> > > 
> > > Von meinem iPhone gesendet
> > > 
> > > > Am 03.09.2017 um 23:01 schrieb Robert Munteanu <rombert@apache.
> > > > org>
> > > > :
> > > > 
> > > > Hi Konrad,
> > > > 
> > > > > On Sat, 2017-09-02 at 10:38 +0200, Konrad Windszus wrote:
> > > > > Sorry for answering late, but wouldn't the buildhelper plugin
> > > > > with
> > > > > its parse-version fulfill our needs: http://www.mojohaus.org/
> > > > > buil
> > > > > d-he
> > > > > lper-maven-plugin/parse-version-mojo.html
> > > > > 
> > > > > That should be able to generate all version strings in the
> > > > > required
> > > > > formats from one source property.
> > > > 
> > > > The functionality is not about setting the project's version,
> > > > but
> > > > about
> > > > generating the 'minimum supported java' version for various
> > > > plugins.
> > > > For javac and animal-sniffer it's usually the Java version
> > > > number.
> > > > For
> > > > the maven-bundle-plugin it's the Bundle-
> > > > RequiredExecutionEnvironment
> > > > header.