Hi folks,
The main advantage of integrating the extensions to the main build is to
centralize everything : you build the framework, you build the extensions.
We benefit of our C.I. infrastructure etc. I can't see what the problem is.
Look at other frameworks, that's how they do it (Spring, Hibernate etc).
Btw I think you concur actually : you give a very good example with the
Spring integration, layouts etc. If you had to do this from scratch, you'd
probably move the Spring extension sources under a submodule of your
agregator project (not in the "core" module), and you'd probably have all
sources in the same tree. That's exactly what I'm talking about :)
For "official" extensions, I've always used double quotes for that :P
I guess "official" means "approved by the community" (the ones you've cited
are good examples).
As for Ivy, I've never used it but I think you'll still need to configure a
repository of some kind to back it. I guess maven integration comes free,
but then you'll still need to build what you depend on with maven... pretty
useless then.
To be honest I don't understand the reluctancy for switching to maven.
If you guys have a better alternative, please speak up. I think switching to
maven was a good move, it brought lots of benefits, the main one being
central repository sync. Now, it can handle our multi module issue very
easily. We don't need to hack anything, it's a feature of the build tool. So
what ?
What's the issue in having a consistent, standard build that works and is
easy to maintain/understand, with central sync for free, loads of tooling
etc. ?
Morten, you said "[Ivy] can be altered to work for us" : that's precisely
it. Maven need no alteration : it already works out of the box and is backed
by a (very) large community. I don't want to "alter" anything : I prefer
stuff that already works.
And btw we already have a maven build, all I'm talking about is to drop ant
definitively and have one and single build system, that can handle the
extensions easily, and doesn't require any work. It must be around half a
day work to refactor the maven Stripes build, and have the extensions tossed
in submodules, integrated to our C.I. and deployed in the maven repo.
Really. Simple, and effective.
For the plugin system now, I think tooling is very nice (shell scripts etc,
a la Grails) but we have absolutely no idea of what it would look like for
now. I suggest (again) using maven to kick start the process because :
1/ it would be consistent with the rest of the build
2/ it handles dependencies
3/ it can even handle war overlay, for plugins that bundle JSPs
In short, using maven would make it really easy to write extensions (inherit
a parent pom) and use them (depend on the extension's pom(s)). Ok, it's not
much compared to rails-style command line tools etc, but it's a start.
Doesn't have to be fancy, all we ask for a first step is that it works and
is easy to use.
The original problem is to enable easier integration of extensions,
centralization of the info etc. Sugar comes after IMHO.
Again, if you guys have a simpler solution, I'm ready to change my mind. But
to be honest, maven really shines for multi-module projects, and that's what
we're moving towards...
For the switch to github, again, I'd like to see this happen as well, but
it's another story I think. We can discuss this in a separate thread maybe ?
Cheers
Remi
2011/4/19 Morten Matras <morten.mat...@gmail.com>
> 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
