[jira] [Commented] (SLING-10031) Move MediaRangeList from Servlets POST to Sling API

2020-12-31 Thread Eric Norman (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257085#comment-17257085
 ] 

Eric Norman commented on SLING-10031:
-

[~olli] It looks like the consumer bundles that import and use stuff from the  
{{org.apache.sling.api.request }}package are probably getting a too specific 
range for the import package version?

Specifically, the import-package item ends up as: org.apache.sling.api.request; 
version="[2.4, 2.5)" for the following bundles which leads to troubles running 
the automated tests in the servlets.resolver project since the new "2.5.0" 
exported package number no longer satisfies that range:
 # org.apache.sling.jcr.jackrabbit.usermanager
 # org.apache.sling.scripting.sightly
 # org.apache.sling.servlets.resolver

I'm assuming this has something to do with bndlib choosing the  
"provider-policy" instead of the "consumer-policy" when calculating the version 
ranges?

>From what I read, the default definitions are:

 
{code:java}
-consumer-policy ${range;[==,+)} 
-provider-policy ${range;[==,=+)} 
{code}
 

I'm not sure what the best solution is here.  Should the ConsumerType and 
ProviderType annotated classes be in different packages to account for how the 
import version policy of bnd treats those?  Or should the consumers supply a 
custom import package macro like the following to override the default behavior?
{code:java}
org.apache.sling.api.request; version="${range;[==,+)}"{code}
Or maybe some other solution that I haven't thought of?

