Gregory Kick wrote:
On 8/22/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
Ok, so I'm coming to the conversation slightly late in the game, but
all of this discussion reminds me of something that's been in the back
of my mind for
Jason van Zyl wrote:
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you have concurrency problems with a local repository?
One team
Jason van Zyl wrote:
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you have concurrency problems with a local repository?
That's
Brian E. Fox wrote:
One big issue I have is that the maven-dependency-plugin seems to
ignore
artifacts produced in the current build execution and only pulls from
the local repository... so I have to run mvn install all the time...
Which goal? The unpack, copy yes, but
Jason van Zyl wrote:
On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
How on earth do you have concurrency problems with a local repository?
Simultaneous builds in a CI system on a multicore machine.
If you are knowingly doing this then I would say different settings
via a
Brett Porter wrote:
On 23/08/2007, at 7:12 AM, Stephen Connolly wrote:
Or a better local repository model ;-)
+1. I already started to draft a proposal for the wiki on this, but
hadn't posted it yet.
One where there are two local repositories (committed and current
build) that get
Wayne Fay wrote:
input on this issue. Its easy enough to do with SurveyMonkey, assuming
we can find someone to write it using neutral language to avoid
unintended bias.
Spoilsport!
How are people supposed to b*tch and moan about the biased survey
results if you go and get somebody to write
Jerome Lacoste wrote:
On 8/31/07, Brett Porter [EMAIL PROTECTED] wrote:
Yeah, I meant to note that - I was thinking that this should be
accompanied by a proposal to take care of the id ambiguity problems
which we've discussed a couple of times before.
I think URLs are still problematic
B
With the following proviso:
I'd like to see main Maven releases more often, and have those main
releases specify a suite of endorsed plugin versions for that Maven
release.
That way, if I want a stable reproducible build, I just continue to use
the version of Maven that I built with. It
A
Brett Porter wrote:
Like the other poll, I'd like to hear from as many people as possible
their opinion this topic (even if you just want to say '0' so we know
where you stand).
[ ] (A) Having a way to include a set of plugins in one small POM
fragment would be a useful feature to have
Dennis Lundberg wrote:
Jason van Zyl wrote:
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
nameTest/name
version1.0-SNAPSHOT/version
build
plugins
Dennis Lundberg wrote:
nicolas de loof wrote:
Hello,
First be sure I've lot's of respect for maven developpers and the
work they
offer to the community.
I'm just curious about WHY there is so fiew releases of maven
plugins, even
when there is JIRA issues with patches avilable or SNAPSHOTS
Piotr Tabor wrote:
Brett Porter pisze:
On 24/09/2007, at 2:57 AM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sun Sep 23 09:57:46 2007
New Revision: 578582
URL: http://svn.apache.org/viewvc?rev=578582view=rev
Log:
o reverting fix for MNG-1323, breaks trunk horribly when everything
not exactly
happy about the directory structure compromise I've picked.
-Stephen
On Nov 30, 2007 8:37 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
I normally have two subfolders of resources:
/src/main/resources/verbatim
/src/main/resources/filtered
/src/test/resources/verbatim
/src/test/resources
I normally have two subfolders of resources:
/src/main/resources/verbatim
/src/main/resources/filtered
/src/test/resources/verbatim
/src/test/resources/filtered
with the following in the build section of the pom
resources
resource
filteringfalse/filtering
Could the plugin dependencies not be specified in the pluginManagement
section in the same pom that has the dependencyManagement, thus when
the plugin is referenced, it will get the dependencies specified in
the parent pom
On Dec 5, 2007 5:16 PM, John Casey [EMAIL PROTECTED] wrote:
Hi everyone,
I am concerned by implications of http://jira.codehaus.org/browse/SUREFIRE-350
We normally, on development machines, will use mvn -Dtest=0 clean
install from the root pom to ensure that all modules have been built
with the latest changes and that those changes compile through all the
subsequent
Ahh, ok more typing, but that will work
I'm changed to
+1
so
On Dec 20, 2007 9:40 AM, Marat Radchenko [EMAIL PROTECTED] wrote:
Hacks are bad :)
Use
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skipExec
instead.
2007/12/20, Stephen Connolly [EMAIL PROTECTED
, Stephen Connolly [EMAIL PROTECTED]:
I am concerned by implications of
http://jira.codehaus.org/browse/SUREFIRE-350
We normally, on development machines, will use mvn -Dtest=0 clean
install from the root pom to ensure that all modules have been built
with the latest changes
Can we make the property shorter and easier to remember...
that's what I liked about the -Dtest=0 hack
-Stephen
On Dec 20, 2007 10:23 PM, Dan Fabulich [EMAIL PROTECTED] wrote:
Jason Chaffee wrote:
You can compile test classes and still use maven.test.skip=true if you
have the compliler
cool.
It's not just me, but hoards of developers who's hands will now be
saved from RSI due to excessive typing
;-)
On Dec 21, 2007 3:35 AM, Dan Fabulich [EMAIL PROTECTED] wrote:
Stephen Connolly wrote:
Can we make the property shorter and easier to remember...
that's what I liked about
/properties
...
then:
mvn -Dcheat=true test
On 21/12/2007, at 5:46 PM, Stephen Connolly wrote:
cool.
It's not just me, but hoards of developers who's hands will now be
saved from RSI due to excessive typing
;-)
On Dec 21, 2007 3:35 AM, Dan Fabulich [EMAIL PROTECTED] wrote
:)
On 21/12/2007, at 7:34 PM, Stephen Connolly wrote:
That's hacking your pom.xml, and hacks are bad ;-)
On Dec 21, 2007 6:51 AM, Brett Porter [EMAIL PROTECTED] wrote:
There's always the one shot:
artifactIdmaven-surefire-configuration/artifactId
configuration
skipExec${cheat
consider
that a hack :)
On 21/12/2007, at 7:34 PM, Stephen Connolly wrote:
That's hacking your pom.xml, and hacks are bad ;-)
On Dec 21, 2007 6:51 AM, Brett Porter [EMAIL PROTECTED] wrote:
There's always the one shot:
artifactIdmaven-surefire-configuration/artifactId
rsync: opendir /asm/asm/3.1 (in maven2) failed: Permission denied (13)
rsync: opendir /asm/asm-analysis/3.1 (in maven2) failed: Permission
denied (13)
rsync: opendir /asm/asm-commons/3.1 (in maven2) failed: Permission denied (13)
rsync: opendir /asm/asm-tree/3.1 (in maven2) failed: Permission
But that will bugger you up...
You are working on the version 2 branch, there is no 2.0 released, only
2.0-SNAPSHOT... you don't care as it is still new and you are happy to use
the last stable release, 1.4...
Now there is some work that is needed for the 1.4 service pack, so
1.4.1-SNAPSHOT
IMHO
I think a vote with the two positions clearly identified (perhaps with pros
and cons for both if the pair of ye can agree on the pros and cons). (unless
somebody else has a third position)
-Stephen.
On Jan 30, 2008 12:56 PM, Mark Hobson [EMAIL PROTECTED] wrote:
On 30/01/2008, Mark Hobson
My understanding is that this is all related to the work that is being done
on the build plan for 2.1.
AFAIK the idea behind @aggregator is that it specifies the mojo as being one
that operates on all child modules. So for example javadoc would want to do
this in order to provide a unified
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
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
Also what about a dependencyVersion
dependencies
dependencyGroup groupId=org.apache.maven.archiva
dependency artifactId=archiva-core version=${pom.version}/
dependencyVersion version=1.1-SNAPSHOT
dependency artifactId=archiva-applet/
dependency
as it is really just publishing
the site!
On Feb 11, 2008 9:33 AM, Stephen Connolly [EMAIL PROTECTED]
wrote:
From
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
one critical advantage of Maven over Ant or other build systems is its
From
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
one critical advantage of Maven over Ant or other build systems is its
universal, intuitive set of verbs used to build any project, it is
imperative
that we preserve the meaning of
On Wed, Feb 13, 2008 at 11:52 PM, Dan Fabulich [EMAIL PROTECTED] wrote:
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic
plugin
use cases, things like aggregation and use of ${reactorProjects}, that
we're
running into under the current setup. I
On Feb 18, 2008 8:03 PM, Brett Porter [EMAIL PROTECTED] wrote:
On 19/02/2008, at 3:15 AM, John Casey wrote:
Things like:
- running the tests twice by necessity
Having being burned by this little foible...
I often see people complain that the code coverage tools runs the unit tests
twice.
I
We ran our tricky builds with RC-4 and everything seems OK.
Some of our builds have locked down plugin versions to earlier than
specified in 2.0.9-RC4 and they did not seem to break
-Stephen
On Fri, Mar 28, 2008 at 6:19 AM, James William Dumay [EMAIL PROTECTED]
wrote:
Brian,
We ran most of
And -P!profile or -P-profile to remove it...
This is especially handy if you have one profile that is always active by
default... the hack of -Pdoesnotexist to disable it is not nice
On Mon, Apr 28, 2008 at 11:03 AM, Bernhard David [EMAIL PROTECTED]
wrote:
Hello,
well there's mvn
My only concern would be plugins... but since 2.0.9 locked down the plugin
versions that should not be as big an issue any more
On Mon, May 5, 2008 at 2:31 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
I think the sentiment is fairly clear. I am going to unwind the
retrotranslating I put in place
I think he said he was going to have to set up a java.net project just to
keep track of them!
On Sat, May 10, 2008 at 2:31 PM, Jorg Heymans [EMAIL PROTECTED]
wrote:
Well hobby project or not, i find it pretty amazing when a project does
100+
quality releases in one year ! At first I thought
On Fri, Jun 27, 2008 at 10:35 AM, Hoeher, Alexander
[EMAIL PROTECTED] wrote:
Hello Maven people,
I have the current version of Maven, Maven 2.0.9 installed.
Any helpful comments welcome!
A. Problem
This is the problem, abstract:
How can I disambiguate jar names of jars taken from Maven
The issue is that the order of dependencies does matter.
Resolving transitive dependencies is based on how near the dependency
is to the pom and the order in which dependencies are listed...
Listing them in alpha order, if you've always done this is fine and
won't change your build (as you've
Jason, did you send to the wrong list by mistake? he asked thinking
this smells like a Hudson question
Sent from my iPod
On 8 Jul 2008, at 19:18, Jason van Zyl [EMAIL PROTECTED] wrote:
Hi,
I imagine this is simple, but for a given job name how do I retrieve
the config.xml? I made a
I have developed a plugin that makes keeping versions of related but
not quite tightly coupled in sync a lot easier.
How do I go about contributing this to mojo?
-Stephen
FYI here's how it works...
In your pom you probably have a property used to define the version in
one place, for example:
Oh and -Dproperties=blah.version,foo.version will only do the update
check for ${blah.version} and ${foo.version}
On Thu, Jul 17, 2008 at 1:35 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
I have developed a plugin that makes keeping versions of related but
not quite tightly coupled in sync
at 1.3.5 while
blah-logging may be at 1.3.7
-Stephen
On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum [EMAIL PROTECTED] wrote:
why not just specify the dependencies with version ranges, if you do there is
no need to rewrite anything it just works...
On Fri, 18 Jul 2008 00:35:17 Stephen
, Stephen Connolly
[EMAIL PROTECTED] wrote:
And then when you want to roll a release?
Anyway, if that was the case why is it that most of the maven plugins
themselves use this pattern?
e.g. version${maven.version}/version
Also you may want to force all one set of components to the same suite
Anyway, my question is how do I go about contributing this?
On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
one use case for this is when you have a suite of components and you
want to force _all_ of them to the same version.
Perhaps you have several suites
-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 10:02 AM
To: Maven Developers List
Subject: Re: How do I go about contributing a plugin to mojo?
Anyway, my question is how do I go about contributing this?
On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly
[EMAIL
Done.
http://jira.codehaus.org/browse/MOJO-1178
if anyone wants to take a bite...
On Thu, Jul 17, 2008 at 3:15 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
OK, so... i'll give that a shot once I reformat it to the Maven code style!
On Thu, Jul 17, 2008 at 3:04 PM, Brian E. Fox [EMAIL
Well is anyone interested?
If it's a blocker I can relicense it to the MIT license.
I'm also working on two more goals:
update-plugins
try-updating-plugins
On Fri, Jul 18, 2008 at 10:27 AM, Stephen Connolly (JIRA)
[EMAIL PROTECTED] wrote:
[plugin submission] versions-maven-plugin
I'm having problems getting this set up to work from behind a http proxy.
I've set up subversion's servers file correctly
Here's what I get from the bootstrap:
started
ERROR: svn: No credential to try. Authentication failed
org.tmatesoft.svn.core.SVNCancelException: svn: No credential to try.
On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter [EMAIL PROTECTED] wrote:
On 23/07/2008, at 1:34 AM, Jason van Zyl wrote:
Ok,
I have a package for the new 140 version as that's what I'm using but what
they have in central currently doesn't use classifiers which is probably not
so good.
On Wed, Jul 23, 2008 at 9:22 AM, Jörg Schaible
[EMAIL PROTECTED] wrote:
Stephen Connolly wrote:
On Wed, Jul 23, 2008 at 1:39 AM, Brett Porter
[EMAIL PROTECTED] wrote:
On 23/07/2008, at 1:34 AM, Jason van Zyl wrote:
Ok,
I have a package for the new 140 version as that's what
AFAIK, provided is not transitive, so a provided dependency is assumed to be
provided by any consumer of b
On Mon, Jul 28, 2008 at 10:48 AM, Mark Hobson [EMAIL PROTECTED] wrote:
Ping.. can anyone share some insight on this please?
Mark
2008/7/22 Mark Hobson [EMAIL PROTECTED]:
Hi there,
On Mon, Jul 28, 2008 at 2:23 PM, Aaron Digulla [EMAIL PROTECTED] wrote:
Quoting Ralph Goers [EMAIL PROTECTED]:
It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a
problem if it was actually installed into a
you can use -DparentVersion=[1.3.4]
to force a specific version and it rewrites the pom without changing
any formatting or comments
Sent from my iPod
On 28 Jul 2008, at 16:51, Aaron Digulla [EMAIL PROTECTED] wrote:
Quoting Stephen Connolly [EMAIL PROTECTED]:
What is the most simple way
On Tue, Jul 29, 2008 at 9:29 AM, Aaron Digulla [EMAIL PROTECTED] wrote:
Quoting Stephen Connolly [EMAIL PROTECTED]:
you can use -DparentVersion=[1.3.4]
to force a specific version and it rewrites the pom without changing
any formatting or comments
That sounds very promising!
In fact
On Wed, Jul 30, 2008 at 8:00 AM, Brett Porter [EMAIL PROTECTED] wrote:
On 30/07/2008, at 4:52 PM, Aaron Digulla wrote:
Quoting Brett Porter [EMAIL PROTECTED]:
I've got some code ready for you to try:
http://www.pdark.de/decentxml-1.0-SNAPSHOT-src.tar.gz
wrong list? :)
I've seen
On Wed, Jul 30, 2008 at 8:33 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 8:00 AM, Brett Porter [EMAIL PROTECTED] wrote:
On 30/07/2008, at 4:52 PM, Aaron Digulla wrote:
Quoting Brett Porter [EMAIL PROTECTED]:
I've got some code ready for you to try:
http
My solution is to allow pom's with classifiers!
That way the -jdk14 jar has a -jdk14 pom to specify it's dependencies.
If the pom is not there then you assume the pom for without the
classifier thus not requiring a DOM change... i.e. could be made work
for 2.0.11. And plus it will only
check if the CLASSPATH environment variable is set. it blows up
javadoc if it is
Sent from my iPod
On 31 Jul 2008, at 18:06, John Casey [EMAIL PROTECTED] wrote:
Hi Vincent,
I can't even get the javadoc plugin to run on my machine under Maven
2.0.9, not with JDK 1.4 or JDK 1.6...so I'm
up the build path and classpath. Those are really for
secondary artifacts like javadoc jars and source jars.
On 31-Jul-08, at 8:48 AM, Stephen Connolly wrote:
My solution is to allow pom's with classifiers!
That way the -jdk14 jar has a -jdk14 pom to specify it's dependencies.
If the pom
On Thu, Jul 31, 2008 at 6:55 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
But perhaps it should be!
Consider this case...
I have an artifact foo... it depends on bar... it does not really care what
JDK
Another artifact manchu also depends on bar... but it needs the jdk14
version
My
This is my objection to basing it on the source encoding.
My preference is to pick output encoding as UTF-8 with a simple means to
change it. Source encoding is a different matter. Some source files should
never be UTF-8 encoded and yet the output should not be encoded in the same
encoding...
On Tue, Aug 5, 2008 at 2:44 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On 5-Aug-08, at 12:28 AM, Aaron Digulla wrote:
Quoting Jason van Zyl [EMAIL PROTECTED]:
But I think looking at StAX and possibly trying to patch that to be
smarter about formatting, if necessary, might be a better
Aaron,
speaking for myself, it's more the aggressive tone of your replies
that's getting in the way.
I agree that SAX and DOM are stinking piles of crap and completely
unsuited to round-tripping preserving human formatting.
However I still think StAX has the potential to be made to do
All,
after the entirely underwhelming response to the versions-maven-plugin
(MOJO-1178) I have had some ideas for making it even better...
The ideas may result in completely refactoring the thing apart... bits to go
in the enforcer plugin... bits to go in the release plugin... bits to maybe
stay
, for the current run of maven... so that I
can proof the changes before writing to disk... this could be necessary for
performing an uber-suite release.
-Stephen
On Fri, Aug 8, 2008 at 1:18 AM, Ralph Goers [EMAIL PROTECTED]wrote:
Stephen Connolly wrote:
Questions:
Is there any way
On Fri, Aug 8, 2008 at 2:15 PM, Aaron Digulla [EMAIL PROTECTED] wrote:
Quoting Jochen Wiedmann [EMAIL PROTECTED]:
That didn't work well. Okay, since you don't believe me, here is an
(incomplete) list of changes I would need in StAX to be able to use it
for
my work instead of having to
OK... one change needed in the StAX API is to fix
XMLOutputFactory.newInstance(String, ClassLoader) to return XMLOutputFactory
and not XMLInputFactory.
;-)
On Fri, Aug 8, 2008 at 7:55 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
On Fri, Aug 8, 2008 at 2:15 PM, Aaron Digulla [EMAIL PROTECTED
.
There could be a need some other event required to signal the end of the
start tag.
-Stephen
On Sat, Aug 9, 2008 at 12:58 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
OK... one change needed in the StAX API is to fix
XMLOutputFactory.newInstance(String, ClassLoader) to return XMLOutputFactory
I think that is the issue
On Mon, Aug 11, 2008 at 9:37 PM, David Jencks [EMAIL PROTECTED]wrote:
Maybe I misunderstood what Benjamin is saying but I believe I've run into
this also... IIUC the situation is that the plugin and its parent pom are in
totally unrelated svn locations and _not_
Of course the problem with that is what if there were local changes when the
build was made? Now the SCM revision is meaningless
On Wed, Aug 13, 2008 at 1:03 PM, nicolas de loof [EMAIL PROTECTED] wrote:
Recent snapshot repository purge introduced issues for those of us that
depend on a
right that this is not a 100% safe way to fix this issue, just an
attempt to make things (a little bit) more stable.
A full fix would be to never use SNAPSHOTs, and to deprecate
release/enforcer option to accept them ;-)
2008/8/13 Stephen Connolly [EMAIL PROTECTED]
Of course the problem
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22,) will not pick up 1.0.0.0.9
-Stephen working for a company that insists on 5 number version numbers
Connolly
On Wed, Aug 13, 2008 at
no
roadmap for them, so a project that requires a bug fix has no other option
2008/8/13 Stephen Connolly [EMAIL PROTECTED]
Oh! there's an option to allow snapshot dependencies in release?
Cool!
I did not know that... Now I can go cause me a heap load of trouble!
On Wed, Aug 13, 2008 at 1
Or... if ye don't like that... why not _use four numbers_ and make the rule
be that for a three number release you must call a vote
Of course that would involve fixing DefaultArtifactVersion.compareTo
-Stephen
On Wed, Aug 13, 2008 at 1:25 PM, Stephen Connolly
[EMAIL PROTECTED] wrote
a project that requires a bug fix has no other
option
2008/8/13 Stephen Connolly [EMAIL PROTECTED]
Oh! there's an option to allow snapshot dependencies in release?
Cool!
I did not know that... Now I can go cause me a heap load of trouble!
On Wed, Aug 13, 2008 at 1:14 PM
The versions-maven-plugin is now rewriting XML correctly after some hackery
with woodstox and string index tracking!
I would like to push a snapshot build for others to test (without having to
build from source)
Before I go doing something wrong what do I need to do and how do I do
it!
all the events you might need to rewrite and then write them when you
are ready.
At least this current solution works and I can _put out there_!
On Thu, Aug 14, 2008 at 3:14 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On 14-Aug-08, at 6:24 AM, Stephen Connolly wrote:
The versions-maven-plugin
Could somebody (not behind a http-proxy) please check out
versions-maven-plugin and deploy the project site?
On Thu, Aug 14, 2008 at 3:33 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
It's a bit of a hack
I have another XML Pull Parser in the works that will do this verbatim no
problem
with your XMLInputStream as the JSR api throws away information
you need.
On Thu, Aug 14, 2008 at 3:39 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On 14-Aug-08, at 7:33 AM, Stephen Connolly wrote:
It's a bit of a hack
I have another XML Pull Parser in the works that will do this verbatim
Events Verbatim Pull-Push)
-Stephen
On Thu, Aug 14, 2008 at 3:47 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
The problem, as I see, with StAX is that they all start from the minimal
parser and build up.
i.e.
XMLInputStream accesses the stream directly.
XMLEventReader wraps
on the
InputFactory as to which woodstox would return.
Dan
On Thursday 14 August 2008 10:53:42 am Stephen Connolly wrote:
Oh, yes I forgot to add:
By driving from the event API we can store all the verbatim
information in
the XMLEvent objects.
Then our XMLEventWriter sees these XMLEvent objects and (when
and I have versions-maven-plugin in development
Sent from my iPod
On 14 Aug 2008, at 18:21, Dennis Lundberg [EMAIL PROTECTED] wrote:
Not yet, but I have one in my head...
Jason Dillon wrote:
Is there any nice plugin which I can run which will look at the
current
project and tell me which
I was thinking of a display-plugin-updates and a update-plugins monos
Sent from my iPod
On 14 Aug 2008, at 18:44, Dennis Lundberg [EMAIL PROTECTED] wrote:
When I find the time for it I'll write down a proposal.
I'm also keep to investigate how my ideas correlates with Stephen's
plugin. It
]
On Fri, Aug 15, 2008 at 9:50 AM, Mark Hobson [EMAIL PROTECTED] wrote:
It'd also be handy to have goals that display/update dependency versions
too.
Mark
2008/8/14 Stephen Connolly [EMAIL PROTECTED]:
I was thinking of a display-plugin-updates and a update-plugins monos
Sent from
, 2008 at 9:50 AM, Mark Hobson [EMAIL PROTECTED] wrote:
It'd also be handy to have goals that display/update dependency versions
too.
Mark
2008/8/14 Stephen Connolly [EMAIL PROTECTED]:
I was thinking of a display-plugin-updates and a update-plugins monos
Sent from my iPod
On 14 Aug
:
Looks good. You may want to consider merging this plugin with this
proposed one:
http://jira.codehaus.org/browse/MOJO-928
Mark
2008/8/15 Stephen Connolly [EMAIL PROTECTED]:
Jusrt checking in the display-plugin-updates mojo to the versions plugin.
The apply-plugin-updates is a bit tricker
]
On Fri, Aug 15, 2008 at 10:03 AM, Mark Hobson [EMAIL PROTECTED] wrote:
2008/8/15 Stephen Connolly [EMAIL PROTECTED]:
I have plans for that too!!!
I want one goal that looks at all the projects in the reactor and ensures
they are all using the same versions
want this. What is the schedule for the first release?
S.
On Fri, Aug 15, 2008 at 10:52 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
Jusrt checking in the display-plugin-updates mojo to the versions plugin.
The apply-plugin-updates is a bit tricker as we have to find
:52 AM, Stephen Connolly
[EMAIL PROTECTED] wrote:
Jusrt checking in the display-plugin-updates mojo to the versions plugin.
The apply-plugin-updates is a bit tricker as we have to find the
pluginManagement sections if necessary
The display-plugin-updates goal will check all the plugins
, now we're bordering on infringing the dependency plugin ;)
Mark
2008/8/15 Stephen Connolly [EMAIL PROTECTED]:
display-dependency-updates goal now added
The display-dependency-updates goal will check all the dependencies used
in
your project and display a list of those dependencies
+0 if 1.1.1 will be in 3/4 weeks
-1 if 1.1.1 will be ages away as I suspect the accirev code will not
work and I cannot test it until 1st Sept when I return from vacation
Sent from my iPod
On 24 Aug 2008, at 09:58, nicolas de loof [EMAIL PROTECTED] wrote:
+1
2008/8/23 Olivier Lamy [EMAIL
if there is a 1.1.1 in the next 3-4 weeks, I'm +0
if it will be longer then -1 as the accurev stuff probably does not
work unless you've done some major trickery
the issue is that you cannot check in changes unless you use a
workspace, and you cannot nest workspaces so unless the release
cross posting to maven dev list
oh and in case anyone has any doubts, I'm +1 ;-)
Sent from my iPod
On 28 Aug 2008, at 12:03, Stephen Connolly [EMAIL PROTECTED]
wrote:
Hi Everyone,
The versions-maven-plugin is currently in the *sandbox*.
This is the first step for a future 1.0.0-alpha-1
I've had a look at that code, and I think it is doing something other than
what is required here!
As I see it, the display-plugin-updates goal should tell you of an update
that is relevant to the *current pom only*.
So if my parent pom specifies a version... then even if there is a newer
version
from my reading of the rules for sandbox plugins, I'm not allowed to
push them to a repo... hence looking to release from the sandbox
in answer to your question,
if you have aggregation separated from inheritance: yes
if aggregation is combined with inheritance: yes if the mavenvreactor
does it alter cr+lf pairs?
does it change formatting of attributes within tags (eg custom
enforcer rules)?
Sent from my iPod
On 29 Aug 2008, at 15:21, Ralph Goers [EMAIL PROTECTED]
wrote:
Yes. The original pom.xml is used and only the artifactId, groupId,
version or parent version
can we hurry up and make a decision?
call a vote with the two options:
1. make 2.1.x be the replacement for 2.0.10... we're making no
promises that there'll be a 2.0.10... the new features will now be in
2.2.x
2. spin a 2.1.0-m1 to get the 2.0.10-tc stuff out there and push for
2.1.0 in
1 - 100 of 2701 matches
Mail list logo
