Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #35002 > unrolled thread

plugin architecture

Started byPhilipp Kraus <philipp.kraus.flashpixx@gmail.com>
First post2016-07-19 23:29 -0700
Last post2016-07-25 11:57 -0700
Articles 6 — 3 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  plugin architecture Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2016-07-19 23:29 -0700
    Re: plugin architecture Qu0ll <qu0ll64@gmail.com> - 2016-07-21 05:10 +1000
      Re: plugin architecture Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2016-07-21 05:17 -0700
        Re: plugin architecture Qu0ll <qu0ll64@gmail.com> - 2016-07-22 06:18 +1000
    Re: plugin architecture Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 23:50 -0400
      Re: plugin architecture Philipp Kraus <philipp.kraus.flashpixx@gmail.com> - 2016-07-25 11:57 -0700

#35002 — plugin architecture

FromPhilipp Kraus <philipp.kraus.flashpixx@gmail.com>
Date2016-07-19 23:29 -0700
Subjectplugin architecture
Message-ID<f6628337-f13e-4a4f-8a4c-fa005d7a7747@googlegroups.com>
Hello,

I'm searching for an indea for a plugin architecture.
I have found PF4J, OOGI and JPF.

At the moment I would like to use PF4J, but I'm at the moment on the conceptiual phase, so
I don't finished my complete requirements. But at the moment I'm thinking about the plugin structure,
so I think my plugins implements an equal interface. Finally a Jar should contains the plugin.
At the moment I have got a question: Is it a good idea, that one Jar file store multiple plugins or is it better that one plugin is represent by one Jar file.

I create a complexe software, so in some cases a multi-plugin approach could be nice, because I can build "plugin packages". On the other hand, the software architecture can be more cleaner, if I don't allowd multi-plugins.

Another question is because I'm using Google Guava and there exists a reflection API, so I can iterate over all classes within a package. IMHO I can use this reflection to load my plugin. Is this a good choice?
A plugin cannot be changed in my case during runtime, so the plugin will put to the classpath / classloader and than I can iterate overall classes within the plugin package and check if a class implements the plugin interface. On this I can instantiate the plugin. 
With this structure I can build the multi-plugin approach.

Hope for some comments to get a better idea for my architecture

Thanks a lot

Phil

[toc] | [next] | [standalone]


#35016

FromQu0ll <qu0ll64@gmail.com>
Date2016-07-21 05:10 +1000
Message-ID<nmoibf$1u04$4@gioia.aioe.org>
In reply to#35002
On 20/07/2016 16:29, Philipp Kraus wrote:
> Hello,
>
> I'm searching for an indea for a plugin architecture.
> I have found PF4J, OOGI and JPF.
>
> At the moment I would like to use PF4J, but I'm at the moment on the conceptiual phase, so
> I don't finished my complete requirements. But at the moment I'm thinking about the plugin structure,
> so I think my plugins implements an equal interface. Finally a Jar should contains the plugin.
> At the moment I have got a question: Is it a good idea, that one Jar file store multiple plugins or is
 > it better that one plugin is represent by one Jar file.
>
> I create a complexe software, so in some cases a multi-plugin approach could be nice, because I can build
 > "plugin packages". On the other hand, the software architecture can 
be more cleaner, if I don't allowd multi-plugins.
>
> Another question is because I'm using Google Guava and there exists a reflection API, so I can iterate over all
 >classes within a package. IMHO I can use this reflection to load my 
plugin. Is this a good choice?
> A plugin cannot be changed in my case during runtime, so the plugin will put to the classpath / classloader and than
 > I can iterate overall classes within the plugin package and check if 
a class implements the plugin interface.
 > On this I can instantiate the plugin.
> With this structure I can build the multi-plugin approach.
>
> Hope for some comments to get a better idea for my architecture

Hi Phil,

I realise it may not be exactly what you are after, but have you 
checked-out Java 9 and the Jigsaw module system?

You will eventually have to make your software Java 9 & Jigsaw 
compatible anyway so maybe it could be a good place to start.

Early releases of Java 9 with Jigsaw have been available for some time.

Also, I am not even sure that JARs are really the way Java is heading 
(especially with Jigsaw).