> Move MediaRangeList from Servlets POST to Sling API
> ---
>
> Key: SLING-10031
> URL: https://issues.apache.org/jira/browse/SLING-10031
> Project: Sling
>  Issue Type: Task
>  Components: API, Servlets
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: API 2.23.2, Servlets POST 2.3.38
>
>
> {{org.apache.sling.servlets.post.impl.helper}} → 
> {{org.apache.sling.api.request}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (SLING-10035) Sling Feature fails when Generated Features Directory is missing

2020-12-31 Thread Andreas Schaefer (Jira)


[ 
https://issues.apache.org/jira/browse/SLING-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257077#comment-17257077
 ] 

Andreas Schaefer commented on SLING-10035:
--

Created a PR for this: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/63

> Sling Feature fails when Generated Features Directory is missing
> 
>
> Key: SLING-10035
> URL: https://issues.apache.org/jira/browse/SLING-10035
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.4.20
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.4.22
>
>
> When I want to aggregate a Feature Model in another module like 'all' and 
> there is not attachment or other FM generation task beforehand the Sling 
> Feature Maven Plugin fails in handleGeneratedFeatures() method. This can be 
> fixed by copying the target folder from the resources but that is a lot of 
> unnecessary work.
>  
> I added code to that method that tries to create the folder if it does not 
> exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [sling-slingfeature-maven-plugin] schaefa commented on pull request #63: Added the creation of the Generated Feature Model folder it is does n…

2020-12-31 Thread GitBox


schaefa commented on pull request #63:
URL: 
https://github.com/apache/sling-slingfeature-maven-plugin/pull/63#issuecomment-753025388


   This is based on ticket: https://issues.apache.org/jira/browse/SLING-10035



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[GitHub] [sling-slingfeature-maven-plugin] schaefa opened a new pull request #63: Added the creation of the Generated Feature Model folder it is does n…

2020-12-31 Thread GitBox


schaefa opened a new pull request #63:
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/63


   …ot exist. This can happen if there is no prior attachment or other FM 
generation and the Maven module in question is just doing the aggregation.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[jira] [Created] (SLING-10035) Sling Feature fails when Generated Features Directory is missing

2020-12-31 Thread Andreas Schaefer (Jira)
Andreas Schaefer created SLING-10035:


 Summary: Sling Feature fails when Generated Features Directory is 
missing
 Key: SLING-10035
 URL: https://issues.apache.org/jira/browse/SLING-10035
 Project: Sling
  Issue Type: Bug
  Components: Feature Model
Affects Versions: slingfeature-maven-plugin 1.4.20
Reporter: Andreas Schaefer
Assignee: Andreas Schaefer
 Fix For: slingfeature-maven-plugin 1.4.22


When I want to aggregate a Feature Model in another module like 'all' and there 
is not attachment or other FM generation task beforehand the Sling Feature 
Maven Plugin fails in handleGeneratedFeatures() method. This can be fixed by 
copying the target folder from the resources but that is a lot of unnecessary 
work.

 

I added code to that method that tries to create the folder if it does not 
exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (SLING-10023) Update launchpad to Apache Felix Framework 7.0.0

2020-12-31 Thread Karl Pauls (Jira)


 [ 
https://issues.apache.org/jira/browse/SLING-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls closed SLING-10023.
--

> Update launchpad to Apache Felix Framework 7.0.0
> 
>
> Key: SLING-10023
> URL: https://issues.apache.org/jira/browse/SLING-10023
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.6.38
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Launchpad Base 2.7.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We should update the launchpad base to Felix framework 7.0.0. As that will 
> require java8 now and implements the R8 core spec we should bump the minor 
> version.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [RESULT][VOTE] Release Apache Sling Launchpad Base 7.0.0-2.7.0

2020-12-31 Thread Karl Pauls
Time to call the vote on the Apache Sling Launchpad Base 7.0.0-2.7.0 release.

* +1 votes from Carsten Ziegeler, David Bosschaert, and Karl Pauls.

* No other votes.

The vote is successful. I will make the artifacts available as soon as possible.


Re: [VOTE] Release Apache Sling Launchpad Base 7.0.0-2.7.0

2020-12-31 Thread Karl Pauls
+1

regards,

Karl

On Wed, Dec 30, 2020 at 6:24 PM  wrote:
>
> +1
>
> David
>
> On Wednesday, 30 December 2020, Carsten Ziegeler 
> wrote:
>
> > +1
> >
> > Carsten
> >
> > Am 28.12.2020 um 12:13 schrieb Karl Pauls:
> >
> >> We solved 1 issue in this release:
> >> https://issues.apache.org/jira/projects/SLING/versions/12349525
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachesling-2389
> >>
> >> You can use this UNIX script to download the release and verify the
> >> signatures:
> >> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.
> >> git;a=blob;f=check_staged_release.sh;hb=HEAD
> >>
> >> Usage:
> >> sh check_staged_release.sh 2389 /tmp/sling-staging
> >>
> >> Please vote to approve these releases:
> >>
> >>[ ] +1 Approve the releases
> >>[ ]  0 Don't care
> >>[ ] -1 Don't release, because ...
> >>
> >>
> > --
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >



-- 
Karl Pauls
karlpa...@gmail.com


Re: Sling Parent: Two source artifacts per release in Maven Central

2020-12-31 Thread Konrad Windszus
Hi,
The reason why "source-release" only appears for very few Maven GAVs in other 
Apache projects is the configuration parameter "runOnlyAtExecutionRoot" 
(https://github.com/apache/maven-apache-parent/blob/01d812b4e78c1661ad61b1d1befcccbed2cc3e3f/pom.xml#L380
 
)
This means that for multi-module releases the source-release only appears on 
the reactor project itself.
For Sling we usually have single-module releases.
As uploading to the Staging Repo but not publishing to Maven Central afterwards 
is not possible, we should not change anything, but probably it is worth to 
document the different classifiers per GAV available from Maven Central in 
https://sling.apache.org/downloads.cgi .
I am gonna prepare a PR.

Konrad

> On 30. Dec 2020, at 20:33, Konrad Windszus  wrote:
> 
> Hi,
> currently all our releases have two different source artifacts:
> 
> - classifier "source-release", generated from 
> https://github.com/apache/maven-apache-parent/blob/01d812b4e78c1661ad61b1d1befcccbed2cc3e3f/pom.xml#L362
> - classifier "sources", generated from 
> https://github.com/apache/sling-parent/blob/96e3aa372ae124d0ab982d9c3fe560766f2d5ede/sling-parent/pom.xml#L147
> 
> You find both artifacts linked e.g. in 
> https://search.maven.org/search?q=sling-settings.
> 
> Was it a deliberate decision to push both to Maven Central?
> I do understand that the first one is the official one relevant for ASF, but 
> for consumers it seems that rather the "sources" one is interesting.
> 
> I quickly cross-checked other ASF projects, and it seems they never upload 
> "source-release" to Maven Central, e.g. 
> https://search.maven.org/search?q=a:oak-run or 
> https://search.maven.org/artifact/org.apache.maven.plugins/maven-release-plugin/3.0.0-M1/maven-plugin
>  but only the "sources" one.
> 
> Should we do the same? If so, any idea how to have both in our staging 
> repository (to be able to vote on both artifacts) but only push one to Maven 
> Central in the end?
> 
> Thanks,
> Konrad