Re: [Stripes-users] Maven convention

[Samuel Santos]

The question is that you don't need to override anything.
We just need an interceptor that calls the method
request.isUserInRole("role") with the roles specified in an annotation. And
obviously have our Taglib support it as well.

Cheers,

--
Samuel Santos
http://www.samaxes.com/


On Fri, Nov 12, 2010 at 2:48 PM, Oscar Westra van Holthe - Kind <
os...@westravanholthe.nl> wrote:

> On 12-11-2010 at 14:44, Samuel Santos wrote:
> > Also, I do not understand why you should have to override the Java EE
> > authentication mechanism in order to have it propagated to the EJB tier.
> Can
> > you explain further?
>
> Actually, it's the other way around: if you want/need to override the
> JavaEE
> authentication mechanism, you'll run into problems because your custom
> authentication won't easily propagate to the EJB tier.
>
>
> Regards,
> Oscar
>
> --
>   ,-_
>  /() ) Oscar Westra van Holthe - Kind
> http://oscar.westravanholthe.nl/
>  (__ (
> =/  ()  DRM "manages access" in the same way that a jail "manages freedom".
>
> -BEGIN PGP SIGNATURE-
>
> iEYEARECAAYFAkzdU9EACgkQLDKOJAl7tOJvEACghK1/bv43Iap3h5XZztVZiDuh
> hnEAoOigY‡ꔛ귏㎍⭚譔�
> =3aEY
> -END PGP SIGNATURE-
>
>
> --
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Oscar Westra van Holthe - Kind]

On 12-11-2010 at 14:44, Samuel Santos wrote:
> Also, I do not understand why you should have to override the Java EE
> authentication mechanism in order to have it propagated to the EJB tier. Can
> you explain further?

Actually, it's the other way around: if you want/need to override the JavaEE
authentication mechanism, you'll run into problems because your custom
authentication won't easily propagate to the EJB tier.


Regards,
Oscar

-- 
   ,-_
  /() ) Oscar Westra van Holthe - Kind  http://oscar.westravanholthe.nl/
 (__ (
=/  ()  DRM "manages access" in the same way that a jail "manages freedom".


signature.asc
Description: Digital signature
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Samuel Santos]

We have always used JAAS in our projects for user authentication and
authorization and never had problem with it. It's easy and straightforward
to use.
I find myself using the SecurityInterceptor (Securing Stripes With ACLs) all
the time since it's a lot simpler than J2EESecurityManager (Security
Interceptor for custom authorization) and its Taglib is a lot more intuitive
and practical. Only once was it not able to satisfy our requirements and we
had to implement our own interceptor.

As Will pointed out, it's a lot more convenient to use an annotation in your
handler methods instead of calling getRequest().isUserInRole("role") each
time you need to authorize a user.

Also, I do not understand why you should have to override the Java EE
authentication mechanism in order to have it propagated to the EJB tier. Can
you explain further?

--
Samuel Santos
http://www.samaxes.com/


On Fri, Nov 12, 2010 at 6:29 AM, Oscar Westra van Holthe - Kind <
os...@westravanholthe.nl> wrote:

> On 11-11-2010 at 20:57, Will Hartung wrote:
> [...]
> > Unfortunately, this is easier said than done, especially before Servlet
> > 3.0. It gets very container specific, especially if you want to propagate
> > the credentials back to the EJB tier in a JEE server.
>
> Here you touch the heart of many problems: AFAIK, overriding the JavaEE
> authentication mechanism and then propagating it to the EJB tier so it can
> be
> used by the standard mechanisms is container specific. It's probably easier
> (for local EJB's at least) to create an entire framework using a session
> variable, and ditch the standard mechanism altogether.
>
>
> > However, there's nothing stopping Stripes from leveraging the existing
> > infrastructure even if it doesn't provide a way to programmatically set
> the
> > role and principle. If someone uses out of the box Form or BASIC
> security,
> > the @Role or whatever annotations will do the trick.
>
> IMHO, this is the best course of action for any framework (if you need it):
> only add to the authorization mechanism, and let the container handle
> authentication and propagate the principal.
>
>
> > I know we have our own custom login handler and our own realm for
> > GlassFish, using its programmatic login so it all works within the
> > framework of the JEE server. But its also GF specific, we'd have to port
> > that were we to go to another server.
> >
> > As far as implementing those modules and such in Stripes, that's not its
> > role, frankly. We use Stripes for login forms, and feed those inputs in
> to
> > our security mechanism. We use a Filter like every one else, but rely on
> > the Principals and Roles back on the EJB tier.
>
> Indeed: a filter at least allows you to override the roles and principles
> in
> the request. Given that Stripes (and many other frameworks as well) work
> more
> or less in the context of a servlet, overriding the principal and roles
> isn't
> even feasible.
>
>
> Regards,
> Oscar
>
> --
>   ,-_  Oscar Westra van Holthe - Kind  
> http://www.xs4all.nl/~kindop/
>  /() )
>  (__ (  No trees were killed in the creation of this message. However,
> =/  ()  many electrons were terribly inconvenienced.
>
> -BEGIN PGP SIGNATURE-
>
> iEYEARECAAYFAkzc3tEACgkQLDKOJAl7tOJWYwCg4JdHEtcoY/MxKJUFzJjfgaO3
> 4QcAmgOFZxfkUdnuCu6fFWTPBlvPGJA/
> =KYOS
> -END PGP SIGNATURE-
>
>
> --
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Oscar Westra van Holthe - Kind]

On 11-11-2010 at 20:57, Will Hartung wrote:
[...]
> Unfortunately, this is easier said than done, especially before Servlet
> 3.0. It gets very container specific, especially if you want to propagate
> the credentials back to the EJB tier in a JEE server.

Here you touch the heart of many problems: AFAIK, overriding the JavaEE
authentication mechanism and then propagating it to the EJB tier so it can be
used by the standard mechanisms is container specific. It's probably easier
(for local EJB's at least) to create an entire framework using a session
variable, and ditch the standard mechanism altogether.


> However, there's nothing stopping Stripes from leveraging the existing
> infrastructure even if it doesn't provide a way to programmatically set the
> role and principle. If someone uses out of the box Form or BASIC security,
> the @Role or whatever annotations will do the trick.

IMHO, this is the best course of action for any framework (if you need it):
only add to the authorization mechanism, and let the container handle
authentication and propagate the principal.


> I know we have our own custom login handler and our own realm for
> GlassFish, using its programmatic login so it all works within the
> framework of the JEE server. But its also GF specific, we'd have to port
> that were we to go to another server.
> 
> As far as implementing those modules and such in Stripes, that's not its
> role, frankly. We use Stripes for login forms, and feed those inputs in to
> our security mechanism. We use a Filter like every one else, but rely on
> the Principals and Roles back on the EJB tier.

Indeed: a filter at least allows you to override the roles and principles in
the request. Given that Stripes (and many other frameworks as well) work more
or less in the context of a servlet, overriding the principal and roles isn't
even feasible.


Regards,
Oscar

-- 
   ,-_  Oscar Westra van Holthe - Kind  http://www.xs4all.nl/~kindop/
  /() )
 (__ (  No trees were killed in the creation of this message. However,
=/  ()  many electrons were terribly inconvenienced.


signature.asc
Description: Digital signature
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Will Hartung]

On Nov 11, 2010, at 6:26 AM, Oscar Westra van Holthe - Kind wrote:

> And honestly, I've not yet encountered a situation where JAAS authorization
> was used. I know that JAAS authorization can be used for user authorization,
> but specifying the permissions for users and objects in a dynamic way using
> JAAS is just too complicated. There are many frameworks offering an easier
> solution for this.
> 
> There are only two reasons why I'd implement authentication using a filter:
> 1. When I want the HttpServletRequest.getUserPrincipal() to return a (proxy
>  to a) domain object, or
> 2. When I want to use the JAAS LoginModule to it's full extend (i.e. create a
>  login wizard using multiple calls to CallbackHandler.handle(Callback[]),
>  like com.sun.security.auth.callback.TextCallbackHandler implicitly does).

And Stripes has nothing to do with JAAS, or security for that matter. The fact 
that we have a convenient Security Interceptor is just that -- convenience.

Now, if someone proposed extending stripes to add ROLE checks much like what 
JEE does already, but down to the event level, I'd be keen to read about such a 
proposal. Something that lets folks declaratively annotate events for certain 
roles, etc. Perhaps reusing the existing JEE annotation that they already have 
on the EJB tier (not quite sure how that would work out, but...its an idea).

But if you were to do that, I'd rather it be off of the standard security 
mechanisms already in place within the Servlet container (i.e checking the 
getUserPrincipal, and isUserInRole). If someone wanted to integrate something 
like Acegi on the front end, but have it still work with a common set of 
annotations, that might be nice too. But, in theory Acegi can integrate with 
the existing JEE infrastructure, so I don't know what that really buys anyone.

Unfortunately, this is easier said than done, especially before Servlet 3.0. It 
gets very container specific, especially if you want to propagate the 
credentials back to the EJB tier in a JEE server.

However, there's nothing stopping Stripes from leveraging the existing 
infrastructure even if it doesn't provide a way to programmatically set the 
role and principle. If someone uses out of the box Form or BASIC security, the 
@Role or whatever annotations will do the trick.

I know we have our own custom login handler and our own realm for GlassFish, 
using its programmatic login so it all works within the framework of the JEE 
server. But its also GF specific, we'd have to port that were we to go to 
another server.

As far as implementing those modules and such in Stripes, that's not its role, 
frankly. We use Stripes for login forms, and feed those inputs in to our 
security mechanism. We use a Filter like every one else, but rely on the 
Principals and Roles back on the EJB tier.

Regards,

Will Hartung


--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Oscar Westra van Holthe - Kind]

On 09-11-2010 at 12:17, Samuel Santos wrote:
> I do agree that we should at least add the support for Java Authentication
> and Authorization Service (JAAS) to Stripes core.

Maybe I'm being silly here, but why? I mean, every servlet container and
application server supports JAAS (the authentication part at least). I
already can add authentication using web.xml, and the only tricky part here
is that often my server needs to use my DB queries (which JBoss already had
an excellent solution for years ago, IMHO).

And honestly, I've not yet encountered a situation where JAAS authorization
was used. I know that JAAS authorization can be used for user authorization,
but specifying the permissions for users and objects in a dynamic way using
JAAS is just too complicated. There are many frameworks offering an easier
solution for this.

There are only two reasons why I'd implement authentication using a filter:
1. When I want the HttpServletRequest.getUserPrincipal() to return a (proxy
   to a) domain object, or
2. When I want to use the JAAS LoginModule to it's full extend (i.e. create a
   login wizard using multiple calls to CallbackHandler.handle(Callback[]),
   like com.sun.security.auth.callback.TextCallbackHandler implicitly does).


Please don't get me wrong: I think it is good to raise the security issue. It
simply is that important. Maybe what I'm missing is consensus on what
security means. I've seen it used as any combination of the following:
- authentication (a user is who he says he is)
- authorization  (a user is allowed to do X, Y and Z, byt not F)
- accountability (on this date & time, user X did Y)
- extra confirmations (authenticating individual transactions, displaying
 extra information, etc. to combat cross-site scripting and other hacks)
- data satefy(the C&D from ACID, and backups; a stretch, but ok)
- SLA & uptime guarantees (this one surprised me)


Oscar

