Does the refactoring of the XML give us any new functionality besides only 'looking better'? And what is the price we pay? Getting non-compatible with existing poms? Someone already mentioned the forward compatibility once 'new' poms get their way into the repos. There are still many companies working with mvn 2.0.4 and lower, which will need the old poms in the public repos. Do we need own public repos then? If so, this would be more the kind of maven-3.0 then.
And for the guys calling for more 'textual' poms: back to make? With all the human readable but highly ambiguous syntax. I personally think this is not a good idea at all. Altough I agree that the attributes would have been better if we got them in 4.0.0 format, i also admit that it's imho simply too late. LieGrü, strub --- Tim O'Brien <[EMAIL PROTECTED]> schrieb: > On Feb 12, 2008, at 10:30 AM, John Casey wrote: > > > 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 read, but it was > > always intended to be rendered in some way. If we had rendering > > tools to give the user a decent view on the POM, all of these > > arguments would go away, since we could just provide additional > > renderers along with the different parsers. > > > > Also, if we're going to accommodate multiple XML formats (element- > > oriented vs. attribute-oriented) would it make more sense to give a > > hint of which format we're using via processing instruction at the > > top or something similar? If we do this, there could be 2 XML-based > > parsers, or 2000...as long as the shared data in the remote > > repository has a standard format, what's the difference? We can > > control the standard format on the central repository, for one > > thing, and definitely make sure it's as consumable as possible for > > older Maven versions. Others running their own internal repositories > > will have their own concerns WRT POM format, and can set their > > internal policy as they see fit. > > > > Open it up to all formats, but make sure that people know that if they > decide to use a YAML format, they are on there own. Provide easy > tools that allow someone to convert back to the "blessed" format. > > I'll stop picking fights about this, but I understand people's > preference to keep a strict standard. I'm all for it, but I also > think that if someone comes along with the "reduced text-format", > there should be a way for them to plug in a parser or a pre- > processor. Even though it might make it more difficult for 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 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 example, we'd can group groupId/artifactId/version into one > >>>>>> attribute > >>>>>> like this: > >>>>>> > >>>>>> <dependency artifact="org.apache.maven:maven-project: > >>>>>> 2.0.8" [...] /> > >>>>> > >>>>> 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 with the > >>>>> POM > >>>>> will > >>>>> also appreciate a proper/pure XML representation of the project > >>>>> model. > >>>>> Consider for instance the pain such string aggregates would cause > >>>>> for XSLT > >>>>> processing of the POM. Merging different pieces of data into a > >>>>> single string > >>>>> is in general a bad idea. > >>>> > >>>> > >>>> Couldn't disagree more. Certain data has a native format. > >>>> Consider > >>>> something like a 24 hour time. Is: > >>>> > >>>> <time>23:22:22.003</time> > >>>> > >>>> an "undue burden" on different parsers? No, this is reasonable. > >>>> This would be unreasonable: > >>>> > >>>> <time hour="23" minute="22" second="22" millis="003"/> > >>>> > >>>> The idea that we have to design data around parsers means that you > >>>> sacrifice usability and readability. > >>>> > >>>> I'd take it one step further than Emmanuel: > >>>> > >>>> <dependencyGroup root="org.apache.maven"> > >>>> <dependency artifact="maven-project:2.0.8"/> > >>>> <dependency artifact="continuum:continuum-model:1.1"/> > >>>> </dependencyGroup> > >>>> > >>>> Should be: > >>>> > >>>> <dependGroup root="org.apache.maven"> > >>>> maven-project:2.0.8 > >>>> continuum:continuum-model:1.1 > >>>> </dependGroup> > >>>> > >>>> XSLT can tokenize strings just fine. > >>>> > >>> > >>> > >>> Than why to use XML? Why not have simple text? > >> > >> Giles, why not simple text? People have already been working with > >> POMs in alternative formats that don't involve XML at all. I > >> guess the real question here is, why would it disturb people so > >> much if someone had an alternative format for a POM for every day > >> use, but when they published to a repo it used the standard format. > >> > >>> > >>> > >>> No seriously, keep the organisation and artefact separated from > >>> the version. There are plenty of use case that needs to > >>> identify them separately (like the management of the conflict, the > >>> management of the dependent projects). > >>> > >>> If you really want something more textual, I suggest you look at > >>> buildr. It give you something like this : > >>> > >>> AXIOM = group("axiom-api", "axiom-impl", "axiom-dom", > >>> :under=>"org.apache.ws.commons.axiom", version=>"1.2.4") > >>> AXIS2 = "org.apache.axis2:axis2:jar:1.2" > >>> OPENJPA = ["org.apache.openjpa:openjpa-all:jar:0.9.7", > >>> "net.sourceforge.serp:serp:jar:1.12.0"] > >>> AXIS_OF_WS = [AXIS2, AXIOM] > >>> > >>> compile.with OPENJPA, AXIS_OF_WS > >>> > >>> > >>> Why not? It might be user friendly (for some users...). But I > >>> don't want to see this in a repository. IMO, XML is > >>> much better. > >>> > >> > >> No one is talking about modifying the repository, the repository > >> should contain one format of POM, but there is no reason why there > >> cannot be a diversity of implementations. Oh wait, people here > >> think it would screw up "Universal Understanding". > >> > >> :-) > >> > >>> > >>> Gilles > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >> > > > > --- > > John Casey > > Committer and PMC Member, Apache Maven > > mail: jdcasey at commonjava dot org > > blog: http://www.ejlife.net/blogs/john > > rss: http://feeds.feedburner.com/ejlife/john > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __________________________________ Ihre erste Baustelle? Wissenswertes für Bastler und Hobby Handwerker. www.yahoo.de/clever --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
