Hi,
To make a long story short, i will begin with the questiom:
I'm trying to figure out what is the Maven way to do this. How can i put up
standards for different kind of poms types (ejb's, assemblies, ears, etc) in
a multimodule environment without using different parents?
-- The long story -
It's really up to the plugin author to document compatibilities rather
than Maven core running around and building a list.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Benedict
Sent: Tuesday, February 12, 2008 5:09 PM
To: Maven Developers List
Subj
>From a commercial perspective... in an interview when I ask 'do you understand
>maven?' I want the prospective consultant/employee to say 'yes' and I want to
>know that that means they can grok poms... if you allow custom formats you
>just don't get that and we end up going the way of ant...
Y
I think that by setting the versions in the superpom, we would already
have eliminated the issue you fear...however going by memory, 2.0.8 came
out before 2.4 and if that's the case, then surely we wouldn't have that
version in the pom.
I think it's safe to say that the versions idea will go forw
It's really the other way around - the Maven core should remain
backwards compatible with all plugins. However sometimes core features
are introduced that plugins need, and that's when they state a minimum
requirement. I do agree that better documenting this in the plugin
sites would be hel
Brett,
I didn't know that. I never knew that kind of feature existed. Can the
minimum recommended version be listed in Maven release notes though? It
would be nice to a have a table with what versions should be used with
2.0.8for the best support. Education and visibility on this issue is
key, imo
On 13/02/2008, at 11:19 AM, Brian E. Fox wrote:
The divergence mostly. The original feature, if it can be grafted on
without breaking existing builds and with out massive amounts of
new, risky code, would be logical in 2.0.x. Everything related to
changing the pom should be in 2.1+. I'm tr
Jason Chaffee wrote:
I am pretty familiar with testng code, so I would like to look into this
further. Is it a correct statement to say that the output we are seeing
on the console is coming directly from testng?
No... Console output in Surefire is a bit strange. :-)
By default, Surefire f
I am pretty familiar with testng code, so I would like to look into this
further. Is it a correct statement to say that the output we are seeing
on the console is coming directly from testng?
-Original Message-
From: Dan Fabulich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 12, 20
The divergence mostly. The original feature, if it can be grafted on without
breaking existing builds and with out massive amounts of new, risky code, would
be logical in 2.0.x. Everything related to changing the pom should be in 2.1+.
I'm trying to stress the + here because I'm really concerned
Are you talking about the divergence of the thread, or the original
feature?
I'm still in favour of renaming 2.0.9 to 2.1 and starting to add
features to a stable code base. After all, we already have.
- Brett
On 13/02/2008, at 4:12 AM, Brian E. Fox wrote:
I think we need to keep a goal o
On 13/02/2008, at 2:30 AM, Jason van Zyl wrote:
At any rate, we can fix that goal and mimic the new behavior. Might
be good to try and raise these things when we've asked repeatedly
for people to try it.
erm, I raised it early on, I raised it again when the alpha was
suggested, and I p
Jason Chaffee wrote:
Hmmm, the bug says it is fixed in 2.4.1 and it still produces a single
suite file and single suite output to the console. I agree with you
Benjamin, I don't think Dan understood the problem and thus didn't
actually fix it. Instead, the fix was for the reporting.
SUREFIRE
But this is how it already works, if I'm reading correctly. The
minimum version of Maven for a plugin is specified by the plugin
itself in the prerequisites tag - if you use an older version of
Maven, you will get the last version of the plugin that worked with it.
- Brett
On 13/02/2008, a
+1
Others plugins (i.e. pdf-plugin) needs this method too
Cheers,
Vincent
2008/2/12, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi,
>
> I've almost completed a RequireSkinVersion rule for the Maven Enforcer
> Plugin. The rule has a parameter named "locales" of type String that accepts
> a comma se
Hmmm, the bug says it is fixed in 2.4.1 and it still produces a single
suite file and single suite output to the console. I agree with you
Benjamin, I don't think Dan understood the problem and thus didn't
actually fix it. Instead, the fix was for the reporting.
-Original Message-
From:
Benjamin's links are the right place to start, though I might add that the
head of that thread is a really long e-mail from me that doesn't directly
address your question. The rest of the thread is about your question.
Executive summary: TestNG support was broken in Surefire 2.3.x; it only
wo
Hi,
I've almost completed a RequireSkinVersion rule for the Maven Enforcer
Plugin. The rule has a parameter named "locales" of type String that accepts
a comma separated list of locale codes just like the Maven Site Plugin. What
is left is the conversion of those codes into Locale objects. I cou
Hi,
Surefire-2.3.1 used to output which test was running and it would create
an output file for each test.
I am using testng. Can anyone tell me why this changed and if there is
any way to configure it to behave in the same manner as previous
releases?
Nice to see I am not the only one who i
Surefire-2.3.1 used to output which test was running and it would create
an output file for each test. For example,
[INFO] [surefire:test]
[INFO] Surefire report directory:
/usr/local/hudson/workspace/common/common/management/target/surefire-rep
orts
-
On 12-Feb-08, at 1:46 PM, Michael McCallum wrote:
From a commercial perspective... in an interview when I ask 'do you
understand
maven?' I want the prospective consultant/employee to say 'yes' and
I want to
know that that means they can grok poms... if you allow custom
formats you
just do
On 12-Feb-08, at 1:19 PM, Milos Kleint wrote:
On Feb 12, 2008 9:53 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 12-Feb-08, at 11:39 AM, Milos Kleint wrote:
anyway,
I fixed both my and Daniels problem here:
http://svn.apache.org/viewvc?view=rev&revision=627055
Great. Hardly tragic. Pr
The plexus-utils upgrade will not happen unless you also changes the
prerequisites to Maven 2.0.6.
[EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Tue Feb 12 13:34:56 2008
New Revision: 627125
URL: http://svn.apache.org/viewvc?rev=627125&view=rev
Log:
Bumping to plexus-compiler-* 1.6-SNAPSHOT t
From a commercial perspective... in an interview when I ask 'do you understand
maven?' I want the prospective consultant/employee to say 'yes' and I want to
know that that means they can grok poms... if you allow custom formats you
just don't get that and we end up going the way of ant...
big t
I've been watching the discussions about introducing a fix set of plugin
versions per Maven version. I see benefit and drawback to each side of the
argument.
Here is another proposal which is dear to my pain :-)
Provide the minimal compatible version of each plugin (of group
org.apache.maven.plug
On Feb 12, 2008 9:53 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 12-Feb-08, at 11:39 AM, Milos Kleint wrote:
>
> > anyway,
> >
> > I fixed both my and Daniels problem here:
> > http://svn.apache.org/viewvc?view=rev&revision=627055
> >
>
> Great. Hardly tragic. Probably took you less time to
On 12-Feb-08, at 11:39 AM, Milos Kleint wrote:
anyway,
I fixed both my and Daniels problem here:
http://svn.apache.org/viewvc?view=rev&revision=627055
Great. Hardly tragic. Probably took you less time to patch it then
write the email.
I also didn't figure that embedding Archetype in net
anyway,
I fixed both my and Daniels problem here:
http://svn.apache.org/viewvc?view=rev&revision=627055
Milos
On Feb 12, 2008 7:52 PM, Milos Kleint <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 6:45 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> >
> > On 12-Feb-08, at 8:16 AM, Milos Kleint wrote:
On Feb 12, 2008 7:17 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
> When a test fails (by throwing a Throwable) Surefire needs to output the
> message string of the failure in the XML test result output; Java strings
> may contain the null character \u. Therefore, not all Java strings
> can be
On Feb 12, 2008 6:45 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 12-Feb-08, at 8:16 AM, Milos Kleint wrote:
>
> > Jason,
> >
> > this is not about mimicking old behaviour. The new code is plain wrong
> > for this case.
>
> Mimicking the behavior means making it work like the previous versio
Jason,
On Tuesday 12 February 2008, Jason van Zyl wrote:
> On 12-Feb-08, at 8:16 AM, Milos Kleint wrote:
> > this is not about mimicking old behaviour. The new code is plain
> > wrong for this case.
>
> Mimicking the behavior means making it work like the previous version.
>
> It would also have
Jochen Wiedmann wrote:
As he wrote, these characters are illegal, regardless of encoding,
CDATA, and so on. XML is a text format and ASCII 0 is a binary
character.
The suggested way to embed binary data into XML is using the base64 encoding.
Apart from that, I do not understand the use case. W
On 12-Feb-08, at 8:16 AM, Milos Kleint wrote:
Jason,
this is not about mimicking old behaviour. The new code is plain wrong
for this case.
Mimicking the behavior means making it work like the previous version.
It would also have been nice if both you and Dan actually looked at
this before
No argument there, but we do still need to be discussing things that
are beyond the scope of the next release. We need to be hashing out
these sorts of issues, so we can keep the hopper full of new work for
successive releases.
We can always work on these sorts of things on feature branches
I think we need to keep a goal of getting 2.1 stabilized so we can start doing
releases before we start doing all new manipulations on the code. It's already
been 2+ years since the 2.0 alpha...that's too long imo.
A while back we tool a list of proposals for 2.1 and IMO, it's not a good idea
t
That's the existing process, where the next mojo to be executed is
discovered based on the metadata of the current one...if the current
mojo requires a fork, the mojos to be included in that fork are
calculated just before the forking mojo is executed. As you go
through the build, executing
I've been thinking for awhile now that we need to find a way to
enable the more common programmatic semantics for mojo ordering...for
instance:
- finally semantics, where a mojo is /always/ executed after another
mojo, regardless of failure status...the only question here is shared
with t
On Feb 12, 2008, at 10:30 AM, John Casey wrote:
FWIW, I think as long as we have a standard format for POMs on a
single remote repository, it doesn't hurt to accommodate all comers
WRT format.
XML is okay for developers familiar with it to read, but it was
always intended to be rendered
No.
New lifecycle phases is a hack, to work around the bigger issue of
not having control over mojo-execution ordering and expression. IMO
we need to deal with the core issue, not continue to treat the symptoms.
-john
On Feb 11, 2008, at 3:44 AM, Wouter Hermeling wrote:
Reading through
FWIW, I think as long as we have a standard format for POMs on a
single remote repository, it doesn't hurt to accommodate all comers
WRT format.
XML is okay for developers familiar with it to read, but it was
always intended to be rendered in some way. If we had rendering tools
to give th
This is getting pretty far afield from the original email in the
thread, but I'd say this is a perfect reason for separating the
statement of dependencies associated with a particular artifact on
the remote repository from the POM used to build it. We can (and do)
deploy the original POM us
Jason,
this is not about mimicking old behaviour. The new code is plain wrong
for this case.
When you define the archetype's groupId, artifactId and version on
command line, the plugin should not offer you a list to pick from.
That's especially tragic when the archetype you want is not in the
list
On Feb 12, 2008, at 9:34 AM, Gilles Scokart wrote:
-Original Message-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: mardi 12 février 2008 16:03
To: Maven Developers List
Subject: Re: An Attribute Based POM
On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:
For example, we'
>We could deploy a "generated" POM that reflects the enabled profiles
and the
>maven model used to build the artifact.
This won't work when the poms are used for inheritance out of the
repository. Suddenly a property meant to be resolved at build time to
something on the developer's machine is res
> -Original Message-
> From: Tim O'Brien [mailto:[EMAIL PROTECTED]
> Sent: mardi 12 février 2008 16:03
> To: Maven Developers List
> Subject: Re: An Attribute Based POM
>
>
> On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:
>
> >> For example, we'd can group groupId/artifactId/ver
On 12-Feb-08, at 1:39 AM, Emmanuel Venisse wrote:
I like the attribute based POM, but we can reduce more the XML. For
example, we'd can group groupId/artifactId/version into one
attribute like
this:
I don't think that would be a great idea. Let's just leave them as
individual attribut
We can create a new goal name, whatever it be, and mimic the old
behavior.
The archetypes don't need to reside in central. I've been taking the
list off the Wiki and turning it into the internal catalog. We can
keep the list itself in that case for the command line. For the
Eclipse use ca
Right of course, but the core idea is that XML doesn't drive the
format or structure of data.It should tell you guys something that
negative reactions to Maven like Buildr use the colon notation.
Maven itself prints out dependencies using the colon notation when you
run the dependenc
Your example just demonstrate the issue with String formated :
23:22:22.003
or
11PM:22:22.003
or
21:22:22.003 UTC
???
The "native" format for time (in computer world) is number of ms since
01/01/1970 .. so its un non-formated binary type
The equivalent XML element should be something like
23:22
The new archetype plugin seems to have broken the normal instructions on
how to create new projects.It doesn't seem to work.
For example, according to:
http://cwiki.apache.org/confluence/display/CAMEL/Creating+a+new+Spring+based+Camel+Route
I should just need to run:
mvn archetype:create
On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:
For example, we'd can group groupId/artifactId/version into one
attribute
like this:
Please don't do this. This would require another parsing step after
the XML
parsing and introduces further error sources. Use XML to structure
the
Well, I'd like to "improve" rather the "dependencies" element:
i.e. inherit the attributes from the surrounding dependencies tag (with the
possibility to override them).
Ralph Goers wrote:
> Actually, there wasn't a singl
For example, we'd can group groupId/artifactId/version into one attribute
like this:
Please don't do this. This would require another parsing step after the XML
parsing and introduces further error sources. Use XML to structure the data,
not some proprietary format. Third-party tools dealing w
I like the attribute based POM, but we can reduce more the XML. For
example, we'd can group groupId/artifactId/version into one attribute like
this:
An other solution would be to group dependencies:
Note that for the continuum-model artifact, I use only "continuum as the
groupId and Ma
An option is to for POM converstion in the deploy plugin to reformat as
4.0.0 format, as the underlying model has not been changed. This would make
4.1.0-model-based projects metadatas available for pre-maven-2.0.9 users.
We could also consider removing unecessary infos from the deployed poms :
w
I tried to set (as you suggested in TODO)
xml.listStyle="flat"
and according to http://modello.codehaus.org/DataModel, this should support:
...
...
but modello ignores the flat style and generates the same parser as wrapped
:
else if ( xmlStreamReader.getLocalName().equals( "depe
I like very much the attributes syntaxe (after all, it is what we are
already using in ivy ;-) ).
Is your intention to use it in the sources pom only, or also in the
published pom. In the seconf case, how do you handle the problem of forward
compatibility? I mean, what will happen to all user th
57 matches
Mail list logo