-- 
   ,-_  Oscar Westra van Holthe - Kind  http://www.xs4all.nl/~kindop/
  /() )
 (__ (  Progress is made by lazy men looking for easier ways to do things.
=/  ()  -- Robert Heinlein


signature.asc
Description: Digital signature
--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[VANKEISBELCK Remi]

Thanks for the offering mate !

The Stripes mvn build is almost good now. There's just this ugly test module
(as you could see it yourself), but apart from that most of it works
perfect. I mean, we gen the taglib descriptors etc, sign the jars etc...
There are a few glitches, but overall, it works fine.

We're just waiting for Ben's green light before a directory structure
refactoring, and it'll be perfect...

He won't be long now : he managed to change all the version numbers etc
yesterday, deploy to central (yes yes !!)...
I think he's beginning his love affair with maven, but he won't say it yet
:P

Cheers

Remi

2010/11/10 Nathan Maves 

> For what it is worth I can personally tell you that we (MyBatis.org)
> team are working hard to achieve this same goal.  We now have around 6
> sub maven project along with the core maven project.  It has really
> helped us deliver faster and more stable releases.  It has also
> allowed us to engage more people from the community to help with
> development.  I would love to see the Stripes community follow suit.
>
> Just last week I was trying to find where the unit tests for Stripes
> were located.  To my surprise they are not in the core module.  I also
> just spent a few minutes trying to find the maven page on the website,
> which I have found in the past, and I can't seem to find it again.  I
> would love to see something as simple as
> http://code.google.com/p/mybatis/wiki/DocMavenTutorial.
>
> For those that are still using Ant you really just need to give it a
> try.  I honestly have never seen someone who gives maven a try for
> their build process ever go back to Ant.  For a product who believes
> in convention over configuration I really think it is a perfect fit
> for Stripes.
>
> I am offering up any help or advice that you may need from myself or
> the MyBatis team.
>
> Nathan
>
> On Wed, Nov 10, 2010 at 7:05 AM, Joaquin Valdez
>  wrote:
> >
> > Thanks Ben!
> > On Nov 10, 2010, at 5:54 AM, Ben Gunter wrote:
> >
> > Thanks. That's exactly what I did, and it must have worked!
> >
> > http://repo2.maven.org/maven2/net/sourceforge/stripes/stripes/1.5.4/
> >
> > On Wed, Nov 10, 2010 at 5:35 AM, VANKEISBELCK Remi 
> wrote:
> >>
> >> Not sure it's not too late, but anyway...
> >>
> >> The gpg thing is in the maven build if I remember well, there's a maven
> plugin for that. You just need pgp on the build machine, with a pubkey that
> you have distributed on the PGP network... then mvn clean deploy -Prelease
> if I'm right : this pushes everything on sonatype's repo.
> >> Then, on sonatype, just close the staging request and release.
> >>
> >> Cheers
> >>
> >> Remi
> >>
> >> 2010/11/10 Ben Gunter 
> >>>
> >>> I'm working on releasing 1.5.4 now, but I can't promise I'll get it
> done tonight. There's some stuff involved I've never done, like GPG signing
> the artifacts and getting them synced to central through Sonatype. If I
> screw something up, the release will be delayed.
> >>>
> >>> -Ben
> >>>
> >>> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos <
> nikol...@brightminds.org> wrote:
> 
>  Samuel,
> 
>  I am very much in favour of Maven on any project to the point that I
> have been very vocal about Stripes and Maven support.
> 
>  However, I would agree with Ben that for 1.5.4 that we just keep
> things as they are.  In fact, I think 1.5.4 has stewed long enough and
> should be officially released as we are approaching a year since the release
> of 1.5.3.  As I have mentioned a number of times "perception" is key in
> software IMHO and a release of 1.5.4 trumps internal project changes - at
> least for me.
> 
>  Speaking of which:
> 
>  Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key
> fixes and it has baked long enough?  No???
> 
>  --Nikolaos
> 
> 
> 
> 
>  Samuel Santos wrote:
> 
>  Ben,
> 
>  Consider this as an excuse to optimize our code structure ;)
> 
>  Cheers,
> 
>  --
>  Samuel Santos
>  http://www.samaxes.com/
> 
> 
>  On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter 
> wrote:
> >
> > This is something we can consider after the release of 1.5.4. I
> didn't feel the need to add a Maven build in the first place, and I surely
> don't like the idea of having to move stuff all around to accommodate it so
> there will be resistance.
> >
> > -Ben
> >
> > On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi 
> wrote:
> >>
> >> Hi Nathan,
> >>
> >> In order to keep the current tooling (ant, ide settings, scripts,
> etc) working, and to get the first maven build working smoothly without
> being intrusive, it has been agreed that nothing had to be changed.
> >>
> >> Now that it works, I already talked about some refactoring of the
> folders to allow less config in poms, and more importantly, to allow tests
> to be in the same module than the core code.
> >>
> >> 

Re: [Stripes-users] Maven convention

[Nathan Maves]

For what it is worth I can personally tell you that we (MyBatis.org)
team are working hard to achieve this same goal.  We now have around 6
sub maven project along with the core maven project.  It has really
helped us deliver faster and more stable releases.  It has also
allowed us to engage more people from the community to help with
development.  I would love to see the Stripes community follow suit.

Just last week I was trying to find where the unit tests for Stripes
were located.  To my surprise they are not in the core module.  I also
just spent a few minutes trying to find the maven page on the website,
which I have found in the past, and I can't seem to find it again.  I
would love to see something as simple as
http://code.google.com/p/mybatis/wiki/DocMavenTutorial.

For those that are still using Ant you really just need to give it a
try.  I honestly have never seen someone who gives maven a try for
their build process ever go back to Ant.  For a product who believes
in convention over configuration I really think it is a perfect fit
for Stripes.

I am offering up any help or advice that you may need from myself or
the MyBatis team.

Nathan

On Wed, Nov 10, 2010 at 7:05 AM, Joaquin Valdez
 wrote:
>
> Thanks Ben!
> On Nov 10, 2010, at 5:54 AM, Ben Gunter wrote:
>
> Thanks. That's exactly what I did, and it must have worked!
>
> http://repo2.maven.org/maven2/net/sourceforge/stripes/stripes/1.5.4/
>
> On Wed, Nov 10, 2010 at 5:35 AM, VANKEISBELCK Remi  wrote:
>>
>> Not sure it's not too late, but anyway...
>>
>> The gpg thing is in the maven build if I remember well, there's a maven 
>> plugin for that. You just need pgp on the build machine, with a pubkey that 
>> you have distributed on the PGP network... then mvn clean deploy -Prelease 
>> if I'm right : this pushes everything on sonatype's repo.
>> Then, on sonatype, just close the staging request and release.
>>
>> Cheers
>>
>> Remi
>>
>> 2010/11/10 Ben Gunter 
>>>
>>> I'm working on releasing 1.5.4 now, but I can't promise I'll get it done 
>>> tonight. There's some stuff involved I've never done, like GPG signing the 
>>> artifacts and getting them synced to central through Sonatype. If I screw 
>>> something up, the release will be delayed.
>>>
>>> -Ben
>>>
>>> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos 
>>>  wrote:

 Samuel,

 I am very much in favour of Maven on any project to the point that I have 
 been very vocal about Stripes and Maven support.

 However, I would agree with Ben that for 1.5.4 that we just keep things as 
 they are.  In fact, I think 1.5.4 has stewed long enough and should be 
 officially released as we are approaching a year since the release of 
 1.5.3.  As I have mentioned a number of times "perception" is key in 
 software IMHO and a release of 1.5.4 trumps internal project changes - at 
 least for me.

 Speaking of which:

 Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key 
 fixes and it has baked long enough?  No???

 --Nikolaos




 Samuel Santos wrote:

 Ben,

 Consider this as an excuse to optimize our code structure ;)

 Cheers,

 --
 Samuel Santos
 http://www.samaxes.com/


 On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>
