eclipse/sisu.inject

Sisu Inject

+-----------+---+-----------+---+---+
|           |   |           |   |   |
|   O-------+   |   O-------+   |   |
|           |   |           |   |   |
+-------O   |   +-------O   |   O   |
|           |   |           |       |
+-----------+---+-----------+-------+

Sisu is a modular JSR330-based container that supports classpath scanning, auto-binding, and dynamic auto-wiring.

Sisu uses Google-Guice to perform dependency injection and provide the core JSR330 support, but removes the need to write explicit bindings in Guice modules. Integration with other containers via the Eclipse Extension Registry and the OSGi Service Registry is a goal of this project.

Maven

<dependency>
  <groupId>org.eclipse.sisu</groupId>
  <artifactId>org.eclipse.sisu.inject</artifactId>
  <version>0.3.5</version>
</dependency>

Documentation

Sisu in 5 minutes

Javadoc

Generation of Named Index

Often Sisu's SpaceModule doesn't scan the full classpath at run time (for relevant annotations) but relies on a pre-generated index at META-INF/sisu/javax.inject.Named. There are two different ways how to create such an index file:

1. By leveraging the Java annotation processor in org.eclipse.sisu.space.SisuIndexAPT6 to generate the index. One needs to enable via javac -processor org.eclipse.sisu.space.SisuIndexAPT6 or with the according maven-compiler-plugin parameter annotationProcessors.
2. By leveraging the dedicated Maven plugin https://github.com/eclipse/sisu.mojos/

Related projects

https://github.com/eclipse/sisu.mojos/

• a Maven plugin that generates annotation indexes for Sisu to avoid classpath scanning at runtime

https://github.com/eclipse/sisu.plexus/

• an extension that implements Plexus container API and injection semantics on top of Sisu

How to Contribute

We accept contributions via GitHub pull requests. Please see How To Contribute to get started.

License

• Eclipse Public License, v1.0

Meaning of sisu

_{From https://en.wikipedia.org/w/index.php?title=Sisu&oldid=371994592}

Sisu is a Finnish term loosely translated into English as strength of will, determination, perseverance, and acting rationally in the face of adversity. However, the word is widely considered to lack a proper translation into any language. Sisu has been described as being integral to understanding Finnish culture. The literal meaning is equivalent in English to "having guts", and the word derives from sisus, which means something inner or interior. However sisu is defined by a long-term element in it; it is not momentary courage, but the ability to sustain an action against the odds. Deciding on a course of action and the sticking to that decision against repeated failures is sisu. It is similar to equanimity, except the forbearance of sisu has a grimmer quality of stress management than the latter. The noun sisu is related to the adjective sisukas, one having the quality of sisu.

Additional information

• Project Website: https://www.eclipse.org/sisu
• Mailing Lists: https://dev.eclipse.org/mailman/listinfo/sisu-dev
• Eclipse PMI: https://projects.eclipse.org/projects/technology.sisu

sisu.inject's Issues

Provide utility method that accepts a series of instances and returns a module with wildcard bindings for each instance (Bugzilla Bug 386447)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386447

Date: 2012-08-01 19:06:47 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-117
Last updated: 2013-07-16 21:17:03 -0400

Comment 2144135

Date: 2012-08-01 19:06:47 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-117

Need to consider whether these instances should be bound as-is (ie. no further injection) or bound with implicit injection of any contained @Inject members (default).

Support for jakarta namespace

Just a discussion starter: "what do we plan with jakarta namespace"?

Guice released "transitional" 6.0.0 (supporting both, javax and jakarta) and 7.0.0 (supporting jakarta only).
Apps using sisu built from the scratch may want to choose jakarta, while Maven (due legacy, especially 4.x) may want to "sit tight" on javax still.... (just to note, supporting newer bytecode is doable with "external asm").

Support automatic registration of AssistedInject factories (Bugzilla Bug 386439)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386439

Date: 2012-08-01 18:48:06 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-63
Last updated: 2013-07-16 21:17:02 -0400

Comment 2144116

Date: 2012-08-01 18:48:06 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-63

Would be useful if you could tag AssistedInject components with @AssistedBy(Factory.class) and the container would then register the factory for you, rather than the current approach of adding a @Named module to explicitly install it.

log classfile format exceptions more aggressively (Bugzilla Bug 461125)

This issue was created automatically with bugzilla2github

Bugzilla Bug 461125

Date: 2015-02-28 07:54:15 -0500
From: Igor Fedorenko <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2015-02-28 07:54:15 -0500

Comment 2525175

Date: 2015-02-28 07:54:15 -0500
From: Igor Fedorenko <[email protected]>

We provide a set of Maven core extensions that are built for java 7. These components are deployed into Maven installation lib/ext directory and are expected to be automatically discovered and used. We had number of rather difficult to troubleshoot bug reports from users who accidentally used java 6 to run Maven. There was no error message or anything else to indicate incompatible java version as the root cause of the problem, so from the user point of view our Maven extensions simply did not work.

I think Sisu should at least log incompatible classfile versions as error so they become more easily visible to the user. Ideally, though, I think Sisu should raise an exception when incompatible classfile is encountered during component discovery.

Binding different instances up-front with different parameters and common dependency (Bugzilla Bug 386440)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386440

Date: 2012-08-01 18:50:16 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-64
Last updated: 2013-07-16 21:17:02 -0400

Comment 2144117

Date: 2012-08-01 18:50:16 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-64

I have a class like this:

@Inject public RemoteSolrServerQueryer( @SolrBaseUrl String solrBaseUrl, String solrCoreName, HttpClient httpClient )

RemoteSolrServerQueryer depends on component HttpClient which is available in the container, solrBaseUrl is a common configuration parameter.

I want to create 3 different RemoteSolrServerQueryer instances for which the only difference is solrBaseUrl.

For now I have to create a Factory or use assisted inject, what I really wish guice/sisu has is I can prepare these 3 instances in a Module because I know all the 3 solrCoreName value up front. Something like:

bind(Queryer).annotatedWith(Gav.class).to(RemoteSolrServerQueryer.class).with(solrCoreName="Gav");

Need to reset AssistedInject factory elements when using BeanScanning.CACHE (Bugzilla Bug 456633)

This issue was created automatically with bugzilla2github

Bugzilla Bug 456633

Date: 2015-01-04 16:55:02 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2015-01-04 16:55:02 -0500

Comment 2501804

Date: 2015-01-04 16:55:02 -0500
From: Stuart McCulloch <[email protected]>

When running multiple tests with BeanScanning.CACHE (which caches and re-uses elements to save setup time) and AssistedInject factories, the following exception can occur:

com.google.inject.CreationException: Unable to create injector, see the following errors:

1) Factories.create() factories may only be used in one Injector!
  at com.google.inject.assistedinject.FactoryProvider2.class(FactoryProvider2.java:86)
  at com.google.inject.assistedinject.FactoryProvider2.initialize(FactoryProvider2.java:577)
  at ClassRealm[plexus.core, parent: null] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule -> org.eclipse.sisu.space.SpaceModule$1 -> org.sonatype.nexus.repository.internal.RepositoryModule -> com.google.inject.assistedinject.FactoryModuleBuilder$1)

