Can't stand to stay silent :)

Traversing the source tree in IDE....
IMO, just like the "ant build" is supported in your IDE, and it sets
your build class path accordingly, the same is possible for Maven
(with at least three different plugins or tools). Hence, the physical
layout of the sources on the disk will simply become a "wood" of
source class-paths :)

I believe the number of source class paths will be always equal in
both cases, and will depend on how many actual modules you have on
disk -- and it is completely unrelated to the tool you are using to
build them (unless you have one "monolithic" source base, and
"subtract" constituents from it to produce different modules with
different contents. But in that case, how would you run Junit tests
from your IDE for example and be sure that it tests the given module,
and not the whole?).

Actually, as JSecurity is right now (one final artifact), the result
of having Ant or Maven build -- as seen thru IDE -- would present
exactly the same picture to you :)

My 2 cents.


Warning: I am biased!

Thanks,
~t~


On Sun, Nov 30, 2008 at 8:47 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
> On Nov 29, 2008, at 11:58 AM, Les Hazlewood wrote:
>
>> Hi Alan,
>>
>> Yep, there's no doubt that we could have a jsecurity-web.jar.  It'd be
>> very easy to do.  Since JSecurity was designed from the ground up to
>> work in any environment, web or not, it would be pretty easy to
>> extract the web stuff into its own jar.
>
> So it comes down to personal preference where you prefer to have the web
> code mixed in with the same place and have the build system extract the bits
> that are needed depending on the Ivy configuration.
>
>> Aside from Ivy configs being better than maven in expressing
>> transitive dependencies, the other main reason for staying with
>> Ivy+Ant was due to 'customizability'.  Modifying Maven to do what you
>> want, e.g. via special plugins, is nasty, especially when Maven
>> upgrades cause your plugins to fail.  Allan can speak more about this,
>> as it has particularly plagued him at work.
>
> Apples and oranges.  IIRC, Allan was struggling with an old pre-existing
> build system.
>
>> I personally can't stand the suggested maven directory structure.  If
>> you have more than one or two modules, the traversing of directory
>> trees in your IDE becomes quickly unbearable.  I just don't like it.
>> The current structure we have in place with Ivy however is a lot more
>> flexible and we can change it any way we like.
>
> Not sure that there is a need for that flexibility in our case.
>
>> At least that's my .02.  And just for clarity's sake, and to quell
>> Joshua's concerns, we don't use the Ivy-generated pom.xml.  We
>> manually edit it to ensure its correctness.
>
> If we're just using it to publish artifacts to the Maven repo then I suggest
> that we remove much of the POM's content that is not relevant to that task.
>
>
> Regards,
> Alan
>
>>
>>
>> Cheers,
>>
>> Les
>>
>> On Sat, Nov 29, 2008 at 3:28 AM, Alan D. Cabrera <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Yep, I read that.  All I could see was an explanation on Ivy
>>> Configurations.
>>> I'm always interested in what can be accomplished cleanly, if at all, in
>>> Ant/Ivy but not the Maven or visa versa.
>>>
>>> In this project's case, I think that things can be handled by splitting
>>> the
>>> web code out into its own jar.
>>>
>>> Of course, I could have missed something.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Nov 28, 2008, at 9:39 PM, Joshua Partogi wrote:
>>>
>>>> Alan,
>>>>
>>>> Les already written it down on http://www.leshazlewood.com/?p=44
>>>>
>>>> I must agree that the pom.xml that Ivy generated does not comply :-(
>>>>
>>>> best regards,
>>>>
>>>> On Sat, Nov 29, 2008 at 4:19 PM, Alan D. Cabrera <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>> s/compelling/interesting to me personally/
>>>>>
>>>>> I don't want to start a flame war...   ;)
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Nov 28, 2008, at 9:16 PM, Alan D. Cabrera wrote:
>>>>>
>>>>>> Near as I can tell this project went w/ Ant/Ivy because of Ivy's
>>>>>> configurations; I'm aware of other reasons but I do not find those
>>>>>> compelling.
>>>>>>
>>>>>> I'm curious about what problems exactly Ivy configurations solved that
>>>>>> Maven did not.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Not by might nor by power, but by His Spirit.
>>>>
>>>> Read my blog: http://joshuajava.wordpress.com/
>>>> Follow me on twitter: http://twitter.com/jpartogi
>>>>
>>>
>>>
>>
>
>



-- 
Thanks,
~t~

Reply via email to