> This is something we can consider after the release of 1.5.4. I didn't 
> feel the need to add a Maven build in the first place, and I surely don't 
> like the idea of having to move stuff all around to accommodate it so 
> there will be resistance.
>
> -Ben
>
> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi  wrote:
>>
>> Hi Nathan,
>>
>> In order to keep the current tooling (ant, ide settings, scripts, etc) 
>> working, and to get the first maven build working smoothly without being 
>> intrusive, it has been agreed that nothing had to be changed.
>>
>> Now that it works, I already talked about some refactoring of the 
>> folders to allow less config in poms, and more importantly, to allow 
>> tests to be in the same module than the core code.
>>
>> For the moment, due to the folder layout that was imposed, I had to 
>> create a specific module for the unit tests. This means that the core 
>> module is built (and deployed if you do mvn deploy) even when tests 
>> fail. It only has to compile to get installed/deployed into maven repos. 
>> That sucks (not that word again...) a lot, and IMHO is the main reason 
>> to so some small refactorings.
>>
>> Ben ? Have you thought about it a little ? Would you mind if I do some 
>> small surgery in 1.5.x and trunk so that we have the tests in the core 
>> module ?
>>
>> Cheers
>>
>> Remi
>>
>>
>> 2010/10/31 Nathan Maves 
>>>
>>> Just curious if anyone has thought to migrate the current layout of the 
>>> st

Re: [Stripes-users] Maven convention

[Joaquin Valdez]

Thanks Ben!

On Nov 10, 2010, at 5:54 AM, Ben Gunter wrote:

> Thanks. That's exactly what I did, and it must have worked!
> 
> http://repo2.maven.org/maven2/net/sourceforge/stripes/stripes/1.5.4/
> 
> On Wed, Nov 10, 2010 at 5:35 AM, VANKEISBELCK Remi  wrote:
> Not sure it's not too late, but anyway...
> 
> The gpg thing is in the maven build if I remember well, there's a maven 
> plugin for that. You just need pgp on the build machine, with a pubkey that 
> you have distributed on the PGP network... then mvn clean deploy -Prelease if 
> I'm right : this pushes everything on sonatype's repo.
> Then, on sonatype, just close the staging request and release.
> 
> Cheers
> 
> Remi
> 
> 2010/11/10 Ben Gunter 
> 
> I'm working on releasing 1.5.4 now, but I can't promise I'll get it done 
> tonight. There's some stuff involved I've never done, like GPG signing the 
> artifacts and getting them synced to central through Sonatype. If I screw 
> something up, the release will be delayed.
> 
> -Ben
> 
> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos 
>  wrote:
> Samuel,
> 
> I am very much in favour of Maven on any project to the point that I have 
> been very vocal about Stripes and Maven support.
> 
> However, I would agree with Ben that for 1.5.4 that we just keep things as 
> they are.  In fact, I think 1.5.4 has stewed long enough and should be 
> officially released as we are approaching a year since the release of 1.5.3.  
> As I have mentioned a number of times "perception" is key in software IMHO 
> and a release of 1.5.4 trumps internal project changes - at least for me.
> 
> Speaking of which:
> 
> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key fixes 
> and it has baked long enough?  No???
> 
> --Nikolaos
> 
> 
> 
> 
> 
> Samuel Santos wrote:
>> 
>> Ben,
>> 
>> Consider this as an excuse to optimize our code structure ;)
>> 
>> Cheers,
>> 
>> --
>> Samuel Santos
>> http://www.samaxes.com/
>> 
>> 
>> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>> This is something we can consider after the release of 1.5.4. I didn't feel 
>> the need to add a Maven build in the first place, and I surely don't like 
>> the idea of having to move stuff all around to accommodate it so there will 
>> be resistance.
>> 
>> -Ben
>> 
>> 
>> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi  wrote:
>> Hi Nathan,
>> 
>> In order to keep the current tooling (ant, ide settings, scripts, etc) 
>> working, and to get the first maven build working smoothly without being 
>> intrusive, it has been agreed that nothing had to be changed.
>> 
>> Now that it works, I already talked about some refactoring of the folders to 
>> allow less config in poms, and more importantly, to allow tests to be in the 
>> same module than the core code. 
>> 
>> For the moment, due to the folder layout that was imposed, I had to create a 
>> specific module for the unit tests. This means that the core module is built 
>> (and deployed if you do mvn deploy) even when tests fail. It only has to 
>> compile to get installed/deployed into maven repos. That sucks (not that 
>> word again...) a lot, and IMHO is the main reason to so some small 
>> refactorings. 
>> 
>> Ben ? Have you thought about it a little ? Would you mind if I do some small 
>> surgery in 1.5.x and trunk so that we have the tests in the core module ?
>> 
>> Cheers
>> 
>> Remi
>> 
>> 
>> 2010/10/31 Nathan Maves 
>> Just curious if anyone has thought to migrate the current layout of the 
>> stripes code to use more Maven conventions?
>> 
>> Nathan
>> 
>> 
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>> 
>> 
> 
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> 
> 
> 
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during 

Re: [Stripes-users] Maven convention

[Ben Gunter]

Thanks. That's exactly what I did, and it must have worked!

http://repo2.maven.org/maven2/net/sourceforge/stripes/stripes/1.5.4/

On Wed, Nov 10, 2010 at 5:35 AM, VANKEISBELCK Remi  wrote:

> Not sure it's not too late, but anyway...
>
> The gpg thing is in the maven build if I remember well, there's a maven
> plugin for that. You just need pgp on the build machine, with a pubkey that
> you have distributed on the PGP network... then mvn clean deploy -Prelease
> if I'm right : this pushes everything on sonatype's repo.
> Then, on sonatype, just close the staging request and release.
>
> Cheers
>
> Remi
>
> 2010/11/10 Ben Gunter 
>
> I'm working on releasing 1.5.4 now, but I can't promise I'll get it done
>> tonight. There's some stuff involved I've never done, like GPG signing the
>> artifacts and getting them synced to central through Sonatype. If I screw
>> something up, the release will be delayed.
>>
>> -Ben
>>
>> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos <
>> nikol...@brightminds.org> wrote:
>>
>>>  Samuel,
>>>
>>> I am very much in favour of Maven on any project to the point that I have
>>> been very vocal about Stripes and Maven support.
>>>
>>> However, I would agree with Ben that for 1.5.4 that we just keep things
>>> as they are.  In fact, I think 1.5.4 has stewed long enough and should be
>>> officially released as we are approaching a year since the release of
>>> 1.5.3.  As I have mentioned a number of times "perception" is key in
>>> software IMHO and a release of 1.5.4 trumps internal project changes - at
>>> least for me.
>>>
>>> Speaking of which:
>>>
>>> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key
>>> fixes and it has baked long enough?  No???
>>>
>>> --Nikolaos
>>>
>>>
>>>
>>>
>>>
>>> Samuel Santos wrote:
>>>
>>> Ben,
>>>
>>> Consider this as an excuse to optimize our code structure ;)
>>>
>>> Cheers,
>>>
>>> --
>>> Samuel Santos
>>> http://www.samaxes.com/
>>>
>>>
>>> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>>>
 This is something we can consider after the release of 1.5.4. I didn't
 feel the need to add a Maven build in the first place, and I surely don't
 like the idea of having to move stuff all around to accommodate it so there
 will be resistance.

 -Ben


 On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi wrote:

> Hi Nathan,
>
> In order to keep the current tooling (ant, ide settings, scripts, etc)
> working, and to get the first maven build working smoothly without being
> intrusive, it has been agreed that nothing had to be changed.
>
> Now that it works, I already talked about some refactoring of the
> folders to allow less config in poms, and more importantly, to allow tests
> to be in the same module than the core code.
>
> For the moment, due to the folder layout that was imposed, I had to
> create a specific module for the unit tests. This means that the core 
> module
> is built (and deployed if you do mvn deploy) even when tests fail. It only
> has to compile to get installed/deployed into maven repos. That sucks (not
> that word again...) a lot, and IMHO is the main reason to so some small
> refactorings.
>
> Ben ? Have you thought about it a little ? Would you mind if I do some
> small surgery in 1.5.x and trunk so that we have the tests in the core
> module ?
>
> Cheers
>
> Remi
>
>
> 2010/10/31 Nathan Maves 
>
>> Just curious if anyone has thought to migrate the current layout of
>> the stripes code to use more Maven conventions?
>>
>>  Nathan
>>
>


 --
 The Next 800 Companies to Lead America's Growth: New Video Whitepaper
 David G. Thomson, author of the best-selling book "Blueprint to a
 Billion" shares his insights and actions to help propel your
 business during the next growth cycle. Listen Now!
 http://p.sf.net/sfu/SAP-dev2dev
 ___
 Stripes-users mailing list
 Stripes-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/stripes-users


>>>
>>>
>>> --
>>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>>> David G. Thomson, author of the best-selling book "Blueprint to a
>>> Billion" shares his insights and actions to help propel your
>>> business during the next growth cycle. Listen Now!
>>> http://p.sf.net/sfu/SAP-dev2dev
>>> ___
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's G

Re: [Stripes-users] Maven convention

[VANKEISBELCK Remi]

Not sure it's not too late, but anyway...

The gpg thing is in the maven build if I remember well, there's a maven
plugin for that. You just need pgp on the build machine, with a pubkey that
you have distributed on the PGP network... then mvn clean deploy -Prelease
if I'm right : this pushes everything on sonatype's repo.
Then, on sonatype, just close the staging request and release.

Cheers

Remi

2010/11/10 Ben Gunter 

> I'm working on releasing 1.5.4 now, but I can't promise I'll get it done
> tonight. There's some stuff involved I've never done, like GPG signing the
> artifacts and getting them synced to central through Sonatype. If I screw
> something up, the release will be delayed.
>
> -Ben
>
> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos <
> nikol...@brightminds.org> wrote:
>
>>  Samuel,
>>
>> I am very much in favour of Maven on any project to the point that I have
>> been very vocal about Stripes and Maven support.
>>
>> However, I would agree with Ben that for 1.5.4 that we just keep things as
>> they are.  In fact, I think 1.5.4 has stewed long enough and should be
>> officially released as we are approaching a year since the release of
>> 1.5.3.  As I have mentioned a number of times "perception" is key in
>> software IMHO and a release of 1.5.4 trumps internal project changes - at
>> least for me.
>>
>> Speaking of which:
>>
>> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key
>> fixes and it has baked long enough?  No???
>>
>> --Nikolaos
>>
>>
>>
>>
>>
>> Samuel Santos wrote:
>>
>> Ben,
>>
>> Consider this as an excuse to optimize our code structure ;)
>>
>> Cheers,
>>
>> --
>> Samuel Santos
>> http://www.samaxes.com/
>>
>>
>> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>>
>>> This is something we can consider after the release of 1.5.4. I didn't
>>> feel the need to add a Maven build in the first place, and I surely don't
>>> like the idea of having to move stuff all around to accommodate it so there
>>> will be resistance.
>>>
>>> -Ben
>>>
>>>
>>> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi wrote:
>>>
 Hi Nathan,

 In order to keep the current tooling (ant, ide settings, scripts, etc)
 working, and to get the first maven build working smoothly without being
 intrusive, it has been agreed that nothing had to be changed.

 Now that it works, I already talked about some refactoring of the
 folders to allow less config in poms, and more importantly, to allow tests
 to be in the same module than the core code.

 For the moment, due to the folder layout that was imposed, I had to
 create a specific module for the unit tests. This means that the core 
 module
 is built (and deployed if you do mvn deploy) even when tests fail. It only
 has to compile to get installed/deployed into maven repos. That sucks (not
 that word again...) a lot, and IMHO is the main reason to so some small
 refactorings.

 Ben ? Have you thought about it a little ? Would you mind if I do some
 small surgery in 1.5.x and trunk so that we have the tests in the core
 module ?

 Cheers

 Remi


 2010/10/31 Nathan Maves 

