[jira] [Closed] (SLING-11411) Remove scope from dependency management

[ https://issues.apache.org/jira/browse/SLING-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed SLING-11411. --- > Remove scope from dependency managem

[jira] [Updated] (SLING-11411) Remove scope from dependency management

ing the scope in the depMgmt is an > [anti-pattern|https://stackoverflow.com/a/20750041], as it makes it very hard > to override the scope. Therefore all scopes should be removed from the > dependency management in the parent poms and at the same time it should be > enforced that the scope i

[jira] [Commented] (SLING-11411) Remove scope from dependency management

/apache/sling-org-apache-sling-api/pull/44: !Screenshot 2022-06-24 at 14.11.25.png! > Remove scope from dependency management > --- > > Key: SLING-11411 > URL: https://issues.apache.org/jira/browse/SLING-11411 >

[jira] [Updated] (SLING-11411) Remove scope from dependency management

://stackoverflow.com/a/20750041], as it makes it very hard to override the scope. Therefore all scopes should be removed from the dependency management in the parent poms and at the same time it should be enforced that the scope is always explicitly set locally with an enforcer rule (SLING-11410) (was: Managing

[jira] [Updated] (SLING-11411) Remove scope from dependency management

://stackoverflow.com/a/20750041], as it makes it very hard to override the scope. Therefore all scopes should be removed from the dependency management in the parent poms and at the same time it should be enforced that the scope is always explicitly set locally with an enforcer rule (SLING-11410) (was: Managing

[jira] [Created] (SLING-11411) Remove scope from dependency management

Konrad Windszus created SLING-11411: --- Summary: Remove scope from dependency management Key: SLING-11411 URL: https://issues.apache.org/jira/browse/SLING-11411 Project: Sling Issue Type

Re: Dependency Management

Hi, On Fri, Jun 3, 2016 at 11:20 AM, Oliver Lietz wrote: > ...AFAIR we are moving ITs closer to the code under test (Bertrand?)... Yes, I've been doing that and encouraging people to do so. OTOH the existing integration test suite in launchpad/integration-tests works and

Re: Dependency Management

Hi, On Tue, Jun 7, 2016 at 1:16 PM, Georg Henzler wrote: > ... just tried to run the latest with hc-core [1] to test something > completely else and obviously it does not work with AEM anymore unless you > deploy commons lang3 elsewhere... I agree that that's bad, because

Re: Dependency Management

On 2016-05-26 14:36, Bertrand Delacretaz wrote: My opinion, and I think this is what we've been doing in Sling forever even if we didn't explicitly document it, is that if a bundle B depends on another *for its API* then the dependency should list the lowest possible version. I agree to this.

Re: Dependency Management

> On 07 Jun 2016, at 10:32, Konrad Windszus wrote: > > Hi, >> On 07 Jun 2016, at 10:12, Oliver Lietz wrote: >> >> On Monday 06 June 2016 14:57:16 Konrad Windszus wrote: >>> I would like to wrap things up here: >>> >>> So it seems the common agreement

Re: Dependency Management

Hi, > On 07 Jun 2016, at 10:12, Oliver Lietz wrote: > > On Monday 06 June 2016 14:57:16 Konrad Windszus wrote: >> I would like to wrap things up here: >> >> So it seems the common agreement is: > > Really? > >> 1) Depend on the lowest possible version of a dependency

Re: Dependency Management

On Monday 06 June 2016 14:57:16 Konrad Windszus wrote: > I would like to wrap things up here: > > So it seems the common agreement is: Really? > 1) Depend on the lowest possible version of a dependency (to let bnd > generate import package ranges which are as broad as possible to support as >

Re: Dependency Management

I would like to wrap things up here: So it seems the common agreement is: 1) Depend on the lowest possible version of a dependency (to let bnd generate import package ranges which are as broad as possible to support as many different systems as possible (even old ones)). A module should only

Re: Dependency Management

On Friday 03 June 2016 20:13:29 Steven Walters wrote: > On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz wrote: > > On Monday 30 May 2016 15:28:04 Robert Munteanu wrote: > > > On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote: > > > > I don't think there is support in Maven

Re: Dependency Management