1 error
	at com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:448)
	at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:176)
	at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:110)
	at com.google.inject.Guice.createInjector(Guice.java:96)
	at com.google.inject.Guice.createInjector(Guice.java:73)
	at com.google.inject.Guice.createInjector(Guice.java:62)

The recommended workaround is to use BeanScanning.INDEX which is almost as fast as the CACHE setting, but doesn't suffer from cache-related issues like the above exception.

To support AssistedInject properly with BeanScanning.CACHE we'll need to reset the affected factory elements, just like we did with the private lookup elements in bug #429366.

Support for binding qualified providers using other scopes (Bugzilla Bug 470493)

This issue was created automatically with bugzilla2github

Bugzilla Bug 470493

Date: 2015-06-18 09:43:11 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2015-06-18 09:43:11 -0400

Comment 2579749

Date: 2015-06-18 09:43:11 -0400
From: Stuart McCulloch <[email protected]>

Currently Sisu supports binding the output provided by qualified providers as either unscoped, Singleton, or EagerSingleton. We should extend this to include other scope annotations such as RequestScope.

Make LifecycleModule/Manager/Builder more re-usable (Bugzilla Bug 433894)

This issue was created automatically with bugzilla2github

Bugzilla Bug 433894

Date: 2014-04-30 14:42:00 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2015-04-23 20:43:58 -0400

Comment 2395608

Date: 2014-04-30 14:42:00 -0400
From: Stuart McCulloch <[email protected]>

So people can use them with other lifecycle annotations.

Comment 2460472

Date: 2014-10-06 12:19:50 -0400
From: Stuart McCulloch <[email protected]>

Moving to backlog until after the fine-grained OSGi integration work is complete.

Raise problem reporting logs to DEBUG

When a LinkageError happens during the instantiation of a bean, the error is logged at TRACE level, which is not very often displayed, especially in maven. This happens if a transitive dependency is missing in a maven extension for example, at the following location

sisu.inject/org.eclipse.sisu.inject/src/org/eclipse/sisu/wire/DependencyAnalyzer.java

Lines 238 to 245 in ac8b554

	catch ( final LinkageError e )
	{
	if ( reportErrors )
	{
	Logs.trace( "Potential problem: {}", type, e );
	}
	applyBinding = Boolean.FALSE;
	}

I suggest to raise a bit the level where potential problems are logged to DEBUG. At least, it's easier to see them and tone down rather than to have no way to figure out where the problem comes from when a bean is not instantiated.

See apache/maven#619 and https://issues.apache.org/jira/browse/MNG-7342

EntryMapAdapter should preserve order of underlying Iterable

As the EntryMapAdapter extends from AbstractMap its iteration order is non-predictable. In order to keep the order from the underlying Iterable it should rather extend from LinkedHashMap.

InjectedTest does not add the LifeCycle module and has no provision for adding modules (Bugzilla Bug 428240)

This issue was created automatically with bugzilla2github

Bugzilla Bug 428240

Date: 2014-02-14 21:11:02 -0500
From: benson margulies <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected]

Last updated: 2014-02-15 11:57:31 -0500

Comment 2363728

Date: 2014-02-14 21:11:02 -0500
From: benson margulies <[email protected]>

I can't seem to make a test using InjectedTest that depends on the LifecycleModule.

Comment 2363730

Date: 2014-02-14 21:22:25 -0500
From: benson margulies <[email protected]>

From 53144e70a07346cd8b5ee45b2fa4a00580caca9a Mon Sep 17 00:00:00 2001
From: Benson Margulies <[email protected]>
Date: Fri, 14 Feb 2014 21:20:03 -0500
Subject: [PATCH] Bug #428240: add ability to add modules, like
 LifecycleModule(), to InjectedTest.