> Just curious if anyone has thought to migrate the current layout of the
> stripes code to use more Maven conventions?
>
>  Nathan
>

>>>
>>>
>>> --
>>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>>> David G. Thomson, author of the best-selling book "Blueprint to a
>>> Billion" shares his insights and actions to help propel your
>>> business during the next growth cycle. Listen Now!
>>> http://p.sf.net/sfu/SAP-dev2dev
>>> ___
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-users mailing list
> Stripes-use

Re: [Stripes-users] Maven convention

[Ben Gunter]

I'm working on releasing 1.5.4 now, but I can't promise I'll get it done
tonight. There's some stuff involved I've never done, like GPG signing the
artifacts and getting them synced to central through Sonatype. If I screw
something up, the release will be delayed.

-Ben

On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:

>  Samuel,
>
> I am very much in favour of Maven on any project to the point that I have
> been very vocal about Stripes and Maven support.
>
> However, I would agree with Ben that for 1.5.4 that we just keep things as
> they are.  In fact, I think 1.5.4 has stewed long enough and should be
> officially released as we are approaching a year since the release of
> 1.5.3.  As I have mentioned a number of times "perception" is key in
> software IMHO and a release of 1.5.4 trumps internal project changes - at
> least for me.
>
> Speaking of which:
>
> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key fixes
> and it has baked long enough?  No???
>
> --Nikolaos
>
>
>
>
>
> Samuel Santos wrote:
>
> Ben,
>
> Consider this as an excuse to optimize our code structure ;)
>
> Cheers,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>
>> This is something we can consider after the release of 1.5.4. I didn't
>> feel the need to add a Maven build in the first place, and I surely don't
>> like the idea of having to move stuff all around to accommodate it so there
>> will be resistance.
>>
>> -Ben
>>
>>
>> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi wrote:
>>
>>> Hi Nathan,
>>>
>>> In order to keep the current tooling (ant, ide settings, scripts, etc)
>>> working, and to get the first maven build working smoothly without being
>>> intrusive, it has been agreed that nothing had to be changed.
>>>
>>> Now that it works, I already talked about some refactoring of the folders
>>> to allow less config in poms, and more importantly, to allow tests to be in
>>> the same module than the core code.
>>>
>>> For the moment, due to the folder layout that was imposed, I had to
>>> create a specific module for the unit tests. This means that the core module
>>> is built (and deployed if you do mvn deploy) even when tests fail. It only
>>> has to compile to get installed/deployed into maven repos. That sucks (not
>>> that word again...) a lot, and IMHO is the main reason to so some small
>>> refactorings.
>>>
>>> Ben ? Have you thought about it a little ? Would you mind if I do some
>>> small surgery in 1.5.x and trunk so that we have the tests in the core
>>> module ?
>>>
>>> Cheers
>>>
>>> Remi
>>>
>>>
>>> 2010/10/31 Nathan Maves 
>>>
 Just curious if anyone has thought to migrate the current layout of the
 stripes code to use more Maven conventions?

  Nathan

>>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Samuel Santos]

I do agree that we should at least add the support for Java Authentication
and Authorization Service (JAAS) to Stripes core.

On the other hand, I also feel that the support for external frameworks
(i.e. Spring) don't belong in Stripes core and should me moved to external
extensions.

Cheers,

--
Samuel Santos
http://www.samaxes.com/


On Mon, Nov 8, 2010 at 7:07 AM, dimension123 dimension123 <
dimension...@gmail.com> wrote:

> I am curious if there are any things related to security that are going
> into 1.5.4.
> I think the only thing lacking with stripes is security and while i
> understand the argument that there are other frameworks that handle security
> well, i feel large corporate tech shops turn down proposals from architects
> pushing stripes because of its lack of security consideration ...security is
> perhaps one of the most important factors when it comes to IT heads adopting
> a new framework;  if they have to use say spring security with stripes, then
> they are going to go spring all the way in many cases i think as the
> impression is that it will be more economical to pour resources into
> learning/adopting a single framework rather than two.
> Just my 2 pennies...
>
> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos <
> nikol...@brightminds.org> wrote:
>
>>  Samuel,
>>
>> I am very much in favour of Maven on any project to the point that I have
>> been very vocal about Stripes and Maven support.
>>
>> However, I would agree with Ben that for 1.5.4 that we just keep things as
>> they are.  In fact, I think 1.5.4 has stewed long enough and should be
>> officially released as we are approaching a year since the release of
>> 1.5.3.  As I have mentioned a number of times "perception" is key in
>> software IMHO and a release of 1.5.4 trumps internal project changes - at
>> least for me.
>>
>> Speaking of which:
>>
>> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key
>> fixes and it has baked long enough?  No???
>>
>> --Nikolaos
>>
>>
>>
>>
>>
>> Samuel Santos wrote:
>>
>> Ben,
>>
>> Consider this as an excuse to optimize our code structure ;)
>>
>> Cheers,
>>
>> --
>> Samuel Santos
>> http://www.samaxes.com/
>>
>>
>> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>>
>>> This is something we can consider after the release of 1.5.4. I didn't
>>> feel the need to add a Maven build in the first place, and I surely don't
>>> like the idea of having to move stuff all around to accommodate it so there
>>> will be resistance.
>>>
>>> -Ben
>>>
>>>
>>> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi wrote:
>>>
 Hi Nathan,

 In order to keep the current tooling (ant, ide settings, scripts, etc)
 working, and to get the first maven build working smoothly without being
 intrusive, it has been agreed that nothing had to be changed.

 Now that it works, I already talked about some refactoring of the
 folders to allow less config in poms, and more importantly, to allow tests
 to be in the same module than the core code.

 For the moment, due to the folder layout that was imposed, I had to
 create a specific module for the unit tests. This means that the core 
 module
 is built (and deployed if you do mvn deploy) even when tests fail. It only
 has to compile to get installed/deployed into maven repos. That sucks (not
 that word again...) a lot, and IMHO is the main reason to so some small
 refactorings.

 Ben ? Have you thought about it a little ? Would you mind if I do some
 small surgery in 1.5.x and trunk so that we have the tests in the core
 module ?

 Cheers

 Remi


 2010/10/31 Nathan Maves 

