directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [VOTE] Policy for Managing TLP POM
Date Wed, 23 May 2007 10:08:59 GMT
I forgot to add two points :
- we need to bring back to the root data like resources/format.xml, so
that committers can use it
when writing code ( I hated having to browse dozens of directories to
find it last night ...)
- we also have to figure what could happen to next release (2.0, 3.0)
regarding this common POM

What about creating a new project which allow users to compile the
whole project (apacheds + kerberos + daemon + shared) ? Note that
kerberos is *not* a project right now, as it is embedded into ads, but
it might be a good idea to separate it from ADS (not sure this is
possible though ...)

Thanks !

Emmanuel

On 5/23/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> I will abstain right now, (make it -0), not that I find your proposal
> insane, but I have some suggestion and concerns that should be
> addressed :
>
> - let's document the actual hierarchy of the project in confluence. We
> have done that once upon a time, it's now time to do it again, would
> it be for Chris only ...
> - we should document the content of this pom on confluence,
> - keep this pom as simplest as possible
> - remove the branch and trunk section of
> http://svn.apache.org/viewvc/directory/tlp-common, just keeping the
> release (this is a proposal, I'm not 100% sure this is the perfect
> idea)
> - I don't really understand the "3. Do not copy the TLP POM in SVN".
> If it means we will just push the TLP pom to maven repo, then it can
> become a pb. I would rather prefer respect my previous point
> - applying this policy to the project means we will need some script
> to build ADS as a whole. It will be a versy simple script, building
> shared, daemon, kerberos and then apacheds. Otherwise, it will be
> painfull for users ...
> - I also have a little concern about Eclipse generated files. If we
> don't have the possibility to generate them with a common pom, then
> fdebugging will start to become a big issue, if we have to grab the
> sources from jars instead of projects : you will be asked for those
> sources when entering in shared for instance. This is not something I
> would like to do, as I'm quite involved in shared ...
>
> Ok, this points may not be valid, but at least we should discard them
> before going farther !
>
> Thanks Alex for having created this page, and for having endorsed the
> task. It's obviously someting we should have done before, but there is
> no better time to do it than as fast as possible ...
>
> btw, this page exists because yesturday we tried to cut the 1.0.2
> release, and it went into a quagmare, as I lacked some background to
> understand the way release are to be generated. See this effort as a
> clarification usefull for any committers who will be in charge of
> cutting a release in the near future :)
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message