I think with this mess it is critical to take issues one step at a time instead
of mixing everything together. I started with the root pom because this is the
first step in a top down approach which IMO is the best way to procede because
it effects the levels below it.
The scope of this is so large that we cannot afford to jumble up all the problems
together. Let's start at the top and work ourselves down. Perhaps several passes
are required to figure out the ultimate configuration for both SVN and Maven but
it must be done in peices. Either this or I can take the lead and just clean it all
then document it. However I'm trying to involve others to make this a collaborative
process. However to make the collaborative process work we need some focus on
each issue first in isolation then within the big picture. Otherwise this is not going to
succeed or result in an even more convoluted mess.
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 ...)
On 5/23/07, Emmanuel Lecharny < email@example.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
> - 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 :)
> Emmanuel Lécharny