On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz wrote: > > On Monday 30 May 2016 15:28:04 Robert Munteanu wrote: > > On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote: > > > I don't think there is support in Maven 3 for unit tests using a > > > different > > > version than

Re: Dependency Management

On Monday 30 May 2016 15:28:04 Robert Munteanu wrote: > On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote: > > I don't think there is support in Maven 3 for unit tests using a > > different > > version than for compile. Not sure if other build tools can handle > > different > > versions of

Re: Dependency Management

On Fri, 2016-05-27 at 09:55 +0200, Konrad Windszus wrote: > I understand and agree with 1. > For 2. I am not on the same page: > > Why should we run ITs with the most recent version instead of the > lowest required version? IMO we should test with the version that is available in the launchpad

Re: Dependency Management

On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote: > > I don't think there is support in Maven 3 for unit tests using a > different  > version than for compile. Not sure if other build tools can handle > different  > versions of dependencies for compile and test. Maven 3 is unable to do

Re: Dependency Management

> On 27 May 2016, at 11:14, Oliver Lietz wrote: > > Upgrading a library bundle to a newer version does NOT break compatibility > with Sling's downstream systems. It is not like upgrading from Java 7 to 8 or > from Declarative Services 1.2 to 1.3. > > If you can deploy

Re: Dependency Management

Upgrading a library bundle to a newer version does NOT break compatibility with Sling's downstream systems. It is not like upgrading from Java 7 to 8 or from Declarative Services 1.2 to 1.3. If you can deploy a newer version of a components/services bundle which runs as singleton (e.g. HC

Re: Dependency Management

Konrad Windszus wrote > I am strongly in favor of letting bnd generate the Import-Package headers > (incl. version ranges) and to not tweak those manually. > Manually adjusting the process is IMHO very error-prone. +5 Carsten -- Carsten Ziegeler Adobe Research Switzerland

Re: Dependency Management

I am strongly in favor of letting bnd generate the Import-Package headers (incl. version ranges) and to not tweak those manually. Manually adjusting the process is IMHO very error-prone. Konrad > On 26 May 2016, at 18:13, Julian Sedding wrote: > > Addendum: I just read

Re: Dependency Management

Addendum: I just read Olli's comment in the ticket. My requirement is that we keep the Import_package version ranges of bundles flexible in order not to require artificially high 3rd party dependency versions. How we achieve this is up for debate and ultimately a tooling issue (by default bnd

Re: Dependency Management

+1 to Bertrand's summary. That matches my understanding of how we're dealing with 3rd party dependencies in Sling. 1. Keep the *required* version of a 3rd party library (an external API we depend upon) as low as easily practical. I.e. normally we don't work around bugs or missing new APIs in 3rd

Re: Dependency Management

Hi, > Am 26.05.2016 um 14:36 schrieb Bertrand Delacretaz : > > Hi, > > On Thu, May 26, 2016 at 10:21 AM, Konrad Windszus wrote: >> ...there was quite a discussion going on in >> https://issues.apache.org/jira/browse/SLING-5603 on how >> to deal with 3rd

Re: Dependency Management

Hi, On Thu, May 26, 2016 at 10:21 AM, Konrad Windszus wrote: > ...there was quite a discussion going on in > https://issues.apache.org/jira/browse/SLING-5603 on how > to deal with 3rd party dependencies in Sling My opinion, and I think this is what we've been doing in

Dependency Management

Hi together, there was quite a discussion going on in https://issues.apache.org/jira/browse/SLING-5603 on how to deal with 3rd party dependencies in Sling. There are basically two different opinions there: a) let each bundle decide on its own in which version it depends on a certain 3rd party

[jira] [Updated] (SLING-3994) Simplify dependency management by letting the caller to supply its own implementations