Just some things to consider...

-- 

And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]

[toc] | [prev] | [next] | [standalone]


#35038

FromPhilipp Kraus <philipp.kraus.flashpixx@gmail.com>
Date2016-07-21 05:17 -0700
Message-ID<be352dcb-26fe-44b2-bb3a-5a8bbd927fb8@googlegroups.com>
In reply to#35016
Hello,

thanks for the information about Java 9, I'm working with 8 at the moment.
Is there a Java 9 release version existing? On http://www.oracle.com/technetwork/java/javase/downloads/index.html the latest version is 8

Phil

[toc] | [prev] | [next] | [standalone]


#35070

FromQu0ll <qu0ll64@gmail.com>
Date2016-07-22 06:18 +1000
Message-ID<nmrane$1ne1$1@gioia.aioe.org>
In reply to#35038
On 21/07/2016 22:17, Philipp Kraus wrote:
> Hello,
>
> thanks for the information about Java 9, I'm working with 8 at the moment.
> Is there a Java 9 release version existing? On http://www.oracle.com/technetwork/java/javase/downloads/index.html the latest version is 8
>
> Phil
>

Yes, there have been for some time (at least Early Releases anyway!):

https://jdk9.java.net/download/

Given that Java 9 is "on track" be for a GA release in Q1 (or Q2) of 
2017, I would seriously consider taking a look at Jigsaw as you may well 
find that the release of your product will either coincide with that of 
Java 9 or be even later.

Staying ahead of the game is important in the software development world 
and the early releases give us all the chance to have products that 
fully utilise the next major Java release almost immediately as that 
version is made publicly available.

YMMV.

-- 

And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]

[toc] | [prev] | [next] | [standalone]


#35104

FromArne Vajhøj <arne@vajhoej.dk>
Date2016-07-22 23:50 -0400
Message-ID<nmuphi$92v$1@gioia.aioe.org>
In reply to#35002
On 7/20/2016 2:29 AM, Philipp Kraus wrote:
> I'm searching for an indea for a plugin architecture. I have found
> PF4J, OOGI and JPF.

What about using what is in Java SE aka ServiceLoader (see
http://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html).

Or do what a lot of people are doing: just use Spring to load
the plugin.

Or do you really need some advanced features with versioning,
dependencies, unload etc.?

>            At the moment I have got a question: Is it a good idea,
> that one Jar file store multiple plugins or is it better that one
> plugin is represent by one Jar file.

One plugin per jar.

> Another question is because I'm using Google Guava and there exists a
> reflection API, so I can iterate over all classes within a package.
> IMHO I can use this reflection to load my plugin. Is this a good
> choice?

Direct reflection is probably too much a reinventing the wheel
framework.

Arne

[toc] | [prev] | [next] | [standalone]


#35135

FromPhilipp Kraus <philipp.kraus.flashpixx@gmail.com>
Date2016-07-25 11:57 -0700
Message-ID<48e31bc2-a539-44a2-ba8b-e61846f24432@googlegroups.com>
In reply to#35104
Am Samstag, 23. Juli 2016 05:50:17 UTC+2 schrieb Arne Vajhøj:
> Or do you really need some advanced features with versioning,
> dependencies, unload etc.?

In my case a plugin should be a Jar package but the plugin can store it's own dependencies.
My plugin should be like ja Mojo plugin.

I think a version checking should be also a nice helpful feature, but I don't need any unloading
structure

So I will take a look on Spring to do it. Did you have got an good link for the basic stuff to learn Spring?

> >            At the moment I have got a question: Is it a good idea,
> > that one Jar file store multiple plugins or is it better that one
> > plugin is represent by one Jar file.
> 
> One plugin per jar.

Thanks, I think this is a good idea

> > Another question is because I'm using Google Guava and there exists a
> > reflection API, so I can iterate over all classes within a package.
> > IMHO I can use this reflection to load my plugin. Is this a good
> > choice?
> 
> Direct reflection is probably too much a reinventing the wheel
> framework.


Yes I think this also, but I collect some ideas at the moment.

Thanks for your great explanation

Phil

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web