---
 .../src/org/eclipse/sisu/launch/InjectedTest.java                   | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/org.eclipse.sisu.inject/src/org/eclipse/sisu/launch/InjectedTest.java b/org.eclipse.sisu.inject/src/org/eclipse/sisu/launch/InjectedTest.java
index 45f2011..8b6284a 100644
--- a/org.eclipse.sisu.inject/src/org/eclipse/sisu/launch/InjectedTest.java
+++ b/org.eclipse.sisu.inject/src/org/eclipse/sisu/launch/InjectedTest.java
@@ -56,12 +56,16 @@ public abstract class InjectedTest
     // Setup
     // ----------------------------------------------------------------------

+    protected Module setUpModule() {
+        return new SetUpModule();
+    }
+
     @Before
     @BeforeMethod
     public void setUp()
         throws Exception
     {
-        Guice.createInjector( new WireModule( new SetUpModule(), spaceModule() ) );
+        Guice.createInjector( new WireModule( setUpModule(), spaceModule() ) );
     }

     @After
--
1.8.3.4 (Apple Git-47)

Comment 2363786

Date: 2014-02-15 11:19:36 -0500
From: Stuart McCulloch <[email protected]>

Note you can use the configure(Binder) method to add bindings or install modules:

    @Override
    public void configure( Binder binder )
    {
        binder.install( new LifecycleModule() );
    }

There's also a configure(Properties) method for setting custom properties.

Comment 2363789

Date: 2014-02-15 11:29:12 -0500
From: benson margulies <[email protected]>

It sure would be nice if configure was an annotated method instead of an overridden method so that a test base class could have one and then subclasses could have them too.

Comment 2363795

Date: 2014-02-15 11:54:51 -0500
From: Stuart McCulloch <[email protected]>

Not sure what you mean by annotated method in this situation. The base test class and sub classes can all have configure(Binder) methods, they just need to remember to call the "super" method as usual if they want to inherit previous configurations.

Comment 2363796

Date: 2014-02-15 11:57:31 -0500
From: benson margulies <[email protected]>

It's the 'super' calls I'm being whiny about.

Imagine an @Configure that works like @Before, so that you wouldn't have to.

I'll make a patch if it bothers me enough.

Meanwhile, this patch looks pretty much useless now.

Document SisuIndexAPT6 and it's presence in services

The SisuIndexAPT6 is enlisted as service.

This should be documented, as page https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.mojos/ where SisuIndexAPT6 Javadoc leads does not make any mention of it.

Switch to JUnit5

Support injection of ordered @Named sequences (Bugzilla Bug 386432)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386432

Date: 2012-08-01 18:36:33 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected]

See also: https://issues.sonatype.org/browse/SISU-4
Last updated: 2013-07-16 21:17:04 -0400

Comment 2144109

Date: 2012-08-01 18:36:33 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-4

For situations where you want a list of specific @Named components in a specific order.

ParametersTest.testCustomParameters fails for test-guice-version=5.0.1

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.eclipse.sisu.wire.ParametersTest
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.659 s <<< FAILURE! - in org.eclipse.sisu.wire.ParametersTest
[ERROR] org.eclipse.sisu.wire.ParametersTest.testCustomParameters  Time elapsed: 0.143 s  <<< ERROR!
com.google.inject.CreationException: 
Unable to create injector, see the following errors:

1) An exception was caught and reported. Message: This Provider cannot be used until the Injector has been created.
  at [unknown source]

2) [Guice/MissingImplementation]: No implementation for String[] annotated with @Parameters() was bound.

Requested by:
1  : ParametersTest.arguments(ParametersTest.java:26)
      \_ for field arguments
     at ParametersTest$2.configure(ParametersTest.java:60)
      \_ installed by: WireModule -> ParametersTest$2

Learn more:
  https://github.com/google/guice/wiki/MISSING_IMPLEMENTATION

3) [Guice/MissingImplementation]: No implementation for Map<String, String> annotated with @Parameters() was bound.

Requested by:
1  : ParametersTest.properties(ParametersTest.java:26)
      \_ for field properties
     at ParametersTest$2.configure(ParametersTest.java:60)
      \_ installed by: WireModule -> ParametersTest$2

Learn more:
  https://github.com/google/guice/wiki/MISSING_IMPLEMENTATION

3 errors

======================
Full classname legend:
======================
Parameters:       "org.eclipse.sisu.Parameters"
ParametersTest:   "org.eclipse.sisu.wire.ParametersTest"
ParametersTest$2: "org.eclipse.sisu.wire.ParametersTest$2"
WireModule:       "org.eclipse.sisu.wire.WireModule"
========================
End of classname legend:
========================

	at org.eclipse.sisu.wire.ParametersTest.testCustomParameters(ParametersTest.java:55)
Caused by: java.lang.IllegalStateException: This Provider cannot be used until the Injector has been created.
	at org.eclipse.sisu.wire.ParametersTest.testCustomParameters(ParametersTest.java:55)

Create a binding publisher that delegates to Java6 service providers (Bugzilla Bug 386442)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386442

Date: 2012-08-01 18:53:01 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-82
Last updated: 2015-02-11 12:06:22 -0500

Comment 2144120

Date: 2012-08-01 18:53:01 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-82

Comment 2517461

Date: 2015-02-11 12:06:22 -0500
From: Stuart McCulloch <[email protected]>

Moving out of 0.3.0 scope

Sisu Annotation Processor output is not reproducible

see example https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/codehaus/mojo/flatten-maven-plugin/flatten-maven-plugin-1.4.1.diffoscope
I imagine (I did not really investigate fully) that it's linked to Annotation Processor way of generating the file

