Something like this approach should work:
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/
On Sat, Sep 26, 2009 at 7:37 PM, Paul Benedict wrote:
> I find myself replicating the same log4j configuration in my Maven projects.
> It's a typical setup I want my p
I find myself replicating the same log4j configuration in my Maven projects.
It's a typical setup I want my projects to always use. Is there any good way
to specify one in a parent POM for all child projects? Would the
maven-remote-resources-plugin be useful for this?
Paul
On 2009-09-26, at 12:11 PM, Albert Kurucz wrote:
I don't want anyone to miss any of the numerous "ok" arifacts.
Those could still be housed by the "Good enough" Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a
difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If Son
On Sat, Sep 26, 2009 at 12:11 PM, Albert Kurucz wrote:
> I don't want anyone to miss any of the numerous "ok" arifacts.
> Those could still be housed by the "Good enough" Central repo.
> I would like to have a setting in my Maven with 3 options:
> -Good enough
> -Good (verified meta)
> -Best (veri
I don't want anyone to miss any of the numerous "ok" arifacts.
Those could still be housed by the "Good enough" Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
which selects which of the 3 maintained repo will be
> central it just too useful... it has gathered critical mass whereby it is
> nearly a right of passage for new java projects to get hosted on central...
> hosting on central becomes one of those things projects are asked to do...
> if we move the goalposts too far or too fast we will kill the crit
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, Albert Kurucz wrote:
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a
difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo
if you start measuring artifact quality, it makes sense to break down
the stats by groupId
at least that way if I see that java.net has 100% quality for
com.stvconsultants.easygloss I can configure my repository manager to
allow that group I'd through, but leave org.glassfish out as its
q
You got the point. But that "quality information" (whatever it's form would
be), could do things like:
- describe the overall quality of repo (let's name it the MRQ score)
- the list (or only the count) of "rules"/"tests" ran (so, a repo of MRQ
score 5 with 5 tests would be "less good" than a repo
IMHO, being buildable by maven is a nice to have, but to be honest, if
somebody wants to build their project with a DOS batch file and a
piece of string I don't mind as long as they publish the artifact with
a valid pom
anything else is setting the repository up for failure
Sent from my [r
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If Sonatype's goal is to sell these tools only for paying cust
I think we all need some clarification, since we all talk about "quality"
(we all agreed upon the basic things unanimously).
What is the "quality" of a maven repository (in general)? Can we measure it?
Can we define it?
A wiki page with piled up (even personal) opinions would be good -- whatever
t
In that case, you're stuck and the release plugin will do the job but don't
use properties to define versions.
I think a certain version of Maven allows to import a pom into another.
Regards
Jeff
On Sat, Sep 26, 2009 at 7:09 PM, Emmanuel24 wrote:
>
> As I said, I define the version in ProjectP
As I said, I define the version in ProjectParent and in this project, I
defined my modules as the figure shows it.
But my modules don't inherit from this project. That is the problem.
Emmanuel.
jeffma...@jeffmaury.com wrote:
>
> In that case, I don't understand where the versions of your proj
In that case, I don't understand where the versions of your projects are
defined because if the parents are enterprise pom, you are not allowed to
modify them !!!
Jeff
On Sat, Sep 26, 2009 at 4:06 PM, Emmanuel24 wrote:
>
> Hi Jeff,
>
> Thank you for your answer. The problem is that I can't chan
Hi Jeff,
Thank you for your answer. The problem is that I can't change parent poms
because it's enterprise poms. My poms inherit from them to respect
enterprise archictecture choices.
Emmanuel.
Jeff MAURY wrote:
>
> From my experience with Maven, I discourage using properties for
> defining
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
> For the additional requirement, getting into the pure Maven repo (The
> best), I really meant: build-able.
>
> Me too, I don't really care what tool you use to build it as long as
> the tool is already checked in and you only use the attached
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
> For the additional requirement, getting into the pure Maven repo (The
> best), I really meant: build-able.
>
> Me too, I don't really care what tool you use to build it as long as
> the tool is already checked in and you only use the attached
Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
> I think we all need some clarification, since we all talk about "quality"
> (we all agreed upon the basic things unanimously).
> What is the "quality" of a maven repository (in general)? Can we measure
> it? Can we define it?
>
> A wiki page
I have a parent pom that has two modules, A & B.
B depends on A.
A depends on P which is a 3rd party jar with provided scope. The task of
module A is to combine the contents of A & P, this sum is the output of A.
Now when we build this (clean install) at the parent pom on two systems we
get two
>From my experience with Maven, I discourage using properties for
defining pom version, Maven does handle it correctly on some cases,
even if the properties are defined on the parent pom
I recommand using version herited from the parent and updating the
parent version with the version plugin
Jeff
A lot of +1-es to this quote
~t~
On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz wrote:
> "Non-buildable source is fine as a gesture of goodwill, but I think if the
> public source isn't buildable, we're gonna end up with egg on our faces."
> Quote from:
>
> http://mail.opensolaris.org/pipermail/o
I have configured Multiple project in my eclipse workspace and each project
has its own POM.XML . I have worked with the dependencies with single
eclipse project with multiple modules in that single project and it works
fine when build with Maven but when working with Different projects is there
an
24 matches
Mail list logo
