directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Consolidate snickers projects into runtime and compiler
Date Mon, 21 Feb 2005 04:45:18 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the existing structure is closer to what is intended. It's not
perfect, but it's ok. Some problems with it:
- - src/images is should be in /xdocs/images, removing the need for src
altogether
- - maven.xml isn't adding anything and could be removed. It's just
aliasing some common tasks.

The main problems with the refactoring:
- - the addition of a /modules/ directory is unnecessary. We generally
encourage most subdirectories being modules in an aggregated project
- - the parent etc directory is fine - separation of master build (at
the root) and inherited values (in etc). However, in this case the root
inherits also inherits etc, so there's no real point to separating them.
- - maven.xml is very lengthy and mostly unnecessary.

Any use of maven.xml is really considered a "last resort". Part of the
intention of Maven is to make goals standard: whenever you pick up a
different project you shouldn't have to learn how to build it, you
should just know. You really don't want to have to write jelly code if
you don't have to :) Keep it simple, keep it standard. It's less work to
set up, and less learning for the end user.

Multiple projects in Maven 1.x was really added very late and not really
tightly integrated - something that has been discussed a lot and central
to the design of Maven2.

ApacheDS and Naming both follow a standard that I'd recommend. I've done
bits and pieces as I've looked at the others, but was wary of changing
too much when I'm not wholly familiar with the output in case I break
something, or take away soeone's favourite shortcut goals :)

Cheers,
Brett

Alan D. Cabrera wrote:

>
>
> Alex Karasulu wrote:
>
>> Alan D. Cabrera wrote:
>>
>>> I have merged all the ASN1 code into a unified multi-project maven
setup in asn1/branches/ber-decoder. I propose that we use this setup
instead of the project heirarchy that we have in trunk. All the code is
neatly in the modules directory. The maven site target now works
correctly. Finally, this setup paves the way for the ASN1 refactoring
that has been discussed on and off as of late.
>>>
>>> Thoughts?
>>
>>
>>
>> Sorry for taking too long to respond - I had to ask a few questions
and get answers regarding your approach with the new proposed maven layout.
>>
>> I asked Jason Van Zyl and he does not consider this layout a standard
and *HIGHLY* recommends against using this approach. If Jason and Brett
do not recommend this then I don't want to go there. However the layout
thing has nothing to do with code consolidation or making the changes to
the architecture that you propose. Having subordinate runtime and a
compiler subprojects can still be the case using the current
multiproject setup we have. There is no need for layout changes.
>>
>> If Brett supports it then I may consider it but after weeks of setting
up our build as it stands today I do not think he'll buy this new
configuration. He would have set us up this way day one.
>
>
>
> I'm confused, I do not see any work being done on the organization of
ASN1 sub-project. If there is a ADS standardization effort underway,
then I'm happy to follow that.
>
>
> Regards,
> Alan
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCGWdeOb5RoQhMkRMRAqSkAKCSoOYOibf7Mtg/XDEiYgD4NQ4VQACfS47F
ThO7k2clVMFPanICmgFri7w=
=gkNQ
-----END PGP SIGNATURE-----


Mime
View raw message