Annotate @EagerSingleton with @Scope for documentation purposes (Bugzilla Bug 417720)

This issue was created automatically with bugzilla2github

Bugzilla Bug 417720

Date: 2013-09-20 15:33:46 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2014-02-03 19:47:44 -0500

Comment 2309386

Date: 2013-09-20 15:33:46 -0400
From: Stuart McCulloch <[email protected]>

Also mark that it is technically a @Scope to make sure people don't add other scopes on the same location by mistake. Note: this may require us to register a placeholder scope implementation to keep Guice happy, even though we really map @EagerAnnotation to <binding>.asEagerSingleton() when analysing the bindings.

Comment 2346285

Date: 2014-01-06 19:36:46 -0500
From: Stuart McCulloch <[email protected]>

See http://git.eclipse.org/c/sisu/org.eclipse.sisu.inject.git/commit/?id=11ec7efbe1e2c4a1b27cdca5d5a86a4fe2ea15a0

Comment 2346287

Date: 2014-01-06 19:40:14 -0500
From: Stuart McCulloch <[email protected]>

Decided not to widen the places where @EagerSingleton can be applied, as currently Sisu only respects this pseudo-scope annotation on classes. Because it wouldn't work applied to a provider method in a module then we should not allow it.

Comment 2346733

Date: 2014-01-07 20:00:47 -0500
From: Stuart McCulloch <[email protected]>

Deferring until a later milestone due to side-effects of marking this with @Scope: namely that Guice then expects you to bind a Scope implementation to the annotation when re-using the component outside of Sisu.

Consider supporting `Collection` types as injection target

Currently injected collection types supported are Set and List, but not Collection.

So something like this is currently not possible:

@Inject
public MyCtor(Collection<MyComponent> myComponents) {
...

Despite I may have Set or List injected. We may want to broaden and recognize these situations as Java would allow passing of Set or List into this ctor.

PS: This just came to my attention, as for example former Aether (Maven Resolver) is full of these:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.14/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTransporterProvider.java#L58

(injects Set, only to pass to method using Collection and primate member is Collection as well).

Outdated wiki page for Plexus -> Sisu migration

IMHO the page https://wiki.eclipse.org/Sisu/PlexusMigration contains a bit outdated information, uses org.sonatype package, while these annodations like Description are deprecated.

Also, do we want maybe to migrate that page here to GH wiki? Or even better into Git repo (as then PRs to fix doco could become possible).

SetUpModule is package-private which makes extension difficult

I needed to override setUp to add an additional module in InjectedTest but its current implementation uses this SetUpModule which is package-private. So I either have to put my class in the org.eclipse.sisu.launch package or duplicate that code. Can this be made public?

sisu.inject/org.eclipse.sisu.inject/src/org/eclipse/sisu/launch/InjectedTest.java

Lines 64 to 68 in 6fa4bc1

	public void setUp()
	throws Exception
	{
	Guice.createInjector( new WireModule( new SetUpModule(), spaceModule() ) );
	}

Make component deprecation easier (Bugzilla Bug 388898)

This issue was created automatically with bugzilla2github

Bugzilla Bug 388898

Date: 2012-09-05 21:28:53 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-123
Last updated: 2013-07-16 21:17:03 -0400

Comment 2156608

Date: 2012-09-05 21:28:53 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-123

As we know, SISU and it's plexus-shim is here to phase out "oldie" plexus.

Typical case happened with sisu-velocity, it's main role is to drop the use of old plexus-velocity (by providing almost same functionality as plexus-velocity did, smaller enhancements was made + it uses @Inject annotations). It's main use is in Nexus that still uses plexus-shim.

If you take a peek at commit that added back the "deprecated" component (to make sisu-velocity a real drop-in replacement), some of us came up with cool idea: could we have sisu suppport generally for all components at the sisu-level. ie. if the chosen impl for a binding is marked with @deprecated annotations, then complain?

See comments https://github.com/sonatype/sisu-velocity/commit/8f903a3ce66c1413876f39bc08f78776e759e0b6

@jdillon: I'd recommend putting this into sisu-proper and not into any plexus related library, as this is useful going forward for pure jsr-330 components too.

Support JUnit 5 (Bugzilla Bug 569968)

This issue was created automatically with bugzilla2github

Bugzilla Bug 569968

Date: 2020-12-30 12:24:41 -0500
From: Benjamin Bentmann <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2020-12-30 12:24:41 -0500

Comment 3213492

Date: 2020-12-30 12:24:41 -0500
From: Benjamin Bentmann <[email protected]>

It would be nice if InjectedTest also supported JUnit 5. Specifically, its setUp() and tearDown() methods need to be annotated with org.junit.jupiter.api.BeforeEach and org.junit.jupiter.api.AfterEach, respectively.

Allow components to ask for dependencies with specific scopes (Bugzilla Bug 386431)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386431

Date: 2012-08-01 18:34:59 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-3
Last updated: 2013-07-16 21:17:03 -0400

Comment 2144108

Date: 2012-08-01 18:34:59 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-3

The auto-wiring code adds bindings for implicit (non-local) injected dependencies by introspecting injection sites and using that information to generate bindings at runtime. At the moment it assumes such bindings are unscoped, but some components might want to inject a dependency using a specific scope (such as per-request or per-session).

Changing the dependency analyzer to look for scope annotations on the injection site is trivial, the main issue is that a lot of scope annotations (such as the existing Guice ones) can only be placed on types, not individual members - one solution would be to mark the component itself with the scope, and then apply that to any of its dependencies. Another thing to watch out for is when the same dependency is used in conflicting scopes. This is of particular concern when you want to scope a configuration value where the raw type is not under your control and value is used in many places.

In fact the best solution might actually be to solve this use-case another way and avoid auto-wiring scoped bindings. For example, currently users can inject Providers to get per-lookup instances and then manage the values themselves.

Ability to use "external" ASM

To prevent being locked...

Could we do something similar like explained here?
google/guice#1657 (comment)

I know this is "tailored" to Maven, but actually, would be cool for all sisu using projects, as one could freely update ASM... as in Maven ASM is anyway "sealed" off.

Document JSR250 lifecycle support

The readme should be extended to explicitly mention JSR250 lifecycle support as Guice standalone does not support it (google/guice#62 (comment)), but it seems this is supported via https://github.com/eclipse/sisu.inject/blob/a41ab393a0c0e6d8eadf0547763fe80168825b49/org.eclipse.sisu.inject/src/org/eclipse/sisu/bean/LifecycleManager.java.

Build hang and CPU skyrocket at sisu-index:indexMojo with mvnd

When building with vanilla maven (mvn 3.8.4), sisu-index:indexMojo of given module finishes (almost) instantly.

But when building with mvnd, it hangs for 1 if not more minute, causing whole build to stall (as other threads finish, and build stops on this one thread). Or maybe not "hangs", but stalls, uses 500% CPU, so it "does something", but the amount of work seems totally different between mvn/mvnd.

Also, mvn builds project in 1:27 (as reported by mvn) while mvnd builds project (due this hang) in 2:54.

Took several thread dumps during hang, and it seems execution IS in sisu mojo:

"BuilderThread 4" #3385 prio=5 os_prio=0 cpu=31465,65ms elapsed=40,43s tid=0x00007f67b81a0000 nid=0x2d8ed runnable  [0x00007f679e9e8000]
   java.lang.Thread.State: RUNNABLE
	at java.util.zip.Inflater.inflateBytesBytes([email protected]/Native Method)
	at java.util.zip.Inflater.inflate([email protected]/Inflater.java:385)
	- locked <0x00000000e2343950> (a java.util.zip.Inflater$InflaterZStreamRef)
	at java.util.zip.InflaterInputStream.read([email protected]/InflaterInputStream.java:153)
	at java.io.InputStream.readNBytes([email protected]/InputStream.java:396)
	at java.io.InputStream.readAllBytes([email protected]/InputStream.java:333)
	at java.util.jar.JarFile.getBytes([email protected]/JarFile.java:821)
	at java.util.jar.JarFile.initializeVerifier([email protected]/JarFile.java:763)
	at java.util.jar.JarFile.getInputStream([email protected]/JarFile.java:852)
	- locked <0x00000000e232c3c8> (a sun.net.www.protocol.jar.URLJarFile)
	at sun.net.www.protocol.jar.JarURLConnection.getInputStream([email protected]/JarURLConnection.java:167)
	at java.net.URL.openStream([email protected]/URL.java:1165)
	at org.eclipse.sisu.space.Streams.open(Streams.java:79)
	at org.eclipse.sisu.space.SpaceScanner.accept(SpaceScanner.java:99)
	at org.eclipse.sisu.space.SpaceScanner.accept(SpaceScanner.java:78)
	at org.eclipse.sisu.space.SisuIndex.index(SisuIndex.java:95)
	at org.eclipse.sisu.mojos.IndexMojo.execute(IndexMojo.java:168)
	- locked <0x0000000099c373b8> (a org.apache.maven.project.MavenProject)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:271)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:196)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.mvndaemon.mvnd.builder.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:178)
	at org.mvndaemon.mvnd.builder.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:198)
	at java.util.concurrent.Executors$RunnableAdapter.call([email protected]/Executors.java:515)
	at java.util.concurrent.FutureTask.run([email protected]/FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run([email protected]/Thread.java:829)

"BuilderThread 4" #3385 prio=5 os_prio=0 cpu=26896,27ms elapsed=35,68s tid=0x00007f67b81a0000 nid=0x2d8ed runnable  [0x00007f679e9e7000]
   java.lang.Thread.State: RUNNABLE
	at sun.security.provider.DigestBase.implCompressMultiBlock0([email protected]/DigestBase.java:149)
	at sun.security.provider.DigestBase.implCompressMultiBlock([email protected]/DigestBase.java:144)
	at sun.security.provider.DigestBase.engineUpdate([email protected]/DigestBase.java:131)
	at java.security.MessageDigest$Delegate.engineUpdate([email protected]/MessageDigest.java:623)
	at java.security.MessageDigest.update([email protected]/MessageDigest.java:345)
	at sun.security.provider.DSA.engineUpdate([email protected]/DSA.java:209)
	at java.security.Signature$Delegate.engineUpdate([email protected]/Signature.java:1394)
	at java.security.Signature.update([email protected]/Signature.java:903)
	at java.security.Signature.update([email protected]/Signature.java:872)
	at sun.security.pkcs.SignerInfo.verify([email protected]/SignerInfo.java:443)
	at sun.security.pkcs.PKCS7.verify([email protected]/PKCS7.java:578)
	at sun.security.pkcs.PKCS7.verify([email protected]/PKCS7.java:595)
	at sun.security.util.SignatureFileVerifier.processImpl([email protected]/SignatureFileVerifier.java:283)
	at sun.security.util.SignatureFileVerifier.process([email protected]/SignatureFileVerifier.java:259)
	at java.util.jar.JarVerifier.processEntry([email protected]/JarVerifier.java:321)
	at java.util.jar.JarVerifier.update([email protected]/JarVerifier.java:234)
	at java.util.jar.JarFile.initializeVerifier([email protected]/JarFile.java:767)
	at java.util.jar.JarFile.getInputStream([email protected]/JarFile.java:852)
	- locked <0x00000000d05a5340> (a sun.net.www.protocol.jar.URLJarFile)
	at sun.net.www.protocol.jar.JarURLConnection.getInputStream([email protected]/JarURLConnection.java:167)
	at java.net.URL.openStream([email protected]/URL.java:1165)
	at org.eclipse.sisu.space.Streams.open(Streams.java:79)
	at org.eclipse.sisu.space.SpaceScanner.accept(SpaceScanner.java:99)
	at org.eclipse.sisu.space.SpaceScanner.accept(SpaceScanner.java:78)
	at org.eclipse.sisu.space.SisuIndex.index(SisuIndex.java:95)
	at org.eclipse.sisu.mojos.IndexMojo.execute(IndexMojo.java:168)
	- locked <0x0000000099c373b8> (a org.apache.maven.project.MavenProject)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:271)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:196)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.mvndaemon.mvnd.builder.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:178)
	at org.mvndaemon.mvnd.builder.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:198)
	at java.util.concurrent.Executors$RunnableAdapter.call([email protected]/Executors.java:515)
	at java.util.concurrent.FutureTask.run([email protected]/FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run([email protected]/Thread.java:829)

Update to Java 8

In order to use Java 8 language features the target version (and by that also the minimum required Java version) should be upgraded from 7 to 8.
This allows for further enhancements like eclipse/sisu.plexus#23.

Limit scope of injections in Eclipse (Bugzilla Bug 386443)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386443

Date: 2012-08-01 18:54:32 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-88
Last updated: 2013-07-16 21:17:03 -0400

Comment 2144121

Date: 2012-08-01 18:54:32 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-88

I would like to be able to limit the source of injected components in Eclipse. For example if software X requires consumers to implement interface A to provide usage specific context, when multiple consumers of software X are present how should each consumer ensure their implementation of A is injected into their instance of software X?

It appeared in limited testing that the first implementation of A injected was then used in subsequent injections of software X for other consumers.

Look into the use of executors/promises/futures when managing life cycles (Bugzilla Bug 427057)

This issue was created automatically with bugzilla2github

Bugzilla Bug 427057

Date: 2014-01-30 18:17:40 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2014-01-30 18:17:40 -0500

Comment 2356913

Date: 2014-01-30 18:17:40 -0500
From: Stuart McCulloch <[email protected]>

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=386446#c1

Support use of @Named on enum types (Bugzilla Bug 448641)

This issue was created automatically with bugzilla2github

Bugzilla Bug 448641

Date: 2014-10-24 07:50:33 -0400
From: Stuart McCulloch <[email protected]>
To: Stuart McCulloch <[email protected]>

Last updated: 2015-05-25 14:44:36 -0400

Comment 2471031

Date: 2014-10-24 07:50:33 -0400
From: Stuart McCulloch <[email protected]>

When it sees @Named on an enum type, Sisu should iterate over the values and bind each one as if it was annotated with @Named(value-name). This would be useful for situations where an enum provides common implementations of an interface, and you want to support injection of the interface but also allow alternative implementations.

Support limited form of JavaEE's @Observes (Bugzilla Bug 452675)

This issue was created automatically with bugzilla2github

Bugzilla Bug 452675

Date: 2014-11-21 11:12:17 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2014-11-21 11:12:17 -0500

Comment 2487116

Date: 2014-11-21 11:12:17 -0500
From: Stuart McCulloch <[email protected]>

https://docs.oracle.com/javaee/6/api/javax/enterprise/event/Observes.html

Could use reflection to detect use of @Observes and automatically register a Mediator to send the appropriate qualified events to the watcher.

Update ASM to 9.6

Only ASM 9.6 supports fully supports bytecode from Java 21

Document the JSR330 based container (Bugzilla Bug 386437)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386437

Date: 2012-08-01 18:44:44 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected]