> Just curious if anyone has thought to migrate the current layout of the
> stripes code to use more Maven conventions?
>
>  Nathan
>

>>>
>>>
>>> --
>>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>>> David G. Thomson, author of the best-selling book "Blueprint to a
>>> Billion" shares his insights and actions to help propel your
>>> business during the next growth cycle. Listen Now!
>>> http://p.sf.net/sfu/SAP-dev2dev
>>> ___
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/l

Re: [Stripes-users] Maven convention

[dimension123 dimension123]

I am curious if there are any things related to security that are going into
1.5.4.
I think the only thing lacking with stripes is security and while i
understand the argument that there are other frameworks that handle security
well, i feel large corporate tech shops turn down proposals from architects
pushing stripes because of its lack of security consideration ...security is
perhaps one of the most important factors when it comes to IT heads adopting
a new framework;  if they have to use say spring security with stripes, then
they are going to go spring all the way in many cases i think as the
impression is that it will be more economical to pour resources into
learning/adopting a single framework rather than two.
Just my 2 pennies...

On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:

>  Samuel,
>
> I am very much in favour of Maven on any project to the point that I have
> been very vocal about Stripes and Maven support.
>
> However, I would agree with Ben that for 1.5.4 that we just keep things as
> they are.  In fact, I think 1.5.4 has stewed long enough and should be
> officially released as we are approaching a year since the release of
> 1.5.3.  As I have mentioned a number of times "perception" is key in
> software IMHO and a release of 1.5.4 trumps internal project changes - at
> least for me.
>
> Speaking of which:
>
> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key fixes
> and it has baked long enough?  No???
>
> --Nikolaos
>
>
>
>
>
> Samuel Santos wrote:
>
> Ben,
>
> Consider this as an excuse to optimize our code structure ;)
>
> Cheers,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>
>> This is something we can consider after the release of 1.5.4. I didn't
>> feel the need to add a Maven build in the first place, and I surely don't
>> like the idea of having to move stuff all around to accommodate it so there
>> will be resistance.
>>
>> -Ben
>>
>>
>> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi wrote:
>>
>>> Hi Nathan,
>>>
>>> In order to keep the current tooling (ant, ide settings, scripts, etc)
>>> working, and to get the first maven build working smoothly without being
>>> intrusive, it has been agreed that nothing had to be changed.
>>>
>>> Now that it works, I already talked about some refactoring of the folders
>>> to allow less config in poms, and more importantly, to allow tests to be in
>>> the same module than the core code.
>>>
>>> For the moment, due to the folder layout that was imposed, I had to
>>> create a specific module for the unit tests. This means that the core module
>>> is built (and deployed if you do mvn deploy) even when tests fail. It only
>>> has to compile to get installed/deployed into maven repos. That sucks (not
>>> that word again...) a lot, and IMHO is the main reason to so some small
>>> refactorings.
>>>
>>> Ben ? Have you thought about it a little ? Would you mind if I do some
>>> small surgery in 1.5.x and trunk so that we have the tests in the core
>>> module ?
>>>
>>> Cheers
>>>
>>> Remi
>>>
>>>
>>> 2010/10/31 Nathan Maves 
>>>
 Just curious if anyone has thought to migrate the current layout of the
 stripes code to use more Maven conventions?

  Nathan

>>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Samuel Santos]

Hi Nikolaos,

Please don't get me wrong, I agree with both of you.
I'm all in favor of Maven ...but only after the release of 1.5.4.

Cheers,

--
Samuel Santos
http://www.samaxes.com/


On Mon, Nov 8, 2010 at 2:09 AM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:

>  Samuel,
>
> I am very much in favour of Maven on any project to the point that I have
> been very vocal about Stripes and Maven support.
>
> However, I would agree with Ben that for 1.5.4 that we just keep things as
> they are.  In fact, I think 1.5.4 has stewed long enough and should be
> officially released as we are approaching a year since the release of
> 1.5.3.  As I have mentioned a number of times "perception" is key in
> software IMHO and a release of 1.5.4 trumps internal project changes - at
> least for me.
>
> Speaking of which:
>
> Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key fixes
> and it has baked long enough?  No???
>
> --Nikolaos
>
>
>
>
>
> Samuel Santos wrote:
>
> Ben,
>
> Consider this as an excuse to optimize our code structure ;)
>
> Cheers,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:
>
>> This is something we can consider after the release of 1.5.4. I didn't
>> feel the need to add a Maven build in the first place, and I surely don't
>> like the idea of having to move stuff all around to accommodate it so there
>> will be resistance.
>>
>> -Ben
>>
>>
>> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi wrote:
>>
>>> Hi Nathan,
>>>
>>> In order to keep the current tooling (ant, ide settings, scripts, etc)
>>> working, and to get the first maven build working smoothly without being
>>> intrusive, it has been agreed that nothing had to be changed.
>>>
>>> Now that it works, I already talked about some refactoring of the folders
>>> to allow less config in poms, and more importantly, to allow tests to be in
>>> the same module than the core code.
>>>
>>> For the moment, due to the folder layout that was imposed, I had to
>>> create a specific module for the unit tests. This means that the core module
>>> is built (and deployed if you do mvn deploy) even when tests fail. It only
>>> has to compile to get installed/deployed into maven repos. That sucks (not
>>> that word again...) a lot, and IMHO is the main reason to so some small
>>> refactorings.
>>>
>>> Ben ? Have you thought about it a little ? Would you mind if I do some
>>> small surgery in 1.5.x and trunk so that we have the tests in the core
>>> module ?
>>>
>>> Cheers
>>>
>>> Remi
>>>
>>>
>>> 2010/10/31 Nathan Maves 
>>>
 Just curious if anyone has thought to migrate the current layout of the
 stripes code to use more Maven conventions?

  Nathan

