|
»
« Return to Thread: RIFE/Modules (was: Here's a handy little utility element)
Re: RIFE/Modules
by Geert Bevin
::
Rate this Message:
Hi Steve,
> I don't think it's a big deal to say that the existing jumpstart is
> a prerequisite. I doubt anyone will have an issue with the idea
> that the modules are a plugin or addon to the base RIFE
> distribution. I don't expect a Firefox extension download link to
> give me Firefox too, to name one not very appropriate example.
>
> Besides, it is quite likely that the vast majority of the people
> downloading the modules will already have the jumpstart anyway,
> since they will want to go through one of the tutorials to find out
> if they care about RIFE in the first place. So bundling it all
> together would just make a bigger download for those people.
I think we misunderstood each-other. The jumpstart would just be the
canvas we use to develop and try out the modules, as well as for
creating examples of their usage. The binary distribution would just
be a jar file with the compiled classes of the sources and any other
required assets (XML files, templates, ...).
As an example, just look at what I did with RIFE/Crud.
> As long as we work out some scheme where people can install
> multiple modules over a jumpstart distribution without them
> overwriting each other, we should be fine. The participant and site
> declarations are the only sticky point there; maybe the "include"
> mechanism needs support for wildcards, so we can just stick
> additional XML files in a couple known directories and they'll be
> picked up automatically by an <include file="rep/site/modules/*"/>
> directive or something like that? (I guess that might not be so
> easy to do when things are packaged into a war file and there is no
> actual directory to scan, but it's a thought.)
This is not possible since RIFE looks up everything through the
claspath. File globbing is thus not an option.
Best regards,
Geert
> -Steve
>
>
> Geert Bevin wrote:
>> So, do you guys have any idea about how to structure this? I was
>> initially thinking of building this on the structure of the
>> jumpstart, but I'm now not so sure that this is a good idea. I did
>> do this for RIFE/Crud though, and people don't seem to have a
>> problem with it since the binary distribution is simply a jar
>> file. The advantage of including the jumpstart is that it's very
>> easy to develop examples and allow people to try out the
>> components. A disadvantage is that the included jumpstart needs to
>> be kept up-to-date with each release, and doing this already takes
>> up a lot of my time.
>>
>> What do you guys think?
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
> I don't think it's a big deal to say that the existing jumpstart is
> a prerequisite. I doubt anyone will have an issue with the idea
> that the modules are a plugin or addon to the base RIFE
> distribution. I don't expect a Firefox extension download link to
> give me Firefox too, to name one not very appropriate example.
>
> Besides, it is quite likely that the vast majority of the people
> downloading the modules will already have the jumpstart anyway,
> since they will want to go through one of the tutorials to find out
> if they care about RIFE in the first place. So bundling it all
> together would just make a bigger download for those people.
I think we misunderstood each-other. The jumpstart would just be the
canvas we use to develop and try out the modules, as well as for
creating examples of their usage. The binary distribution would just
be a jar file with the compiled classes of the sources and any other
required assets (XML files, templates, ...).
As an example, just look at what I did with RIFE/Crud.
> As long as we work out some scheme where people can install
> multiple modules over a jumpstart distribution without them
> overwriting each other, we should be fine. The participant and site
> declarations are the only sticky point there; maybe the "include"
> mechanism needs support for wildcards, so we can just stick
> additional XML files in a couple known directories and they'll be
> picked up automatically by an <include file="rep/site/modules/*"/>
> directive or something like that? (I guess that might not be so
> easy to do when things are packaged into a war file and there is no
> actual directory to scan, but it's a thought.)
This is not possible since RIFE looks up everything through the
claspath. File globbing is thus not an option.
Best regards,
Geert
> -Steve
>
>
> Geert Bevin wrote:
>> So, do you guys have any idea about how to structure this? I was
>> initially thinking of building this on the structure of the
>> jumpstart, but I'm now not so sure that this is a good idea. I did
>> do this for RIFE/Crud though, and people don't seem to have a
>> problem with it since the binary distribution is simply a jar
>> file. The advantage of including the jumpstart is that it's very
>> easy to develop examples and allow people to try out the
>> components. A disadvantage is that the included jumpstart needs to
>> be kept up-to-date with each release, and doing this already takes
>> up a lot of my time.
>>
>> What do you guys think?
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
« Return to Thread: RIFE/Modules (was: Here's a handy little utility element)
| Free embeddable forum powered by Nabble | Forum Help |
