You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2008/12/27 00:12:05 UTC
Having multiple build systems for jsecurity
I'm wondering if it would be possible to have multiple build systems
for the same body of code. Each build system proponent would take
responsibility for maintaining their build system. It would kinda
like be Berlin after WWII.
Thoughts?
Regards,
Alan
RE: Having multiple build systems for jsecurity
Posted by "Kofford, C Todd" <tk...@ku.edu>.
I've been watching this thread and just had to speak up.
I just completed a project where I used Jsecurity for the 1st time, and
I have to say that Les & Jeremy both were extremely prompt and helpful
each time I had questions or ran into problems. I'm not just talking
about one or two sentence answers, but full blown solutions to my
problem and in many cases several to choose from. If you don't believe
me go check it out for yourselves and search for my name, Todd Kofford,
in the forums.
I've been developing software for quite a while and have been involved
in many development communities, but I have to say the support that I
got from the Jsecurity forums was second to none. It was some of the
most prompt and best support that I have ever received and I wasn't even
paying them a dime!
Just my 2 cents,
Todd Kofford
tkofford@ku.edu
University of Kansas - IT
-----Original Message-----
From: les.hazlewood@anjinllc.com [mailto:les.hazlewood@anjinllc.com] On
Behalf Of Les Hazlewood
Sent: Friday, January 02, 2009 2:02 PM
To: jsecurity-dev@incubator.apache.org
Subject: Re: Having multiple build systems for jsecurity
On Fri, Jan 2, 2009 at 12:55 PM, Alan D. Cabrera
<li...@toolazydogs.com>wrote:
>
> On Dec 31, 2008, at 6:38 AM, Jeremy Haile wrote:
>
> I'm glad that you are interested in investigating JSecurity, even if
it's
>> just edging over the line =)
>>
>
> Don't expect people to want to climb on board the project with these
kinds
> of responses....
I think you might have misinterpreted Jeremy's response - I'm fairly
certain
he said that tongue-in-cheek with a smile on his face (thus the
emoticon).
We have a long-standing and proud tradition of being extremely open to
all
of our users' input in practically all cases. We're also very proactive
in
helping people with solutions, offering advice, and answering general
email
and forum postings on the project lists and even on other project lists
(Grails, user groups, etc).
Cheers,
Les
Re: Having multiple build systems for jsecurity
Posted by Jeremy Haile <jh...@fastmail.fm>.
> > On Dec 31, 2008, at 6:38 AM, Jeremy Haile wrote:
> >
> > I'm glad that you are interested in investigating JSecurity, even if it's
> >> just edging over the line =)
> >>
> >
> > Don't expect people to want to climb on board the project with these kinds
> > of responses....
>
>
> I think you might have misinterpreted Jeremy's response - I'm fairly
> certain
> he said that tongue-in-cheek with a smile on his face (thus the
> emoticon).
Yes - definitely. I do sincerely appreciate David's interest in the
project and hearing his viewpoints! The "just edging over the line" was
meant to be tongue-in-cheek humor. I apologize if I inadvertently
caused any offense.
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
On Fri, Jan 2, 2009 at 12:55 PM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
>
> On Dec 31, 2008, at 6:38 AM, Jeremy Haile wrote:
>
> I'm glad that you are interested in investigating JSecurity, even if it's
>> just edging over the line =)
>>
>
> Don't expect people to want to climb on board the project with these kinds
> of responses....
I think you might have misinterpreted Jeremy's response - I'm fairly certain
he said that tongue-in-cheek with a smile on his face (thus the emoticon).
We have a long-standing and proud tradition of being extremely open to all
of our users' input in practically all cases. We're also very proactive in
helping people with solutions, offering advice, and answering general email
and forum postings on the project lists and even on other project lists
(Grails, user groups, etc).
Cheers,
Les
Re: Having multiple build systems for jsecurity
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 31, 2008, at 6:38 AM, Jeremy Haile wrote:
> On Dec 30, 2008, at 8:50 PM, David Jencks wrote:
>>>
>> I will go farther and say that my observation of projects here at
>> apache is that the ones using maven generally are a __LOT__ more
>> open to comments, contributions, integration proposals, and outside
>> interest than the ones using ant. My experience with the ones
>> using ant is generally that they tend to have an attitude that they
>> know better than anyone else how their project might be used or
>> might fit into other contexts.
>
> OK - I can sort of see your point, despite it being a *gross* over-
> generalization.
David is relating his personal experiences and observations. I don't
see where he takes those and makes a generalization across the board.
>> Partly as a result of these experiences and partly due to the
>> typically incomprehensible project organization of ant built
>> projects I have to be MUCH more interested in the subject area of
>> an ant built project before I will investigate it. For me
>> JSecurity is just barely edging over into "worth investigating
>> despite the project organization and build system".
>
> I'm glad that you are interested in investigating JSecurity, even if
> it's just edging over the line =)
Don't expect people to want to climb on board the project with these
kinds of responses....
Regards,
Alan
Re: Having multiple build systems for jsecurity
Posted by Jeremy Haile <jh...@fastmail.fm>.
On Dec 30, 2008, at 8:50 PM, David Jencks wrote:
>>
> I will go farther and say that my observation of projects here at
> apache is that the ones using maven generally are a __LOT__ more
> open to comments, contributions, integration proposals, and outside
> interest than the ones using ant. My experience with the ones using
> ant is generally that they tend to have an attitude that they know
> better than anyone else how their project might be used or might fit
> into other contexts.
OK - I can sort of see your point, despite it being a *gross* over-
generalization. I agree projects who think they know better than
anyone else is bad.
> Partly as a result of these experiences and partly due to the
> typically incomprehensible project organization of ant built
> projects I have to be MUCH more interested in the subject area of an
> ant built project before I will investigate it. For me JSecurity is
> just barely edging over into "worth investigating despite the
> project organization and build system".
I'm glad that you are interested in investigating JSecurity, even if
it's just edging over the line =)
> This situation is not all that surprising since maven makes the
> dependencies on other projects very explicit and clear and provides
> a uniform and standard way for other projects to deploy on your
> project. Ant tries to hide the fact that all non-trivial projects
> depend on other projects and that other projects might want to
> depend on yours by simply not dealing with it at all. I don't have
> any experience with ivy so don't have any idea how it might affect
> this.
I agree here, but only when you're talking about old-school ant
projects. Ant+Ivy projects, on the other hand, make dependencies very
clear since they define them explicitly in ivy.xml, which is a very
concise, easy-to-read file. I encourage you to check out JSecurity's
ivy.xml file, which should make it very clear what JSecurity's
dependencies are.
I also encourage you to check out some more info on Ant+Ivy vs Maven,
as there are tons of blog posts out there on the subject. Here are a
couple to get you started:
http://ant.apache.org/ivy/m2comparison.html (also check out the links
in the first paragraph, which lead to some other viewpoints/debates)
http://www.leshazlewood.com/?p=44
Jeremy
Re: Having multiple build systems for jsecurity
Posted by David Jencks <da...@yahoo.com>.
On Dec 30, 2008, at 5:16 PM, Alan D. Cabrera wrote:
>
> On Dec 27, 2008, at 10:51 PM, Niklas Gustavsson wrote:
>
>> On Sat, Dec 27, 2008 at 12:12 AM, Alan D. Cabrera <list@toolazydogs.com
>> > wrote:
>>> I'm wondering if it would be possible to have multiple build
>>> systems for the
>>> same body of code. Each build system proponent would take
>>> responsibility
>>> for maintaining their build system. It would kinda like be Berlin
>>> after
>>> WWII.
>>
>> Out of personal experience, I prefer Maven, simply because I find.it
>> proposes more consistent builds over multiple projects. And, there is
>> tons of experience at Apache when using Maven to fulfill all the
>> Apache requirements on releases (licenses, notices, license headers,
>> GPG).
>
> Yeah, this has been my experience as well. Maven projects are
> easier to grok. Ant projects are a free for all since every
> developer creates a build system to suite their personal tastes.
>
> I've mentioned it before but will repeat it again here so as to
> avoid the earlier unproductive thread. The touchpoint of ASF
> projects is the code not the release JARs and WARs. One of the
> priorities is to make things easy to grasp and transparent for new
> and potential community members not just keep the status quo of the
> original developer group.
I will go farther and say that my observation of projects here at
apache is that the ones using maven generally are a __LOT__ more open
to comments, contributions, integration proposals, and outside
interest than the ones using ant. My experience with the ones using
ant is generally that they tend to have an attitude that they know
better than anyone else how their project might be used or might fit
into other contexts.
Partly as a result of these experiences and partly due to the
typically incomprehensible project organization of ant built projects
I have to be MUCH more interested in the subject area of an ant built
project before I will investigate it. For me JSecurity is just barely
edging over into "worth investigating despite the project organization
and build system".
I'm exaggerating a bit but not nearly as much as I wish I was. It's
also entirely possible that my experience is caused entirely by the
particular ant-built projects I've dealt with.
This situation is not all that surprising since maven makes the
dependencies on other projects very explicit and clear and provides a
uniform and standard way for other projects to deploy on your
project. Ant tries to hide the fact that all non-trivial projects
depend on other projects and that other projects might want to depend
on yours by simply not dealing with it at all. I don't have any
experience with ivy so don't have any idea how it might affect this.
thanks
david jencks
>
>
>
> Regards,
> Alan
>
Re: Having multiple build systems for jsecurity
Posted by Jeremy Haile <jh...@fastmail.fm>.
On Dec 30, 2008, at 8:16 PM, Alan D. Cabrera wrote:
> I've mentioned it before but will repeat it again here so as to
> avoid the earlier unproductive thread. The touchpoint of ASF
> projects is the code not the release JARs and WARs. One of the
> priorities is to make things easy to grasp and transparent for new
> and potential community members not just keep the status quo of the
> original developer group.
I definitely believe that, but I think everyone is bringing their
biased opinion to the table. The simplified issue here is flexibility
vs consistency/convention. Ant+Ivy offers much more flexibility,
whereas Maven is very consistent and does things the "Maven-way".
Ant's flexibility can be abused, just as any flexible system can be -
but I think it can easily be argued that JSecurity isn't abusing it.
It's current build is pretty standard and simple.
I don't think it's fair to say that the Maven solution is the only
consistent approach though - even using Ant, we're following
approaches that have been the Java industry-standard for many, many
years. We have a docs, samples, src, support, and test directory.
Nothing difficult to grok there. We pull dependencies into a lib
directory...ok, pretty standard. We create a "build" directory that
contains pre-processed and compiled files that are being prepared for
artifacts.
Is this the Maven way? No, not exactly. Is it consistent? Uh, yeah
- I've seen a million Java projects setup this exact way for the past
8 years or so. It's a slightly "flatter" directory structure than the
standard Maven structure, and to some contributors that matters, to
others "who cares".
I think there are a lot of smart people on this list, and throughout
the Java community - some prefer Ant+Ivy, some prefer Maven, some
prefer more cutting edge build systems like buildr or gradle. I think
there are pros and cons to every approach, and it's valid for us to
discuss those, but ultimately this is going to boil down to how people
value flexibility in handling cases that Maven doesn't handle
automagically vs. how they value consistency with other projects that
do things the Maven way.
Jeremy
Re: Having multiple build systems for jsecurity
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 27, 2008, at 10:51 PM, Niklas Gustavsson wrote:
> On Sat, Dec 27, 2008 at 12:12 AM, Alan D. Cabrera <list@toolazydogs.com
> > wrote:
>> I'm wondering if it would be possible to have multiple build
>> systems for the
>> same body of code. Each build system proponent would take
>> responsibility
>> for maintaining their build system. It would kinda like be Berlin
>> after
>> WWII.
>
> Out of personal experience, I prefer Maven, simply because I find.it
> proposes more consistent builds over multiple projects. And, there is
> tons of experience at Apache when using Maven to fulfill all the
> Apache requirements on releases (licenses, notices, license headers,
> GPG).
Yeah, this has been my experience as well. Maven projects are easier
to grok. Ant projects are a free for all since every developer
creates a build system to suite their personal tastes.
I've mentioned it before but will repeat it again here so as to avoid
the earlier unproductive thread. The touchpoint of ASF projects is
the code not the release JARs and WARs. One of the priorities is to
make things easy to grasp and transparent for new and potential
community members not just keep the status quo of the original
developer group.
Regards,
Alan
Re: Having multiple build systems for jsecurity
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, Dec 27, 2008 at 12:12 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I'm wondering if it would be possible to have multiple build systems for the
> same body of code. Each build system proponent would take responsibility
> for maintaining their build system. It would kinda like be Berlin after
> WWII.
It would probably be a good idea to one of the build system being the
"official", which is used for releases. Otherwise, formal binariy
releases would look different from time to time, and users might be
confused when trying to replicate the releases
Out of personal experience, I prefer Maven, simply because I find.it
proposes more consistent builds over multiple projects. And, there is
tons of experience at Apache when using Maven to fulfill all the
Apache requirements on releases (licenses, notices, license headers,
GPG).
/niklas
Re: Having multiple build systems for jsecurity
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 30, 2008, at 3:25 PM, James William Dumay wrote:
> Hey Alan,
>
> On 27/12/08 10:12, Alan D. Cabrera wrote:
>> I'm wondering if it would be possible to have multiple build
>> systems for the same body of code. Each build system proponent
>> would take responsibility for maintaining their build system. It
>> would kinda like be Berlin after WWII.
>>
>> Thoughts?
> Speaking as a dude who does build systems for a living I'd have to
> say that you should tread carefully having two build systems.
>
> Depending on what your default build already does it may be somewhat
> challenging to ensure that all supported build systems have the
> _exact_ same output. Not to mention that contributor time could
> probably be spent working on code.
>
> Another thing to consider is the support overhead for new users to
> the project - what build system should they use? Is the one they
> chose up to date and functional?
>
> If your going down this path, its probably best just to release
> using the same build system every time to avoid inconsistencies and
> other headaches.
We currently use the Maven POM to push out releases to the
repository. I imagine that we would do the same with the new fully
supported POMs.
Regards,
Alan
Re: Having multiple build systems for jsecurity
Posted by James William Dumay <ja...@atlassian.com>.
Hey Alan,
On 27/12/08 10:12, Alan D. Cabrera wrote:
> I'm wondering if it would be possible to have multiple build systems
> for the same body of code. Each build system proponent would take
> responsibility for maintaining their build system. It would kinda
> like be Berlin after WWII.
>
> Thoughts?
Speaking as a dude who does build systems for a living I'd have to say
that you should tread carefully having two build systems.
Depending on what your default build already does it may be somewhat
challenging to ensure that all supported build systems have the _exact_
same output. Not to mention that contributor time could probably be
spent working on code.
Another thing to consider is the support overhead for new users to the
project - what build system should they use? Is the one they chose up to
date and functional?
If your going down this path, its probably best just to release using
the same build system every time to avoid inconsistencies and other
headaches.
Cheers,
James
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
I originally thought of the 'support' subdirectories as having a 1:1
correspondence with a 3rd party API. If that would be the case, then
wouldn't the following make sense?
core
web (I call it web to match the package - also 'web' seems more
general whereas war seems very artifact-specific)
support/spring
support/ehcache
support/quartz
support/crowd
support/openid4java
Then in the support source trees, you'd have
org.jsecurity.<thirdPartyName>.foo.bar...
For example in the support/crowd source tree, you'd see
org.jsecurity.crowd.realm.CrowdRealm (or something like that)
What do you think?
On Sat, Dec 27, 2008 at 1:40 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Let's start w/ our modules. Here's what I think where we're going:
>
> core
> war (better name/organization?)
> support/spring
> support/ecache
> support/quartz
> support/struts
> realms/crowd
> realms/openid
>
> How do you see the directories, i.e. code, resources, etc.?
>
>
> Regards,
> Alan
>
>
> On Dec 26, 2008, at 3:35 PM, Les Hazlewood wrote:
>
>> I'm certainly ok with that, as long as we get to design the directory
>> layouts, and a tool doesn't dictate it to us...
>>
>> On Fri, Dec 26, 2008 at 6:30 PM, Emmanuel Lecharny <el...@gmail.com>
>> wrote:
>>>
>>> Alan D. Cabrera wrote:
>>>>
>>>> I'm wondering if it would be possible to have multiple build systems for
>>>> the same body of code. Each build system proponent would take
>>>> responsibility for maintaining their build system. It would kinda like
>>>> be
>>>> Berlin after WWII.
>>>
>>> Sure ! I will rule the french area ... Who will be in charge of the
>>> russian
>>> one ? ;)
>>>
>>> Seriously, yes, we could, but it would be a lost of time, IMHO. When it
>>> works, don't fix it...
>>>
>>> --
>>> --
>>> cordialement, regards,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>> directory.apache.org
>>>
>>>
>>>
>
>
Re: Having multiple build systems for jsecurity
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sat, Dec 27, 2008 at 8:00 PM, Les Hazlewood <lh...@apache.org> wrote:
> so, for example, we would have
>
> trunk/
> |--build.xml
> |--pom.xml
> |--build.gradle
> |--core/
> | |--src/
> | |--test/
> |--web/
> | |--src/
> | |--test/
> |--support/
> | |--spring/
> | | |--src/
> | | |--test/
> | |--ehcache/
> | | |--src/
> | | |--test/
That should work fine with Maven, of course, you would have a pom.xml
for each module (core, web...). Also, it might be worth separating
Java code and resources (don't think Maven cares, but I do think this
is a reasonable thing with the Maven defaults).
/niklas
Re: Having multiple build systems for jsecurity
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 27, 2008, at 11:00 AM, Les Hazlewood wrote:
>> How do you see the directories, i.e. code, resources, etc.?
>
> After working with wicket source trees in my own project trees, I've
> become
> keen on keeping things co-located based on pacakge.
I like to co-locate based on functionality. Following that paradigm
the packages happen to cluster similarly.
> My personal preference
> is to have a src and a test directory directly under the module
> directory
> with code and resources co-located side-by-side for easy access/
> lookup. I
> noticed this greatly simplified my build scripts too.
Maven work with this setup. Thinking ahead, if any resources need to
be pre-processed, e.g. macro processing, things could get messy on
both Maven and Ant. If we placed the resources in a separate resource
directory per Maven convention we wouldn't need those messy bits.
Just something to think about.
> so, for example, we would have
>
> trunk/
> |--build.xml
> |--pom.xml
> |--build.gradle
> |--core/
> | |--src/
> | |--test/
> |--web/
> | |--src/
> | |--test/
> |--support/
> | |--spring/
> | | |--src/
> | | |--test/
> | |--ehcache/
> | | |--src/
> | | |--test/
>
> etc...
>
> Is this copacetic? If it is, and we were to have a maven build in
> addition
> to the regular build, could maven handle this directory structure?
Seems ok to me. Maven can handle it but I have to add some POM
"noise" to get it to work. I'm willing to compromise here so long as
no one points ad those bits and says "yuck".
Regards,
Alan
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
Given that Maven can conform to the directory layout I suggested (apparently
with pom modifications, no plugins), I would *like* to see us use that
directory if possible. If the team doesn't want that, then fine, I'll deal
with it. But I'd like to hold a vote on it after people have had the
ability to review it - it looks like a few folks are busy for the holidays
and aren't able to chime in...
Cheers,
Les
On Sat, Dec 27, 2008 at 3:38 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Les Hazlewood wrote:
>
>> Therein lies my #1 gripe about adopting Maven. The second you might want
>> to
>> do something that is not the Maven Way, you end up backed in a corner.
>>
> I see Maven as the "SAP for projects" : you'd better adapt to it,
> otherwise, it will cost you much more to adapt Maven to fit your desires.
> Where SAP is good is that it has been successfully adapted to ten of
> thousands of enterprises, so they can't be totally wrong. So is Maven. A
> last point is that if I have a problem with Maven, I have dozens of fellows
> around me to help me. Add that you don't change a build system every single
> day ...
>
> Enough for me to forget about my dislike for Maven.
>
>> I
>> can't, in good conscience, ever vote in favor of a build system that
>> doesn't
>> offer flexibility should it be needed or desired. I would rather see a
>> build system that builds by convention but allows overrides where you want
>> it.
>>
>>
> I vote for any build system which is stable, established in a couple of
> hours, used, and documented.
>
>> I personally don't care what the casual builder of our framework wants to
>> use or how they want things laid-out - they don't live in the source code
>> on
>> a regular basis.
>>
> We are talking about the project's developpers not the users. They are
> using the jars, not the build.
>
>> I care about what the development team prefers. If
>> others on the dev team vote for a directory structure that matches the
>> Maven
>> Way, then I will accept it. I however will not vote that way.
>>
>> But, I just did some googling:
>>
>>
>> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>
>> "Please try to conform to this structure as much as possible; however, if
>> you can't these settings can be overridden via the project descriptor."
>>
>> So, it appears that they are 'overridable'...
>>
>>
> Yeah, but this is not the Maven way ... Otherwise, you fell back in the
> 'Plugin writers' category, and trust me, this is not a funny place to be!
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Having multiple build systems for jsecurity
Posted by Emmanuel Lecharny <el...@gmail.com>.
Les Hazlewood wrote:
> Therein lies my #1 gripe about adopting Maven. The second you might want to
> do something that is not the Maven Way, you end up backed in a corner.
I see Maven as the "SAP for projects" : you'd better adapt to it,
otherwise, it will cost you much more to adapt Maven to fit your
desires. Where SAP is good is that it has been successfully adapted to
ten of thousands of enterprises, so they can't be totally wrong. So is
Maven. A last point is that if I have a problem with Maven, I have
dozens of fellows around me to help me. Add that you don't change a
build system every single day ...
Enough for me to forget about my dislike for Maven.
> I
> can't, in good conscience, ever vote in favor of a build system that doesn't
> offer flexibility should it be needed or desired. I would rather see a
> build system that builds by convention but allows overrides where you want
> it.
>
I vote for any build system which is stable, established in a couple of
hours, used, and documented.
> I personally don't care what the casual builder of our framework wants to
> use or how they want things laid-out - they don't live in the source code on
> a regular basis.
We are talking about the project's developpers not the users. They are
using the jars, not the build.
> I care about what the development team prefers. If
> others on the dev team vote for a directory structure that matches the Maven
> Way, then I will accept it. I however will not vote that way.
>
> But, I just did some googling:
>
> http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>
> "Please try to conform to this structure as much as possible; however, if
> you can't these settings can be overridden via the project descriptor."
>
> So, it appears that they are 'overridable'...
>
Yeah, but this is not the Maven way ... Otherwise, you fell back in the
'Plugin writers' category, and trust me, this is not a funny place to be!
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
Therein lies my #1 gripe about adopting Maven. The second you might want to
do something that is not the Maven Way, you end up backed in a corner. I
can't, in good conscience, ever vote in favor of a build system that doesn't
offer flexibility should it be needed or desired. I would rather see a
build system that builds by convention but allows overrides where you want
it.
I personally don't care what the casual builder of our framework wants to
use or how they want things laid-out - they don't live in the source code on
a regular basis. I care about what the development team prefers. If
others on the dev team vote for a directory structure that matches the Maven
Way, then I will accept it. I however will not vote that way.
But, I just did some googling:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
"Please try to conform to this structure as much as possible; however, if
you can't these settings can be overridden via the project descriptor."
So, it appears that they are 'overridable'...
On Sat, Dec 27, 2008 at 3:13 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Les Hazlewood wrote:
>
> Nope... It's not the 'maven' way :)
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Having multiple build systems for jsecurity
Posted by Emmanuel Lecharny <el...@gmail.com>.
Les Hazlewood wrote:
> That's the maven default, isn't it?
>
yes, like it or not :/ That's the price to pay to play with maven. IMHO,
it's not very expensive.
> I've mentioned that I really don't like that many directories in my source
> tree (I know, its my own hangup, but its just something I can't stand - call
> it a quirk, call it a fatal character flaw, whatever ;) ).
I really don't care about this layout, as it's totally transparent to me
once it has been created on day one. And if other build system are more
versatile, they can cope with such structure. In an IDE, it makes no
difference anyway.
> The maven
> default dir tree is a burden if you like to hover in the 'project files'
> view (not package view) of a project. Feels overly segmented and
> misdirecting...
>
I'm dealing with it for 4 years now, and I don't see it as a burden. May
be I'm used to it, just because I consider that it's not really a big
deal. I tend to focus more on code, tests and doco... It's a bit like
code convention -tabs/spaces or { position - : at some point, you just
let it be, because it just lead to religion wars. Adopting what fits the
largest community is generally a good politic.
Plus you don't hover the project files very often.
> I was hoping that Maven could be told to alter its defaults. Is this not
> possible?
>
Nope... It's not the 'maven' way :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
That's the maven default, isn't it?
I've mentioned that I really don't like that many directories in my source
tree (I know, its my own hangup, but its just something I can't stand - call
it a quirk, call it a fatal character flaw, whatever ;) ). The maven
default dir tree is a burden if you like to hover in the 'project files'
view (not package view) of a project. Feels overly segmented and
misdirecting...
I was hoping that Maven could be told to alter its defaults. Is this not
possible?
On Sat, Dec 27, 2008 at 2:20 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Les Hazlewood wrote:
>
>> How do you see the directories, i.e. code, resources, etc.?
>>>
>>>
>>
>> After working with wicket source trees in my own project trees, I've
>> become
>> keen on keeping things co-located based on pacakge. My personal
>> preference
>> is to have a src and a test directory directly under the module directory
>> with code and resources co-located side-by-side for easy access/lookup. I
>> noticed this greatly simplified my build scripts too.
>>
>> so, for example, we would have
>>
>> trunk/
>> |--build.xml
>> |--pom.xml
>> |--build.gradle
>> |--core/
>> | |--src/
>> | |--test/
>> |--web/
>> | |--src/
>> | |--test/
>> |--support/
>> | |--spring/
>> | | |--src/
>> | | |--test/
>> | |--ehcache/
>> | | |--src/
>> | | |--test/
>>
>> etc...
>>
>> Is this copacetic? If it is, and we were to have a maven build in
>> addition
>> to the regular build, could maven handle this directory structure?
>>
>>
> Nope. But close...
>
> you must have something like :
>
> core/
> |--src
> |--main
> | |--java
> | |--resources
> |--test
> |--java
> |--resources
>
> This should not be a real burden though.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Having multiple build systems for jsecurity
Posted by Emmanuel Lecharny <el...@gmail.com>.
Les Hazlewood wrote:
>> How do you see the directories, i.e. code, resources, etc.?
>>
>
> After working with wicket source trees in my own project trees, I've become
> keen on keeping things co-located based on pacakge. My personal preference
> is to have a src and a test directory directly under the module directory
> with code and resources co-located side-by-side for easy access/lookup. I
> noticed this greatly simplified my build scripts too.
>
> so, for example, we would have
>
> trunk/
> |--build.xml
> |--pom.xml
> |--build.gradle
> |--core/
> | |--src/
> | |--test/
> |--web/
> | |--src/
> | |--test/
> |--support/
> | |--spring/
> | | |--src/
> | | |--test/
> | |--ehcache/
> | | |--src/
> | | |--test/
>
> etc...
>
> Is this copacetic? If it is, and we were to have a maven build in addition
> to the regular build, could maven handle this directory structure?
>
Nope. But close...
you must have something like :
core/
|--src
|--main
| |--java
| |--resources
|--test
|--java
|--resources
This should not be a real burden though.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Having multiple build systems for jsecurity
Posted by Jeremy Haile <jh...@fastmail.fm>.
On Dec 27, 2008, at 2:00 PM, Les Hazlewood wrote:
>>
> trunk/
> |--build.xml
> |--pom.xml
> |--build.gradle
> |--core/
> | |--src/
> | |--test/
> |--web/
> | |--src/
> | |--test/
> |--support/
> | |--spring/
> | | |--src/
> | | |--test/
> | |--ehcache/
> | | |--src/
> | | |--test/
+1 for this directory structure. As far as the build tool - since we
aren't currently having any problems and it works with this structure
I say we stick with Ant+Ivy.
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
> How do you see the directories, i.e. code, resources, etc.?
After working with wicket source trees in my own project trees, I've become
keen on keeping things co-located based on pacakge. My personal preference
is to have a src and a test directory directly under the module directory
with code and resources co-located side-by-side for easy access/lookup. I
noticed this greatly simplified my build scripts too.
so, for example, we would have
trunk/
|--build.xml
|--pom.xml
|--build.gradle
|--core/
| |--src/
| |--test/
|--web/
| |--src/
| |--test/
|--support/
| |--spring/
| | |--src/
| | |--test/
| |--ehcache/
| | |--src/
| | |--test/
etc...
Is this copacetic? If it is, and we were to have a maven build in addition
to the regular build, could maven handle this directory structure?
Cheers,
Les
Re: Having multiple build systems for jsecurity
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Let's start w/ our modules. Here's what I think where we're going:
core
war (better name/organization?)
support/spring
support/ecache
support/quartz
support/struts
realms/crowd
realms/openid
How do you see the directories, i.e. code, resources, etc.?
Regards,
Alan
On Dec 26, 2008, at 3:35 PM, Les Hazlewood wrote:
> I'm certainly ok with that, as long as we get to design the directory
> layouts, and a tool doesn't dictate it to us...
>
> On Fri, Dec 26, 2008 at 6:30 PM, Emmanuel Lecharny <elecharny@gmail.com
> > wrote:
>> Alan D. Cabrera wrote:
>>>
>>> I'm wondering if it would be possible to have multiple build
>>> systems for
>>> the same body of code. Each build system proponent would take
>>> responsibility for maintaining their build system. It would kinda
>>> like be
>>> Berlin after WWII.
>>
>> Sure ! I will rule the french area ... Who will be in charge of the
>> russian
>> one ? ;)
>>
>> Seriously, yes, we could, but it would be a lost of time, IMHO.
>> When it
>> works, don't fix it...
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
Re: Having multiple build systems for jsecurity
Posted by Les Hazlewood <lh...@apache.org>.
I'm certainly ok with that, as long as we get to design the directory
layouts, and a tool doesn't dictate it to us...
On Fri, Dec 26, 2008 at 6:30 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Alan D. Cabrera wrote:
>>
>> I'm wondering if it would be possible to have multiple build systems for
>> the same body of code. Each build system proponent would take
>> responsibility for maintaining their build system. It would kinda like be
>> Berlin after WWII.
>
> Sure ! I will rule the french area ... Who will be in charge of the russian
> one ? ;)
>
> Seriously, yes, we could, but it would be a lost of time, IMHO. When it
> works, don't fix it...
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Having multiple build systems for jsecurity
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alan D. Cabrera wrote:
> I'm wondering if it would be possible to have multiple build systems
> for the same body of code. Each build system proponent would take
> responsibility for maintaining their build system. It would kinda
> like be Berlin after WWII.
Sure ! I will rule the french area ... Who will be in charge of the
russian one ? ;)
Seriously, yes, we could, but it would be a lost of time, IMHO. When it
works, don't fix it...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org