You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/05/23 03:00:13 UTC
[VOTE] Policy for Managing TLP POM
Hi all,
I compiled some documentation talking about how we should handle a parent
POM for our TLP
so all subprojects can inherit from it. We have been using it incorrectly
and have been loosing
track of it. I explain all this and expose some simple policy (6 rules) that
will help us keep this
all straight [1].
Please read this and let's vote on it make it official.
[ ] +1 Apply this policy/process for TLP POM management
[ ] +/-0 Abstain - don't understand or don't care
[ ] -1 Do *NOT* apply this policy for TLP POM management
-- Alex
-------
[1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
[VOTE] [RESULTS] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
Let me add the [RESULTS] tag for searching in the mail archive.
Alex
On 5/28/07, Alex Karasulu <ak...@apache.org> wrote:
>
> This vote is closed. Results:
>
> +1 Votes
> -------------------------
> Ersin Er
> Emmanuel Lecharny
> Alex Karasulu
> Chris Custine (non-binding)
>
> +/-0 Votes
> --------------------------
> Stefan Zoerner
> Stefan Seelmann
> Ole Ersoy (non-binding)
>
> No -1 votes.
>
> The policy is to be instated now since we have the required 3 binding
> votes.
>
> Thanks,
> Alex
>
>
>
> I compiled some documentation talking about how we should handle a parent
> > > POM for our TLP
> > > so all subprojects can inherit from it. We have been using it
> > > incorrectly and have been loosing
> > > track of it. I explain all this and expose some simple policy (6
> > > rules) that will help us keep this
> > > all straight [1].
> > >
> > > Please read this and let's vote on it make it official.
> > >
> > > [ ] +1 Apply this policy/process for TLP POM management
> > > [ ] +/-0 Abstain - don't understand or don't care
> > > [ ] -1 Do *NOT* apply this policy for TLP POM management
> > >
> > > -- Alex
> > >
> > > -------
> > > [1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
> > >
> > >
> > >
> > >
> >
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
This vote is closed. Results:
+1 Votes
-------------------------
Ersin Er
Emmanuel Lecharny
Alex Karasulu
Chris Custine (non-binding)
+/-0 Votes
--------------------------
Stefan Zoerner
Stefan Seelmann
Ole Ersoy (non-binding)
No -1 votes.
The policy is to be instated now since we have the required 3 binding votes.
Thanks,
Alex
I compiled some documentation talking about how we should handle a parent
> > POM for our TLP
> > so all subprojects can inherit from it. We have been using it
> > incorrectly and have been loosing
> > track of it. I explain all this and expose some simple policy (6 rules)
> > that will help us keep this
> > all straight [1].
> >
> > Please read this and let's vote on it make it official.
> >
> > [ ] +1 Apply this policy/process for TLP POM management
> > [ ] +/-0 Abstain - don't understand or don't care
> > [ ] -1 Do *NOT* apply this policy for TLP POM management
> >
> > -- Alex
> >
> > -------
> > [1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
> >
> >
> >
> >
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
+1
Alex
On 5/22/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Hi all,
>
> I compiled some documentation talking about how we should handle a parent
> POM for our TLP
> so all subprojects can inherit from it. We have been using it incorrectly
> and have been loosing
> track of it. I explain all this and expose some simple policy (6 rules)
> that will help us keep this
> all straight [1].
>
> Please read this and let's vote on it make it official.
>
> [ ] +1 Apply this policy/process for TLP POM management
> [ ] +/-0 Abstain - don't understand or don't care
> [ ] -1 Do *NOT* apply this policy for TLP POM management
>
> -- Alex
>
> -------
> [1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
>
>
>
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
> [X] +1 Apply this policy/process for TLP POM management
Alex
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
After my clarifications on IRC about this stuff do you want to reconsider
your vote?
On 5/23/07, Emmanuel Lecharny <el...@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
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Ole Ersoy <ol...@gmail.com>.
Just echoing your thoughts basically,
while "gently" pointing to some examples
in my Sanbox...trying to be helpful with
respect to the analysis and solution creation
process.
Here goes:
The "cookbook" mojo
is meant to facilitate breaking
up a challenge into a gazillion little pieces
like like this and then sequencing
them until there's clarity wrt the simplest
solution / process.
For instance with the DAS Design Guide I've probably read through
the recipes in sequence at least 30 times by now,
adding little details as I'm going along, and deleting
others as I realize they are not necessary.
This helps me focus on little tasks,
while occasionally looking at the Table of Contents
of the Eclipse Guide to get a "Horizontal" birds eye
of the process, with the end goal of making the process
as simple as possible.
Cheers,
- Ole
Alex Karasulu wrote:
SNIP
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
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.
Alex
On 5/23/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> 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 <el...@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
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <el...@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
Re: [VOTE] Policy for Managing TLP POM
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: [VOTE] Policy for Managing TLP POM
Posted by Ersin Er <er...@gmail.com>.
[X] +1 Apply this policy/process for TLP POM management
On 5/23/07, Alex Karasulu <ak...@apache.org> wrote:
> Hi all,
>
> I compiled some documentation talking about how we should handle a parent
> POM for our TLP
> so all subprojects can inherit from it. We have been using it incorrectly
> and have been loosing
> track of it. I explain all this and expose some simple policy (6 rules) that
> will help us keep this
> all straight [1].
>
> Please read this and let's vote on it make it official.
>
> [ ] +1 Apply this policy/process for TLP POM management
> [ ] +/-0 Abstain - don't understand or don't care
> [ ] -1 Do *NOT* apply this policy for TLP POM management
>
> -- Alex
>
> -------
> [1] -
> http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
>
>
>
--
Ersin
Re: [VOTE] Policy for Managing TLP POM
Posted by Stefan Seelmann <se...@apache.org>.
> [X] +/-0 Abstain - don't understand or don't care
Regards,
Stefan Seelmann
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
Hi Chris,
On 5/23/07, Chris Custine <ch...@gmail.com> wrote:
>
> I fall into the "dazed and confused" camp at the moment so I need to do
> some more reading to fully understand. One part in particular that I don't
> understand is this line:
>
> "This causes it's misuse to facilitate building ApacheDS and all it's
> dependencies in one big build. This must stop because this usage makes it
> inconvenient to use for building other projects like Triplesec and LDAP
> Studio once it moves to Maven."
>
>
The point I was trying to make here (unclearly tho) was that the TLP pom is
being used more so for a parent of the ApacheDS project and to build it.
This is resulting in problems like the copies of this file being in
different places and we're adding things into this TLP pom for ApacheDS
build specifics of which the modules section is one part.
I actually LIKE it this way :-) I don't think this actually causes any
> harm anyway, because if you build a project that references this pom as a
> parent, the modules section is ignored IIRC. Are you talking about some
> other issue with the parent pom?
Well yes if your subproject defines it's own modules section this is not a
problem because it is overridden. However this pom is being used to build
ApacheDS with its dependent projects and in addition to having an ApacheDS
modules section there are other elements that are geared more towards the
ADS build. I want to stop doing this and keep the TLP pom subproject
agnostic. To do so we just need to stop using it for doing ADS builds with
all it's deps while using this POM. We can use another pom with the proper
modules section to trigger the build with the deps in those SVN folder with
the externals directives that pull in all the needed deps for ADS. Here
take a look at this example here:
http://svn.apache.org/viewvc/directory/apacheds/branches/1.0-with-dependencies/pom.xml?revision=540806&view=markup
This pom is located here:
http://svn.apache.org/viewvc/directory/apacheds/branches/1.0-with-dependencies/
It is not the TLP POM nor the parent pom referenced by the subprojects
pulled in via the externals defined in this folder. It is just there to
trigger the build of ADS with it's dependencies by having the proper modules
section in it. This way we do not mess with the TLP POM and cause it to
change nor do we have ADS specific build directives in it. Is this a little
more clear? Sorry about being ambiguous before.
Alex
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
NP Chris thanks for expending the brain cycles to look over this mess.
Alex
On 5/23/07, Chris Custine <ch...@gmail.com> wrote:
>
> You know what? Disregard my last email. I wasn't thinking about this
> properly. I understand what you are saying now (don't ask me why I didn't
> get it 5 minutes ago). In fact, I agree with you 100%.
>
> Two things...
> 1). Not sure I understand what rule #3 is about.
> 2). In this scenario, the maven guys also recommend just using an
> incremented counter for the parent pom version, like 1,2,3,4,5 instead of
> 1.0, 1.2, 2.0, etc. I guess this is basically because there is no
> artifact produced so the versioning should be as simple as possible. Just
> passing that along...
>
> And now that I have my head on straight... my first vote. ;-)
>
> [x] +1 Apply this policy/process for TLP POM management
>
>
> On 5/23/07, Chris Custine <chris.custine@gmail.com > wrote:
> >
> > I fall into the "dazed and confused" camp at the moment so I need to do
> > some more reading to fully understand. One part in particular that I don't
> > understand is this line:
> >
> > "This causes it's misuse to facilitate building ApacheDS and all it's
> > dependencies in one big build. This must stop because this usage makes it
> > inconvenient to use for building other projects like Triplesec and LDAP
> > Studio once it moves to Maven."
> >
> > I actually LIKE it this way :-) I don't think this actually causes any
> > harm anyway, because if you build a project that references this pom as a
> > parent, the modules section is ignored IIRC. Are you talking about some
> > other issue with the parent pom?
> >
> > These maven setups are definitely a complex issue so I find myself
> > wanting to take a cautious approach...
> >
> > Chris
> >
> > On 5/22/07, Alex Karasulu <ak...@apache.org> wrote:
> > >
> > > Hi all,
> > >
> > > I compiled some documentation talking about how we should handle a
> > > parent POM for our TLP
> > > so all subprojects can inherit from it. We have been using it
> > > incorrectly and have been loosing
> > > track of it. I explain all this and expose some simple policy (6
> > > rules) that will help us keep this
> > > all straight [1].
> > >
> > > Please read this and let's vote on it make it official.
> > >
> > > [ ] +1 Apply this policy/process for TLP POM management
> > > [ ] +/-0 Abstain - don't understand or don't care
> > > [ ] -1 Do *NOT* apply this policy for TLP POM management
> > >
> > > -- Alex
> > >
> > > -------
> > > [1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
> > >
> > >
> > >
> > >
> >
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Chris Custine <ch...@gmail.com>.
You know what? Disregard my last email. I wasn't thinking about this
properly. I understand what you are saying now (don't ask me why I didn't
get it 5 minutes ago). In fact, I agree with you 100%.
Two things...
1). Not sure I understand what rule #3 is about.
2). In this scenario, the maven guys also recommend just using an
incremented counter for the parent pom version, like 1,2,3,4,5 instead of
1.0, 1.2, 2.0, etc. I guess this is basically because there is no artifact
produced so the versioning should be as simple as possible. Just passing
that along...
And now that I have my head on straight... my first vote. ;-)
[x] +1 Apply this policy/process for TLP POM management
On 5/23/07, Chris Custine <ch...@gmail.com> wrote:
>
> I fall into the "dazed and confused" camp at the moment so I need to do
> some more reading to fully understand. One part in particular that I don't
> understand is this line:
>
> "This causes it's misuse to facilitate building ApacheDS and all it's
> dependencies in one big build. This must stop because this usage makes it
> inconvenient to use for building other projects like Triplesec and LDAP
> Studio once it moves to Maven."
>
> I actually LIKE it this way :-) I don't think this actually causes any
> harm anyway, because if you build a project that references this pom as a
> parent, the modules section is ignored IIRC. Are you talking about some
> other issue with the parent pom?
>
> These maven setups are definitely a complex issue so I find myself wanting
> to take a cautious approach...
>
> Chris
>
> On 5/22/07, Alex Karasulu <ak...@apache.org> wrote:
> >
> > Hi all,
> >
> > I compiled some documentation talking about how we should handle a
> > parent POM for our TLP
> > so all subprojects can inherit from it. We have been using it
> > incorrectly and have been loosing
> > track of it. I explain all this and expose some simple policy (6 rules)
> > that will help us keep this
> > all straight [1].
> >
> > Please read this and let's vote on it make it official.
> >
> > [ ] +1 Apply this policy/process for TLP POM management
> > [ ] +/-0 Abstain - don't understand or don't care
> > [ ] -1 Do *NOT* apply this policy for TLP POM management
> >
> > -- Alex
> >
> > -------
> > [1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
> >
> >
> >
> >
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Alex Karasulu <ak...@apache.org>.
Yes you got it :).
Alex
On 5/23/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi Chris,
>
> I was puzzled too, but I put it first on my unablility to understand
> complex engish sentences, because I'm not a native english...
>
> Ok, here is some explaination :
> - the TLP pom.xml was just intended to gather very common infos like
> remote maven repos, nothing more
> - it was used (misused would be a better term) to build ADS as a
> whole, and this was *not* a good idea.
>
> So this TLP pom.xml is still usefull, but must be pointed only by
> subprojects, and not been used to build the server.
>
> To build the server, there is another pom.xml which can be found in
> apacheds-XXX-with-dependencies (where XXX is the version).
>
> Hope it helps.
>
> Alex, did I understood what you told me ?
>
> Emmanuel
>
>
> On 5/23/07, Chris Custine <ch...@gmail.com> wrote:
> > I fall into the "dazed and confused" camp at the moment so I need to do
> some
> > more reading to fully understand. One part in particular that I don't
> > understand is this line:
> > "This causes it's misuse to facilitate building ApacheDS and all it's
> > dependencies in one big build. This must stop because this usage makes
> it
> > inconvenient to use for building other projects like Triplesec and LDAP
> > Studio once it moves to Maven."
> > I actually LIKE it this way :-) I don't think this actually causes any
> > harm anyway, because if you build a project that references this pom as
> a
> > parent, the modules section is ignored IIRC. Are you talking about some
> > other issue with the parent pom?
> >
> > These maven setups are definitely a complex issue so I find myself
> wanting
> > to take a cautious approach...
> >
> > Chris
> >
> >
> > On 5/22/07, Alex Karasulu <ak...@apache.org> wrote:
> > > Hi all,
> > >
> > > I compiled some documentation talking about how we should handle a
> parent
> > POM for our TLP
> > > so all subprojects can inherit from it. We have been using it
> incorrectly
> > and have been loosing
> > > track of it. I explain all this and expose some simple policy (6
> rules)
> > that will help us keep this
> > > all straight [1].
> > >
> > > Please read this and let's vote on it make it official.
> > >
> > > [ ] +1 Apply this policy/process for TLP POM management
> > > [ ] +/-0 Abstain - don't understand or don't care
> > > [ ] -1 Do *NOT* apply this policy for TLP POM management
> > >
> > > -- Alex
> > >
> > > -------
> > > [1] -
> > http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
> > >
> > >
> > >
> >
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Chris,
I was puzzled too, but I put it first on my unablility to understand
complex engish sentences, because I'm not a native english...
Ok, here is some explaination :
- the TLP pom.xml was just intended to gather very common infos like
remote maven repos, nothing more
- it was used (misused would be a better term) to build ADS as a
whole, and this was *not* a good idea.
So this TLP pom.xml is still usefull, but must be pointed only by
subprojects, and not been used to build the server.
To build the server, there is another pom.xml which can be found in
apacheds-XXX-with-dependencies (where XXX is the version).
Hope it helps.
Alex, did I understood what you told me ?
Emmanuel
On 5/23/07, Chris Custine <ch...@gmail.com> wrote:
> I fall into the "dazed and confused" camp at the moment so I need to do some
> more reading to fully understand. One part in particular that I don't
> understand is this line:
> "This causes it's misuse to facilitate building ApacheDS and all it's
> dependencies in one big build. This must stop because this usage makes it
> inconvenient to use for building other projects like Triplesec and LDAP
> Studio once it moves to Maven."
> I actually LIKE it this way :-) I don't think this actually causes any
> harm anyway, because if you build a project that references this pom as a
> parent, the modules section is ignored IIRC. Are you talking about some
> other issue with the parent pom?
>
> These maven setups are definitely a complex issue so I find myself wanting
> to take a cautious approach...
>
> Chris
>
>
> On 5/22/07, Alex Karasulu <ak...@apache.org> wrote:
> > Hi all,
> >
> > I compiled some documentation talking about how we should handle a parent
> POM for our TLP
> > so all subprojects can inherit from it. We have been using it incorrectly
> and have been loosing
> > track of it. I explain all this and expose some simple policy (6 rules)
> that will help us keep this
> > all straight [1].
> >
> > Please read this and let's vote on it make it official.
> >
> > [ ] +1 Apply this policy/process for TLP POM management
> > [ ] +/-0 Abstain - don't understand or don't care
> > [ ] -1 Do *NOT* apply this policy for TLP POM management
> >
> > -- Alex
> >
> > -------
> > [1] -
> http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
> >
> >
> >
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] Policy for Managing TLP POM
Posted by Chris Custine <ch...@gmail.com>.
I fall into the "dazed and confused" camp at the moment so I need to do some
more reading to fully understand. One part in particular that I don't
understand is this line:
"This causes it's misuse to facilitate building ApacheDS and all it's
dependencies in one big build. This must stop because this usage makes it
inconvenient to use for building other projects like Triplesec and LDAP
Studio once it moves to Maven."
I actually LIKE it this way :-) I don't think this actually causes any
harm anyway, because if you build a project that references this pom as a
parent, the modules section is ignored IIRC. Are you talking about some
other issue with the parent pom?
These maven setups are definitely a complex issue so I find myself wanting
to take a cautious approach...
Chris
On 5/22/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Hi all,
>
> I compiled some documentation talking about how we should handle a parent
> POM for our TLP
> so all subprojects can inherit from it. We have been using it incorrectly
> and have been loosing
> track of it. I explain all this and expose some simple policy (6 rules)
> that will help us keep this
> all straight [1].
>
> Please read this and let's vote on it make it official.
>
> [ ] +1 Apply this policy/process for TLP POM management
> [ ] +/-0 Abstain - don't understand or don't care
> [ ] -1 Do *NOT* apply this policy for TLP POM management
>
> -- Alex
>
> -------
> [1] - http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.html
>
>
>
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Ole Ersoy <ol...@gmail.com>.
++0
Change is good!
Stefan Zoerner wrote:
> Alex Karasulu wrote:
>> Please read this and let's vote on it make it official.
>>
>> [ ] +1 Apply this policy/process for TLP POM management
>> [ ] +/-0 Abstain - don't understand or don't care
>> [ ] -1 Do *NOT* apply this policy for TLP POM management
>
> +/-0
> (Don't have the time to read in order to make an informed decision)
>
>
> Greetings,
> Stefan
>
>
Re: [VOTE] Policy for Managing TLP POM
Posted by Stefan Zoerner <st...@labeo.de>.
Alex Karasulu wrote:
> Please read this and let's vote on it make it official.
>
> [ ] +1 Apply this policy/process for TLP POM management
> [ ] +/-0 Abstain - don't understand or don't care
> [ ] -1 Do *NOT* apply this policy for TLP POM management
+/-0
(Don't have the time to read in order to make an informed decision)
Greetings,
Stefan