Hi folks

For plugin management I've seen that grails uses Apache Ivy. This works with
Maven and can be altered to work for us I think.

Moving to maven - I'm not sure that really gives much benefit. When we start
building a system with plugins we need a dependency management system (Ivy
og Maven). Since we are using ant now - going for the ant based solution
(Apache Ivy) sounds like a good idea for me.

Please comment.

Morten

2011/4/19 Samuel Santos <sama...@gmail.com>

> Hi Remi and all,
>
> I'm not a huge fan of integrating extensions into the main build, "de facto
> standard" is somewhat subjective.
> I believe we should first think about a better plugin system (as Morten
> pointed out on Stripes LinkedIn Group).
>
> What I would like to see in Stripes:
>
>    1. Full Maven build;
>    2. Validate what belongs to core and what doesn't, I do believe that:
>       1. Spring integration should be moved from core to a plugin (Java EE
>       users will probably never use/need this feature);
>       2. Stripes Layout Tags should be moved from core to a plugin
>       (Sitemesh users will probably never use/need this feature);
>       3. Stripes Security should be moved from plugin to core (Security
>       and JAAS integration is a fundamental feature in any Java web 
> framework).
>    3. Move Stripes source code to GitHub:
>       1. Create a Stripes organization;
>       2. Create Stripes Core project under Stripes organization (developers
>       can fork it, fix issues and add new features, that can later be pulled 
> into
>       the master branch);
>       3. Allow developers to create plugins / extensions under Stripes
>       organization or fork their plugins.
>
>
> However, I'm not sure that we should do any change before Stripes 1.6.
> I miss ObjectPostProcessor so much that I rather prefer to release 1.6
> first and then make the changes.
>
> What do you think?
>
> Cheers,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Mon, Apr 18, 2011 at 10:47 PM, VANKEISBELCK Remi <r...@rvkb.com> wrote:
>
>> Hey Ben,
>>
>> First things first, what about :
>> 1/ full maven build (yeah, drop ant for good), with refactoring of the
>> source folders etc.
>> 2/ integrate all  extensions to the main build (as submodules) -
>> Stripersist / Stripes security for starters
>>
>> 3/ ask plugin devs to submit doc for their plugins, to be integrated to
>> the main wiki
>>
>> I know you're not a maven freak, but really, 2 separate builds is awkward,
>> and having a standard build would help a lot for third party integration. I
>> really think a small source layout refactoring and dropping all the
>> build.xml stuff wouldn't hurt.
>>
>> I'm ok to do this on 1.5.x and trunk whenever you want.
>>
>> Cheers
>>
>> Remi
>>
>>
>> 2011/4/18 Ben Gunter <gunter...@gmail.com>
>>
>>> I just chimed in on the LinkedIn discussion, though there's not much to
>>> my response. Basically, I'd like to see a clear plan for what you want to
>>> do. Then we can discuss how to execute the plan.
>>>
>>>
>>> On Thu, Apr 14, 2011 at 9:01 PM, Morten Matras 
>>> <morten.mat...@gmail.com>wrote:
>>>
>>>> Hi George
>>>>
>>>> In the Stripesframework linked in group there is an ongoing discussion
>>>> regarding this topic.
>>>>
>>>> There seems to be a consensus regarding your ideas. Currently we're
>>>> waiting for Ben / Tim to give their opinion before stepping forward with
>>>> some action.
>>>>
>>>> Ben?
>>>>
>>>> Thanks
>>>>
>>>> Morten
>>>>
>>>> 2011/4/14 George Clark <gc1...@gmail.com>
>>>>
>>>>> Hi all,
>>>>>
>>>>>    I enjoy Stripes in my personal time.  Unfortunately, at the office
>>>>> we're using Grails.  I'm wondering if any of you have thought about or
>>>>> implemented a grails-type plugin solution in your dev environments?
>>>>>
>>>>>    There are a few things I enjoy about Grails and one of them is their
>>>>> plugin strategy.  It can be messy at times but I feel we've leveraged it
>>>>> well and it's become pretty valuable.   An example might be something
>>>>> off-the-shelf like an Acegi authentication plugin.  It can be "installed"
>>>>> through maven, and it's controllers, configuration and WEB-INF resources 
>>>>> are
>>>>> merged into the main application.
>>>>>
>>>>>    But I suppose the real benefit is if you're in charge of five or six
>>>>> applications in different repositories and want to share more than just
>>>>> taglibs.  For instance, we have a system that consumes events from running
>>>>> applications and makes decisions to notify people of said events.   We've
>>>>> built a plugin that provides beans to create such events, controllers to 
>>>>> act
>>>>> as an interface to the queued data, and controllers that provide views to
>>>>> allow humans to inspect the app directly complete with images, css and
>>>>> javascript.  It appears as a complete application structure:
>>>>> controllers/views/jars/assests, etc.
>>>>>
>>>>>    Any person creating a new webapp merely adds event-monitoring-plugin
>>>>> in their pom and now they've met the corporate web interface for 
>>>>> monitoring
>>>>> and reporting.  Occasionally the plugin is upgraded and we can simply 
>>>>> change
>>>>> the value in the pom and rebuild the application.  I'm feeling like if we
>>>>> were doing this is stripes I would be copying these resources into every
>>>>> application and they would live within that applications resources.
>>>>>
>>>>>    I suppose I could do something at build time where I unzip a package
>>>>> over-top of main application code which adds controllers and adds 
>>>>> resources
>>>>> to WEB-INF.  Maybe I could also make it smart enough to modify the
>>>>> ActionResolver.Packages list.   Or, maybe I just need to think about this
>>>>> differently altogether!
>>>>>
>>>>>    What kinds of processes/solutions do you use when wanting to share
>>>>> this kind of code?
>>>>>
>>>>> Thanks!
>>>>> George
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Benefiting from Server Virtualization: Beyond Initial Workload
>>>>> Consolidation -- Increasing the use of server virtualization is a top
>>>>> priority.Virtualization can reduce costs, simplify management, and
>>>>> improve
>>>>> application availability and disaster protection. Learn more about
>>>>> boosting
>>>>> the value of server virtualization.
>>>>> http://p.sf.net/sfu/vmware-sfdev2dev
>>>>> _______________________________________________
>>>>> Stripes-users mailing list
>>>>> Stripes-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>   Morten Matras
>>>>   Consultant
>>>>   Blob Communication ApS
>>>>   Svendsagervej 42
>>>>   DK-5240 Odense NØ
>>>>   P: (+45) 36 96 07 06
>>>>   W: www.blobcom.com
>>>>   E: morten.mat...@gmail.com
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Benefiting from Server Virtualization: Beyond Initial Workload
>>>> Consolidation -- Increasing the use of server virtualization is a top
>>>> priority.Virtualization can reduce costs, simplify management, and
>>>> improve
>>>> application availability and disaster protection. Learn more about
>>>> boosting
>>>> the value of server virtualization.
>>>> http://p.sf.net/sfu/vmware-sfdev2dev
>>>> _______________________________________________
>>>> Stripes-users mailing list
>>>> Stripes-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Benefiting from Server Virtualization: Beyond Initial Workload
>>> Consolidation -- Increasing the use of server virtualization is a top
>>> priority.Virtualization can reduce costs, simplify management, and
>>> improve
>>> application availability and disaster protection. Learn more about
>>> boosting
>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>>> _______________________________________________
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Benefiting from Server Virtualization: Beyond Initial Workload
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve
>> application availability and disaster protection. Learn more about
>> boosting
>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>


-- 
  Morten Matras
  Consultant
  Blob Communication ApS
  Svendsagervej 42
  DK-5240 Odense NØ
  P: (+45) 36 96 07 06
  W: www.blobcom.com
  E: morten.mat...@gmail.com
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to