FYI, I know that in the past Resin supported both Elements and attributes in
it's config XML. It was really neat. If you preferred one over the other, you
could use it. Don't know if it is still that way though.
Jason
From: Jason Chaffee [jason.chaf...
I like the idea of having some things as attributes.
See the following links on information on when to use attributes and when to
use elements.
http://www.ibm.com/developerworks/xml/library/x-eleatt.html
http://nedbatchelder.com/blog/200412/elements_vs_attributes.html
http://www.x12.org/x12org/c
Or even just artifacts in compressed form
equates to:
guice
com.google
1.3
implies (after short resolution>
maven-compiler-plugin
1.2
Christian.
On Sep 4, 2009, at 6:05 PM, Paul Benedict wrote:
Yes, the XML is verbose, and tooling helps but I think most people
write it
Yes, the XML is verbose, and tooling helps but I think most people write it
by hand. The only evolutionary change I support is the ability to specify
simple nested elements as attributes.
Paul
On Fri, Sep 4, 2009 at 4:40 PM, Jason Chaffee wrote:
> For what it is worth, I have heard many complain
For what it is worth, I have heard many complaints either about using XML
and/or about the current structure of the XML as well. I have heard this from
developers I have worked with and I have read some blogs about this too. I
can't tell you where those blogs are now because I pretty much dis
Who said anything about a reasonable person? :) I don't have such a
hatred - I'm quite used to it, but it has come up in nearly every
client in the last 3 years - not as a final or deal-breaking barrier
to adoption, but a barrier nonetheless.
I'm happy to support it - I just need a seam or
On 2009-09-04, at 10:59 PM, Christian Edward Gruber wrote:
So I agree that it is a valid concern, and there needs to be a
canonical format (which will probably be XML) which all artifacts
are saved as - but in my source tree, it should be entirely possible
to have an alternate way to speci
So I agree that it is a valid concern, and there needs to be a
canonical format (which will probably be XML) which all artifacts are
saved as - but in my source tree, it should be entirely possible to
have an alternate way to specify, since often I've found that XML-
hatred is a barrier to M
Hi
I had the same problem in with the NAR plugin at the time. No way to
make those SNAPSHOTS
work if you deploy multi-platform artifacts with classifiers. I hope
this can be fixed in 3.0 as
there did not seem a way out in 2.x for NAR to handle it correctly.
Regards
Mark Donszelmann
On Sep
On Fri, Sep 4, 2009 at 4:36 PM, Jason van Zyl wrote:
> Why not just incorporate the full coordinate in the metadata. This is also a
> problem for finding attached artifacts like javadocs and sources. There is
> no record of them in the metadata. If we had a complete catalog of the the
> artifacts d
Why not just incorporate the full coordinate in the metadata. This is
also a problem for finding attached artifacts like javadocs and
sources. There is no record of them in the metadata. If we had a
complete catalog of the the artifacts deployed and not just for the
primary this would not b
> Just my 2 cents as a Maven evangelist in a big private company. Even if
> Maven is around for years now, basic endusers just start to get
> accustomed to pom.xml and Maven philosophy (really! people are far slowest to
> change than in OpenSource project team).
>
> Please, please don't mess every
On Fri, Sep 4, 2009 at 4:06 PM, Jason van Zyl wrote:
> I think it can be in the same vein as the no versions for plugins. Not a
> very good idea and potentially harmful.
>
> We put it in, deprecate it over 3.0 and it becomes taboo in 3.1. If it's a
> bad practice in the majority of cases then we el
I would prefer to deprecate them in 2.x and definitively remove them
in 3.x. It seems more logical.
Arnaud
On Friday, September 4, 2009, Jason van Zyl wrote:
> I think it can be in the same vein as the no versions for plugins. Not a very
> good idea and potentially harmful.
>
> We put it in, de
I think it can be in the same vein as the no versions for plugins. Not
a very good idea and potentially harmful.
We put it in, deprecate it over 3.0 and it becomes taboo in 3.1. If
it's a bad practice in the majority of cases then we eliminate it.
Over the life of 3.0 to 3.1 should be long
Hi,
> De : Jason van Zyl
> [...]
> Personally, I don't see a different XML format being any great usability
> gain.
> With editors and IDEs it's not that bad and you also have to consider what
> people are already accustom to. I honestly think another XML format would
> just
> be confusing
Not going to happen during 3.0. The facility is there the
ramifications of changing the format have not been dealt with. I see
the mechanism being battle tested with a Groovy or Ruby based system
that embeds Maven and uses a custom POM format. It is not going to be
a simple matter of just u
I've used classifiers before, though I think it's a bit of a hack.
There's also the native plugin which makes .nar archives - you should
look and see what it does, since it is geared for native c/c++ builds
(I believe)
Christian.
On Sep 4, 2009, at 10:58 AM, Brian Fox wrote:
I was rece
Hi all,
So I saw Jason's highlights of 3.x future plans, and decoupling
POMs from format. We're starting to use m3 on an open-source little
project at Google, and the main problem people have with Maven has
been the gawd-awful (not my words) of the xml format. I used the
maven-yamlp
These questions belong on the user list. If you asked there, I'll answer it ;-)
On Wed, Sep 2, 2009 at 4:26 PM, Arul Anand S P wrote:
> hi all,
>
> I am having a property named test.version in parent pom.xml
>
>
> 8
>
>
> and I have a the below entry in child pomT.xml
>
>
>
I ran to the same thing and ended up to turn off timestamp snapshot
-D
On Fri, Sep 4, 2009 at 8:04 AM, Christian Edward
Gruber wrote:
> I've used classifiers before, though I think it's a bit of a hack. There's
> also the native plugin which makes .nar archives - you should look and see
> what
On Fri, Sep 4, 2009 at 11:12 AM, Stephen
Connolly wrote:
> In fact we rarely deploy -SNAPSHOTs at all... the only time we have deployed
> -SNAPSHOT builds is when SV have a complex test scenario and we need to
> check the fix before we roll a big suite release
>
The normal best practice is to have
True - I missed that part. We used -SNAPSHOT only for volatile
versions, but if we wanted to lock in on a specific snapshot, we'd
roll a milestone or nightly build. In fact, one client just rolled a
nightly release and stamped it 1.2.3-NIGHTLY-20070325 (or so). But
this is a real release,
In fact we rarely deploy -SNAPSHOTs at all... the only time we have deployed
-SNAPSHOT builds is when SV have a complex test scenario and we need to
check the fix before we roll a big suite release
2009/9/4 Stephen Connolly
> I find that we have given up on unique snapshots
>
> we just use n
I find that we have given up on unique snapshots
we just use non-unique all the time.
if you need a unique snapshot, just roll a release, e.g. 1.0-milestone-1
-Stephen
2009/9/4 Brian Fox
> I was recently working with a customer to move them off of using
> non-unique snapshots for various
I was recently working with a customer to move them off of using
non-unique snapshots for various reasons. In the process we discovered
a problem with snapshots, classifiers and multi-platform builds.
In this scenario, we have a project that is built on multiple
platforms, say windows, solaris and
I'm game... is this the formal vote?
2009/9/4 Arnaud HERITIER
> +1 to propose you to join us as committer :-)
> Arnaud
>
> On Fri, Sep 4, 2009 at 3:08 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > +1 for Arnaud being leader
> >
> > 2009/9/4 Arnaud HERITIER
> >
> > > A l
Hi,
As I can see Benjamin has started to add it for site plugin 3.x
compatible version in mojo.
If some could do the same ?
I have started to add few notes regarding the site plugin [1].
Thanks,
--
Olivier
[1] http://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plugin
2009/9/3 Be
I saw this on Benjamin's compat page yesterday and thought I'd throw
it up for discussion:
Non-unique Snapshot Deployments
The setting false for a distribution
repository has no effect in version 3.x, snapshot artifacts will
always be deployed using a timestamped version.
I personally am not a fa
+1
-Original Message-
From: Arnaud HERITIER [mailto:aherit...@gmail.com]
Sent: Friday, September 04, 2009 8:20 AM
To: Maven Developers List
Subject: Re: What's block maven-toolchains-plugin getting *any* release at
all?
+1 to propose you to join us as committer :-)
Arnaud
On Fri, Sep 4,
+1 to propose you to join us as committer :-)
Arnaud
On Fri, Sep 4, 2009 at 3:08 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> +1 for Arnaud being leader
>
> 2009/9/4 Arnaud HERITIER
>
> > A leader ?
> >
> > On Fri, Sep 4, 2009 at 10:32 AM, Stephen Connolly <
> > stephen.alan.
+1 for Arnaud being leader
2009/9/4 Arnaud HERITIER
> A leader ?
>
> On Fri, Sep 4, 2009 at 10:32 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Any king of release whatsoever... as long as it's not -SNAPSHOT
> >
> > -Stephen
> >
>
A leader ?
On Fri, Sep 4, 2009 at 10:32 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Any king of release whatsoever... as long as it's not -SNAPSHOT
>
> -Stephen
>
I committed the new page and updated the home page as well. See r811294.
The changes will be visible the next time the site will be generated.
Cheers,
- Fabrice
belling...@apache.org
On Thu, Sep 3, 2009 at 9:49 PM, Arnaud HERITIER <
arnaud.herit...@exoplatform.com> wrote:
> +1
> it's a reall
Any king of release whatsoever... as long as it's not -SNAPSHOT
-Stephen
35 matches
Mail list logo
