they'll do in practice is just change
it and force it over the current version or worse avoid making changes that
really should be done b/c it's too much hassle.
--
Michael McCallum
Enterprise Engineer
mailto:gho...@apache.org
different artifacts that use older versions and maven will tell you that
you cannot package those two projects together.
~Michael
--
Michael McCallum
Enterprise Engineer
mailto:gho...@apache.org
-
To unsubscribe, e-mail: dev
and makes sense... and why not use
natural numbering
anyway its more elegant... get rid of this odd development termininology of 0
versions.
my 2c
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe
On Mon, 17 Nov 2008 00:43:03 Dave Syer wrote:
Michael McCallum-3 wrote:
just start at 2.1 and everything just works and makes sense...
Sorry, not to me, and not to anyone I know who uses version ranges. The
works or make sense ;-)
OSGi version conventions always used to annoy me
there.
I have the same feeling.
Daniel
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
should error on such property names -- or at
least be configured to have forbidden names.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
-ArtifactVersionsspecialtreatment
I'm confused... you are distriguishing between local and remote repositories
when you've just abstracted the concept into a virtual reader... why?
Why would you scan directories rather than read the metadata is that to
support other tools that just dump jars?
--
Michael
aka releases
there is just no easy way to do it...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
of remote repos thats a design flaw...
the local repo should be treated like all others...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
in the pom... thats just a bit too chicken and egg...
I define all my repositories in settings.xml
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Please comment if this does not sound natural or breaks some
well-established usage patterns.
Thanks,
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael
/index.html
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
in
case enforce it with a tool
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote:
Michael McCallum wrote:
To be well rounded we should consider other approaches to dependencies
its worth having a look at how gentoo does versioning with ranges and
slots... http://www.gentoo.org/
http://devmanual.gentoo.org/general
and that is exactly why i use ranges...
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
don't care what gas i put in my car it should just work...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Tue, 05 Aug 2008 19:28:47 Aaron Digulla wrote:
I mean, there was *no* XML parser which can do 100%
round-tripping before DecentXML. It's just a non-issue for the XML guys.
xom using xerces 2.6.7 was supposed to be able to do a complete round trip,
have you disproved that?
--
Michael
, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
McCallum
Development Lead
somedomain Ltd
cell: 021.576.907
msn: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
aim: gholamses
http://www.somedomain.co.nz
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe
On Thu, 24 Jul 2008 15:10:40 Michael McCallum wrote:
I'm getting stack traces rather than the nice message when an artifact does
not exist the repository...
For regular maven user you could almost get away with this... but for newbies
its will give them the willies and drive them away getting
to limit things.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
that we have going on now... we should be able to stably
release things in faster small increments without breaking things... except
when we want to.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe
...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
figured i should pull my finger out and patch something rather than
just talking all the time, jon would be proud
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
On Sat, 12 Jul 2008 09:10:03 John Casey wrote:
I think if we're going to try to take a hard line on maintaining a
public API, then we need to define that API in a separate artifact
that we can place strict limits on.
thats a great idea
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL
work for people? Maybe locking on windows
actually make a positive impact finally?
Thoughts anyone?
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
On Mon, 23 Jun 2008 14:26:38 Michael McCallum wrote:
have a meeting will explain in more detail later...
have not forgotten just been really busy and want to give this a proper
treatment...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
in the broken project...
i don't think that you can ever make a generic solution to this problem you
always need a flexible solution close to home, because ultimately you need to
manage when and where things change if you ever hope to produce stable
software in a timely fashion.
--
Michael
consistency
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
of project i.e. webapp, assembly, model, service etc otherwise you get heaps
of projects with duplicated plugin configs and its hard to manage
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e
seconds
[INFO] Finished at: Thu Jun 05 16:10:09 CEST 2008
[INFO] Final Memory: 9M/16M
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise
strategies that all fail in different
ways.
jw
On Wed, May 21, 2008 at 7:11 PM, Brett Porter [EMAIL PROTECTED] wrote:
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
components I think we can cover most of the bases
without the need for pluggable. If anyone really really needs pluggable they
can ship there own maven patch internally there is no need to make it too
easy.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
/
./cglib/cglib/2.1_3/
./cglib/cglib/rc2-1.0/
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
the
following...
[a-zA-Z]* [0-9]*
You could also then say
!alpha
!beta
!arbitrary
!1
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
, rc and SNAPSHOT always with - prefixes in the repository.
p.s. the three emails were intentional
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
state into the svn tag for the
released parent pom which in my view creates unnecessary confusion
for anyone trying to understand what's going on in svn.
Big fan of this... aggregation != inheritance
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
I found that one of my dependencies bundles some source in the jar... the
compiler plugin compiles it and it ends up in my artifact. Has anyone see
this before?
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
the PMC lay down the intended direction? I'm not
sure whether this thread needs to get any longer.. :)
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
thumbs up for views like dependency:tree etc that make the pom human
readable... which i think is most of the problem...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
2008 13:17:09 Martijn Dashorst wrote:
On 2/12/08, Michael McCallum [EMAIL PROTECTED] wrote:
You can change the tool to make a bad pom look good but at the end of the
day
there is something wrong if your declared dependency list looks like
that...
How come? To get reproducible builds, you
-type=text%2Fplainview=co
http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplainview=co
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
the intended direction? I'm not
sure whether this thread needs to get any longer.. :)
open to a vote
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
flexible
compromise.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- and chances are no recent backups.
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
Hobson wrote:
Hi Michael,
On 23/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
Firstly IMHO of MNG-3092 is that is it not the right thing for maven in
general.
I believe with MNG-2994 and appropriate use of profiles to enable and
disable snapshot repositories you can have
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 arrives and bang! you are scuppered
On Jan 23, 2008 7:31 PM, Michael McCallum [EMAIL PROTECTED] wrote:
BTW if you want to _not_
concerned that MNG-3092 is a one way street where better more flexible
solutions could exist. But having said that if you did fix 3092 it would not
adversely affect me right now. And if it does... well I'll figure something
out.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
comment on the status of MNG-3351? We are at a blocking point
now where we cannot build anymore with maven.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
release
with the MSHADE-9 fix in it.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
against the latest releases of all projects
what more do you need?
On Tue, 15 Jan 2008 06:41:42 Mark Hobson wrote:
On 10/01/2008, Michael McCallum [EMAIL PROTECTED] wrote:
another thought...
by default you could not have snapshot repositories enabled and just
enable them with a profile
On Tue, 15 Jan 2008 08:43:38 Michael McCallum wrote:
It's crazy that version ranges are still unusable in 2.0.8..
* we can mix and match snapshots during development if we need to
would not appear to work, i could swear i had this working in the last year...
oh well, i can see how that would
start a vote for this issue here I guess the same rules as releases
would apply. 72 hours only pmc votes are binding. etc etc
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
a profile to enable if you want to pick up the snapshot plugin
repo for testing...
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
can use profiles and
separate repositories to force it if you really want to
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
plugin when defined in
ranges, it would appear to work on the defined not resolved dependencies...
you have to use the enforcer plugin which works on the resolved tree.
cheers
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
release because snapshots are not filtered out.
the enforcer plugin definitely fixes this and the generateReleasePoms=true
ensures that the build from tag uses the same clean deps as when tagging
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
IMHO, I think our approach excels in making sure this doesn't happen.
First and foremost, if this version range issue can be fixed, snapshots
will never be considered valid unless explicitly asked for. Therefore
snapshot deploys
saying is that I will accept any RELEASED version from 1.0 (inclusive) to
2.0 (exclusive). I am not saying I want any SNAPSHOTS to be allowed. The
only time a SNAPSHOT should be allowed is when it is specified by an
inclusive version range boundary.
Michael McCallum-3 wrote:
you can specify
line. You run
the risk of breaking builds otherwise.
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
Bentmann
i second that
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
?
I could give a first version of the source code modification if the idea is
correct.
Thanks.
Cyril
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
69 matches
Mail list logo
