I'm having trouble building the trunk of Continuum. It's complaining about:
Missing:
--
1) bcel:bcel:jar:5.2
...
Path to dependency:
1) org.apache.maven.continuum:continuum-test:jar:2.0-SNAPSHOT
2) jpox:jpox-enhancer:jar:1.1.9
3) bcel:bcel:jar:5.2
Looks like
That's nice,
so I reconsider my vote as -0 : only a fix until plugin version are required
by maven 2.1, but I had prefered the equivalent enforcer code to be
integrated to core and WARN (optionally FAIL) when no plugin version is
specified. This would be
- more educational
- a good preparation
Hello,
Maven detractors blam maven POM.xml to become huge XML files even for
simple tasks.
Considering the comparison with ant, the latest use XML attributes an few
XML elements, making tasks declaration consise.
Could we introduce a new XML schema (for maven 2.1) to support simple types
Hi Dennis,
2008/2/10, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: dennisl
Date: Sun Feb 10 05:28:36 2008
New Revision: 620284
URL: http://svn.apache.org/viewvc?rev=620284view=rev
Log:
[MCHANGES-88] NoSuchMethodError with maven 2.0.8 when generating
changes-report
Submitted by: Niall
As a long-time Maven user: a big +1000 from me :)
On Feb 10, 2008 11:34 AM, nicolas de loof [EMAIL PROTECTED] wrote:
Hello,
Maven detractors blam maven POM.xml to become huge XML files even for
simple tasks.
Considering the comparison with ant, the latest use XML attributes an few
XML
I see your +1000 and will raise you +5000 as this is really needed.
Wb
On Feb 10, 2008 8:08 AM, Arik Kfir [EMAIL PROTECTED] wrote:
As a long-time Maven user: a big +1000 from me :)
--
Thanks,
Arik Kfir.
I'm sure there is lot's of interest for some XML compression
the main discution is HOW ?
AFAIK this would require some changes in Modello to generate a more flexible
XML Reader.
The schema generation would not be too complex : generate both elements and
attributes for simple types (I don't think
Vincent Siveton wrote:
Hi Dennis,
2008/2/10, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: dennisl
Date: Sun Feb 10 05:28:36 2008
New Revision: 620284
URL: http://svn.apache.org/viewvc?rev=620284view=rev
Log:
[MCHANGES-88] NoSuchMethodError with maven 2.0.8 when generating changes-report
Nicolas,
I agree that POM verbosity is a problem, but I also think that a lot
of people on this list are not going to want to introduce
revolutionary changes to POM structure without being convinced (as we
are) that it is a problem.
The first step to this would be to add the ability to
Using attributes in place of XML elements is not revolutionary. I don't
speak here about writting POMs in groovy !
This is just about better use of XML, it requires only a tweak of the
Xpp3Parser to handle attributes the same way it handles nested elements, and
maybe to change the install/deploy
On Feb 10, 2008, at 10:57 AM, nicolas de loof wrote:
Using attributes in place of XML elements is not revolutionary. I
don't
speak here about writting POMs in groovy !
That's the difference, I do. I think people should have the
opportunity to replace the parser entirely and write
Tim,
I see where you're going and in general I agree with you as I think most
software should be extensible to handle unknown environments and unique
situations. However, I think the biggest bang for buck is to fix/enhance
the current one way and then add pluggability for POM parser substitution
On Feb 10, 2008, at 11:14 AM, Wendell Beckwith wrote:
Tim,
I see where you're going and in general I agree with you as I think
most
software should be extensible to handle unknown environments and
unique
situations.
However, I think the biggest bang for buck is to fix/enhance
the
Also look here for previous discussions:
http://docs.codehaus.org/display/MAVEN/Terse+POM+Syntax+-+Design+Discussion
http://docs.codehaus.org/display/MAVEN/POM+Loading+and+Building
You might want to start by looking at those and cleaning those up.
Sifting out anything that's in JIRA.
On
This is not a trivial task so I would suggest the following:
1) find out what the ideal representation would be
2) determine what would be needed in modello to generate the reader/
writer (this will actually be a lot of work)
3) try the changes out in the core
Dealing with 1) should be
2008/2/10, Dennis Lundberg [EMAIL PROTECTED]:
Vincent Siveton wrote:
Hi Dennis,
2008/2/10, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Author: dennisl
Date: Sun Feb 10 05:28:36 2008
New Revision: 620284
URL: http://svn.apache.org/viewvc?rev=620284view=rev
Log:
[MCHANGES-88]
Hi Wayne/Devlist:
I guess this should be on the developers list so I'm switching gears (please
include my email in any response since I'm not on the dev list yet):
When the javadoc plugin attempts to grab the javadoc binaries version in the
JavadocUtil.getJavadocVersion() it attempts to execute:
What is the status of the maven-continuum-plugin module?
I need a build (actually, a release,) on one Continuum server to force
a build on another Continuum server. A maven plugin configured in the
release profile was my first thought, and I remembered seeing some
commits to this plugin.
No release yet but since we need it to release MPIR, the
maven-doxia-tools release will be soon :)
Please have a look at MSITE-279 before. As far as I noticed, the offending
code parts have been moved to the maven-doxia-tools so it would be good to
get that fixed before their release.
2008/2/10, Benjamin Bentmann [EMAIL PROTECTED]:
No release yet but since we need it to release MPIR, the
maven-doxia-tools release will be soon :)
Please have a look at MSITE-279 before. As far as I noticed, the offending
code parts have been moved to the maven-doxia-tools so it would be
2008/2/10, Alexander Sack [EMAIL PROTECTED]:
Hi Wayne/Devlist:
I guess this should be on the developers list so I'm switching gears (please
include my email in any response since I'm not on the dev list yet):
When the javadoc plugin attempts to grab the javadoc binaries version in the
Is there any reason again why it can't use -version?
-version gives a lot of unuseful informations.
The unuseful information should not be a problem for the version parsing. On
the other hand, -fullversion is for internal use only according to [0]
so it seems wise to switch to -version and
2. Those who have not locked their versions down
By the way, this includes Maven itself. For instance, I see plugin builds
that fetch other plugin SNAPSHOTs from my local repo that I have built for
testing patches.
As a matter of advertising, it might be helpful if the Maven sources would
Of course they should :-)
If you have anything specific, please file it in JIRA or send a mail
here and I'll take care of it.
Don't worry, once enforcer goes out, I'll be setting up our poms to get
it all locked down. As I mentioned in my previous email, I've been
manually doing it in the
As a matter of advertising, it might be helpful if the Maven sources
would
give a good example ;-)
Absolutely. I have started doing this with all my releases (I use the
enforcer snapshot to find them, then take it out for now). 2.0.8,
dependency and archetype all have things locked down.
Tim O'Brien wrote:
People will use whatever implementation they feel like using. I'd
propose that you start by shipping Maven with two:
1. Classic - the way it works now
2. Reduced XML - the thing that Nicolas proposed
If someone wants to ship an implementation that understands something
Benjamin Bentmann wrote:
2. Those who have not locked their versions down
By the way, this includes Maven itself. For instance, I see plugin
builds that fetch other plugin SNAPSHOTs from my local repo that I have
built for testing patches.
As a matter of advertising, it might be helpful if
If you have anything specific
Some Maven or Mojo plugins...
please file it in JIRA
Sorry, but I won't due to my laziness ;-). In lack of a
reportingManagement in Maven 2.0, one cannot do this simply by means of a
single updated parent POM but would really need to update each sub module
POM.
There will be no choice but to walk in a few bytes of the POM,
determine the version and use the appropriate reader.
That said I don't think anything language specific a la ruby or groovy
has any place in Maven proper. Lots of room for side projects that use
the embedder and whatever other
the current pom structure is very easy to edit in many editors...
attributes would make it a bit simpler in some circumstances but not
necessarily more readable
perhaps a pom to yaml printer plugin would help people to read it...
I would say that people who really want to change it probably
On 10-Feb-08, at 1:59 PM, Benjamin Bentmann wrote:
2.0.8, dependency and archetype all have things locked down.
In case you meant the maven-dependency-plugin:
[INFO] Scanning for projects...
[INFO]
[INFO] Building
The tools to do this are all in modello already. I'm experimenting
with a very basic conversion right now.
On 11/02/2008, at 8:38 AM, Jason van Zyl wrote:
There will be no choice but to walk in a few bytes of the POM,
determine the version and use the appropriate reader.
That said I don't
2.0.8, dependency and archetype all have things locked down.
In case you meant the maven-dependency-plugin:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Dependency Plugin
[INFO]task-segment: [site]
That's not what I understand as a version lock down. Sure, the site
might
not be that important but I still would like it to be as reproducible
as
anything else I can generate out of a given POM.
The reporting is the last piece and is the reason I haven't released the
enforcer yet. The report
I wish we could turn nested tags into attributes. Spring has a p namespace
which is a very similar idea. If Maven isn't going to take advantage of
attributes, using them as alises for nested tag shortcuts seems reasonable.
Paul
Just please somebody implement either enforcer:display-plugin-versions or
help:display-plugin-versions
On Feb 10, 2008 10:37 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
The enforcer is entirely pluggable so that wouldn't be a problem if
someone wanted to implement that.
On 10-Feb-08, at 2:29
The enforcer is entirely pluggable so that wouldn't be a problem if
someone wanted to implement that.
On 10-Feb-08, at 2:29 PM, Benjamin Bentmann wrote:
I think another rule would be more appropriate.
Sounds reasonable, two different POM elements, two different rules.
To make things
I think another rule would be more appropriate.
Sounds reasonable, two different POM elements, two different rules. To make
things complete a third rule would be RequireSkinVersion.
Benjamin
-
To unsubscribe, e-mail:
If the whole plugin versions in the super pom goes ahead, which I think is a
good idea by the way.
It may be useful to release Maven more often, so that the super pom gets
updates on a more regular basis, i.e. at least once a month.
I know releases are getting more regular, but from my
Um - any reason that 2.0.8.1 can't be released that only contains an
update to the superpom's plugin-set? (again, assuming this line of
action is pursued)
Christian.
On 10-Feb-08, at 18:18 , Stephen Connolly wrote:
If the whole plugin versions in the super pom goes ahead, which I
think is
Just please somebody implement either enforcer:display-plugin-versions
or
help:display-plugin-versions
The code to do this is in the enforcer rule now, once I get the rule
solidified and released, I'll move it to a common piece and add it to
help.
Um - any reason that 2.0.8.1 can't be released that only contains an
update to the superpom's plugin-set? (again, assuming this line of
action is pursued)
It seems pretty certain to me that this is going to happen. I'd rather
see 2.0.9 come out, but naturally sooner rather than later and I
It may be useful to release Maven more often, so that the super pom
gets
updates on a more regular basis, i.e. at least once a month.
In general I agree we need to release more often and intend to make sure
it starts happening. I will not however consider a release simply to
update the super
I think you are missing my point. I have no problem with allowing a more
compact XML using attributes instead of elements. But the minute you
allow the parser to be pluggable you allow folks to start inventing
their own POM syntax. I would find that situation completely
unacceptable. I don't
Hmmm...what about a more simple solution that uses XSLT processing instructions?
?xml-stylesheet type=text/xsl href=myMavenPomFormat.xsl ?
Then, Maven just has to detect that instruction when loading the XML,
and apply the stylesheet accordingly to get the standard Maven XML.
The advantages
On Feb 9, 2008 9:39 AM, Raphaël Piéroni [EMAIL PROTECTED] wrote:
The documentation you saw is:
- not yet committed
- generated from the plugin module
the documentation in the parent module is 1 year old. and appart from
the descriptor, a bit dated.
I commit now the release is done.
This
Yep, that's what I referred to with flattening lists. I don't think
that's too hard - I just wanted to get feedback on the first attempt.
- Brett
On 11/02/2008, at 5:58 PM, Tim O'Brien wrote:
Why not further steps towards terseness?
1. Get rid of collection container elements.
Why this:
I think the same steps apply Nico, if you're going to run with it.
Which I assume you are because you suggested it.
Take whatever information you've gathered and make some samples of the
ideal format folks seem to like.
Then we can look at the technical aspects. Brett's done some of the
Please have a look at MSITE-279 before.
Sure! Could you send us a new patch on maven-doxia-tools?
Updated patch for MSITE-279.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Hi,
I've always wanted to see an attribute based POM, so based on Nicolas'
suggestion I killed some time after waking up early this morning to do
it.
JIRA: http://jira.codehaus.org/browse/MNG-3397
Here is a build to try:
On Feb 7, 2008 7:08 PM, Brett Porter [EMAIL PROTECTED] wrote:
I have some additions :)
I also think we need to keep reviewing the types of problems people
have and helping them diagnose them. It seems that figuring out repo
whitelists and blacklists and the cause of proxy problems is still
On 10-Feb-08, at 8:08 PM, Ralph Goers wrote:
I think you are missing my point. I have no problem with allowing a
more compact XML using attributes instead of elements. But the
minute you allow the parser to be pluggable you allow folks to start
inventing their own POM syntax. I would find
Why not further steps towards terseness?
1. Get rid of collection container elements.
Why this:
execution id=generate
goals
goaldescriptor/goal
/goals
/execution
When this wold suffice:
execution id=generate
goaldescriptor/goal
/execution
This seems like a trivial
53 matches
Mail list logo