>>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
>
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Nikolaos Giannopoulos]

Samuel,

I am very much in favour of Maven on any project to the point that I 
have been very vocal about Stripes and Maven support.


However, I would agree with Ben that for 1.5.4 that we just keep things 
as they are.  In fact, I think 1.5.4 has stewed long enough and should 
be officially released as we are approaching a year since the release of 
1.5.3.  As I have mentioned a number of times "perception" is key in 
software IMHO and a release of 1.5.4 trumps internal project changes - 
at least for me.


Speaking of which:

Ben:  Any idea when 1.5.4 will be released?  It contains a lot of key 
fixes and it has baked long enough?  No???


--Nikolaos




Samuel Santos wrote:

Ben,

Consider this as an excuse to optimize our code structure ;)

Cheers,

--
Samuel Santos
http://www.samaxes.com/


On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter > wrote:


This is something we can consider after the release of 1.5.4. I
didn't feel the need to add a Maven build in the first place, and
I surely don't like the idea of having to move stuff all around to
accommodate it so there will be resistance.

-Ben


On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi mailto:r...@rvkb.com>> wrote:

Hi Nathan,

In order to keep the current tooling (ant, ide settings,
scripts, etc) working, and to get the first maven build
working smoothly without being intrusive, it has been agreed
that nothing had to be changed.

Now that it works, I already talked about some refactoring of
the folders to allow less config in poms, and more
importantly, to allow tests to be in the same module than the
core code.

For the moment, due to the folder layout that was imposed, I
had to create a specific module for the unit tests. This means
that the core module is built (and deployed if you do mvn
deploy) even when tests fail. It only has to compile to get
installed/deployed into maven repos. That sucks (not that word
again...) a lot, and IMHO is the main reason to so some small
refactorings.

Ben ? Have you thought about it a little ? Would you mind if I
do some small surgery in 1.5.x and trunk so that we have the
tests in the core module ?

Cheers

Remi


2010/10/31 Nathan Maves mailto:nathan.ma...@gmail.com>>

Just curious if anyone has thought to migrate the current
layout of the stripes code to use more Maven conventions?

Nathan




--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/stripes-users


--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Samuel Santos]

Ben,

Consider this as an excuse to optimize our code structure ;)

Cheers,

--
Samuel Santos
http://www.samaxes.com/


On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter  wrote:

> This is something we can consider after the release of 1.5.4. I didn't feel
> the need to add a Maven build in the first place, and I surely don't like
> the idea of having to move stuff all around to accommodate it so there will
> be resistance.
>
> -Ben
>
>
> On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi  wrote:
>
>> Hi Nathan,
>>
>> In order to keep the current tooling (ant, ide settings, scripts, etc)
>> working, and to get the first maven build working smoothly without being
>> intrusive, it has been agreed that nothing had to be changed.
>>
>> Now that it works, I already talked about some refactoring of the folders
>> to allow less config in poms, and more importantly, to allow tests to be in
>> the same module than the core code.
>>
>> For the moment, due to the folder layout that was imposed, I had to create
>> a specific module for the unit tests. This means that the core module is
>> built (and deployed if you do mvn deploy) even when tests fail. It only has
>> to compile to get installed/deployed into maven repos. That sucks (not that
>> word again...) a lot, and IMHO is the main reason to so some small
>> refactorings.
>>
>> Ben ? Have you thought about it a little ? Would you mind if I do some
>> small surgery in 1.5.x and trunk so that we have the tests in the core
>> module ?
>>
>> Cheers
>>
>> Remi
>>
>>
>> 2010/10/31 Nathan Maves 
>>
>>> Just curious if anyone has thought to migrate the current layout of the
>>> stripes code to use more Maven conventions?
>>>
>>> Nathan
>>>
>>
>
>
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[Ben Gunter]

This is something we can consider after the release of 1.5.4. I didn't feel
the need to add a Maven build in the first place, and I surely don't like
the idea of having to move stuff all around to accommodate it so there will
be resistance.

-Ben

On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi  wrote:

> Hi Nathan,
>
> In order to keep the current tooling (ant, ide settings, scripts, etc)
> working, and to get the first maven build working smoothly without being
> intrusive, it has been agreed that nothing had to be changed.
>
> Now that it works, I already talked about some refactoring of the folders
> to allow less config in poms, and more importantly, to allow tests to be in
> the same module than the core code.
>
> For the moment, due to the folder layout that was imposed, I had to create
> a specific module for the unit tests. This means that the core module is
> built (and deployed if you do mvn deploy) even when tests fail. It only has
> to compile to get installed/deployed into maven repos. That sucks (not that
> word again...) a lot, and IMHO is the main reason to so some small
> refactorings.
>
> Ben ? Have you thought about it a little ? Would you mind if I do some
> small surgery in 1.5.x and trunk so that we have the tests in the core
> module ?
>
> Cheers
>
> Remi
>
>
> 2010/10/31 Nathan Maves 
>
>> Just curious if anyone has thought to migrate the current layout of the
>> stripes code to use more Maven conventions?
>>
>> Nathan
>>
>
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Maven convention

[VANKEISBELCK Remi]

Hi Nathan,

In order to keep the current tooling (ant, ide settings, scripts, etc)
working, and to get the first maven build working smoothly without being
intrusive, it has been agreed that nothing had to be changed.

Now that it works, I already talked about some refactoring of the folders to
allow less config in poms, and more importantly, to allow tests to be in the
same module than the core code.

For the moment, due to the folder layout that was imposed, I had to create a
specific module for the unit tests. This means that the core module is built
(and deployed if you do mvn deploy) even when tests fail. It only has to
compile to get installed/deployed into maven repos. That sucks (not that
word again...) a lot, and IMHO is the main reason to so some small
refactorings.

Ben ? Have you thought about it a little ? Would you mind if I do some small
surgery in 1.5.x and trunk so that we have the tests in the core module ?

Cheers

Remi


2010/10/31 Nathan Maves 

> Just curious if anyone has thought to migrate the current layout of the
> stripes code to use more Maven conventions?
>
> Nathan
>
>
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Stripes-users] Maven convention

[Nathan Maves]

Just curious if anyone has thought to migrate the current layout of the
stripes code to use more Maven conventions?

Nathan
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users