See also: https://issues.sonatype.org/browse/SISU-12
Last updated: 2013-07-16 21:17:02 -0400

Comment 2144114

Date: 2012-08-01 18:44:44 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-12

Separate to the Plexus migration guide, we need to formally document the new API / programming model.

Consider binding provider implementation types using wildcard key (Bugzilla Bug 513442)

This issue was created automatically with bugzilla2github

Bugzilla Bug 513442

Date: 2017-03-10 07:07:09 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2017-03-10 07:07:09 -0500

Comment 2812915

Date: 2017-03-10 07:07:09 -0500
From: Stuart McCulloch <[email protected]>

So provider implementations can be looked up by any of their superclasses/interfaces. Note this is different from looking up the type they provide, this is about locating the actual provider implementation itself. This is useful when the provider implements additional management interfaces.

Avoid calling mediators while holding the locator lock (Bugzilla Bug 539379)

This issue was created automatically with bugzilla2github

Bugzilla Bug 539379

Date: 2018-09-24 08:23:14 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2018-09-24 08:30:49 -0400

Comment 2981172

Date: 2018-09-24 08:23:14 -0400
From: Stuart McCulloch <[email protected]>

Currently we maintain a lock on the locator when calling out to mediators (a variation on the listener pattern). This can lead to deadlocks when a mediator needs to lock a component, and at exactly the same time another thread already in that component calls back into the locator.

