I believe it would be a great proof of the whole concept if the DI system
could be plugged into the new commons plugin system using the SPI commons
plugin provides for plugins.
On Thu, Apr 14, 2022 at 8:00 PM Matt Sicker wrote:
> Yes, at this point, it would help to see what aspects of this woul
Yes, at this point, it would help to see what aspects of this would be
useful or welcomed as a library. In the meantime, I've been asked if I
could port the log4j DI system back to 2.x, so I may end up working on
that in the near term and defer any work to extract code to Commons
until we have a be
It sounds like embedded in this discussion are some use cases / requirements.
Would quantifying these some with a high level list of features that this
plugin architecture is to provide?
What would the basic functionality and/or interfaces be…something like:
- Register Plugin/Services
- Plugin/S
Users should be required to do as little as possible to adapt the
plugin system to the environment it is running in*but plugins shouldn’t know or
care anything about how they are located and loaded.* Plugins are also to the
application or framework that will be using them. They essentially def
, not code. Dependency injection could
> certainly be
> >> part of the plugin framework but that would be for implementors of
> plugins,
> >> not the users using them. Users of Maven don’t know that Plexus is used
> under
> >> the covers and neither should us
examples like
>> Log4j
>> and Apache Flume, and even Apache Maven. All wire components together via
>> user provided configuration, not code. Dependency injection could certainly
>> be
>> part of the plugin framework but that would be for implementors of plugins,
&
f the plugin framework but that would be for implementors of plugins,
not the users using them. Users of Maven don’t know that Plexus is used under
the covers and neither should users of a commons-plugins implementation.
- What will distinguish it from module systems, like OSGi and what will
stop it
Start it here, if it fails, we'll all learn something I am sure.
Gary
On Tue, Apr 12, 2022, 08:53 Gilles Sadowski wrote:
> Le mar. 12 avr. 2022 à 13:23, Gary Gregory a
> écrit :
> >
> > Commons Component can and do depend on other runtime libraries, for
> > example, VFS, Configuration, JCS, an
Hi Matt,
That's normal thinking IMO not devil's advocacy :-) The JDK provides a bare
bones extension mechanism in the service loader but that's not enough for a
real plugin system.
Gary
On Tue, Apr 12, 2022, 11:30 Matt Benson wrote:
> Devil's advocate thought: given that Commons, while not offi
Devil's advocate thought: given that Commons, while not officially limited
to such, has heretofore concentrated on the Java ecosystem; as the core JDK
evolves, matures and provides more and more functionality out of the box,
possibly Commons components would have to increase in complexity to be abl
Le mar. 12 avr. 2022 à 13:23, Gary Gregory a écrit :
>
> Commons Component can and do depend on other runtime libraries, for
> example, VFS, Configuration, JCS, and so on. There are libraries that are
> naturally lower level where we do want to keep zero depencies like IO and
> Lang. If an app has
Commons Component can and do depend on other runtime libraries, for
example, VFS, Configuration, JCS, and so on. There are libraries that are
naturally lower level where we do want to keep zero depencies like IO and
Lang. If an app has a plugin system it seems evident to me that it would be
the kin
Hello.
Le mar. 12 avr. 2022 à 08:58, Romain Manni-Bucau
a écrit :
>
> Sounds like https://svn.apache.org/repos/asf/commons/sandbox/ can be a
> ready to start place even if I still think incubator is the real place for
> such a project since it will quickly overpass commons standard case with a
>
to a broader ecosystem/platform normally.
> but I
> > > could be wrong.
> > >
> > > Btw: Commons VFS has a plug-in system, mostly for providers.
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.eckenfels.net
Goers
> > Gesendet: Monday, April 11, 2022 12:00:12 AM
> > An: Commons Developers List
> > Betreff: Re: New component proposal: commons-plugins
> >
> > See below
> >
> > > On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
> > >
> > > Tha
; --
> http://bernd.eckenfels.net
>
> Von: Ralph Goers
> Gesendet: Monday, April 11, 2022 12:00:12 AM
> An: Commons Developers List
> Betreff: Re: New component proposal: commons-plugins
>
> See below
>
> > On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
>
Von: Ralph Goers
Gesendet: Monday, April 11, 2022 12:00:12 AM
An: Commons Developers List
Betreff: Re: New component proposal: commons-plugins
See below
> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
>
> Thanks Ralph for the detailed explanation. I appreciate it and now I
ework but that would be for implementors of plugins,
not the users using them. Users of Maven don’t know that Plexus is used under
the covers and neither should users of a commons-plugins implementation.
> - What will distinguish it from module systems, like OSGi and what will
> stop it
what
> will
> > > > > stop it from becoming another OSGi by the years as new features get
> > > added
> > > > > to the library.
> > > > > - What applications using plugins are the examples for different
> > > solutions?
>
o
> > explained
> > > > patiently why it is not a simple ServiceLoader, but it is only one way
> > to
> > > > solve it. Other applications may approach the issue differently. Maven,
> > > > Attlassian products, other build tools, JUnit 5 and so on.)
&g
; > >
> > > On Thu, Apr 7, 2022 at 7:57 PM Ralph Goers >
> > > wrote:
> > >
> > > >
> > > >
> > > > > On Apr 7, 2022, at 2:52 AM, Peter Verhas wrote:
> > > > >
> > > > >
> > > > >
gt;
> > > >> I would suggest that before responding to this email that
> > > >> you go look at how log4j-plugins is implemented in the master branch.
> > > >>
> > > >
> > > > Sure, if you propose to create a commons-plugin libr
mmons-plugin library that is an
> > extract
> > > of the plugin handling of log4j so that log4j next releases do not need
> > to
> > > keep the functionality inside log4j but rather as a dependency on this
> > new
> > > library. On the other hand, if the g
xt releases do not need
> to
> > keep the functionality inside log4j but rather as a dependency on this
> new
> > library. On the other hand, if the goal is to create something that is
> > useful generally then we should look at other solutions as well.
>
> It remains
ld look at other solutions as well.
>
> It remains to be seen whether Log4j would replace log4j-plugins with
> Commons-plugins. The point of looking at Log4j was to understand the
> problem it is solving and how it solves it.
>
>
> >
> >
> >> From t
her solutions as well.
It remains to be seen whether Log4j would replace log4j-plugins with
Commons-plugins. The point of looking at Log4j was to understand the
problem it is solving and how it solves it.
>
>
>> From this it is clear that you completely misunderstand what the plugin
Le jeu. 7 avr. 2022 à 14:34, Gary Gregory a écrit :
>
> A slight tangent: a smaller simpler component idea? The log4j variable
> interpolation, the ${lookup:variable} type of logic is in many places:
> deprecated in Commons Lang, now in Commons Text, also implemented in
> Commons Configuration. We
A slight tangent: a smaller simpler component idea? The log4j variable
interpolation, the ${lookup:variable} type of logic is in many places:
deprecated in Commons Lang, now in Commons Text, also implemented in
Commons Configuration. We could bring in the Log4j version, now safer than
other impleme
>
> > The plugin system is design to convert configuration data into
> instantiated objects.
>
For me that very much reads a dependency injection framework.
--
Peter Verhas
pe...@verhas.com
t: +41791542095
skype: verhas
> If I had known this was going to turn into a debate I wouldn’t have
> responded to the
> question. But it seems either my response wasn’t clear, you did not
> understand
> what I wrote, or you have some preconceived notion as to why anything
> beyond
> ServiceLoader is needed.
I believe that a
On Sat, Apr 2, 2022, 2:33 PM Matt Sicker wrote:
> Hi all, I’ve got a proposal for a new Commons component that I’d like to
> get feedback on. Essentially, I’d like to propose the creation of a Commons
> Plugins component inspired by the plugin system developed for Log4j 3.x
> [
Le 04/04/2022 à 02:27, Ralph Goers a écrit :
I don’t think so. Commons Configuration (which I was working actively on when
I started writing Log4j 2) is designed to provide access to the configuration
data.
The plugin system is design to convert configuration data into instantiated
objects.
I
If I had known this was going to turn into a debate I wouldn’t have responded
to the
question. But it seems either my response wasn’t clear, you did not understand
what I wrote, or you have some preconceived notion as to why anything beyond
ServiceLoader is needed. I would suggest that before r
gt; > G
> >
> > On Sun, Apr 3, 2022, 22:18 Ralph Goers
> wrote:
> >
> >> If you look at Log4j, we parse the configuration and convert it to a
> Node
> >> hierarchy.
> >> Variable interpolation occurs as the Nodes are constructed.
> >>
>
ent.
> >> The plugins have their versions.
> >> And the base program has its version.
> >> And the plugin registration mechanism has its own version.
> >> How to make it work would be a big challenge.
> >> If we wanna make a useful plugin management s
its own version.
>> How to make it work would be a big challenge.
>> If we wanna make a useful plugin management system, maybe a good way is
>> first to learn about some existing usage of these things(although developed
>> in different groups/repos), like eclipse, jetbrains i
Matt,
I don’t see commons-plugins needing a configuration. Remember, there are
several components
in Log4j that don’t use a configuration file. Namely, Lookups,
PatternConverters, KeyProviders,
and Watchers, I view the plugin system as an API that a configuration system
would use to
hese things(although developed
> in different groups/repos), like eclipse, jetbrains idea, even OSGI...
>
> Gary Gregory 于2022年4月4日周一 21:11写道：
>
> > I am trying to figure out the input and output of a Commons Plugins
> > that Log4j would use.
> >
> > Gary
> >
mmons component that I’d like to
> > get feedback on. Essentially, I’d like to propose the creation of a
> Commons
> > Plugins component inspired by the plugin system developed for Log4j 3.x
> > [0]. This library would be a lightweight dependency injection and
> > conf
to figure out the input and output of a Commons Plugins
> that Log4j would use.
>
> Gary
>
> On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers
> wrote:
> >
> > It has been too long since I looked at Commons Configuration for me to
> answer that.
> >
> > Ralph
&g
>From the Log4j side of things, I didn't exactly overhaul the
configuration parsing or representation of it, so it would depend on
how different that looks in this proposed component. Ideally, though,
a commons-plugins component would replace log4j-plugins and
log4j-plugin-processor al
I am trying to figure out the input and output of a Commons Plugins
that Log4j would use.
Gary
On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers wrote:
>
> It has been too long since I looked at Commons Configuration for me to answer
> that.
>
> Ralph
>
> > On Apr 3, 2022,
22:18 Ralph Goers wrote:
>
>> If you look at Log4j, we parse the configuration and convert it to a Node
>> hierarchy.
>> Variable interpolation occurs as the Nodes are constructed.
>>
>> But again, Nothing says a Commons Plugins implementation has to work the
>>
s are constructed.
>>
>> But again, Nothing says a Commons Plugins implementation has to work the
>> same way.
>>
>> Ralph
>>
>>>> On Apr 3, 2022, at 7:12 PM, Gary Gregory wrote:
>>>
>>> Nice thread :-)
>>>
&g
.
>
> But again, Nothing says a Commons Plugins implementation has to work the
> same way.
>
> Ralph
>
> > On Apr 3, 2022, at 7:12 PM, Gary Gregory wrote:
> >
> > Nice thread :-)
> >
> > Where does the parsing of configuration files mix in such a stack?
If you look at Log4j, we parse the configuration and convert it to a Node
hierarchy.
Variable interpolation occurs as the Nodes are constructed.
But again, Nothing says a Commons Plugins implementation has to work the same
way.
Ralph
> On Apr 3, 2022, at 7:12 PM, Gary Gregory wr
Nice thread :-)
Where does the parsing of configuration files mix in such a stack?
Where does variable interpolation come into play?
Gary
On Sun, Apr 3, 2022, 20:50 Ralph Goers wrote:
> Matt J,
>
> I fully expect that if commons-plugins came into fruition it would bear a
> rese
Matt J,
I fully expect that if commons-plugins came into fruition it would bear a
resemblance
to the Log4j plugin system but there would be differences. For example, while
Log4j
integrates with Spring we don’t currently support having the logging
configuration in
application.yml. I also
;
>> Hi all, I’ve got a proposal for a new Commons component that I’d like to
>> get feedback on. Essentially, I’d like to propose the creation of a Commons
>> Plugins component inspired by the plugin system developed for Log4j 3.x
>> [0]. This library would be a lightweight depende
like to
>> get feedback on. Essentially, I’d like to propose the creation of a Commons
>> Plugins component inspired by the plugin system developed for Log4j 3.x
>> [0]. This library would be a lightweight dependency injection and
>> configuration library where developers cr
component that I’d like to
> > get feedback on. Essentially, I’d like to propose the creation of a Commons
> > Plugins component inspired by the plugin system developed for Log4j 3.x
> > [0]. This library would be a lightweight dependency injection and
> > configuration libra
Should this be in Commons Configuration?
Gary
On Sat, Apr 2, 2022, 15:33 Matt Sicker wrote:
> Hi all, I’ve got a proposal for a new Commons component that I’d like to
> get feedback on. Essentially, I’d like to propose the creation of a Commons
> Plugins component inspired by the plug
What is the feature not provided by Service Loader?
On Sat 2. Apr 2022 at 21:33, Matt Sicker wrote:
> Hi all, I’ve got a proposal for a new Commons component that I’d like to
> get feedback on. Essentially, I’d like to propose the creation of a Commons
> Plugins component inspired by t
Hi all, I’ve got a proposal for a new Commons component that I’d like to get
feedback on. Essentially, I’d like to propose the creation of a Commons Plugins
component inspired by the plugin system developed for Log4j 3.x [0]. This
library would be a lightweight dependency injection and
On 21 June 2013 14:35, Matt Benson wrote:
> I'm not retroactively -1ing anything, but don't we typically have a formal
> vote for moving any component from sandbox to proper? What was different
> about these plugins?
They are intended for use in Commons builds, much like Commons Parent
and the C
I'm not retroactively -1ing anything, but don't we typically have a formal
vote for moving any component from sandbox to proper? What was different
about these plugins?
Thanks,
Matt
On Thu, Jun 20, 2013 at 9:06 AM, sebb wrote:
> On 20 June 2013 14:43, Gary Gregory wrote:
> > Is there any tho
On 20 June 2013 14:43, Gary Gregory wrote:
> Is there any thought on easing managing a site for multiple versions of a
> component.
Please start a new thread for this.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
Is there any thought on easing managing a site for multiple versions of a
component. Right now, for some components, we have >1 Javadoc site. It
would be nice to at least automate that. But why not have the whole site?
https://commons.apache.org/proper/commons-lang/2.6
https://commons.apache.org/p
Thank you for taking the initiative and doing this work Sebb.
Gary
On Jun 19, 2013, at 19:45, sebb wrote:
> I've been developing some Maven plugins in the Sandbox, and I now
> propose to move them to Commons proper.
>
> commons-javadocfix-plugin
>
> Runs the Oracle JavadocF
I've been developing some Maven plugins in the Sandbox, and I now
propose to move them to Commons proper.
commons-javadocfix-plugin
Runs the Oracle JavadocFixTool as a Maven plugin or a Java
command-line application.
The tool was released by Oracle recently in order to fix up
On 18 June 2013 03:36, Bruno P. Kinoshita wrote:
> Hi sebb,
>
> I think there's a small typo in the Javadocs?
>
> s/wildard/wildcard/
Indeed, fixed, thanks!
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additi
ons/sandbox/commons-digest-plugin/trunk/src/main/java/org/apache/commons/plugins/digest/DigestMojo.java
>
>
>Author: sebb
>Date: Mon Jun 17 23:25:57 2013
>New Revision: 1493972
>
>URL: http://svn.apache.org/r1493972
>Log:
>Javadocs
>
>Modified:
>
>comm
62 matches
Mail list logo
