On Wed, 2008-02-27 at 12:51 +0100, Fabian Christ wrote:
> The problem with the pattern groupId="org.apache.maven.archiva" artifactId= are the missing line
> breaks and spaces. Your can't find the information of interest in such
> a string. So people will start adding line breaks and you get near
Hi there,
I read through this discussion as a Maven user and (sometimes) plugin
developer and also like the idea of more readable POMs. But I also
agree with Jörg's opinion:
> +1 for more readable POMs
>
> I personally like the idea of the attributes because it makes
> it a lot easier to write
I think there could be one not yet discussed drawback of attribute
based pom content.
Most (or all?) xml parsers will not keep track of spacing between
attributes, so any tool that writes the pom (release plugin?) might
mess up formatting..
Disclaimer: I haven't actually checked..
Milos
On Mon,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
just to give my feedback on the thread:
+1 for NOT overloading 2.1
When it is about further versions and long term future of maven:
- -infinity for
artifact="org.apache.maven:maven-project:2.0.8"
How do you want to express versions range
I don't buy into the objection that simplifying the POM is "too late". If
there is not a 4.1, there will be a 5.0. Eventually the POM will change --
if it doesn't happen with attributes, it will be for another reason. The
schema dictates what is valid/invalid. If people want verbosity, let them
con
On 13/02/2008, at 7:15 PM, Mark Struberg wrote:
Does the refactoring of the XML give us any new functionality
besides only 'looking better'?
No, but it seems that's reason enough :) The technical underpinnings
do give the value of being able to add things to the model now,
however, and s
r people
> building out tool support, if someone wanted to do something like
> create a binary format, there's nothing stopping them.
>
>
> > -john
> >
> > On Feb 12, 2008, at 10:55 AM, Tim O'Brien wrote:
> >
> >>
> >> On Feb 12, 2008, at 9:34 A
>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
To: Maven Developers List
Subject: Re: An Attribute Based POM
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:
come later. If we continue to stuff new
> things into 2.1 then it will probably never see the light of day.
>
> -Original Message-
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 12, 2008 8:31 AM
> To: Maven Developers List
> Subject: Re: An Attribu
obably never see the light of day.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 12, 2008 8:31 AM
To: Maven Developers List
Subject: Re: An Attribute Based POM
FWIW, I think as long as we have a standard format for POMs on a
single remote repository
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
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
esday, February 12, 2008 8:31 AM
To: Maven Developers List
Subject: Re: An Attribute Based POM
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 rea
.1 then it will probably never see the
light of day.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 12, 2008 8:31 AM
To: Maven Developers List
Subject: Re: An Attribute Based POM
FWIW, I think as long as we have a standard format for POMs on a
single re
essage-
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/version into one
attribute
like this
n
On Feb 12, 2008, at 10:55 AM, Tim O'Brien wrote:
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
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
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 ex
>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 e
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
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
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
If I ever need an xml diver ill give you a ring :-P
But most folks I know don't care to swim in xml... They'd drownd...
--jason
-Original Message-
From: "Don Brown" <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:01:43
To:"Maven Developers List"
b 2008 16:51:07
To:"Maven Developers List"
Subject: Re: An Attribute Based POM
Are you saying that if you are looking forward to dealing with more
verbosity, you should interview at Atlassian? :)
On 12/02/2008, at 4:47 PM, Don Brown wrote:
> Atlassian is hiring ... :)
>
> On 2/
more verbose... So all us
> >> maven folk can keep our jobbies :-P
> >>
> >> --jason
> >>
> >>
> >> -Original Message-
> >> From: Brett Porter <[EMAIL PROTECTED]>
> >>
> >> Date: Tue, 12 Feb 2008 16:35:35
&g
n more verbose... So all us
maven folk can keep our jobbies :-P
--jason
-Original Message-
From: Brett Porter <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:35:35
To:"Maven Developers List"
Subject: Re: An Attribute Based POM
Yes, I happen to agree with the theory Shane
PROTECTED]>
>
> Date: Tue, 12 Feb 2008 16:35:35
> To:"Maven Developers List"
> Subject: Re: An Attribute Based POM
>
>
> Yes, I happen to agree with the theory Shane and Jason outlined and is
> why I accepted the status quo for 5 years :) But I always thought th
IMO we should strive to make the pom even more verbose... So all us maven folk
can keep our jobbies :-P
--jason
-Original Message-
From: Brett Porter <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:35:35
To:"Maven Developers List"
Subject: Re: An Attribute Based POM
Yes, I happen to agree with the theory Shane and Jason outlined and is
why I accepted the status quo for 5 years :) But I always thought the
Maven dependencies tag in Ant looked better and was easier to read. I
think the expanded format makes more sense for machine-generated and -
read docum
Whether an attribute-based design is "proper" is a less important
question than what makes Maven more usable. Form should follow
function. What users care about is more readable POMs, less typing,
and less clutter. I've been really impressed with the Maven team
adopting a more programmatic appro
On 11-Feb-08, at 8:48 PM, Shane Isbell wrote:
I know that it is not always clear when to use and attribute and
when to use
an element; but typically, attributes are used to attach metadata or
nonessential information about an element, while subelements are
essential
parts of the parent elem
I know that it is not always clear when to use and attribute and when to use
an element; but typically, attributes are used to attach metadata or
nonessential information about an element, while subelements are essential
parts of the parent element. To me, the groupId, artifactId and version
would
sure but each project should not do that and using standard OO principles i
can encapsulate it in reusable artifacts
i average 5 deps per artifact and have (9 different) assemblies that result in
about 84 jars each, with no dependency management sections and i have
reproducible builds
by facto
Well I'm actually thinking that we just make the change to allow
optional version for artifacts in the reactor, chopping the whole
section :)
- Brett
On 12/02/2008, at 2:21 PM, Ralph Goers wrote:
Actually, there wasn't a single dependency in that pom. Those were
all managed dependency dec
Actually, there wasn't a single dependency in that pom. Those were all
managed dependency declarations. I'm not surprised to see something like
that, however it would really be better if it was:
artifactId="bill-of-materials" version="1.1-SNAPSHOT" type="pom"/>
instead of
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 need to specify the versions of
a
IMO
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...
> Here are two different files for comparison (it halved the size):
>
http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-t
On 12/02/2008, at 3:33 AM, Jason van Zyl wrote:
Sure, I think it's important not to conflate additions to the simple
maneuver to attributes.
Agreed - what Niall proposed was in the scope of simplifying the
current POM, but adding new features like excludeAll is not.
Also just looking
Sure, I think it's important not to conflate additions to the simple
maneuver to attributes.
Also just looking over the the thread, I don't think dependencyGroups
are necessary as I think many people, from my experience, expect a
dependency on a POM to yield the same result even though it d
I am very much for allowing simple types to be attribute-based. I think that
alone is worth the addition to Maven 2.1.
Paul
I think we might be deviating from the normal pom a bit much here unless
you plan to support this in the regular pom processing also.
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 4:40 AM
To: Maven Developers List
Subject: Re: An Attribute
On Feb 11, 2008 1:23 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> I'm collecting these up to put back into the wiki later on
Please, add also:
or something similar.
> though
> this initial attempt is intended not to change the model just yet
> (though it's very feasible with the current
I think this would be better served by just having dependencyGroup,
and inheriting something from that, and allowing them to be nested.
...
I think the second use case across versions is uncommon and makes it
harder to read.
I'm collecting these up to put back into the w
Also what about a
On Feb 11, 2008 11:40 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On F
On Feb 11, 2008 6:45 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> 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
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
m
Why not further steps towards terseness?
1. Get rid of collection container elements.
Why this:
descriptor
When this wold suffice:
descriptor
This seems like a trivial issue, but when you look at all of the
container elements, dependencies, plugins, exclusio
57 matches
Mail list logo