This bug will investigate ways to avoid holding onto the lock while calling out to external code.

Comment 2981176

Date: 2018-09-24 08:30:49 -0400
From: Stuart McCulloch <[email protected]>

Until this is fixed implementations affected by this bug (which should be limited to those that work on activating other components) can replace their internal lock with the locator lock as a workaround. Since the affected calls are calling back into the locator, this is effectively hoisting that lock into the component to avoid the lock order issue.

Upgrade ASM in Sisu to 9.2 (Bugzilla Bug 546874)

This issue was created automatically with bugzilla2github

Bugzilla Bug 546874

Date: 2019-04-30 13:35:25 -0400
From: Robert Scholte <[email protected]>
To: Stuart McCulloch <[email protected]>
CC: [email protected]

Last updated: 2019-11-05 19:10:55 -0500

Comment 3034851

Date: 2019-04-30 13:35:25 -0400
From: Robert Scholte <[email protected]>

According to https://issues.apache.org/jira/browse/MNG-6580 Sisu is not capable in scanning Java class files with target/release 9+ due to an old version of ASM.
I've marked it as critical since there's no workaround (other than staying on a n older Java version).

Comment 3093146

Date: 2019-11-05 19:10:55 -0500
From: Stuart McCulloch <[email protected]>

I've put a small workaround in the 0.3.4 release which means the scanner now attempts to scan bytecode up to and including the Java 14 level. This was possible because the scanner only does a light scan of the class file and isn't affected by recent bytecode additions.

I'll leave this ticket open as I still want to get master onto the latest ASM release.

Automatically install lifecycle module if bundle imports javax.annotation (Bugzilla Bug 427066)

This issue was created automatically with bugzilla2github

Bugzilla Bug 427066

Date: 2014-01-30 21:11:35 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2014-01-30 21:11:35 -0500

Comment 2356934

Date: 2014-01-30 21:11:35 -0500
From: Stuart McCulloch <[email protected]>

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=386446#c5

Make it easier to provide a ClassFinder wrapper given a BeanScanning argument (Bugzilla Bug 429266)

This issue was created automatically with bugzilla2github

Bugzilla Bug 429266

Date: 2014-02-27 14:40:32 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2014-02-27 14:40:32 -0500

Comment 2369464

Date: 2014-02-27 14:40:32 -0500
From: Stuart McCulloch <[email protected]>

By adding utility to map BeanScanning value to specific ClassFinder implementation

Should we consider moving to EPLv2 license?

As I see EPLv1 is deprecated and Eclipse encourages projects to move to EPLv2...

Update to ASM 9.4 to support Java 20

Only 9.4 added support for Java 20 (https://asm.ow2.io/versions.html). The embedded version is currently at 9.2 (https://github.com/eclipse/sisu.inject/tree/master/org.eclipse.sisu.inject/src/org/eclipse/sisu/space/asm) which only supports up to Java 18. At the same time it would be good to just depend on ASM instead of embedding it to allow consumers to override that dependency with a newer version without relying on a Sisu release.

@Priority not honored on Providers (Bugzilla Bug 552486)

This issue was created automatically with bugzilla2github

Bugzilla Bug 552486

Date: 2019-10-28 11:10:21 -0400
From: GianMaria Romanato <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected]

Last updated: 2021-05-03 06:43:33 -0400

Comment 3091201

Date: 2019-10-28 11:10:21 -0400
From: GianMaria Romanato <[email protected]>

When ranking bindings, Sisu does not currently take into account @Priority annotations on javax.inject.Provider implementations.

Comment 3241617

Date: 2021-05-03 06:43:33 -0400
From: Nikolas Falco <[email protected]>

Original request thread with more details

https://www.eclipse.org/lists/sisu-users/msg00158.html

Any change to get solution for this?

Visualize graph of component dependencies (Bugzilla Bug 386433)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386433

Date: 2012-08-01 18:38:29 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

See also: https://issues.sonatype.org/browse/SISU-6
Last updated: 2013-07-16 21:17:03 -0400

Comment 2144110

Date: 2012-08-01 18:38:29 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-6