[ https://issues.apache.org/jira/browse/SLING-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated SLING-3994: --- Fix Version/s: Content Distribution 0.1.0 Simplify dependency management by letting

RE: Question on dependency management while adding a test case

this worked well, resolved in https://issues.apache.org/jira/browse/SLING-4033 stefan -Original Message- From: Julian Sedding [mailto:jsedd...@gmail.com] Sent: Friday, October 10, 2014 4:28 PM To: dev@sling.apache.org Subject: Re: Question on dependency management while adding a test

Question on dependency management while adding a test case

Hello Team, I am adding a test case of [0], for this I need to use latest of groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.testing.resourceresolver-mock/artifactId ? This introduces a dependency to sling.api:2.7.0, because of resource.getValueMap sling

Re: Question on dependency management while adding a test case

Hi Amit, On Fri, Oct 10, 2014 at 10:57 AM, Amit.. Gupta. amitg...@adobe.com wrote: Hello Team, I am adding a test case of [0], for this I need to use latest of groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.testing.resourceresolver-mock/artifactId ?

Re: Question on dependency management while adding a test case

Hi Robert, Currently tests are part of sling event module. Thanks -Amit From: Robert Munteanu romb...@apache.org Sent: Friday, October 10, 2014 1:41 PM To: dev@sling.apache.org Subject: Re: Question on dependency management while adding a test case Hi

RE: [mocks] Question on dependency management while adding a test case

Are the Event tests part of the same module? If they are, you can move them to a different module and then test + runtime dependencies are separated. Robert this would be a workaround, but not a nice one if these mocks are used widely in a lot of projects. this is a general problem for all of

Re: Question on dependency management while adding a test case

Hi Amit We could change the resourceresolver-mock to use a lower Sling API version than it implements. I.e. in MockResourceResolver, change all resource.getValueMap() to ResourceUtil.getValueMap(resource). Then it should be compatible with lower API versions. This should work as long as there are

Re: Question on dependency management while adding a test case

Rethinking this, can't we simply exclude the api dependency when including the resourceresolver-mock ? groupIdorg.apache.sling/groupId artifactIdorg.apache.sling.testing.resourceresolver-mock/artifactId exclusions exclusion groupIdorg.apache.sling/groupId

Re: Question on dependency management while adding a test case

...@apache.org Sent: Friday, October 10, 2014 8:17 PM To: dev@sling.apache.org Subject: Re: Question on dependency management while adding a test case Rethinking this, can't we simply exclude the api dependency when including the resourceresolver-mock ? groupIdorg.apache.sling/groupId

[jira] [Created] (SLING-3994) Simplify dependency management by letting the caller to supply its own implementations

Marius Petria created SLING-3994: Summary: Simplify dependency management by letting the caller to supply its own implementations Key: SLING-3994 URL: https://issues.apache.org/jira/browse/SLING-3994

[jira] [Updated] (SLING-3994) Simplify dependency management by letting the caller to supply its own implementations

), queueDistributionStrategy.target: (name=error), transportAuthenticationProvider.target : (name=publishAdmin) } {code} Simplify dependency management by letting the caller to supply its own implementations

[jira] [Commented] (SLING-2861) Include Apache Commons Lang in Dependency Management

pom minimalistic in terms of dependencies. That means a bit more work at the module level in some cases, but the end result is less coupling between modules which is good. Include Apache Commons Lang in Dependency Management

[jira] [Resolved] (SLING-2861) Include Apache Commons Lang in Dependency Management

is too large, closing as won't fix. Include Apache Commons Lang in Dependency Management Key: SLING-2861 URL: https://issues.apache.org/jira/browse/SLING-2861 Project: Sling

[jira] [Created] (SLING-2861) Include Apache Commons Lang in Dependency Management

Dan Klco created SLING-2861: --- Summary: Include Apache Commons Lang in Dependency Management Key: SLING-2861 URL: https://issues.apache.org/jira/browse/SLING-2861 Project: Sling Issue Type

[jira] [Commented] (SLING-2861) Include Apache Commons Lang in Dependency Management

from 2.4 IIRC some of the split functions are not there and there might be other differences. It will be obvious, the build will fail. Include Apache Commons Lang in Dependency Management Key: SLING-2861

[jira] Updated: (SLING-811) Reduce Dependency Management form parent pom

[ https://issues.apache.org/jira/browse/SLING-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-811: Component/s: (was: Launchpad Launcher) Reduce Dependency Management form parent pom

[jira] Updated: (SLING-811) Reduce Dependency Management form parent pom

) (was: Event) (was: Scripting JSP) (was: JCR Resource) Servlets Reduce Dependency Management form parent pom Key: SLING-811 URL: https