Guice provides a grapher (http://code.google.com/p/google-guice/wiki/Grapher) to visualize binding dependencies. However it doesn't capture dependencies introduced via custom injection, such as with the TypeListener approach.

By extending the grapher to capture both types of bindings we can easily visualize Nexus component dependencies; which would be useful for developers to see how it all fits together, and help avoid tightly-coupled components.

The output from the Guice grapher could be fed directly into Eclipse Zest (http://www.eclipse.org/gef/zest/) by using the dot4zest Eclipse feature (http://wiki.eclipse.org/Graphviz_DOT_as_a_DSL_for_Zest).

This low-priority sub-task will look into feeding custom dependencies (like from TypeListener) into the grapher.

Manage the lifecycle of components constructed using 'new' in a provider (Bugzilla Bug 467320)

This issue was created automatically with bugzilla2github

Bugzilla Bug 467320

Date: 2015-05-14 07:30:45 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2015-05-14 07:30:45 -0400

Comment 2563401

Date: 2015-05-14 07:30:45 -0400
From: Stuart McCulloch <[email protected]>

Currently any components constructed using 'new' in a provider are not managed by the LifecycleModule. This is because they are not covered by Guice's TypeListener, instead we need to use the ProvisionListener to detect them (though we need to be careful to avoid duplicates, since the same component could trigger multiple provision calls).

Note it is possible to tell the BeanManager about external instances:

   if (beanManager.manage(instance.getClass()) {
       beanManager.manage(instance);
   }

but this is a bit clunky and could be improved to be a single call.

Named modules not picked up at runtime (Bugzilla Bug 550176)

This issue was created automatically with bugzilla2github

Bugzilla Bug 550176

Date: 2019-08-18 11:00:31 -0400
From: Jose Montoya <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected]

Last updated: 2019-08-19 09:26:14 -0400

Comment 3061512

Date: 2019-08-18 11:00:31 -0400
From: Jose Montoya <[email protected]>

Having an issue where a module annotated with Name is picked up and configured correctly during tests, but at runtime it is not picked up and the bindings missing. I'm not sure what dependencies I need for this to happen automatically. I've tried just adding the sisu plugin as JSR330 documentation states but that's not doing it. Additionally I added dependencies to sisu.inject and sisu.inject.extender as suggested in ticket 393214.

Comment 3061770

Date: 2019-08-19 09:26:14 -0400
From: Stuart McCulloch <[email protected]>

Hi Jose,

Thanks for the report - could you provide more details about how you're building and packaging the application?

You could also try running with -Dsisu.debug to get detailed information about what bindings have been found and if there were any potential issues with those bindings.

--
Cheers, Stuart

LifecycleManager reatains classes forever

The following Map in LifecycleManager

sisu.inject/org.eclipse.sisu.inject/src/org/eclipse/sisu/bean/LifecycleManager.java

Lines 31 to 32 in 6fa4bc1

	private final Map<Class<?>, BeanLifecycle> lifecycles = //
	new ConcurrentHashMap<Class<?>, BeanLifecycle>( 16, 0.75f, 1 );

prevents no longer used classes (and more important their classloaders) from being garbage collected, see for example

• eclipse-m2e/m2e-core#1214

This should use some strategies like WeakHashMap so if the class is only referenced from this component it could still be freed.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=581407

Support automatic injection of Eclipse extensions (Bugzilla Bug 386434)

This issue was created automatically with bugzilla2github

Bugzilla Bug 386434

Date: 2012-08-01 18:40:10 -0400
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected]

Depends on: #386430
See also: https://issues.sonatype.org/browse/SISU-7
Last updated: 2015-02-11 12:09:56 -0500

Comment 2144111

Date: 2012-08-01 18:40:10 -0400
From: Stuart McCulloch <[email protected]>

Migrated from https://issues.sonatype.org/browse/SISU-7

Currently you can inject Eclipse extensions into JSR330 applications by registering the appropriate peaberry bindings in a custom Guice binding module. We should try to make this more automatic by including results from the Eclipse extension registry (if available) when looking up bean implementations via the BeanLocator.

Comment 2397529

Date: 2014-05-06 10:18:09 -0400
From: Stuart McCulloch <[email protected]>

Logged https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8265 to track potential re-use of IP from Peaberry (which I also created) in implementing this feature.

Comment 2517466

Date: 2015-02-11 12:09:56 -0500
From: Stuart McCulloch <[email protected]>

Moving out of 0.3.0 scope, current focus is on service publisher first then extensions.

PreConstruct PreDestroy should be own annotations

Just like Description, and sisu should stop pulling in "unpopular" dependencies like javax stuff for only those two annotations. Maybe make the behave in similar way how Sisu;s Nullable is working (annotation from several packages are all recognized as Nullable annotation)

Too eager determination of scanning need for a specific OSGi bundle (Bugzilla Bug 394734)

This issue was created automatically with bugzilla2github

Bugzilla Bug 394734

Date: 2012-11-21 01:59:06 -0500
From: Tuomas Kiviaho <[email protected]>
To: Project Inbox <[email protected]>
CC: [email protected], [email protected]

Last updated: 2013-11-11 20:25:01 -0500

Comment 2185926

Date: 2012-11-21 01:59:06 -0500
From: Tuomas Kiviaho <[email protected]>

SisuActivator.needScanning(Bundle) optimizes the need for scanning of certain bundle in such way that some corner case situations do not get scanned.

1. Fragment doesn't get scanned when it's host doesn't contain annotations as imports
2. Bundle doesn't get scanned if it embeds sisu thus doesn't have annotations as imports

I think that both cases are resolvable using BundleWiring.

Comment 2186466

Date: 2012-11-21 19:26:35 -0500
From: Stuart McCulloch <[email protected]>

Yes, it should be possible to support both cases without too much performance impact to the general case (we don't want to do an in-depth eager scan of all bundles if we can avoid it).

BTW, feel free to suggest a patch - either attach it here or submit at https://git.eclipse.org/r/ for review (see http://wiki.eclipse.org/Gerrit)

Comment 2328984

Date: 2013-11-11 20:25:01 -0500
From: Stuart McCulloch <[email protected]>

FYI you can now choose your own selection strategy by subclassing BundleScanner and SisuExtender (since Sisu 0.1.0) and using them in your own extender bundle.

Get rid of Tycho packaging "eclipse-plugin"

Instead of leveraging the tycho packaging "eclipse-plugin" one should leverage packaging "jar" with https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/README.md. This allows to get rid of a manually maintained MANIFEST.MF and properly supporting package versions via https://docs.osgi.org/javadoc/r6/annotation/org/osgi/annotation/versioning/Version.html.

This is supported to be referenced even from inside Eclipse with more recent Tycho/PDE versions via via https://xn--lubisoft-0za.gmbh/en/articles/using-maven-artifacts-in-pde-rcp-and-tycho-builds/. Main consumers of Sisu (IMHO Maven) are however outside of OSGi world anyways.

Compare with eclipse/sisu.plexus#28.