Re: maven is a swamp

[Graham Leggett]

On 20 Oct 2010, at 1:17 PM, Martin Gainty wrote:

IDEs from my experience are tools to create (workspace) environments  
and to create xml scripts  to compile, package and deploy  
wars and ears
the useful life of an IDE passes when the webapp is promoted to  
production and the op implements the goals in the pom.xml to deploy  
to appserver


What you're describing sounds monolithic.

Any great big monolithic application is going to be painful to manage,  
and maven won't be able to help you if you try have one pom file to  
rule them all.


Break your projects into bits, and then assemble the bits at the end  
in a separate project. Then in a separate project again, configure the  
magic install behaviour that you want.


When your project is made of many bits, you want to be able to repeat  
your build - maven steps in and ensures that everything is pinned to  
the correct dependencies correctly. Maven only does this however if  
you've asked it to.


Regards,
Graham
--


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Ron Wheeler]

 On 20/10/2010 7:17 AM, Martin Gainty wrote:

IDEs from my experience are tools to create (workspace) environments and to create 
xml scripts  to compile, package and deploy wars and ears
the useful life of an IDE passes when the webapp is promoted to production and 
the op implements the goals in the pom.xml to deploy to appserver


Get the ANT out of your workflow if you want a happy life.

Pick one or the other. Both are good tools.
ANT is a great tool on its own but when it comes in contact with Maven 
workflow, the combination can produce toxic or explosive byproducts.  :-)



If you need to edit a pom that late in your cycle and you do not want to 
edit XML, then you need to provide a GUI editor.

I am not sure why op is changing a POM file at that point in the cycle.
Sounds like a problem in the workflow or POM structure.
Could they not just invoke a Maven deploy with their settings.xml file 
or Maven arguments set up to do the deployment with the unedited POM?


Perhaps I am missing something but I am not comfortable with op 
modifying a tested and approved application - not the Java, not the 
scripts and certainly not the POM.


Ron


Martin Gainty
__
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und 
Vertraulichkeitanmerkung/Note de déni et de confidentialité
  Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.





Date: Tue, 19 Oct 2010 15:03:28 -0400
Subject: Re: maven is a swamp
From: rick.ma...@mtvn.com
To: users@maven.apache.org

I think that's the main point. Nobody thinks XML is wonderful to read or
write, but it's easily read by any tools, languages and by humans. XML is a
standard, like it or not. It's a glue. Glue is good. Glue lets the logic be
language neutral and portable.


On 10/15/10 6:40 PM, "Ron Wheeler"  wrote:


   Who cares what language Maven uses?
There are IDEs with editors that eliminate the need to look at XML.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: maven is a swamp

[Martin Gainty]

IDEs from my experience are tools to create (workspace) environments and to 
create xml scripts  to compile, package and deploy wars and ears
the useful life of an IDE passes when the webapp is promoted to production and 
the op implements the goals in the pom.xml to deploy to appserver

Martin Gainty 
__ 
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und 
Vertraulichkeitanmerkung/Note de déni et de confidentialité
 Ez az
üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




> Date: Tue, 19 Oct 2010 15:03:28 -0400
> Subject: Re: maven is a swamp
> From: rick.ma...@mtvn.com
> To: users@maven.apache.org
> 
> I think that's the main point. Nobody thinks XML is wonderful to read or
> write, but it's easily read by any tools, languages and by humans. XML is a
> standard, like it or not. It's a glue. Glue is good. Glue lets the logic be
> language neutral and portable.
> 
> 
> On 10/15/10 6:40 PM, "Ron Wheeler"  wrote:
> 
> > 
> >   Who cares what language Maven uses?
> > There are IDEs with editors that eliminate the need to look at XML.
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
  

Re: maven is a swamp

[Rick Mangi]

I think that's the main point. Nobody thinks XML is wonderful to read or
write, but it's easily read by any tools, languages and by humans. XML is a
standard, like it or not. It's a glue. Glue is good. Glue lets the logic be
language neutral and portable.


On 10/15/10 6:40 PM, "Ron Wheeler"  wrote:

> 
>   Who cares what language Maven uses?
> There are IDEs with editors that eliminate the need to look at XML.
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Jochen Wiedmann]

On Thu, Oct 14, 2010 at 7:25 PM, Kenneth McDonald
 wrote:

> 1) Maven is declarative vs. procedural. This is great, but Prolog has been 
> that
> way for decades. Why build such a complex syntax when a much simpler one
> already existed.

That's comparing apples and peaches. Prolog is a general-purpose
language [1], whereas Maven is dedicated to a particular type of task.
Obviously, it's much more feasible to have a declarative approach for
the latter.

> 2) Relates to 1). I still think this is important. AFAIK, XML was NEVER 
> intended to
> be a syntax for direct editing by the user. It is needlessly verbose and 
> redundant,
> and seriously obscures the actual intent of the code. As the simplest possible
> example, what is the point in writing 
> false
> when what is really meant is the (IMHO) much easier to read someGenericOption 
> = false.

That's basically XML bashing. You might have problems with editing
XML, I don't. Apart from that, you are reducing what Maven gives you
to a syntactical discussion here, which doesn't make too much sense
for me. As other have rightfully pointed out, there are very
comfortable editors for Maven POM's, which easily hide the XML syntax.
XML is wonderful for building tools and editors.


[1] http://en.wikipedia.org/wiki/Prolog


> 3) Yes, I'm aware there is something called polyglot maven. (Haven't looked 
> at it yet, as
> I don't want to add yet another layer of complexity to what I'm doing.) 
> Doesn't the simple
> existence of this prove my point? There were never polyglot makefiles--in 
> spite of all
> of their (numerous) problems, the syntax of makefiles was simple enough there 
> was
> never a demand for them.

It proves the point that people like you are enjoying discussions
about syntax. :-)


> 4) Maybe I'm missing something, but maven seems to be all about predefined 
> maven
> tasks. (Not sure I'm using the right terminology). If there's something 
> simple I can do
> from the command line, maven doesn't provide an obvious way for me to do it.

You are obvoiusly missing the ability to create own Maven plugins.
Others are doing this, hence there are hundreds or even thousands. You
can choose between using and combining existing ones (which most of us
prefer) and writing your own.


> 5) Maven is just too complex. The comment I've seen is, "If users would just 
> read a
> book...", but what if I don't have the time to read an entire book simply to 
> figure out how
> to push my docs to github? With command-line access, I wouldn't need to do 
> so. And
> if the project got so big that an ad hoc solution didn't suffice, _then_ I 
> could come back
> and read the book.

I never needed a book to work with Maven. Books are for those who
*like* to have books. If you are one of them, good for you to *have*
them. If not, you neither need one.

Jochen



-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Ron Wheeler]

 Who cares what language Maven uses?
There are IDEs with editors that eliminate the need to look at XML.

If your favorite IDE makes you edit POM files by hand, take it up the 
IDE maker or get an IDE that makes your life better.


Stop complaining about a how the creators of Maven decided to persist 
the data.
To my way of thinking, it is a lot better than a binary blob and or a 
multi-level properties file.
In case I ever want to actually inspect a POM manually, I can. Even my 
text editor can spot errors while manually editing files and make 
suggestions about legal constructs.


The rest of the time i use the high level editor built into my free IDE.

I also structure my projects and workflow so that my POMs are small and 
simple and not a major part of my development team's concerns. They 
require minimal attention aside from version changes (30 seconds or less 
to prepare an artifact for a new release).



Ron



On 15/10/2010 4:58 PM, Thiessen, Todd (Todd) wrote:

Hehe. Wow.

That guy who gathered that data is the Maven founder. It IS his job to get a 
pulse of how Maven users feel about it.

For a guy that claims to have so much experience, you sure don't do your 
homework.


-Original Message-
From: Kenneth McDonald [mailto:kenneth.m.mcdon...@sbcglobal.net]
Sent: Friday, October 15, 2010 4:50 PM
To: Maven Users List
Subject: Re: maven is a swamp

Well, just to make it concrete, I am not a troll. I've been doing dev for
20+ years, have lots of
experience with large projects, etc. etc. If I have to drop names, I was
associated with one of
the two main sites of the Human Genome Project.

I still don't get the complacency at the XML swamp. How is
false

possibly better than

false

which would in turn be better than:

genericTagName = "false"

XML is a swamp of undertulized, overused redundancy. Period.

In response to the person who'd interrogated 2K+ people to see if they
thought
XML was overrdone;  Wow, that's really impressive! Where did you find the
time
to ask all those people and still get your your job done? Whereas, if I
ask the five
people who I know well, and who have to use these tools, the answer is,
"what
a bunch of garbage". They HATE XML.

Still not convinced? What about the simple fact of that that languages
before, and the
languages _since_ have not been written in a dialect of XML. If XML were
such a great
solution, surely it would have cleared here by now.

But of course it hasn't. The reasons is because it's a CRAPPY SOLUTION.
Period. No Line breaks.
Unless one is writing for ultimate display in the web, XML  SUCKS

In all the best to have all the people who have responded to this,
I don't see how you can continue maintain your position,
Yours,
Ken
On Oct 15, 2010, at 8:27 AM, Yanko, Curtis wrote:


+1



Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time

-Original Message-
From: Brian Smith [mailto:bmjsm...@gmail.com]
Sent: Friday, October 15, 2010 5:39 AM
To: Maven Users List
Subject: Re: maven is a swamp

I really fail at understanding the XML rage.  Yeah it's verbose.  How's
that a problem?  We've had tools with auto complete, auto format and
syntax highlighting for well over a decade, we also now have fairly
robust GUIs too.  If you're hand editing a 2000 line xml file in a

green

screen terminal you're doing the equivalent of using an abacus and I'm
afraid you're not the user new tools ought to be aimed at.

XML has a huge ubiquity value.  It might not be the *best* tool for the
job for each individual user but it's the only one that is widely

enough

understood to not put an additional learning burden on the user.  When

I

learned Maven I had to grok concepts like dependencyManagement and
plugins and phases.  I didn't have to learn XML, I already knew it.  If
Maven POMs were written in Python or A.N.Other language/markup I'd have
to learn that too.  There are many useful libraries that make it easier
to produce GUI tools on top of XML that don't exist for alternatives,

so

we'd have less tooling for POMs.  Tooling and minimising the learning
required are good things.

The _actual_ problem I see is the lack of "best practise" use for
plugins off the beaten track.  The documentation is usually fairly good
at telling you how to make a plugin do something, it's less than
brilliant at recommending best practises and unless it's one of the
mainstream ones covered by the sonatype book it's hard to find.  I've
found the best thing to do in those cases is go look at large, open
source projects and see how they do it.  Ken's original problem in this
thread (and the others he's been getting help with on the scala list)
are _nothing_ to do with XML, that is just the target of frustration.
They would have happene

Re: maven is a swamp

[Brian Smith]

On 15 October 2010 21:50, Kenneth McDonald  wrote:

> Well, just to make it concrete, I am not a troll. I've been doing dev for
> 20+ years, have lots of
> experience with large projects, etc. etc. If I have to drop names, I was
> associated with one of
> the two main sites of the Human Genome Project.
>
> I still don't get the complacency at the XML swamp. How is
> false
>
> possibly better than
>
> false
>
> which would in turn be better than:
>
> genericTagName = "false"
>
> XML is a swamp of undertulized, overused redundancy. Period.
>
> In response to the person who'd interrogated 2K+ people to see if they
> thought
> XML was overrdone;  Wow, that's really impressive! Where did you find the
> time
> to ask all those people and still get your your job done? Whereas, if I ask
> the five
> people who I know well, and who have to use these tools, the answer is,
> "what
> a bunch of garbage". They HATE XML.
>
> Still not convinced? What about the simple fact of that that languages
> before, and the
> languages _since_ have not been written in a dialect of XML. If XML were
> such a great
> solution, surely it would have cleared here by now.
>
> But of course it hasn't. The reasons is because it's a CRAPPY SOLUTION.
> Period. No Line breaks.
> Unless one is writing for ultimate display in the web, XML  SUCKS
>
> In all the best to have all the people who have responded to this,
> I don't see how you can continue maintain your position,
> Yours,
> Ken


I don't think you're going to convince many people with a rant like
that. Not one person in this thread has taken the position that XML is
great.  I don't think anybody, even the people who did design it, would
design XML the same way now.  There are far stronger criticisms of it than
named end tags though.

It is like it is for a bunch of reasons that are to do with its hereditary
burden carried from SGML, the people involved in the original specification
and (sadly) the process of managing that amongst other reasons.  If you're
interested the history and design decisions can be read up at the w3c.

However even acknowledging that there are valid and well thought out
criticisms of XML design beyond the ones you've brought up in this thread,
it hasn't become so widely used (and misused) by some accident.  It is very
popular for exactly the reason that it was the best choice for maven -
 because it is very simple to understand and to build tools for.

I think really you're lucky POMs are in XML, because if they were in
something like python you'd have had all of the same difficulties without
the target to vent at.  And with far less help, since maven would not be
nearly as popular if read a POM required people to learn a programming
language as well as the semantics for maven.

I hope you get over the XML thing and find maven useful to you - best way to
do that is to follow conventions and use tools.

Regards

Brian

Re: maven is a swamp

[Brian Topping]

On Oct 15, 2010, at 4:50 PM, Kenneth McDonald wrote:

> I still don't get the complacency at the XML swamp.

If I have to speak Italian to get the best cup of coffee in Little Italy, so 
what if it's a chore?  A focus on language instead of semantics leaves one lost 
to the opportunity at hand.

Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: maven is a swamp

[Thiessen, Todd (Todd)]

Hehe. Wow.

That guy who gathered that data is the Maven founder. It IS his job to get a 
pulse of how Maven users feel about it.

For a guy that claims to have so much experience, you sure don't do your 
homework.

> -Original Message-
> From: Kenneth McDonald [mailto:kenneth.m.mcdon...@sbcglobal.net]
> Sent: Friday, October 15, 2010 4:50 PM
> To: Maven Users List
> Subject: Re: maven is a swamp
> 
> Well, just to make it concrete, I am not a troll. I've been doing dev for
> 20+ years, have lots of
> experience with large projects, etc. etc. If I have to drop names, I was
> associated with one of
> the two main sites of the Human Genome Project.
> 
> I still don't get the complacency at the XML swamp. How is
> false
> 
> possibly better than
> 
> false
> 
> which would in turn be better than:
> 
> genericTagName = "false"
> 
> XML is a swamp of undertulized, overused redundancy. Period.
> 
> In response to the person who'd interrogated 2K+ people to see if they
> thought
> XML was overrdone;  Wow, that's really impressive! Where did you find the
> time
> to ask all those people and still get your your job done? Whereas, if I
> ask the five
> people who I know well, and who have to use these tools, the answer is,
> "what
> a bunch of garbage". They HATE XML.
> 
> Still not convinced? What about the simple fact of that that languages
> before, and the
> languages _since_ have not been written in a dialect of XML. If XML were
> such a great
> solution, surely it would have cleared here by now.
> 
> But of course it hasn't. The reasons is because it's a CRAPPY SOLUTION.
> Period. No Line breaks.
> Unless one is writing for ultimate display in the web, XML  SUCKS
> 
> In all the best to have all the people who have responded to this,
> I don't see how you can continue maintain your position,
> Yours,
> Ken
> On Oct 15, 2010, at 8:27 AM, Yanko, Curtis wrote:
> 
> > +1
> >
> > 
> >
> > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> > Making IT Happen, one build at a time
> >
> > -Original Message-
> > From: Brian Smith [mailto:bmjsm...@gmail.com]
> > Sent: Friday, October 15, 2010 5:39 AM
> > To: Maven Users List
> > Subject: Re: maven is a swamp
> >
> > I really fail at understanding the XML rage.  Yeah it's verbose.  How's
> > that a problem?  We've had tools with auto complete, auto format and
> > syntax highlighting for well over a decade, we also now have fairly
> > robust GUIs too.  If you're hand editing a 2000 line xml file in a
> green
> > screen terminal you're doing the equivalent of using an abacus and I'm
> > afraid you're not the user new tools ought to be aimed at.
> >
> > XML has a huge ubiquity value.  It might not be the *best* tool for the
> > job for each individual user but it's the only one that is widely
> enough
> > understood to not put an additional learning burden on the user.  When
> I
> > learned Maven I had to grok concepts like dependencyManagement and
> > plugins and phases.  I didn't have to learn XML, I already knew it.  If
> > Maven POMs were written in Python or A.N.Other language/markup I'd have
> > to learn that too.  There are many useful libraries that make it easier
> > to produce GUI tools on top of XML that don't exist for alternatives,
> so
> > we'd have less tooling for POMs.  Tooling and minimising the learning
> > required are good things.
> >
> > The _actual_ problem I see is the lack of "best practise" use for
> > plugins off the beaten track.  The documentation is usually fairly good
> > at telling you how to make a plugin do something, it's less than
> > brilliant at recommending best practises and unless it's one of the
> > mainstream ones covered by the sonatype book it's hard to find.  I've
> > found the best thing to do in those cases is go look at large, open
> > source projects and see how they do it.  Ken's original problem in this
> > thread (and the others he's been getting help with on the scala list)
> > are _nothing_ to do with XML, that is just the target of frustration.
> > They would have happened regardless of the language for POM
> > specification.
> >
> > For us, Maven's killed about 12,000 lines of ant legacy built up over a
> > few years, and also done a drive by on a couple of dozen ivy files,
> > replacing them with one medium size POM declaring dependency versions,
> a
&

Re: maven is a swamp

[Kenneth McDonald]

Well, just to make it concrete, I am not a troll. I've been doing dev for 20+ 
years, have lots of
experience with large projects, etc. etc. If I have to drop names, I was 
associated with one of
the two main sites of the Human Genome Project.

I still don't get the complacency at the XML swamp. How is
false

possibly better than

false

which would in turn be better than:

genericTagName = "false"

XML is a swamp of undertulized, overused redundancy. Period.

In response to the person who'd interrogated 2K+ people to see if they thought
XML was overrdone;  Wow, that's really impressive! Where did you find the time
to ask all those people and still get your your job done? Whereas, if I ask the 
five
people who I know well, and who have to use these tools, the answer is, "what
a bunch of garbage". They HATE XML. 

Still not convinced? What about the simple fact of that that languages before, 
and the
languages _since_ have not been written in a dialect of XML. If XML were such a 
great
solution, surely it would have cleared here by now.

But of course it hasn't. The reasons is because it's a CRAPPY SOLUTION. Period. 
No Line breaks.
Unless one is writing for ultimate display in the web, XML  SUCKS

In all the best to have all the people who have responded to this,
I don't see how you can continue maintain your position,
Yours,
Ken
On Oct 15, 2010, at 8:27 AM, Yanko, Curtis wrote:

> +1 
> 
> 
> 
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time
> 
> -Original Message-
> From: Brian Smith [mailto:bmjsm...@gmail.com] 
> Sent: Friday, October 15, 2010 5:39 AM
> To: Maven Users List
> Subject: Re: maven is a swamp
> 
> I really fail at understanding the XML rage.  Yeah it's verbose.  How's
> that a problem?  We've had tools with auto complete, auto format and
> syntax highlighting for well over a decade, we also now have fairly
> robust GUIs too.  If you're hand editing a 2000 line xml file in a green
> screen terminal you're doing the equivalent of using an abacus and I'm
> afraid you're not the user new tools ought to be aimed at.
> 
> XML has a huge ubiquity value.  It might not be the *best* tool for the
> job for each individual user but it's the only one that is widely enough
> understood to not put an additional learning burden on the user.  When I
> learned Maven I had to grok concepts like dependencyManagement and
> plugins and phases.  I didn't have to learn XML, I already knew it.  If
> Maven POMs were written in Python or A.N.Other language/markup I'd have
> to learn that too.  There are many useful libraries that make it easier
> to produce GUI tools on top of XML that don't exist for alternatives, so
> we'd have less tooling for POMs.  Tooling and minimising the learning
> required are good things.
> 
> The _actual_ problem I see is the lack of "best practise" use for
> plugins off the beaten track.  The documentation is usually fairly good
> at telling you how to make a plugin do something, it's less than
> brilliant at recommending best practises and unless it's one of the
> mainstream ones covered by the sonatype book it's hard to find.  I've
> found the best thing to do in those cases is go look at large, open
> source projects and see how they do it.  Ken's original problem in this
> thread (and the others he's been getting help with on the scala list)
> are _nothing_ to do with XML, that is just the target of frustration.
> They would have happened regardless of the language for POM
> specification.
> 
> For us, Maven's killed about 12,000 lines of ant legacy built up over a
> few years, and also done a drive by on a couple of dozen ivy files,
> replacing them with one medium size POM declaring dependency versions, a
> dozen small ones declaring dependencies, and a bunch of minimal ones -
> all with NO bespoke build instructions in.  Using nexus has killed the
> need to maintain an internal ivy repository which was a real pain in the
> rear, and we can now easily share deliverables with the other couple of
> hundred developers we have working in the same technologies around the
> globe.  It's been very painless by comparison to what we were doing
> before and well worth the switchover.
> 
> Regards
> 
> Brian
> 
> On 15 October 2010 08:56,  wrote:
> 
>> On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
>>>> A fact to note though is that I've asked over 2k people over the 
>> last two years at talks and in any average crowd the people who care 
>> to have a different format or DSL is around 3%.
>> 
>> An

Re: maven is a swamp

[Kathryn Huxtable]

First off, I think Maven is great. I'm in the middle of stuff, so I'm not 
moving to Maven 3 until I get to a good stopping place. (Probably about six 
months or so.)

On Oct 15, 2010, at 9:20 AM, Graham Leggett wrote:

> Guy who wrote ant build script is spontaneously thrown out of the third floor 
> plate glass window.

Ah. Spontaneous human defenestration! Next week on "Fringe". Or something. 
Anyway, very nice.

-K
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Graham Leggett]

On 14 Oct 2010, at 7:00 PM, Leon Rosenberg wrote:


This isn't quite true since ant allows you to build 'your own maven'
in few hours. The effort to learn maven is much higher, at least I had
to spend a lot more time since now.
On the other side the effort to learn ant is moderate. But maybe I'm
biased here ;-)


Reading this, it's like saying "I hear you're building an airplane in  
your garage, why all the trouble? You just take this piece of paper,  
and fold it like this...".



And, you can't deploy with maven...


mvn deploy?

Which you would never do manually, because deployment is done  
automatically during "mvn release:perform".



Well actually what bothers me is that my build scripts very shorter
than my poms. My typical build script in my pre-maven time was 3 rows
long:



   

   
   

   



Now take a look at this from the point of view of somebody who has  
never seen your ant project before.


They check the project out, they see "build.xml", they than go "oh  
cool, an ant build, let's try 'ant install'".


Error.

Oh, it's complaining about a file that doesn't exist in a directory I  
don't have, no idea why, let me try and reverse engineer the ant  
script. Oh look, I have to check out something else and stick it in  
some directory structure. Oops, I already have a build directory, let  
me rearrange the directories on my disk. Right, it's checked out, let  
me try that again.


Error.

Oh, what is it this time. Reverse engineer the basic-project.xml. Oh,  
they've called it "ant jar" for some reason, which was different to my  
ant scripts from the other project, where it was 'ant install'. Let me  
try "ant jar".


Error.

Oh for crying out loud. Reverse engineer the basic-project.xml.  
Discover that someone made a change to the shared ant script to fix  
the requirements of project Y, but that has broken project X. Let me  
try and hack it to work. Ooh look, it works now.


Later, you check out project Y, and you try and build it.

Error.

Guy who wrote ant build script is spontaneously thrown out of the  
third floor plate glass window.


In comparison, I might check out your project, look in the root of the  
project and see "pom.xml". "Oh, cool, a maven build, let me go 'mvn  
install'".


Done.


Well thats another point, what if I have more than one source code
directory? For example I have a project which contains an apt-based
code generator.


You don't know, and you don't care, because the maven plugin that  
knows about apt-based code generation worried about that for you,  
that's its job.


I have some projects that use the Torque database code generator. The  
plugin has a default location it places the classes, and it tells  
maven, and that path automatically appears in my Eclipse project when  
I ran "mvn eclipse:eclipse". Again, I didn't know it was doing this  
and I didn't care. I was too busy getting on with the job at hand with  
code.



At the core of ant is the question "how do I make ant do this?".

At the core of maven is the question "how does maven do this.".

Remove the "I" from the equation, and just do it like maven wants  
you to do

it, and suddenly everything becomes a *lot* more reliable.


I don't know.. I have use-cases over use-cases with stuff that maven
isn't doing per default.


Stop and think about that for a bit. Do you really have this use case,  
or is it a nice to have?



Example: get cobertura/findbugs/pdm reports without site phase. I
actually expect the CI to call verify instead of building a site. I
spent three days trying to get a cobertura report out of verify and
finally gave up.


I type "maven cobertura plugin" into Google. On the opening page of  
the first hit, under "goals overview", I see "cobertura:cobertura". I  
run "mvn cobertura:cobertura". Done.



Example: pack and unpack additional files into jar files. We have a
project which is an embedded-tool for webapps, similar to
tomcat-manager, but inside the webapp. We are used to package it as
jar and include jsp/img/js/css files into it, and unpack them in the
process of building of the final war. Manageable with maven? Yes, but
a lot of code.


Why are you trying to insert additional files into jar files? When you  
build the jar file, use the maven-resources-plugin to insert the  
additional files in the right place from the default src/main/ 
resources directory. Once released, the jar is sealed, you don't touch  
it again.


Fiddling with jars after release is evil beyond words. I was involved  
in an outage where we had to get the code running in production up on  
a developer machine to reproduce a bug. Oops, the code didn't build.  
How on earth did code that didn't build end up in production? Sheepish  
admission from project developer: "I might have added an additional  
file to the jar after the release was finished, as I didn't want to  
bump the version number".


Don't do it.


And than this uncertainty. We need to add some files to the war.

Re: maven is a swamp

[Ron Wheeler]

 On 15/10/2010 5:38 AM, Brian Smith wrote:

I really fail at understanding the XML rage.  Yeah it's verbose.  How's that
a problem?  We've had tools with auto complete, auto format and syntax
highlighting for well over a decade, we also now have fairly robust GUIs
too.  If you're hand editing a 2000 line xml file in a green screen terminal
you're doing the equivalent of using an abacus and I'm afraid you're not the
user new tools ought to be aimed at.

+1

XML has a huge ubiquity value.  It might not be the *best* tool for the job
for each individual user but it's the only one that is widely enough
understood to not put an additional learning burden on the user.  When I
learned Maven I had to grok concepts like dependencyManagement and plugins
and phases.  I didn't have to learn XML, I already knew it.  If Maven POMs
were written in Python or A.N.Other language/markup I'd have to learn that
too.  There are many useful libraries that make it easier to produce GUI
tools on top of XML that don't exist for alternatives, so we'd have less
tooling for POMs.  Tooling and minimising the learning required are good
things.


+1

The _actual_ problem I see is the lack of "best practise" use for plugins
off the beaten track.  The documentation is usually fairly good at telling
you how to make a plugin do something, it's less than brilliant at
recommending best practises and unless it's one of the mainstream ones
covered by the sonatype book it's hard to find.  I've found the best thing
to do in those cases is go look at large, open source projects and see how
they do it.  Ken's original problem in this thread (and the others he's been
getting help with on the scala list) are _nothing_ to do with XML, that is
just the target of frustration.  They would have happened regardless of the
language for POM specification.

Moving any mention of custom plug-ins to another Apache project might be 
the best favour that the developers could do for Maven.
Maven is incredibly flexible but it will build almost anything that I 
can think of with 3 or 4 standard plug-ins.
We build a portal with over 60 projects with 3 Maven plug-ins that come 
out of the box.
Our application includes a few web service, lots of portlets, and some 
standalone batch jobs and some library aggregation projects.


We use Nexus, Eclipse/STS and Subversion. as supporting tools.
We do not use CI which seems to be a lot more trouble than it is worth 
and from the chatter here seems to encourage overly coupled application 
design, bad QC and overly complex workflows but I might just be getting 
the "worst CI practices" rather than good examples of CI "Best Practice".




For us, Maven's killed about 12,000 lines of ant legacy built up over a few
years, and also done a drive by on a couple of dozen ivy files, replacing
them with one medium size POM declaring dependency versions, a dozen small
ones declaring dependencies, and a bunch of minimal ones - all with NO
bespoke build instructions in.  Using nexus has killed the need to maintain
an internal ivy repository which was a real pain in the rear, and we can now
easily share deliverables with the other couple of hundred developers we
have working in the same technologies around the globe.  It's been very
painless by comparison to what we were doing before and well worth the
switchover.

Regards

Brian


We started with Maven so we did not have legacy stuff to get rid of.

This is a complex pom for us since it uses a plug-in to build an 
executable jar and most do not so, so as Brian said, do not need a build 
section at all.
To set up a new project, one only needs  to change the artifact-id, 
change the versions where needed  and remove the entire  section 
if one is not building a standalone executable.
The POM for a webservice is only slightly different in that it has to 
build the client library as well as the service endpoint.
This POM will include about 50 third party libraries(Hibernate, Spring, 
Mysql, Apache Commons, CXF, etc.)  plus the client side access to our 
web services as well as the API and core libraries that provide access 
to the database and utilities.


It is being built to run with most of the code being at 1.9.1 (current 
approved versions of the third party libraries) but the lms-libraries 
are at 1.11.1-SNAPSHOT to get the current development version of the 
database APIs and implementation and utilities.


We are careful with upwards compatibility and build aggregation projects 
for libraries to make it easier for project developers to get the 
right/approved stuff without worrying about the details.


People do not deploy SNAPSHOTS to the Nexus archive without being 
prepared to stand behind their testing of the SNAPSHOT and to take the 
heat for deploying broken SNAPSHOTS.



http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>


lms-pom-master

RE: maven is a swamp

[Yanko, Curtis]

+1 



Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time

-Original Message-
From: Brian Smith [mailto:bmjsm...@gmail.com] 
Sent: Friday, October 15, 2010 5:39 AM
To: Maven Users List
Subject: Re: maven is a swamp

I really fail at understanding the XML rage.  Yeah it's verbose.  How's
that a problem?  We've had tools with auto complete, auto format and
syntax highlighting for well over a decade, we also now have fairly
robust GUIs too.  If you're hand editing a 2000 line xml file in a green
screen terminal you're doing the equivalent of using an abacus and I'm
afraid you're not the user new tools ought to be aimed at.

XML has a huge ubiquity value.  It might not be the *best* tool for the
job for each individual user but it's the only one that is widely enough
understood to not put an additional learning burden on the user.  When I
learned Maven I had to grok concepts like dependencyManagement and
plugins and phases.  I didn't have to learn XML, I already knew it.  If
Maven POMs were written in Python or A.N.Other language/markup I'd have
to learn that too.  There are many useful libraries that make it easier
to produce GUI tools on top of XML that don't exist for alternatives, so
we'd have less tooling for POMs.  Tooling and minimising the learning
required are good things.

The _actual_ problem I see is the lack of "best practise" use for
plugins off the beaten track.  The documentation is usually fairly good
at telling you how to make a plugin do something, it's less than
brilliant at recommending best practises and unless it's one of the
mainstream ones covered by the sonatype book it's hard to find.  I've
found the best thing to do in those cases is go look at large, open
source projects and see how they do it.  Ken's original problem in this
thread (and the others he's been getting help with on the scala list)
are _nothing_ to do with XML, that is just the target of frustration.
They would have happened regardless of the language for POM
specification.

For us, Maven's killed about 12,000 lines of ant legacy built up over a
few years, and also done a drive by on a couple of dozen ivy files,
replacing them with one medium size POM declaring dependency versions, a
dozen small ones declaring dependencies, and a bunch of minimal ones -
all with NO bespoke build instructions in.  Using nexus has killed the
need to maintain an internal ivy repository which was a real pain in the
rear, and we can now easily share deliverables with the other couple of
hundred developers we have working in the same technologies around the
globe.  It's been very painless by comparison to what we were doing
before and well worth the switchover.

Regards

Brian

On 15 October 2010 08:56,  wrote:

> On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
>  >> A fact to note though is that I've asked over 2k people over the 
> last two years at talks and in any average crowd the people who care 
> to have a different format or DSL is around 3%.
>
> And I one of them :-) I always havent been a friend of XML and I happy

> to see the possibilities maven3 offers (although I prefer using gradle

> -
> bygones)
>
> What I'm wondering most is - why the heck do you write to the maven 
> mailinglist how you dislike maven ? Is your intention to convince 
> people that they are doing bad stuff over the last xxx years ? Is it 
> just pure boredness ?
>
> I dont like Ruby or Clojure - what is the reason to bother the 
> ruby/clojure mailing list that their syntax is apparently horrible ?
>
> Sorry - I dont get it... If you dont like maven - dont use it... there

> are tons of alternatives around.
>
> Or what point do I miss here ?
>
>
>

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[mremersoncod]

 oh sorry for this misunderstanding.

I just quoted your (Jason) statement that just a few people like to have a dsl 
instead of xml and that I'm one of them ... 

The rest is basically to Ken, as I dont understand at all why he is complaining 
on this list or for what purpose

sorry

 


 

 

-Original Message-
From: Jason van Zyl 
To: Maven Users List 
Sent: Fri, Oct 15, 2010 1:46 pm
Subject: Re: maven is a swamp



On Oct 15, 2010, at 3:56 AM, mremerson...@aim.com wrote:

> On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
>>> A fact to note though is that I've asked over 2k people over the last two 
years at talks and in any average crowd the people who care to have a different 
format or DSL is around 3%.
> 
> And I one of them :-) I always havent been a friend of XML and I happy to see 
the possibilities maven3 offers (although I prefer using gradle - bygones)
> 
> What I'm wondering most is - why the heck do you write to the maven 
mailinglist how you dislike maven ? Is your intention to convince people that 
they are doing bad stuff over the last xxx years ? Is it just pure boredness ?
> 
> I dont like Ruby or Clojure - what is the reason to bother the ruby/clojure 
mailing list that their syntax is apparently horrible ?
> 
> Sorry - I dont get it... If you dont like maven - dont use it... there are 
tons of alternatives around.
> 
> Or what point do I miss here ?
> 

I actually don't understand a single thing you said.

I'm actually not sure if you're responding to me or Kenneth.

> 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

We know what we are, but know not what we may be.

  -- Shakespeare





 

Re: maven is a swamp

[Arnaud Héritier]

>>> 
>>> 
>> But the payoff is you don't need code completion! You just put in a )/}/] or 
>> so, and your code is completed! Any yes, any competent text editor can check 
>> for braces mismatches etc.
>> 
>> I recognize the concern, I just don't see it as valid. I've been programming 
>> in Python for twenty years now. I won't say it's always the case, but in a 
>> large number of cases, the terseness you gain in your code more than offsets 
>> things like code completion, static analysis, etc.
>> 
>> And yes, I specifically intend this to apply to XML. I can't see how moving 
>> to a YAML model would be anything but a win for maven.
>> 
> 
> http://github.com/sonatype/polyglot-maven/blob/master/pmaven-yaml/src/test/resources/pom.config.yml
> 
> Already works with Maven's current core. Along with Scala, Clojure, and Ruby.
> 
> A fact to note though is that I've asked over 2k people over the last two 
> years at talks and in any average crowd the people who care to have a 
> different format or DSL is around 3%.
> 

Me too. 
Xml verbosity and usage is sincerely not the major complain I received when 
doing various talks. 
And Maven 3.x will help those who are allergic to it.

Arnaud


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Jason van Zyl]

On Oct 15, 2010, at 3:56 AM, mremerson...@aim.com wrote:

> On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
>>> A fact to note though is that I've asked over 2k people over the last two 
>>> years at talks and in any average crowd the people who care to have a 
>>> different format or DSL is around 3%.
> 
> And I one of them :-) I always havent been a friend of XML and I happy to see 
> the possibilities maven3 offers (although I prefer using gradle - bygones)
> 
> What I'm wondering most is - why the heck do you write to the maven 
> mailinglist how you dislike maven ? Is your intention to convince people that 
> they are doing bad stuff over the last xxx years ? Is it just pure boredness ?
> 
> I dont like Ruby or Clojure - what is the reason to bother the ruby/clojure 
> mailing list that their syntax is apparently horrible ?
> 
> Sorry - I dont get it... If you dont like maven - dont use it... there are 
> tons of alternatives around.
> 
> Or what point do I miss here ?
> 

I actually don't understand a single thing you said.

I'm actually not sure if you're responding to me or Kenneth.

> 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

We know what we are, but know not what we may be.

  -- Shakespeare

Re: maven is a swamp

[Brian Smith]

I really fail at understanding the XML rage.  Yeah it's verbose.  How's that
a problem?  We've had tools with auto complete, auto format and syntax
highlighting for well over a decade, we also now have fairly robust GUIs
too.  If you're hand editing a 2000 line xml file in a green screen terminal
you're doing the equivalent of using an abacus and I'm afraid you're not the
user new tools ought to be aimed at.

XML has a huge ubiquity value.  It might not be the *best* tool for the job
for each individual user but it's the only one that is widely enough
understood to not put an additional learning burden on the user.  When I
learned Maven I had to grok concepts like dependencyManagement and plugins
and phases.  I didn't have to learn XML, I already knew it.  If Maven POMs
were written in Python or A.N.Other language/markup I'd have to learn that
too.  There are many useful libraries that make it easier to produce GUI
tools on top of XML that don't exist for alternatives, so we'd have less
tooling for POMs.  Tooling and minimising the learning required are good
things.

The _actual_ problem I see is the lack of "best practise" use for plugins
off the beaten track.  The documentation is usually fairly good at telling
you how to make a plugin do something, it's less than brilliant at
recommending best practises and unless it's one of the mainstream ones
covered by the sonatype book it's hard to find.  I've found the best thing
to do in those cases is go look at large, open source projects and see how
they do it.  Ken's original problem in this thread (and the others he's been
getting help with on the scala list) are _nothing_ to do with XML, that is
just the target of frustration.  They would have happened regardless of the
language for POM specification.

For us, Maven's killed about 12,000 lines of ant legacy built up over a few
years, and also done a drive by on a couple of dozen ivy files, replacing
them with one medium size POM declaring dependency versions, a dozen small
ones declaring dependencies, and a bunch of minimal ones - all with NO
bespoke build instructions in.  Using nexus has killed the need to maintain
an internal ivy repository which was a real pain in the rear, and we can now
easily share deliverables with the other couple of hundred developers we
have working in the same technologies around the globe.  It's been very
painless by comparison to what we were doing before and well worth the
switchover.

Regards

Brian

On 15 October 2010 08:56,  wrote:

> On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
>  >> A fact to note though is that I've asked over 2k people over the last
> two years at talks and in any average crowd the people who care to have a
> different format or DSL is around 3%.
>
> And I one of them :-) I always havent been a friend of XML and I happy to
> see the possibilities maven3 offers (although I prefer using gradle -
> bygones)
>
> What I'm wondering most is - why the heck do you write to the maven
> mailinglist how you dislike maven ? Is your intention to convince people
> that they are doing bad stuff over the last xxx years ? Is it just pure
> boredness ?
>
> I dont like Ruby or Clojure - what is the reason to bother the ruby/clojure
> mailing list that their syntax is apparently horrible ?
>
> Sorry - I dont get it... If you dont like maven - dont use it... there are
> tons of alternatives around.
>
> Or what point do I miss here ?
>
>
>

Re: maven is a swamp

[mremersoncod]

On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
 >> A fact to note though is that I've asked over 2k people over the last two 
 >> years at talks and in any average crowd the people who care to have a 
 >> different format or DSL is around 3%.

And I one of them :-) I always havent been a friend of XML and I happy to see 
the possibilities maven3 offers (although I prefer using gradle - bygones)

What I'm wondering most is - why the heck do you write to the maven mailinglist 
how you dislike maven ? Is your intention to convince people that they are 
doing bad stuff over the last xxx years ? Is it just pure boredness ?

I dont like Ruby or Clojure - what is the reason to bother the ruby/clojure 
mailing list that their syntax is apparently horrible ?

Sorry - I dont get it... If you dont like maven - dont use it... there are tons 
of alternatives around.

Or what point do I miss here ?

Re: maven is a swamp

[Ron Wheeler]

 On 14/10/2010 7:01 PM, Wayne Fay wrote:

And yes, I specifically intend this to apply to XML. I can't see how
moving to a YAML model would be anything but a win for maven.
It does not seem like anything to consider since IDE's can provide a 
nice GUI editor.

It feels like your entire complaint about Maven boils down to the use
of XML in the pom... You can't simply accept this as a trade-off for
the other benefits offered by Maven, or offer up an alternative
YAML/JSON-style pom file format (that you've developed) ala polyglot??

Yes, the XML is not hugely user-friendly. Yes, an alternative format
that is more user-friendly would be nice. The existence of polyglot is
sufficient evidence of these points. But I have never felt this alone
was a huge barrier to Maven adoption nor to my own personal usage of
Maven -- generally hand edited in vi or another similar tool, I don't
use m2e often. And I'm not even a PMC member like Stephen. ;-)

If Maven 4 moved to a YAML/JSON model, would that make you happy
enough to use Maven and simultaneously solve world hunger, bring peace
to the world, etc? Or would you just find more things to complain
about? ;-)

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Jason van Zyl]

On Oct 14, 2010, at 6:30 PM, Kenneth McDonald wrote:

> 
> On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote:
> 
>> Hi Kenneth !
>> 
>> Drawback of using a Python/YAML like solution is code completion.
>> 
> But the payoff is you don't need code completion! You just put in a )/}/] or 
> so, and your code is completed! Any yes, any competent text editor can check 
> for braces mismatches etc.
> 
> I recognize the concern, I just don't see it as valid. I've been programming 
> in Python for twenty years now. I won't say it's always the case, but in a 
> large number of cases, the terseness you gain in your code more than offsets 
> things like code completion, static analysis, etc.
> 
> And yes, I specifically intend this to apply to XML. I can't see how moving 
> to a YAML model would be anything but a win for maven.
> 

http://github.com/sonatype/polyglot-maven/blob/master/pmaven-yaml/src/test/resources/pom.config.yml

Already works with Maven's current core. Along with Scala, Clojure, and Ruby.

A fact to note though is that I've asked over 2k people over the last two years 
at talks and in any average crowd the people who care to have a different 
format or DSL is around 3%.

At any rate anything is possible with Maven 3.

> Just to let you know I'm not firmly entrenched in one camp, the static 
> analysis that Scala supplies seems to me to overcome the inherit "benefits" 
> of dynamic analysis.
> 
> Ken
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: maven is a swamp

[Benson Margulies]

Step 1: even fairly straightforward POMs that need more than the
default conventions rapidly get verbose and hard to read due to XML.

Step 2: Hiding behind that, though, there are, I claim, areas of
genuine confusion.

For the simple cases, it's fine to say 'convention over
configuration'. Lots of us can agree on the conventions for turning a
heap of Java files into a Jar.

However, for better or worse, many of us have to do things with builds
for which there is no self-evident convention. The maven plugins for
the job pick something, and then reality shows up and kicks us in the
head. XML amplifies this, but there is an underlying problem there.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Frederic Camblor]

I won't argue about closing tag, it's obvious a "}" is cleaner than a
""

But I insist about code completion that is :
- I'm in  section, I don't remember how my tag for target directory
is named, I hit ctrl+space (under eclipse *cough*) and it provide me with
all available tags in the  section ...
- ... plus it provides, too, a documentation for all tags !

I don't know if with YAML, we can use an xml schema to describe the current
document structure.
If so, it will have all the benefits.
If not, it will lose something important to my point of view.

Frédéric

On Fri, Oct 15, 2010 at 12:30 AM, Kenneth McDonald <
kenneth.m.mcdon...@sbcglobal.net> wrote:

>
> On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote:
>
> > Hi Kenneth !
> >
> > Drawback of using a Python/YAML like solution is code completion.
> >
> But the payoff is you don't need code completion! You just put in a )/}/]
> or so, and your code is completed! Any yes, any competent text editor can
> check for braces mismatches etc.
>
> I recognize the concern, I just don't see it as valid. I've been
> programming in Python for twenty years now. I won't say it's always the
> case, but in a large number of cases, the terseness you gain in your code
> more than offsets things like code completion, static analysis, etc.
>
> And yes, I specifically intend this to apply to XML. I can't see how moving
> to a YAML model would be anything but a win for maven.
>
> Just to let you know I'm not firmly entrenched in one camp, the static
> analysis that Scala supplies seems to me to overcome the inherit "benefits"
> of dynamic analysis.
>
> Ken
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven is a swamp

[Wayne Fay]

> And yes, I specifically intend this to apply to XML. I can't see how
> moving to a YAML model would be anything but a win for maven.

It feels like your entire complaint about Maven boils down to the use
of XML in the pom... You can't simply accept this as a trade-off for
the other benefits offered by Maven, or offer up an alternative
YAML/JSON-style pom file format (that you've developed) ala polyglot??

Yes, the XML is not hugely user-friendly. Yes, an alternative format
that is more user-friendly would be nice. The existence of polyglot is
sufficient evidence of these points. But I have never felt this alone
was a huge barrier to Maven adoption nor to my own personal usage of
Maven -- generally hand edited in vi or another similar tool, I don't
use m2e often. And I'm not even a PMC member like Stephen. ;-)

If Maven 4 moved to a YAML/JSON model, would that make you happy
enough to use Maven and simultaneously solve world hunger, bring peace
to the world, etc? Or would you just find more things to complain
about? ;-)

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Kenneth McDonald]

On Oct 14, 2010, at 5:09 PM, Frederic Camblor wrote:

> Hi Kenneth !
> 
> Drawback of using a Python/YAML like solution is code completion.
> 
But the payoff is you don't need code completion! You just put in a )/}/] or 
so, and your code is completed! Any yes, any competent text editor can check 
for braces mismatches etc.

I recognize the concern, I just don't see it as valid. I've been programming in 
Python for twenty years now. I won't say it's always the case, but in a large 
number of cases, the terseness you gain in your code more than offsets things 
like code completion, static analysis, etc.

And yes, I specifically intend this to apply to XML. I can't see how moving to 
a YAML model would be anything but a win for maven.

Just to let you know I'm not firmly entrenched in one camp, the static analysis 
that Scala supplies seems to me to overcome the inherit "benefits" of dynamic 
analysis.

Ken


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Stephen Connolly]

On 14 October 2010 22:56, Kenneth McDonald
 wrote:
>>> Hi Wayne, I'll post one more response to your well-thought-out question.
>>>
>>> Here is the pom file I'm currently using:
>>>
>>> and just so you don't have to scroll all the way to the bottom to see the 
>>> comments, I'll put them here :-)
>>>
>>> - Is there _anything_ in the structure of this file which leads me to an 
>>> "aha, I understand what the major
>>> and minor parts of the file are all about" moment?
>>>
>>> - Does the file get across what it means both concisely and clearly?
>>>
>>> - Is the syntax of the file for the convenience of the programmer, or the 
>>> convenience of the tools
>>> that process it?
>>>
>>> - Could someone well-versed in programming, but without an understanding of 
>>> maven, make at
>>> least some sense of this file?
>>>
>>> IMHO, the answers are no, no, for the convenience of the tools, and no. In 
>>> terms of readability,
>>> this file (and all pom files I've seen) are simply disasters. In terms of 
>>> semantics--OK, pretty good.
>>> In terms of usability, what a piece of garbage!
>>
>> But why would you ever see this?
>> Doesn't your IDE support Maven?
>
> I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it makes 
> me look at the pom as xml. But
> even that begs the question.

IntelliJ kicks ass

>> There is no reason why any of my guys would ever look at this as XML.
>> We use Eclipse/STS as an IDE and this simple POM would never require anyone 
>> to do anything in XML.
>>
>> Hand editing POMs is not a reasonable thing to do in 2010  unless you are 
>> debugging Maven and want to break a POM to see what Maven does.
>>
> I agree. Hand editing POMs is not reasonable because POMs are not amenable to 
> hand editing. That's a problem
> of the POM format, not of the concept of hand editing.

I routinely edit my pom's by hand using vi, I do not feel any major
pain so doing, and I have some rather complex pom's at that... I have
one pom that starts two jetty, selenium, a derby database, some other
odds and sods and runs integration tests with failsafe... ok ok ok so
i'm a pmc, but still it's no big deal working with the pom as is

>
>> You need to look at parent POMs to get rid of the clutter:
>>
>> This goes in the project parent POM so you don't put it in a POM that 
>> generates an artifact:
>
> That may be the case (and is something that is nonobvious from reading basic 
> maven docs), but...
>>
>>    
>>        
>>            kmcdonald
>>            Kenneth McDonald
>>            ykkenmcd [at] gmail com
>>        
>>    
>>
>>    
>>        
>>            Lesser General Public License (LGPL)
>>            http://www.gnu.org/copyleft/lesser.txt
>>            repo
>>        
>>    
>>
> developers = [{id: "kmcdonald", name: "Kenneth McDonald", email: "ykkenmcd 
> [at] gmail com"}]
>
> licenses = [
>                {
>                        name: "Lesser General Public License (LGPL)",
>                        url: "http://www.gnu.org/copyleft/lesser.txt";
>                        distribution: "repo"
>                }
> ]
>
> That's ten lines of code vs. fifteen, and the ten lines are _much_ more 
> readable. And I could've compressed those ten lines further without much 
> effort. C'mon, people, where's your sense of proportion? The syntax I've used 
> is pretty Pythonic (not sure if it's exactly that since I've used 
> Perl/Python/JavaScript so interchangeably), but it's been around for a _LONG_ 
> time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT is the 
> problem with using a syntax that is:
>
>        a) easily parsed
>        b) easily read
>        c) easily written
>
> Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea that 
> things should be text _unless_ they are explicitly marked as not text. This 
> completely flies in the face of I don't know how many years of CS, and is 
> simply wrong. Most of most coding constructs is control logic. It follows 
> that it should be easy to write the control logic, a little bit more 
> difficult to write the literals. Now when HTML was being designed, that was 
> different, because they were designing to a format whose primary purpose was 
> visual represention on a page. Guess what, boys and girls--we're not doing 
> that anymore! XML is a control format, and should make it easy to write the 
> control parts of the statements, and a little tougher to write the literal 
> parts. The fact that it doesn't do this is evidence if its almost complete 
> inadequacy to serve as a control language.
>
> ...I've edited out a lot here below for brevity.
>
> Cheers,
> Ken
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For addit

Re: maven is a swamp

[Frederic Camblor]

Hi Kenneth !

Drawback of using a Python/YAML like solution is code completion.

I remember some discussion where Jason was planning to add XML namespaces
for plugins, allowing to define specific schemas for  tags.
We are OK, this is not done yet, but the perspective is interesting to my
mind (it would offer "inline documentation" while hand coding the pom...)

Using YAML would lose this possibility to my mind (since data won't be
strongly typed).

Frédéric

On Thu, Oct 14, 2010 at 11:56 PM, Kenneth McDonald <
kenneth.m.mcdon...@sbcglobal.net> wrote:

> >> Hi Wayne, I'll post one more response to your well-thought-out question.
> >>
> >> Here is the pom file I'm currently using:
> >>
> >> and just so you don't have to scroll all the way to the bottom to see
> the comments, I'll put them here :-)
> >>
> >> - Is there _anything_ in the structure of this file which leads me to an
> "aha, I understand what the major
> >> and minor parts of the file are all about" moment?
> >>
> >> - Does the file get across what it means both concisely and clearly?
> >>
> >> - Is the syntax of the file for the convenience of the programmer, or
> the convenience of the tools
> >> that process it?
> >>
> >> - Could someone well-versed in programming, but without an understanding
> of maven, make at
> >> least some sense of this file?
> >>
> >> IMHO, the answers are no, no, for the convenience of the tools, and no.
> In terms of readability,
> >> this file (and all pom files I've seen) are simply disasters. In terms
> of semantics--OK, pretty good.
> >> In terms of usability, what a piece of garbage!
> >
> > But why would you ever see this?
> > Doesn't your IDE support Maven?
>
> I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it
> makes me look at the pom as xml. But
> even that begs the question.
> > There is no reason why any of my guys would ever look at this as XML.
> > We use Eclipse/STS as an IDE and this simple POM would never require
> anyone to do anything in XML.
> >
> > Hand editing POMs is not a reasonable thing to do in 2010  unless you are
> debugging Maven and want to break a POM to see what Maven does.
> >
> I agree. Hand editing POMs is not reasonable because POMs are not amenable
> to hand editing. That's a problem
> of the POM format, not of the concept of hand editing.
>
> > You need to look at parent POMs to get rid of the clutter:
> >
> > This goes in the project parent POM so you don't put it in a POM that
> generates an artifact:
>
> That may be the case (and is something that is nonobvious from reading
> basic maven docs), but...
> >
> >
> >
> >kmcdonald
> >Kenneth McDonald
> >ykkenmcd [at] gmail com
> >
> >
> >
> >
> >
> >Lesser General Public License (LGPL)
> >http://www.gnu.org/copyleft/lesser.txt
> >repo
> >
> >
> >
> developers = [{id: "kmcdonald", name: "Kenneth McDonald", email: "ykkenmcd
> [at] gmail com"}]
>
> licenses = [
>{
>name: "Lesser General Public License (LGPL)",
> url: "http://www.gnu.org/copyleft/lesser.txt";
> distribution: "repo"
>}
> ]
>
> That's ten lines of code vs. fifteen, and the ten lines are _much_ more
> readable. And I could've compressed those ten lines further without much
> effort. C'mon, people, where's your sense of proportion? The syntax I've
> used is pretty Pythonic (not sure if it's exactly that since I've used
> Perl/Python/JavaScript so interchangeably), but it's been around for a
> _LONG_ time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT
> is the problem with using a syntax that is:
>
>a) easily parsed
>b) easily read
>c) easily written
>
> Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea
> that things should be text _unless_ they are explicitly marked as not text.
> This completely flies in the face of I don't know how many years of CS, and
> is simply wrong. Most of most coding constructs is control logic. It follows
> that it should be easy to write the control logic, a little bit more
> difficult to write the literals. Now when HTML was being designed, that was
> different, because they were designing to a format whose primary purpose was
> visual represention on a page. Guess what, boys and girls--we're not doing
> that anymore! XML is a control format, and should make it easy to write the
> control parts of the statements, and a little tougher to write the literal
> parts. The fact that it doesn't do this is evidence if its almost complete
> inadequacy to serve as a control language.
>
> ...I've edited out a lot here below for brevity.
>
> Cheers,
> Ken
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.o

Re: maven is a swamp

[Kenneth McDonald]

>> Hi Wayne, I'll post one more response to your well-thought-out question.
>> 
>> Here is the pom file I'm currently using:
>> 
>> and just so you don't have to scroll all the way to the bottom to see the 
>> comments, I'll put them here :-)
>> 
>> - Is there _anything_ in the structure of this file which leads me to an 
>> "aha, I understand what the major
>> and minor parts of the file are all about" moment?
>> 
>> - Does the file get across what it means both concisely and clearly?
>> 
>> - Is the syntax of the file for the convenience of the programmer, or the 
>> convenience of the tools
>> that process it?
>> 
>> - Could someone well-versed in programming, but without an understanding of 
>> maven, make at
>> least some sense of this file?
>> 
>> IMHO, the answers are no, no, for the convenience of the tools, and no. In 
>> terms of readability,
>> this file (and all pom files I've seen) are simply disasters. In terms of 
>> semantics--OK, pretty good.
>> In terms of usability, what a piece of garbage!
> 
> But why would you ever see this?
> Doesn't your IDE support Maven?

I use IntelliJ IDEA, one of the better thought of IDEs. Regardless, it makes me 
look at the pom as xml. But
even that begs the question.
> There is no reason why any of my guys would ever look at this as XML.
> We use Eclipse/STS as an IDE and this simple POM would never require anyone 
> to do anything in XML.
> 
> Hand editing POMs is not a reasonable thing to do in 2010  unless you are 
> debugging Maven and want to break a POM to see what Maven does.
> 
I agree. Hand editing POMs is not reasonable because POMs are not amenable to 
hand editing. That's a problem
of the POM format, not of the concept of hand editing.

> You need to look at parent POMs to get rid of the clutter:
> 
> This goes in the project parent POM so you don't put it in a POM that 
> generates an artifact:

That may be the case (and is something that is nonobvious from reading basic 
maven docs), but...
> 
>
>
>kmcdonald
>Kenneth McDonald
>ykkenmcd [at] gmail com
>
>
> 
>
>
>Lesser General Public License (LGPL)
>http://www.gnu.org/copyleft/lesser.txt
>repo
>
>
> 
developers = [{id: "kmcdonald", name: "Kenneth McDonald", email: "ykkenmcd [at] 
gmail com"}]

licenses = [
{
name: "Lesser General Public License (LGPL)",
url: "http://www.gnu.org/copyleft/lesser.txt";
distribution: "repo"
}
]

That's ten lines of code vs. fifteen, and the ten lines are _much_ more 
readable. And I could've compressed those ten lines further without much 
effort. C'mon, people, where's your sense of proportion? The syntax I've used 
is pretty Pythonic (not sure if it's exactly that since I've used 
Perl/Python/JavaScript so interchangeably), but it's been around for a _LONG_ 
time. Much longer than Maven has been using--Gaggh--XML. Exactly WHAT is the 
problem with using a syntax that is:

a) easily parsed
b) easily read
c) easily written

Oh, and while I'm at it, I'll mention another pet peeve of XML: The idea that 
things should be text _unless_ they are explicitly marked as not text. This 
completely flies in the face of I don't know how many years of CS, and is 
simply wrong. Most of most coding constructs is control logic. It follows that 
it should be easy to write the control logic, a little bit more difficult to 
write the literals. Now when HTML was being designed, that was different, 
because they were designing to a format whose primary purpose was visual 
represention on a page. Guess what, boys and girls--we're not doing that 
anymore! XML is a control format, and should make it easy to write the control 
parts of the statements, and a little tougher to write the literal parts. The 
fact that it doesn't do this is evidence if its almost complete inadequacy to 
serve as a control language.

...I've edited out a lot here below for brevity.

Cheers,
Ken



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Ron Wheeler]

 On 14/10/2010 3:32 PM, Kenneth McDonald wrote:

On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:


As much fun as all this commentary is, unless Ken comes back and posts
a reply, I feel like we're simply the victims of a drive-by
trolling...

As such, I recommend letting this thread die, at least until Ken comes
back and adds something to the discussion... Ken???


Hi Wayne, I'll post one more response to your well-thought-out question.

Here is the pom file I'm currently using:

and just so you don't have to scroll all the way to the bottom to see the 
comments, I'll put them here :-)

- Is there _anything_ in the structure of this file which leads me to an "aha, 
I understand what the major
and minor parts of the file are all about" moment?

- Does the file get across what it means both concisely and clearly?

- Is the syntax of the file for the convenience of the programmer, or the 
convenience of the tools
that process it?

- Could someone well-versed in programming, but without an understanding of 
maven, make at
least some sense of this file?

IMHO, the answers are no, no, for the convenience of the tools, and no. In 
terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms of 
semantics--OK, pretty good.
In terms of usability, what a piece of garbage!


But why would you ever see this?
Doesn't your IDE support Maven?
There is no reason why any of my guys would ever look at this as XML.
We use Eclipse/STS as an IDE and this simple POM would never require 
anyone to do anything in XML.


Hand editing POMs is not a reasonable thing to do in 2010  unless you 
are debugging Maven and want to break a POM to see what Maven does.


I will admit to occasionally cutting and pasting between XML files if I 
have a lot of duplicate sections but this is a "once in a project" thing 
that hardly ever happens

I am more likely to copy the whole POM and use the editor to finish.

You need to look at parent POMs to get rid of the clutter:

This goes in the project parent POM so you don't put it in a POM that 
generates an artifact:




kmcdonald
Kenneth McDonald
ykkenmcd [at] gmail com





Lesser General Public License (LGPL)
http://www.gnu.org/copyleft/lesser.txt
repo



All of this belongs in the parent as well since it will be the same for each 
module.



org.apache.maven.plugins
maven-dependency-plugin
2.1


org.scala-tools
maven-scala-plugin
2.14.1



compile
testCompile





org.apache.maven.plugins
maven-surefire-plugin
2.6

false

**/*Test.*
**/*Suite.*





As does this:



org.scala-tools
maven-scala-plugin
2.14.1


org.apache.maven.plugins
maven-dependency-plugin
2.1





Your POM gets pretty small and easy to edit using a POM editor once you move 
out the stuff that belongs elsewhere.

Non of this stuff is going to trouble the Eclipse POM editor even if you do not 
do it the smart way.


Ron


So I guess my comment is, decent internals, horrible externals.

http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
 4.0.0
 ykken.rex
 rex
 0.5-SNAPSHOT
 2010

 
 
 kmcdonald
 Kenneth McDonald
 ykkenmcd [at] gmail com
 
 

 
 
 Lesser General Public License (LGPL)
 http://www.gnu.org/copyleft/lesser.txt
 repo
 
 

 
 2.8.0
 

 
 
 scala-tools.org
 Scala-Tools Maven2 Repository
 http://scala-tools.org/repo-releases
 
 

 
 
 snapshots.scala-tools.org
 Scala-Tools Maven2 Repository
 http://scala-tools.org/repo-releases
 
 

 
 
 org.scala-lang
 scala-compiler
 ${scala.version}
 
 
 org.scala-lang
 scala-library
 ${scala.version}
 
 
 junit
 junit
 4.8.1
 test
 
 
 

RE: maven is a swamp

[Yanko, Curtis]

To me, the answer is yes,yes, yes but then I don't see Maven as a
*programming* language.

To me I can quickly see what we are trying to do and what it needs to do
it.

In a world where Source + Tools = Product (where tools = tools +
libraries) I see documentation about the tools.




Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time

-Original Message-
From: Kenneth McDonald [mailto:kenneth.m.mcdon...@sbcglobal.net] 
Sent: Thursday, October 14, 2010 3:32 PM
To: Maven Users List
Subject: Re: maven is a swamp


On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:

> As much fun as all this commentary is, unless Ken comes back and posts

> a reply, I feel like we're simply the victims of a drive-by 
> trolling...
> 
> As such, I recommend letting this thread die, at least until Ken comes

> back and adds something to the discussion... Ken???
> 
Hi Wayne, I'll post one more response to your well-thought-out question.

Here is the pom file I'm currently using:

and just so you don't have to scroll all the way to the bottom to see
the comments, I'll put them here :-)

- Is there _anything_ in the structure of this file which leads me to an
"aha, I understand what the major and minor parts of the file are all
about" moment?

- Does the file get across what it means both concisely and clearly?

- Is the syntax of the file for the convenience of the programmer, or
the convenience of the tools that process it?

- Could someone well-versed in programming, but without an understanding
of maven, make at least some sense of this file?

IMHO, the answers are no, no, for the convenience of the tools, and no.
In terms of readability, this file (and all pom files I've seen) are
simply disasters. In terms of semantics--OK, pretty good.
In terms of usability, what a piece of garbage!

So I guess my comment is, decent internals, horrible externals.

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ykken.rex
rex
0.5-SNAPSHOT
2010



kmcdonald
Kenneth McDonald
ykkenmcd [at] gmail com





Lesser General Public License (LGPL)
http://www.gnu.org/copyleft/lesser.txt
repo




2.8.0




scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases





snapshots.scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases





org.scala-lang
scala-compiler
${scala.version}


org.scala-lang
scala-library
${scala.version}


junit
junit
4.8.1
test


org.scalatest
scalatest
1.2
test




src/main/scala
src/test/scala


org.apache.maven.plugins
maven-dependency-plugin
2.1


org.scala-tools
maven-scala-plugin
2.14.1



compile
testCompile





org.apache.maven.plugins
maven-surefire-plugin
2.6

false

**/*Test.*
**/*Suite.*








org.scala-tools
maven-scala-plugin
2.14.1


org.apache.maven.plugins
maven-dependency-plugin
2.1






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in 

Re: maven is a swamp

[Kenneth McDonald]

On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:

> As much fun as all this commentary is, unless Ken comes back and posts
> a reply, I feel like we're simply the victims of a drive-by
> trolling...
> 
> As such, I recommend letting this thread die, at least until Ken comes
> back and adds something to the discussion... Ken???
> 
Hi Wayne, I'll post one more response to your well-thought-out question.

Here is the pom file I'm currently using:

and just so you don't have to scroll all the way to the bottom to see the 
comments, I'll put them here :-)

- Is there _anything_ in the structure of this file which leads me to an "aha, 
I understand what the major
and minor parts of the file are all about" moment?

- Does the file get across what it means both concisely and clearly?

- Is the syntax of the file for the convenience of the programmer, or the 
convenience of the tools
that process it?

- Could someone well-versed in programming, but without an understanding of 
maven, make at
least some sense of this file?

IMHO, the answers are no, no, for the convenience of the tools, and no. In 
terms of readability,
this file (and all pom files I've seen) are simply disasters. In terms of 
semantics--OK, pretty good.
In terms of usability, what a piece of garbage!

So I guess my comment is, decent internals, horrible externals.

http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ykken.rex
rex
0.5-SNAPSHOT
2010



kmcdonald
Kenneth McDonald
ykkenmcd [at] gmail com





Lesser General Public License (LGPL)
http://www.gnu.org/copyleft/lesser.txt
repo




2.8.0




scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases





snapshots.scala-tools.org
Scala-Tools Maven2 Repository
http://scala-tools.org/repo-releases





org.scala-lang
scala-compiler
${scala.version}


org.scala-lang
scala-library
${scala.version}


junit
junit
4.8.1
test


org.scalatest
scalatest
1.2
test




src/main/scala
src/test/scala


org.apache.maven.plugins
maven-dependency-plugin
2.1


org.scala-tools
maven-scala-plugin
2.14.1



compile
testCompile





org.apache.maven.plugins
maven-surefire-plugin
2.6

false

**/*Test.*
**/*Suite.*








org.scala-tools
maven-scala-plugin
2.14.1


org.apache.maven.plugins
maven-dependency-plugin
2.1






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Kenneth McDonald]

On Oct 14, 2010, at 9:11 AM, Wayne Fay wrote:

> As much fun as all this commentary is, unless Ken comes back and posts
> a reply, I feel like we're simply the victims of a drive-by
> trolling...
> 
> As such, I recommend letting this thread die, at least until Ken comes
> back and adds something to the discussion... Ken???

Sure, happy to.

I won't be quite as angry in this post as in the last one :-), but I still have 
a lot
of complaints against the Maven way of doing things. I won't hit them all, here
are a few random thoughts:

1) Maven is declarative vs. procedural. This is great, but Prolog has been that
way for decades. Why build such a complex syntax when a much simpler one
already existed.

2) Relates to 1). I still think this is important. AFAIK, XML was NEVER 
intended to
be a syntax for direct editing by the user. It is needlessly verbose and 
redundant,
and seriously obscures the actual intent of the code. As the simplest possible
example, what is the point in writing 
false
when what is really meant is the (IMHO) much easier to read someGenericOption = 
false.

3) Yes, I'm aware there is something called polyglot maven. (Haven't looked at 
it yet, as
I don't want to add yet another layer of complexity to what I'm doing.) Doesn't 
the simple
existence of this prove my point? There were never polyglot makefiles--in spite 
of all
of their (numerous) problems, the syntax of makefiles was simple enough there 
was
never a demand for them.

4) Maybe I'm missing something, but maven seems to be all about predefined maven
tasks. (Not sure I'm using the right terminology). If there's something simple 
I can do 
from the command line, maven doesn't provide an obvious way for me to do it.

5) Maven is just too complex. The comment I've seen is, "If users would just 
read a
book...", but what if I don't have the time to read an entire book simply to 
figure out how
to push my docs to github? With command-line access, I wouldn't need to do so. 
And
if the project got so big that an ad hoc solution didn't suffice, _then_ I 
could come back
and read the book.

So those are just a few random thoughts. Make of them what you will.

Thanks,
Ken


> 
> Wayne
> 
> On Wed, Oct 13, 2010 at 5:13 PM, Rick Mangi  wrote:
>> Flexible and elegant aren't necessarily the same thing... Any language that
>> prides itself on its ability to be obfuscated can't be elegant ;-)
>> 
>> That said, I do love it.
>> 
>> As far as Maven goes, the elegance of maven is that it does 90% of what you
>> need it to do with very little or no effort and the other 10% can be done
>> without much hassle.
>> 
>> 
>> On 10/13/10 10:48 AM, "Kathryn Huxtable" 
>> wrote:
>> 
>>> It does. The rest of the language is rather ugly, though. -K
>>> 
>>> On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote:
>>> 
 I just enjoyed the bit about perl having elegant and concise data 
 structures
 :-)
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Leon Rosenberg]

Hello,

On Wed, Oct 13, 2010 at 10:53 PM, Graham Leggett  wrote:
> On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote:
>
>> Many traditional programming languages are declarative and not
>> procedural or are based on declarative concepts, most of the time the
>> declarative nature of such languages proved itself problematic.
>> But seriously is there a comparison matrix somewhere which compares
>> ant+ivy vs maven?
>
> A comparison would make little sense, because ant and maven aren't
> alternatives for one another. Ant is a language that allows you to create
> custom build scripts, but you are required to write those build scripts
> yourself, over and over again. Maven on the other hand arrives with built in
> knowledge on how to build things, you are only required to tell maven the
> basics, like the name of the artifact, the version, etc. Maven does
> everything else for you without you having to tell it how to do it.

This isn't quite true since ant allows you to build 'your own maven'
in few hours. The effort to learn maven is much higher, at least I had
to spend a lot more time since now.
On the other side the effort to learn ant is moderate. But maybe I'm
biased here ;-)
And, you can't deploy with maven...

>
>> As an ant+ivy user I have recently tried out maven
>> (yes, i hand-wrote poms for about 15 projects) which mostly depend on
>> each other, I got them all published in nexus etc. I must say that I'm
>> pretty shaken how unreliable maven build are.
>
> I predict the core of your problem is "as an ant+ivy user...".
>
> With ant, you adopt the mindset "I need to tell ant to do X, then Y, then
> Z". With maven, you don't tell it how to do anything, it already knows how
> to do stuff.

Well actually what bothers me is that my build scripts very shorter
than my poms. My typical build script in my pre-maven time was 3 rows
long:












>
> If you try and approach maven with the idea that you want to tell maven to
> do X, Y and then Z, you'll very quickly come unstuck, because you'll be
> fighting with maven, trying to convince it to do things in your order
> instead of maven's built in order.
>
> Maven already knows how to do stuff. All you need to do is fill in the
> blanks. Tell maven what kind of artifact it is, what it is called. And don't
> stray from the defaults - you don't need to put your source code in some
> weird directory structure, if maven defaults to src/main/java, put your code
> in src/main/java and leave it at that.

Well thats another point, what if I have more than one source code
directory? For example I have a project which contains an apt-based
code generator. The other source-directory of the project is annotated
with apt annotations from the first source part and can't be compiled
before the first part is compiled. Further on, the generated code
itself has to be compiled as well. And yes it works with maven and
some plugins but in much less elegant way as in ant.

>
> When you find yourself in a situation where you have a 5 line pom file,
> with hundreds of plugins all custom configured, you're fighting against
> maven. This isn't maven's fault, this is the fault of the person who created
> the pom. Keep it simple, keep it to default behaviour.
>
>> With ant it either works or not. If it works, it works everywhere, in
>> console, in eclipse in hudson.
>
> In my experience, I have not once encountered an ant build that worked,
> ever. The reason was simple: the build is always secondary to the code
> itself. Inevitably, the ant build only performed the basics, even "ant
> clean" was left out most of the time. Every single one I encountered had
> some or other path that was hard coded to "C:\Program Files\..." with the
> developer expecting everyone else to just recreate the same directory
> structure, it was ridiculous. Maven has gone off and solved the build
> problem, it does not rely on every developer's half hearted attempt to write
> a build script when they're under pressure to produce code, not build.
>
> At the core of ant is the question "how do I make ant do this?".
>
> At the core of maven is the question "how does maven do this.".
>
> Remove the "I" from the equation, and just do it like maven wants you to do
> it, and suddenly everything becomes a *lot* more reliable.

I don't know.. I have use-cases over use-cases with stuff that maven
isn't doing per default.
Example: get cobertura/findbugs/pdm reports without site phase. I
actually expect the CI to call verify instead of building a site. I
spent three days trying to get a cobertura report out of verify and
finally gave up.
Example: pack and unpack additional files into jar files. We have a
project which is an embedded-tool for webapps, similar to
tomcat-manager, but inside the webapp. We are used to package it as
jar and include jsp/img/js/css files into it, and unpack them in the
process of building of the final war. Manageable with maven? Yes, but
a lot of code.

And t

Re: maven is a swamp

[Wayne Fay]

As much fun as all this commentary is, unless Ken comes back and posts
a reply, I feel like we're simply the victims of a drive-by
trolling...

As such, I recommend letting this thread die, at least until Ken comes
back and adds something to the discussion... Ken???

Wayne

On Wed, Oct 13, 2010 at 5:13 PM, Rick Mangi  wrote:
> Flexible and elegant aren't necessarily the same thing... Any language that
> prides itself on its ability to be obfuscated can't be elegant ;-)
>
> That said, I do love it.
>
> As far as Maven goes, the elegance of maven is that it does 90% of what you
> need it to do with very little or no effort and the other 10% can be done
> without much hassle.
>
>
> On 10/13/10 10:48 AM, "Kathryn Huxtable" 
> wrote:
>
>> It does. The rest of the language is rather ugly, though. -K
>>
>> On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote:
>>
>>> I just enjoyed the bit about perl having elegant and concise data structures
>>> :-)
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Rick Mangi]

Flexible and elegant aren't necessarily the same thing... Any language that
prides itself on its ability to be obfuscated can't be elegant ;-)

That said, I do love it.

As far as Maven goes, the elegance of maven is that it does 90% of what you
need it to do with very little or no effort and the other 10% can be done
without much hassle.


On 10/13/10 10:48 AM, "Kathryn Huxtable" 
wrote:

> It does. The rest of the language is rather ugly, though. -K
> 
> On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote:
> 
>> I just enjoyed the bit about perl having elegant and concise data structures
>> :-)
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Ron Wheeler]

 On 13/10/2010 7:24 PM, Barrie Treloar wrote:

On Thu, Oct 14, 2010 at 9:34 AM, Graham Leggett  wrote:
[del]

As soon as you need to start documenting things, you're starting to go
wrong. Practically, you may have to document some things, such as where to
get certificates for access, but you should strive to keep this
documentation to zero or as near zero as humanly possible.

Documentation costs money to write, it costs money to read, it costs money
when someone missed the vital bit of the documentation and things go wrong.
This is where the "configuration by convention" really shines. If you know
the convention, you don't need to waste time with documentation,
troubleshooting, customisation, you just get on with it.

While in principle I agree, it assumes that the developer has
bootstrapped knowledge about how maven does stuff.

This is where people need to read the books on maven development.
So once they have read (and understood) the books at
http://maven.apache.org/articles.html then your statements become
true.

Maven does lack a "best practices" documentation that sorts out "what 
you can do with Maven" from "what you should do with Maven".
You can do damn near anything with but most of these things are evil and 
work against your best interests.

This is because my experience has been that a developer using Ant has
to learn Ant in order to get the build working, they become a
semi-expert or at least an advanced Ant user.
But those that use Maven can stay at a very basic level of Maven
understanding, "mvn install" and you are done.
The down side is that because they get stuck at a basic level it
becomes more difficult to become an advanced user.
Not becuase becoming an advanced user is hard, but they are not forced
to become one.
I do not want to become an expert Maven user. I have a very large portal 
in production made up of over 60 Mavenize projects.
I just need Maven to work and do its thing without me having to bend it 
to some crazy workflow that I used before we adopted Maven.
I do not want to use any more plug-ins than I have to (3 so far) and I 
certainly do not want my team writing plug-ins or Ant procedures to 
build the web services, servlets and stand-alone applications that we 
need, if minor changes to our mindsets will avoid the need.



So it does mean that they lean on the local maven expert for knowledge
and when things go wrong have more trouble working out why and how to
fix it.

One should not try to force bad workflow practices onto Maven.
If one does things in a sensible way, a team does not need an Maven expert.


Having been the Ant expert and attempting to build the "one ant build
file for any project", I was finding this more and more difficult and
complex to achieve and maintain.
I found Maven 2 a few years back and I've never regretted the
decision, and as a last resort (because I'm too lazy to write a plugin
or the solution is too once off)  I can always write an Ant snippet to
do some work that maven will run for me but not like the original
poster who started this thread off.

Ant is a wonderful programming language that I have also used in the 
past but I am not going to make my Java developers learn it in order 
build Java applications.
I want them to be Java, Spring, Hibernate and application design experts 
and any time they spend on warping Eclipse/STS or the build process is 
wasted.
Maven and Eclipse/STS has done what we need out of the box using the GUI 
POM editor.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Barrie Treloar]

On Thu, Oct 14, 2010 at 9:59 AM, Benson Margulies  wrote:
> I'm concerned that the circle of congratulations here is somewhat
> oversimplifying this.
>
> I've brought Maven into my day job.
>
> I've arranged all the code involved to follow the maven way of doing things.
>
> And yet, I have some POM files that are veritable thickets of XML, and
> attract a fair amount of unfavorable commentary from the people who
> work for me.

This is the crux of my comment about advanced Maven users compared
with advanced Ant users.
When you extend your pom file piece by piece, each piece on itself is
easily understandable.
But when you get the less experienced person looking at the completed
pom they are overwhelmed.
I dont have any suggestions for this except to convince them to skill up.
I'd suggest that any alternative build system would still be at least
as ugly to read and understand.

[del]

> I don't hate on Maven. But I think that some people who show up on
> this list in a state of frustration get pretty short shrift.

That basic work flow of compile and install jars to repo should work
out of the box with no issues.
All of your examples are the "extra" bits over and above this, which
definitely have some wrinkles.
And mostly the wrinkles are around working out what the convention should be.

The benefit is that as more people work out the convention they can be
coded once in the plugin and all users can benefit from it.
The problem is that very few people actually do this.
If you compare this to Ant you are on your own, writing a build
maintained by one.

Personally, I am amazed when people expect a tool to do everything and
anything they can think of out of the box.
It takes an enormous amount of effort to get to that state, but it is
slowly getting there.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Benson Margulies]

I'm concerned that the circle of congratulations here is somewhat
oversimplifying this.

I've brought Maven into my day job.

I've arranged all the code involved to follow the maven way of doing things.

And yet, I have some POM files that are veritable thickets of XML, and
attract a fair amount of unfavorable commentary from the people who
work for me.

Howcome? Well, convention over configuration is great ... *when the
situation is covered by the convention*. There tends to be a steep
step function in complexity from a trivial POM to any other.

For just one example, consider a POM that uses jetty with failsafe to
run integration tests against a web container. I could come up with
some other examples where, with no use of antrun, my poms are way too
long and verbose to be easily read or digested.

Or, consider the fun and games involved in JNI usage, which forces me
to wrap all my poms in makefiles to get the environment set correctly.

In another realm, the site plugin is a never-ending source of
frustration for some of us, given it's tendency to run the javadoc six
or seven times.

I don't hate on Maven. But I think that some people who show up on
this list in a state of frustration get pretty short shrift.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Barrie Treloar]

On Thu, Oct 14, 2010 at 9:34 AM, Graham Leggett  wrote:
[del]
> As soon as you need to start documenting things, you're starting to go
> wrong. Practically, you may have to document some things, such as where to
> get certificates for access, but you should strive to keep this
> documentation to zero or as near zero as humanly possible.
>
> Documentation costs money to write, it costs money to read, it costs money
> when someone missed the vital bit of the documentation and things go wrong.
> This is where the "configuration by convention" really shines. If you know
> the convention, you don't need to waste time with documentation,
> troubleshooting, customisation, you just get on with it.

While in principle I agree, it assumes that the developer has
bootstrapped knowledge about how maven does stuff.

This is where people need to read the books on maven development.
So once they have read (and understood) the books at
http://maven.apache.org/articles.html then your statements become
true.

This is because my experience has been that a developer using Ant has
to learn Ant in order to get the build working, they become a
semi-expert or at least an advanced Ant user.
But those that use Maven can stay at a very basic level of Maven
understanding, "mvn install" and you are done.
The down side is that because they get stuck at a basic level it
becomes more difficult to become an advanced user.
Not becuase becoming an advanced user is hard, but they are not forced
to become one.
So it does mean that they lean on the local maven expert for knowledge
and when things go wrong have more trouble working out why and how to
fix it.

Having been the Ant expert and attempting to build the "one ant build
file for any project", I was finding this more and more difficult and
complex to achieve and maintain.
I found Maven 2 a few years back and I've never regretted the
decision, and as a last resort (because I'm too lazy to write a plugin
or the solution is too once off)  I can always write an Ant snippet to
do some work that maven will run for me but not like the original
poster who started this thread off.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Graham Leggett]

On 13 Oct 2010, at 10:52 PM, Wendy Smoak wrote:


Help with the website is always welcome.

The source code for the website is here:
http://svn.apache.org/repos/asf/maven/site/trunk/
The home page is down at
http://svn.apache.org/repos/asf/maven/site/trunk/src/site/xdoc/index.xml.vm
(Most other pages are under src/site/apt).

If you need help editing/building/submitting a patch, come join us on
the dev list and ask.

(Graham, would you be okay with having your post adapted for the
website, should someone have the time and energy to work on it?)


Definitely.

I think some key points maven needs to make are these:

- "Maven already knows how to do stuff. Now step aside, and let maven  
do what it has to do, don't get in maven's way".


- "You don't need to customise maven to fit your project, customise  
your project to fit maven".


- "If you need to document your build, you're doing it wrong".

Maven knows how to do stuff. So do developers who know how to use maven.

If you've used maven correctly, you don't need to document anything at  
all. You tell your new developer "here's the URL of the maven- 
generated site, off you go".


The developer knows where on the site to find the location of the  
project in SCM. The developer checks out the project. The developer  
knows how to build the project. The developer knows how to obtain all  
the dependencies. The developer knows how to release the project when  
they're done. The developer didn't need to read a single piece of  
documentation that wasn't autogenerated for your project.


As soon as you need to start documenting things, you're starting to go  
wrong. Practically, you may have to document some things, such as  
where to get certificates for access, but you should strive to keep  
this documentation to zero or as near zero as humanly possible.


Documentation costs money to write, it costs money to read, it costs  
money when someone missed the vital bit of the documentation and  
things go wrong. This is where the "configuration by convention"  
really shines. If you know the convention, you don't need to waste  
time with documentation, troubleshooting, customisation, you just get  
on with it.


Regards,
Graham
--


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Wendy Smoak]

On Wed, Oct 13, 2010 at 4:35 PM, Ron Wheeler
 wrote:
>  Excellent!!! I wish I could express myself as clearly and elegantly.
> This should be on the front page of the Maven website (or right next to it).

Help with the website is always welcome.

The source code for the website is here:
http://svn.apache.org/repos/asf/maven/site/trunk/
The home page is down at
http://svn.apache.org/repos/asf/maven/site/trunk/src/site/xdoc/index.xml.vm
(Most other pages are under src/site/apt).

If you need help editing/building/submitting a patch, come join us on
the dev list and ask.

(Graham, would you be okay with having your post adapted for the
website, should someone have the time and energy to work on it?)

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Ron Wheeler]

 Excellent!!! I wish I could express myself as clearly and elegantly.
This should be on the front page of the Maven website (or right next to it).

On 13/10/2010 3:53 PM, Graham Leggett wrote:

On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote:


Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven?


A comparison would make little sense, because ant and maven aren't 
alternatives for one another. Ant is a language that allows you to 
create custom build scripts, but you are required to write those build 
scripts yourself, over and over again. Maven on the other hand arrives 
with built in knowledge on how to build things, you are only required 
to tell maven the basics, like the name of the artifact, the version, 
etc. Maven does everything else for you without you having to tell it 
how to do it.



As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.


I predict the core of your problem is "as an ant+ivy user...".

With ant, you adopt the mindset "I need to tell ant to do X, then Y, 
then Z". With maven, you don't tell it how to do anything, it already 
knows how to do stuff.


If you try and approach maven with the idea that you want to tell 
maven to do X, Y and then Z, you'll very quickly come unstuck, because 
you'll be fighting with maven, trying to convince it to do things in 
your order instead of maven's built in order.


Maven already knows how to do stuff. All you need to do is fill in the 
blanks. Tell maven what kind of artifact it is, what it is called. And 
don't stray from the defaults - you don't need to put your source code 
in some weird directory structure, if maven defaults to src/main/java, 
put your code in src/main/java and leave it at that.


When you find yourself in a situation where you have a 5 line pom 
file, with hundreds of plugins all custom configured, you're fighting 
against maven. This isn't maven's fault, this is the fault of the 
person who created the pom. Keep it simple, keep it to default behaviour.



With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson.


In my experience, I have not once encountered an ant build that 
worked, ever. The reason was simple: the build is always secondary to 
the code itself. Inevitably, the ant build only performed the basics, 
even "ant clean" was left out most of the time. Every single one I 
encountered had some or other path that was hard coded to "C:\Program 
Files\..." with the developer expecting everyone else to just recreate 
the same directory structure, it was ridiculous. Maven has gone off 
and solved the build problem, it does not rely on every developer's 
half hearted attempt to write a build script when they're under 
pressure to produce code, not build.


At the core of ant is the question "how do I make ant do this?".

At the core of maven is the question "how does maven do this.".

Remove the "I" from the equation, and just do it like maven wants you 
to do it, and suddenly everything becomes a *lot* more reliable.



I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other?


Yes.

The whole point of maven is repeatability. What that means 
practically, is that ops call you and say "we have problem X in 
production, v2.3.4 of the code, can you fix it".


If you cannot get v2.3.4 of the code - and by that I mean precisely 
v2.3.4 of the code - up and running in your development environment, 
you're toast.


To do that, v2.3.4 of the code must be built against a pristine tag. 
And v2.3.4 of the code must depend on other jars who were also built 
from a pristine tag.


What a SNAPSHOT is is a great big red flag that says "ALL BETS ARE 
OFF". SNAPSHOTs are built from random untraceable working copies. You 
should *never* allow a SNAPSHOT to find its way into production.


When you use the maven-release-plugin (and you should), it performs 
all the checks and balances to verify that your build is entirely free 
of SNAPSHOTs, and that your code is checked in cleanly.


Regards,
Graham
--


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Graham Leggett]

On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote:


Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven?


A comparison would make little sense, because ant and maven aren't  
alternatives for one another. Ant is a language that allows you to  
create custom build scripts, but you are required to write those build  
scripts yourself, over and over again. Maven on the other hand arrives  
with built in knowledge on how to build things, you are only required  
to tell maven the basics, like the name of the artifact, the version,  
etc. Maven does everything else for you without you having to tell it  
how to do it.



As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.


I predict the core of your problem is "as an ant+ivy user...".

With ant, you adopt the mindset "I need to tell ant to do X, then Y,  
then Z". With maven, you don't tell it how to do anything, it already  
knows how to do stuff.


If you try and approach maven with the idea that you want to tell  
maven to do X, Y and then Z, you'll very quickly come unstuck, because  
you'll be fighting with maven, trying to convince it to do things in  
your order instead of maven's built in order.


Maven already knows how to do stuff. All you need to do is fill in the  
blanks. Tell maven what kind of artifact it is, what it is called. And  
don't stray from the defaults - you don't need to put your source code  
in some weird directory structure, if maven defaults to src/main/java,  
put your code in src/main/java and leave it at that.


When you find yourself in a situation where you have a 5 line pom  
file, with hundreds of plugins all custom configured, you're fighting  
against maven. This isn't maven's fault, this is the fault of the  
person who created the pom. Keep it simple, keep it to default  
behaviour.



With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson.


In my experience, I have not once encountered an ant build that  
worked, ever. The reason was simple: the build is always secondary to  
the code itself. Inevitably, the ant build only performed the basics,  
even "ant clean" was left out most of the time. Every single one I  
encountered had some or other path that was hard coded to "C:\Program  
Files\..." with the developer expecting everyone else to just recreate  
the same directory structure, it was ridiculous. Maven has gone off  
and solved the build problem, it does not rely on every developer's  
half hearted attempt to write a build script when they're under  
pressure to produce code, not build.


At the core of ant is the question "how do I make ant do this?".

At the core of maven is the question "how does maven do this.".

Remove the "I" from the equation, and just do it like maven wants you  
to do it, and suddenly everything becomes a *lot* more reliable.



I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other?


Yes.

The whole point of maven is repeatability. What that means  
practically, is that ops call you and say "we have problem X in  
production, v2.3.4 of the code, can you fix it".


If you cannot get v2.3.4 of the code - and by that I mean precisely  
v2.3.4 of the code - up and running in your development environment,  
you're toast.


To do that, v2.3.4 of the code must be built against a pristine tag.  
And v2.3.4 of the code must depend on other jars who were also built  
from a pristine tag.


What a SNAPSHOT is is a great big red flag that says "ALL BETS ARE  
OFF". SNAPSHOTs are built from random untraceable working copies. You  
should *never* allow a SNAPSHOT to find its way into production.


When you use the maven-release-plugin (and you should), it performs  
all the checks and balances to verify that your build is entirely free  
of SNAPSHOTs, and that your code is checked in cleanly.


Regards,
Graham
--


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Benson Margulies]

This thread has jumped the shark. I recommend letting it drown.

On Wed, Oct 13, 2010 at 3:44 PM, Jason Chaffee  wrote:
> I agree with how things seem to run differently on cmd-line, vs. eclipse, vs. 
> Hudson.  I can be extremely frustrating.
>
> However, maven does take a "convention over configuration" approach to things 
> for the most part.   Many times the problems people encounter are not 
> following the convention and they are trying to configure maven to do 
> something that isn't a best practice.
>
> -Original Message-
> From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
> Sent: Wednesday, October 13, 2010 11:52 AM
> To: Maven Users List
> Subject: Re: maven is a swamp
>
> On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:
>>
>> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
>>
>>> Suprisingly maven is not the first programming language to use XML
>>
>> This is worth clarifying.  What makes Maven unique, and I believe 
>> groundbreaking, is that the POM is declarative, not procedural.  It is not a 
>> programming language in the traditional sense.  There are many examples of 
>> procedural languages written in XML, and many agree they are painful to use. 
>>  That's why the one that was used in Maven 1.x is notably absent from Maven 
>> 2.x
>
> Many traditional programming languages are declarative and not
> procedural or are based on declarative concepts, most of the time the
> declarative nature of such languages proved itself problematic.
> But seriously is there a comparison matrix somewhere which compares
> ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
> (yes, i hand-wrote poms for about 15 projects) which mostly depend on
> each other, I got them all published in nexus etc. I must say that I'm
> pretty shaken how unreliable maven build are.
> With ant it either works or not. If it works, it works everywhere, in
> console, in eclipse in hudson. With maven, I got plenty of builds that
> run in console but not in eclipse, or in eclipse but not in hudson, or
> in hudson but not in console. Besides that I haven't found anything in
> maven that isn't present in ant somehow, except for parent-poms, but
> they got added to the recent ivy release so they don't count anymore
> ;-)
>
> I find it pretty hard to maintain versions with maven. Do I have to
> make them all depend on RELEASE version of each other? Distinct
> versions of each other? SNAPSHOTS? I started with snapshot, but I
> couldn't publish a second version without republishing everything, so
> I consider this bad idea...
>
> regards
> Leon
>
> P.S. Is there a documentation somewhere which really describes which
> lifecycle phase is meant for what?
>
> .
>>
>> Once you get used to the paradigm shift and get used to it, it becomes 
>> remarkably easy to look at any build and find what it is doing.  While many 
>> systems (like Ivy) have started using Maven's central repository, if they 
>> use procedural descriptions of a build, they are missing the vision that 
>> Maven has.
>>
>> Personally, I find it frustrating to have to dissect an Ant build to figure 
>> out what's going on.  A Maven build is validated against a schema, and 
>> finding what I am looking for is predictable and quick.  It's also fast to 
>> write, since most IDEs can do type-completion with a schema declaration, and 
>> many have been augmented to read plugin.xml files inside plugins to do type 
>> completion of plugin configuration as well.
>>
>> Lastly, having a validated structure for the build allows IDEs to import the 
>> POM directly, and because the Plugin interface is so simple, it's easy for 
>> IDEs to integrate against plugins.  In my experience, this level of 
>> integration is unique to Maven.
>>
>> Hope you stick with it.  Maven will really grow on you, as it has with a 
>> huge number of folks over the last few years.
>>
>> Brian
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: maven is a swamp

[Jason Chaffee]

I agree with how things seem to run differently on cmd-line, vs. eclipse, vs. 
Hudson.  I can be extremely frustrating.

However, maven does take a "convention over configuration" approach to things 
for the most part.   Many times the problems people encounter are not following 
the convention and they are trying to configure maven to do something that 
isn't a best practice.

-Original Message-
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] 
Sent: Wednesday, October 13, 2010 11:52 AM
To: Maven Users List
Subject: Re: maven is a swamp

On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:
>
> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
>
>> Suprisingly maven is not the first programming language to use XML
>
> This is worth clarifying.  What makes Maven unique, and I believe 
> groundbreaking, is that the POM is declarative, not procedural.  It is not a 
> programming language in the traditional sense.  There are many examples of 
> procedural languages written in XML, and many agree they are painful to use.  
> That's why the one that was used in Maven 1.x is notably absent from Maven 2.x

Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)

I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...

regards
Leon

P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?

.
>
> Once you get used to the paradigm shift and get used to it, it becomes 
> remarkably easy to look at any build and find what it is doing.  While many 
> systems (like Ivy) have started using Maven's central repository, if they use 
> procedural descriptions of a build, they are missing the vision that Maven 
> has.
>
> Personally, I find it frustrating to have to dissect an Ant build to figure 
> out what's going on.  A Maven build is validated against a schema, and 
> finding what I am looking for is predictable and quick.  It's also fast to 
> write, since most IDEs can do type-completion with a schema declaration, and 
> many have been augmented to read plugin.xml files inside plugins to do type 
> completion of plugin configuration as well.
>
> Lastly, having a validated structure for the build allows IDEs to import the 
> POM directly, and because the Plugin interface is so simple, it's easy for 
> IDEs to integrate against plugins.  In my experience, this level of 
> integration is unique to Maven.
>
> Hope you stick with it.  Maven will really grow on you, as it has with a huge 
> number of folks over the last few years.
>
> Brian
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Ron Wheeler]

 On 13/10/2010 2:52 PM, Leon Rosenberg wrote:

On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:

On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:


Suprisingly maven is not the first programming language to use XML

This is worth clarifying.  What makes Maven unique, and I believe 
groundbreaking, is that the POM is declarative, not procedural.  It is not a 
programming language in the traditional sense.  There are many examples of 
procedural languages written in XML, and many agree they are painful to use.  
That's why the one that was used in Maven 1.x is notably absent from Maven 2.x

Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)

I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...

regards
Leon

P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?


Maven is really missing a best practice section.
You can do almost anything with Maven but most of those things are 
really bad ways to go about developing.


If you read the workflows that people are trying to shoehorn into Maven, 
you would think that there are no standard platforms for running 
applications and each company writes their own web server.
I can not believe that there are so many different ways to deploy java 
applications.




.

Once you get used to the paradigm shift and get used to it, it becomes 
remarkably easy to look at any build and find what it is doing.  While many 
systems (like Ivy) have started using Maven's central repository, if they use 
procedural descriptions of a build, they are missing the vision that Maven has.

Personally, I find it frustrating to have to dissect an Ant build to figure out 
what's going on.  A Maven build is validated against a schema, and finding what 
I am looking for is predictable and quick.  It's also fast to write, since most 
IDEs can do type-completion with a schema declaration, and many have been 
augmented to read plugin.xml files inside plugins to do type completion of 
plugin configuration as well.

Lastly, having a validated structure for the build allows IDEs to import the 
POM directly, and because the Plugin interface is so simple, it's easy for IDEs 
to integrate against plugins.  In my experience, this level of integration is 
unique to Maven.

Hope you stick with it.  Maven will really grow on you, as it has with a huge 
number of folks over the last few years.

Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Leon Rosenberg]

On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping  wrote:
>
> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:
>
>> Suprisingly maven is not the first programming language to use XML
>
> This is worth clarifying.  What makes Maven unique, and I believe 
> groundbreaking, is that the POM is declarative, not procedural.  It is not a 
> programming language in the traditional sense.  There are many examples of 
> procedural languages written in XML, and many agree they are painful to use.  
> That's why the one that was used in Maven 1.x is notably absent from Maven 2.x

Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven? As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson. With maven, I got plenty of builds that
run in console but not in eclipse, or in eclipse but not in hudson, or
in hudson but not in console. Besides that I haven't found anything in
maven that isn't present in ant somehow, except for parent-poms, but
they got added to the recent ivy release so they don't count anymore
;-)

I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other? Distinct
versions of each other? SNAPSHOTS? I started with snapshot, but I
couldn't publish a second version without republishing everything, so
I consider this bad idea...

regards
Leon

P.S. Is there a documentation somewhere which really describes which
lifecycle phase is meant for what?

.
>
> Once you get used to the paradigm shift and get used to it, it becomes 
> remarkably easy to look at any build and find what it is doing.  While many 
> systems (like Ivy) have started using Maven's central repository, if they use 
> procedural descriptions of a build, they are missing the vision that Maven 
> has.
>
> Personally, I find it frustrating to have to dissect an Ant build to figure 
> out what's going on.  A Maven build is validated against a schema, and 
> finding what I am looking for is predictable and quick.  It's also fast to 
> write, since most IDEs can do type-completion with a schema declaration, and 
> many have been augmented to read plugin.xml files inside plugins to do type 
> completion of plugin configuration as well.
>
> Lastly, having a validated structure for the build allows IDEs to import the 
> POM directly, and because the Plugin interface is so simple, it's easy for 
> IDEs to integrate against plugins.  In my experience, this level of 
> integration is unique to Maven.
>
> Hope you stick with it.  Maven will really grow on you, as it has with a huge 
> number of folks over the last few years.
>
> Brian
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[chemit]

Le Wed, 13 Oct 2010 11:52:04 -0400,
Ron Wheeler  a écrit :

>   I was just replying to the list using the last post in the
> conversation.
> 
> Not to anyone in particular.
> 
My bad in that case :) 
> 
> 
> On 13/10/2010 9:57 AM, chemit wrote:
> > Le Wed, 13 Oct 2010 08:58:27 -0400,
> > Ron Wheeler  a écrit :
> >
> >>Doing the wrong thing and not using an IDE with a POM editor is
> >> not a good recipe for a smooth development cycle.
> >> I will admit to occasionally editing XML but that is for extreme
> >> cases while you are getting set up..
> >>
> > euh wrong person :)
> >
> > You should have respond to previous mail, ... I love maven and all
> > the xml stuff (arch to su much in facts.) I was just responding to
> > the guy Kenneth which seems to be pretty angry with Maven and xml ;)
> >
> >
> >> If you don't like XML:
> >> 1) Get your development workflow Mavenized
> >> 2) Get a Maven Repo set up
> >> 3) Restructure your projects to fit the way Maven works
> >> 3) Use an IDE that supports Maven with a proper human oriented
> >> editor
> >> - Eclipse STS is very good at this.
> >>
> >> Then you will have no need of XML editing and no need to screw
> >> around with command line Maven or custom plug-ins or custom goals.
> >> You will not spend a lot of time in this forum moaning about the
> >> unfairness of life and the difficulty of using Maven.
> >>
> >> Once you start using Maven properly, it is a very high level tool
> >> for building Java applications such as:
> >> Java WebServices
> >> Java Servlets
> >> Java Portlets
> >> Java Standalone applications
> >>
> >> If you are building something else, my comments may not be
> >> relevant.
> >>
> >>
> >> Ron
> >>
> >>
> >>
> >> On 13/10/2010 2:47 AM, chemit wrote:
> >>> Le Tue, 12 Oct 2010 19:35:46 -0500,
> >>> Kenneth McDonald   a écrit :
> >>>
>  Yes, I realize this is flamebait, but after trying to puzzle out
>  the following maven plugin:
> 
>    
>    maven-antrun-plugin
>    1.6
>    
>    
>    deploy
>    deploy-gh-pages
>    
>    run
>    
>    
>    
>  location=""/>   
>    
>    
>  dir="${gh-pages-dir}">   
>    
>  dir="${gh-pages-dir}">   
>    
>    
>    
>    
>    
>    
> 
>  I simply can't resist. Whoever in their right mind decided
>  software developers to think that requiring other developers to
>  write config files in XML was a proper decision?
> 
>  Python, Ruby, and (yes even Perl) have had had much more elegant
>  and concise ways of managing complex data structures for years
>  now. And there's a reason JSON has become so popular--primarily
>  because XML is not, and was never intended to be, a format for
>  developers to write specifications in.
> >>> First of all using the ant plugin is against "Best pratices", so
> >>> for me and from this point, why critisize something when you are
> >>> doing it the wrong way ?
> >>>
>  Let's take a look at the most obvious of the problems in the
>  above:
> 
>  location=""/>   
>    
>    
>  dir="${gh-pages-dir}">   
>    
>  dir="${gh-pages-dir}">   
>    
> 
>  Now, I'm still very new to maven, but it strikes me that what the
>  above is saying is (in Pythonic code, but feel free to convert to
>  your own):
> 
>  import git
>  gh-pages-dir = ""
>  git(dir=gh-pages-dir, "add .")
>  git(dir=gh-pages-dir, "commit")
>  git(dir=gh-pages-dir, "push origin gh-pages")
> 
>  I'm sure there are errors in the translation--but I'm equally
>  sure that if these errors were corrected, they would not
>  substantially alter the ratio of XML to Pythonic code. Ruby and
>  even Perl would do just as well.
> 
> >>> but if it is so simple as you say, you should be able to write
> >>> your simply code without any doubt...
> >>>
>  So here's a challenge to the (very intelligent) folks at apache.
>  Open your minds to the fact that XML is not only the Final
>  Solution, but isn't even close to the b

Re: maven is a swamp

[Ron Wheeler]

 I was just replying to the list using the last post in the conversation.

Not to anyone in particular.



On 13/10/2010 9:57 AM, chemit wrote:

Le Wed, 13 Oct 2010 08:58:27 -0400,
Ron Wheeler  a écrit :


   Doing the wrong thing and not using an IDE with a POM editor is not
a good recipe for a smooth development cycle.
I will admit to occasionally editing XML but that is for extreme
cases while you are getting set up..


euh wrong person :)

You should have respond to previous mail, ... I love maven and all the
xml stuff (arch to su much in facts.) I was just responding to the guy
Kenneth which seems to be pretty angry with Maven and xml ;)



If you don't like XML:
1) Get your development workflow Mavenized
2) Get a Maven Repo set up
3) Restructure your projects to fit the way Maven works
3) Use an IDE that supports Maven with a proper human oriented editor
- Eclipse STS is very good at this.

Then you will have no need of XML editing and no need to screw around
with command line Maven or custom plug-ins or custom goals.
You will not spend a lot of time in this forum moaning about the
unfairness of life and the difficulty of using Maven.

Once you start using Maven properly, it is a very high level tool for
building Java applications such as:
Java WebServices
Java Servlets
Java Portlets
Java Standalone applications

If you are building something else, my comments may not be relevant.


Ron



On 13/10/2010 2:47 AM, chemit wrote:

Le Tue, 12 Oct 2010 19:35:46 -0500,
Kenneth McDonald   a écrit :


Yes, I realize this is flamebait, but after trying to puzzle out
the following maven plugin:

  
  maven-antrun-plugin
  1.6
  
  
  deploy
  deploy-gh-pages
  
  run
  
  
  
 
  
  
 
  
 
  
  
  
  
  
  

I simply can't resist. Whoever in their right mind decided software
developers to think that requiring other developers to write config
files in XML was a proper decision?

Python, Ruby, and (yes even Perl) have had had much more elegant
and concise ways of managing complex data structures for years
now. And there's a reason JSON has become so popular--primarily
because XML is not, and was never intended to be, a format for
developers to write specifications in.

First of all using the ant plugin is against "Best pratices", so
for me and from this point, why critisize something when you are
doing it the wrong way ?


Let's take a look at the most obvious of the problems in the above:

 
  
  
 
  
 
  

Now, I'm still very new to maven, but it strikes me that what the
above is saying is (in Pythonic code, but feel free to convert to
your own):

import git
gh-pages-dir = ""
git(dir=gh-pages-dir, "add .")
git(dir=gh-pages-dir, "commit")
git(dir=gh-pages-dir, "push origin gh-pages")

I'm sure there are errors in the translation--but I'm equally sure
that if these errors were corrected, they would not substantially
alter the ratio of XML to Pythonic code. Ruby and even Perl would
do just as well.


but if it is so simple as you say, you should be able to write your
simply code without any doubt...


So here's a challenge to the (very intelligent) folks at apache.
Open your minds to the fact that XML is not only the Final
Solution, but isn't even close to the best solution, and start
producing some products that are configurable without an entire
manual in front of oneself. I realize that arriving at an optimal
solution is not really possible, but XML is so suboptimal as to
beggar belief.

I am just so sick of using crappy "solutions" (read: XML) layered
over top of what could be good solutions.


Yes crappy is the right world, I sujjest you to go back to
MakeFile, no xml, no convention, just... CRAP :)


Sorry, had to vent. Who knows, maybe it'll do some good?

And you feel better now ?

Ken McDonald


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org







--

Re: maven is a swamp

[Kathryn Huxtable]

It does. The rest of the language is rather ugly, though. -K

On Oct 13, 2010, at 9:07 AM, Rick Mangi wrote:

> I just enjoyed the bit about perl having elegant and concise data structures
> :-)
> 
> 
> On 10/13/10 9:57 AM, "chemit"  wrote:
> 
>> Le Wed, 13 Oct 2010 08:58:27 -0400,
>> Ron Wheeler  a écrit :
>> 
>>>  Doing the wrong thing and not using an IDE with a POM editor is not
>>> a good recipe for a smooth development cycle.
>>> I will admit to occasionally editing XML but that is for extreme
>>> cases while you are getting set up..
>>> 
>> euh wrong person :)
>> 
>> You should have respond to previous mail, ... I love maven and all the
>> xml stuff (arch to su much in facts.) I was just responding to the guy
>> Kenneth which seems to be pretty angry with Maven and xml ;)
>> 
>> 
>>> If you don't like XML:
>>> 1) Get your development workflow Mavenized
>>> 2) Get a Maven Repo set up
>>> 3) Restructure your projects to fit the way Maven works
>>> 3) Use an IDE that supports Maven with a proper human oriented editor
>>> - Eclipse STS is very good at this.
>>> 
>>> Then you will have no need of XML editing and no need to screw around
>>> with command line Maven or custom plug-ins or custom goals.
>>> You will not spend a lot of time in this forum moaning about the
>>> unfairness of life and the difficulty of using Maven.
>>> 
>>> Once you start using Maven properly, it is a very high level tool for
>>> building Java applications such as:
>>> Java WebServices
>>> Java Servlets
>>> Java Portlets
>>> Java Standalone applications
>>> 
>>> If you are building something else, my comments may not be relevant.
>>> 
>>> 
>>> Ron
>>> 
>>> 
>>> 
>>> On 13/10/2010 2:47 AM, chemit wrote:
 Le Tue, 12 Oct 2010 19:35:46 -0500,
 Kenneth McDonald  a écrit :
 
> Yes, I realize this is flamebait, but after trying to puzzle out
> the following maven plugin:
> 
> 
> maven-antrun-plugin
> 1.6
> 
> 
> deploy
> deploy-gh-pages
> 
> run
> 
> 
> 
>  location=""/>  
> 
> 
>  dir="${gh-pages-dir}">  
> 
>  dir="${gh-pages-dir}">  
> 
> 
> 
> 
> 
> 
> 
> I simply can't resist. Whoever in their right mind decided software
> developers to think that requiring other developers to write config
> files in XML was a proper decision?
> 
> Python, Ruby, and (yes even Perl) have had had much more elegant
> and concise ways of managing complex data structures for years
> now. And there's a reason JSON has become so popular--primarily
> because XML is not, and was never intended to be, a format for
> developers to write specifications in.
 First of all using the ant plugin is against "Best pratices", so
 for me and from this point, why critisize something when you are
 doing it the wrong way ?
 
> Let's take a look at the most obvious of the problems in the above:
> 
>  location=""/>  
> 
> 
>  dir="${gh-pages-dir}">  
> 
>  dir="${gh-pages-dir}">  
> 
> 
> Now, I'm still very new to maven, but it strikes me that what the
> above is saying is (in Pythonic code, but feel free to convert to
> your own):
> 
> import git
> gh-pages-dir = ""
> git(dir=gh-pages-dir, "add .")
> git(dir=gh-pages-dir, "commit")
> git(dir=gh-pages-dir, "push origin gh-pages")
> 
> I'm sure there are errors in the translation--but I'm equally sure
> that if these errors were corrected, they would not substantially
> alter the ratio of XML to Pythonic code. Ruby and even Perl would
> do just as well.
> 
 but if it is so simple as you say, you should be able to write your
 simply code without any doubt...
 
> So here's a challenge to the (very intelligent) folks at apache.
> Open your minds to the fact that XML is not only the Final
> Solution, but isn't even close to the best solution, and start
> producing some products that are configurable without an entire
> manual in front of oneself. I realize that arriving at an optimal
> solution is not 

Re: maven is a swamp

[Rick Mangi]

I just enjoyed the bit about perl having elegant and concise data structures
:-)


On 10/13/10 9:57 AM, "chemit"  wrote:

> Le Wed, 13 Oct 2010 08:58:27 -0400,
> Ron Wheeler  a écrit :
> 
>>   Doing the wrong thing and not using an IDE with a POM editor is not
>> a good recipe for a smooth development cycle.
>> I will admit to occasionally editing XML but that is for extreme
>> cases while you are getting set up..
>> 
> euh wrong person :)
> 
> You should have respond to previous mail, ... I love maven and all the
> xml stuff (arch to su much in facts.) I was just responding to the guy
> Kenneth which seems to be pretty angry with Maven and xml ;)
> 
> 
>> If you don't like XML:
>> 1) Get your development workflow Mavenized
>> 2) Get a Maven Repo set up
>> 3) Restructure your projects to fit the way Maven works
>> 3) Use an IDE that supports Maven with a proper human oriented editor
>> - Eclipse STS is very good at this.
>> 
>> Then you will have no need of XML editing and no need to screw around
>> with command line Maven or custom plug-ins or custom goals.
>> You will not spend a lot of time in this forum moaning about the
>> unfairness of life and the difficulty of using Maven.
>> 
>> Once you start using Maven properly, it is a very high level tool for
>> building Java applications such as:
>> Java WebServices
>> Java Servlets
>> Java Portlets
>> Java Standalone applications
>> 
>> If you are building something else, my comments may not be relevant.
>> 
>> 
>> Ron
>> 
>> 
>> 
>> On 13/10/2010 2:47 AM, chemit wrote:
>>> Le Tue, 12 Oct 2010 19:35:46 -0500,
>>> Kenneth McDonald  a écrit :
>>> 
 Yes, I realize this is flamebait, but after trying to puzzle out
 the following maven plugin:
 
  
  maven-antrun-plugin
  1.6
  
  
  deploy
  deploy-gh-pages
  
  run
  
  
  
  >>> location=""/>  
  
  
  >>> dir="${gh-pages-dir}">  
  
  >>> dir="${gh-pages-dir}">  
  
  
  
  
  
  
 
 I simply can't resist. Whoever in their right mind decided software
 developers to think that requiring other developers to write config
 files in XML was a proper decision?
 
 Python, Ruby, and (yes even Perl) have had had much more elegant
 and concise ways of managing complex data structures for years
 now. And there's a reason JSON has become so popular--primarily
 because XML is not, and was never intended to be, a format for
 developers to write specifications in.
>>> First of all using the ant plugin is against "Best pratices", so
>>> for me and from this point, why critisize something when you are
>>> doing it the wrong way ?
>>> 
 Let's take a look at the most obvious of the problems in the above:
 
  >>> location=""/>  
  
  
  >>> dir="${gh-pages-dir}">  
  
  >>> dir="${gh-pages-dir}">  
  
 
 Now, I'm still very new to maven, but it strikes me that what the
 above is saying is (in Pythonic code, but feel free to convert to
 your own):
 
 import git
 gh-pages-dir = ""
 git(dir=gh-pages-dir, "add .")
 git(dir=gh-pages-dir, "commit")
 git(dir=gh-pages-dir, "push origin gh-pages")
 
 I'm sure there are errors in the translation--but I'm equally sure
 that if these errors were corrected, they would not substantially
 alter the ratio of XML to Pythonic code. Ruby and even Perl would
 do just as well.
 
>>> but if it is so simple as you say, you should be able to write your
>>> simply code without any doubt...
>>> 
 So here's a challenge to the (very intelligent) folks at apache.
 Open your minds to the fact that XML is not only the Final
 Solution, but isn't even close to the best solution, and start
 producing some products that are configurable without an entire
 manual in front of oneself. I realize that arriving at an optimal
 solution is not really possible, but XML is so suboptimal as to
 beggar belief.
 
 I am just so sick of using crappy "solutions" (read: XML) layered
 over top of what could be good solutions.
 
>>> Yes crappy is 

Re: maven is a swamp

[chemit]

Le Wed, 13 Oct 2010 08:58:27 -0400,
Ron Wheeler  a écrit :

>   Doing the wrong thing and not using an IDE with a POM editor is not
> a good recipe for a smooth development cycle.
> I will admit to occasionally editing XML but that is for extreme
> cases while you are getting set up..
> 
euh wrong person :) 

You should have respond to previous mail, ... I love maven and all the
xml stuff (arch to su much in facts.) I was just responding to the guy
Kenneth which seems to be pretty angry with Maven and xml ;)


> If you don't like XML:
> 1) Get your development workflow Mavenized
> 2) Get a Maven Repo set up
> 3) Restructure your projects to fit the way Maven works
> 3) Use an IDE that supports Maven with a proper human oriented editor
> - Eclipse STS is very good at this.
> 
> Then you will have no need of XML editing and no need to screw around 
> with command line Maven or custom plug-ins or custom goals.
> You will not spend a lot of time in this forum moaning about the 
> unfairness of life and the difficulty of using Maven.
> 
> Once you start using Maven properly, it is a very high level tool for 
> building Java applications such as:
> Java WebServices
> Java Servlets
> Java Portlets
> Java Standalone applications
> 
> If you are building something else, my comments may not be relevant.
> 
> 
> Ron
> 
> 
> 
> On 13/10/2010 2:47 AM, chemit wrote:
> > Le Tue, 12 Oct 2010 19:35:46 -0500,
> > Kenneth McDonald  a écrit :
> >
> >> Yes, I realize this is flamebait, but after trying to puzzle out
> >> the following maven plugin:
> >>
> >>  
> >>  maven-antrun-plugin
> >>  1.6
> >>  
> >>  
> >>  deploy
> >>  deploy-gh-pages
> >>  
> >>  run
> >>  
> >>  
> >>  
> >>   >> location=""/>  
> >>  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>
> >> I simply can't resist. Whoever in their right mind decided software
> >> developers to think that requiring other developers to write config
> >> files in XML was a proper decision?
> >>
> >> Python, Ruby, and (yes even Perl) have had had much more elegant
> >> and concise ways of managing complex data structures for years
> >> now. And there's a reason JSON has become so popular--primarily
> >> because XML is not, and was never intended to be, a format for
> >> developers to write specifications in.
> > First of all using the ant plugin is against "Best pratices", so
> > for me and from this point, why critisize something when you are
> > doing it the wrong way ?
> >
> >> Let's take a look at the most obvious of the problems in the above:
> >>
> >>   >> location=""/>  
> >>  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>   >> dir="${gh-pages-dir}">  
> >>  
> >>
> >> Now, I'm still very new to maven, but it strikes me that what the
> >> above is saying is (in Pythonic code, but feel free to convert to
> >> your own):
> >>
> >> import git
> >> gh-pages-dir = ""
> >> git(dir=gh-pages-dir, "add .")
> >> git(dir=gh-pages-dir, "commit")
> >> git(dir=gh-pages-dir, "push origin gh-pages")
> >>
> >> I'm sure there are errors in the translation--but I'm equally sure
> >> that if these errors were corrected, they would not substantially
> >> alter the ratio of XML to Pythonic code. Ruby and even Perl would
> >> do just as well.
> >>
> > but if it is so simple as you say, you should be able to write your
> > simply code without any doubt...
> >
> >> So here's a challenge to the (very intelligent) folks at apache.
> >> Open your minds to the fact that XML is not only the Final
> >> Solution, but isn't even close to the best solution, and start
> >> producing some products that are configurable without an entire
> >> manual in front of oneself. I realize that arriving at an optimal
> >> solution is not really possible, but XML is so suboptimal as to
> >> beggar belief.
> >>
> >> I am just so sick of using crappy "solutions" (read: XML) layered
> >> over top of what could be good solutions.
> >>
> > Yes crappy is the right world, I sujjest you to go back to
> > MakeFile, no xml, no convention, just... CRAP :)
> >
> >> Sorry, had to vent. Who knows, maybe it'll do some good?
> > And you feel be

Re: maven is a swamp

[Ron Wheeler]

 Doing the wrong thing and not using an IDE with a POM editor is not a 
good recipe for a smooth development cycle.
I will admit to occasionally editing XML but that is for extreme cases 
while you are getting set up..


If you don't like XML:
1) Get your development workflow Mavenized
2) Get a Maven Repo set up
3) Restructure your projects to fit the way Maven works
3) Use an IDE that supports Maven with a proper human oriented editor - 
Eclipse STS is very good at this.


Then you will have no need of XML editing and no need to screw around 
with command line Maven or custom plug-ins or custom goals.
You will not spend a lot of time in this forum moaning about the 
unfairness of life and the difficulty of using Maven.


Once you start using Maven properly, it is a very high level tool for 
building Java applications such as:

Java WebServices
Java Servlets
Java Portlets
Java Standalone applications

If you are building something else, my comments may not be relevant.


Ron



On 13/10/2010 2:47 AM, chemit wrote:

Le Tue, 12 Oct 2010 19:35:46 -0500,
Kenneth McDonald  a écrit :


Yes, I realize this is flamebait, but after trying to puzzle out the
following maven plugin:

 
 maven-antrun-plugin
 1.6
 
 
 deploy
 deploy-gh-pages
 
 run
 
 
 
   
 
 
   
 
   
 
 
 
 
 
 

I simply can't resist. Whoever in their right mind decided software
developers to think that requiring other developers to write config
files in XML was a proper decision?

Python, Ruby, and (yes even Perl) have had had much more elegant and
concise ways of managing complex data structures for years now. And
there's a reason JSON has become so popular--primarily because XML is
not, and was never intended to be, a format for developers to write
specifications in.

First of all using the ant plugin is against "Best pratices", so for me
and from this point, why critisize something when you are doing it the
wrong way ?


Let's take a look at the most obvious of the problems in the above:

   
 
 
   
 
   
 

Now, I'm still very new to maven, but it strikes me that what the
above is saying is (in Pythonic code, but feel free to convert to
your own):

import git
gh-pages-dir = ""
git(dir=gh-pages-dir, "add .")
git(dir=gh-pages-dir, "commit")
git(dir=gh-pages-dir, "push origin gh-pages")

I'm sure there are errors in the translation--but I'm equally sure
that if these errors were corrected, they would not substantially
alter the ratio of XML to Pythonic code. Ruby and even Perl would do
just as well.


but if it is so simple as you say, you should be able to write your
simply code without any doubt...


So here's a challenge to the (very intelligent) folks at apache. Open
your minds to the fact that XML is not only the Final Solution, but
isn't even close to the best solution, and start producing some
products that are configurable without an entire manual in front of
oneself. I realize that arriving at an optimal solution is not really
possible, but XML is so suboptimal as to beggar belief.

I am just so sick of using crappy "solutions" (read: XML) layered
over top of what could be good solutions.


Yes crappy is the right world, I sujjest you to go back to MakeFile, no
xml, no convention, just... CRAP :)


Sorry, had to vent. Who knows, maybe it'll do some good?

And you feel better now ?

Ken McDonald


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[chemit]

Le Tue, 12 Oct 2010 19:35:46 -0500,
Kenneth McDonald  a écrit :

> Yes, I realize this is flamebait, but after trying to puzzle out the
> following maven plugin:
> 
> 
> maven-antrun-plugin
> 1.6
> 
> 
> deploy
> deploy-gh-pages
> 
> run
> 
> 
> 
>  location=""/> 
> 
> 
>  dir="${gh-pages-dir}"> 
> 
>  dir="${gh-pages-dir}"> 
> 
> 
> 
> 
> 
> 
> 
> I simply can't resist. Whoever in their right mind decided software
> developers to think that requiring other developers to write config
> files in XML was a proper decision?
> 
> Python, Ruby, and (yes even Perl) have had had much more elegant and
> concise ways of managing complex data structures for years now. And
> there's a reason JSON has become so popular--primarily because XML is
> not, and was never intended to be, a format for developers to write
> specifications in.
First of all using the ant plugin is against "Best pratices", so for me
and from this point, why critisize something when you are doing it the
wrong way ?

> 
> Let's take a look at the most obvious of the problems in the above:
> 
>  location=""/> 
> 
> 
>  dir="${gh-pages-dir}"> 
> 
>  dir="${gh-pages-dir}"> 
> 
> 
> Now, I'm still very new to maven, but it strikes me that what the
> above is saying is (in Pythonic code, but feel free to convert to
> your own):
> 
> import git
> gh-pages-dir = ""
> git(dir=gh-pages-dir, "add .")
> git(dir=gh-pages-dir, "commit")
> git(dir=gh-pages-dir, "push origin gh-pages")
> 
> I'm sure there are errors in the translation--but I'm equally sure
> that if these errors were corrected, they would not substantially
> alter the ratio of XML to Pythonic code. Ruby and even Perl would do
> just as well. 
> 
but if it is so simple as you say, you should be able to write your
simply code without any doubt...

> So here's a challenge to the (very intelligent) folks at apache. Open
> your minds to the fact that XML is not only the Final Solution, but
> isn't even close to the best solution, and start producing some
> products that are configurable without an entire manual in front of
> oneself. I realize that arriving at an optimal solution is not really
> possible, but XML is so suboptimal as to beggar belief.
> 
> I am just so sick of using crappy "solutions" (read: XML) layered
> over top of what could be good solutions.
> 
Yes crappy is the right world, I sujjest you to go back to MakeFile, no
xml, no convention, just... CRAP :)

> Sorry, had to vent. Who knows, maybe it'll do some good?
And you feel better now ?
> 
> Ken McDonald
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 



-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
email: che...@codelutin.com  
http://www.codelutin.com 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Brian Topping]

On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:

> Suprisingly maven is not the first programming language to use XML

This is worth clarifying.  What makes Maven unique, and I believe 
groundbreaking, is that the POM is declarative, not procedural.  It is not a 
programming language in the traditional sense.  There are many examples of 
procedural languages written in XML, and many agree they are painful to use.  
That's why the one that was used in Maven 1.x is notably absent from Maven 2.x.

Once you get used to the paradigm shift and get used to it, it becomes 
remarkably easy to look at any build and find what it is doing.  While many 
systems (like Ivy) have started using Maven's central repository, if they use 
procedural descriptions of a build, they are missing the vision that Maven has. 

Personally, I find it frustrating to have to dissect an Ant build to figure out 
what's going on.  A Maven build is validated against a schema, and finding what 
I am looking for is predictable and quick.  It's also fast to write, since most 
IDEs can do type-completion with a schema declaration, and many have been 
augmented to read plugin.xml files inside plugins to do type completion of 
plugin configuration as well.

Lastly, having a validated structure for the build allows IDEs to import the 
POM directly, and because the Plugin interface is so simple, it's easy for IDEs 
to integrate against plugins.  In my experience, this level of integration is 
unique to Maven.

Hope you stick with it.  Maven will really grow on you, as it has with a huge 
number of folks over the last few years.

Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: maven is a swamp

[Martin Gainty]

Think of maven is a way to declare operations and attributes to acheieve tasks 
in a build environment using XML
Suprisingly maven is not the first programming language to use XML
ColdFusion is composed of XML declarative descriptors to express operations 
thru element descriptors and operators as attributes
In the 1990s Ant being the only tool build available to create as well as 
deploy jars, wars and ears is also implemented using XML
A short description is available here:
http://en.wikipedia.org/wiki/XML
 
If your idea is to come up with a programmatic interface such as API then your 
architecture will help Maven expand its user-base

(Not a spokesman for Jason or Brett)
Martin Gainty~Hungry Alligator
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.



 

> Subject: maven is a swamp
> From: kenneth.m.mcdon...@sbcglobal.net
> Date: Tue, 12 Oct 2010 19:35:46 -0500
> To: users@maven.apache.org
> 
> Yes, I realize this is flamebait, but after trying to puzzle out the 
> following maven plugin:
> 
> 
> maven-antrun-plugin
> 1.6
> 
> 
> deploy
> deploy-gh-pages
> 
> run
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I simply can't resist. Whoever in their right mind decided software 
> developers to think that requiring other developers to write config files in 
> XML was a proper decision?
> 
> Python, Ruby, and (yes even Perl) have had had much more elegant and concise 
> ways of managing complex data structures for years now. And there's a reason 
> JSON has become so popular--primarily because XML is not, and was never 
> intended to be, a format for developers to write specifications in.
> 
> Let's take a look at the most obvious of the problems in the above:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Now, I'm still very new to maven, but it strikes me that what the above is 
> saying is (in Pythonic code, but feel free to convert to your own):
> 
> import git
> gh-pages-dir = ""
> git(dir=gh-pages-dir, "add .")
> git(dir=gh-pages-dir, "commit")
> git(dir=gh-pages-dir, "push origin gh-pages")
> 
> I'm sure there are errors in the translation--but I'm equally sure that if 
> these errors were corrected, they would not substantially alter the ratio of 
> XML to Pythonic code. Ruby and even Perl would do just as well. 
> 
> So here's a challenge to the (very intelligent) folks at apache. Open your 
> minds to the fact that XML is not only the Final Solution, but isn't even 
> close to the best solution, and start producing some products that are 
> configurable without an entire manual in front of oneself. I realize that 
> arriving at an optimal solution is not really possible, but XML is so 
> suboptimal as to beggar belief.
> 
> I am just so sick of using crappy "solutions" (read: XML) layered over top of 
> what could be good solutions.
> 
> Sorry, had to vent. Who knows, maybe it'll do some good?
> 
> Ken McDonald
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
  

Re: maven is a swamp

[Wayne Fay]

> Yes, I realize this is flamebait, but after trying to puzzle out the 
> following maven plugin:
>
>            
>                maven-antrun-plugin

Write a proper Maven plugin instead of leaning on the antrun plugin to
do your dirty work. They are surprisingly simple to write -- I'm sure
you can figure it out.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: maven is a swamp

[Yanko, Curtis]

Using antrun is not Maven 




Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time

-Original Message-
From: Kenneth McDonald [mailto:kenneth.m.mcdon...@sbcglobal.net] 
Sent: Tuesday, October 12, 2010 8:36 PM
To: Maven Users List
Subject: maven is a swamp

Yes, I realize this is flamebait, but after trying to puzzle out the
following maven plugin:


maven-antrun-plugin
1.6


deploy
deploy-gh-pages

run



















I simply can't resist. Whoever in their right mind decided software
developers to think that requiring other developers to write config
files in XML was a proper decision?

Python, Ruby, and (yes even Perl) have had had much more elegant and
concise ways of managing complex data structures for years now. And
there's a reason JSON has become so popular--primarily because XML is
not, and was never intended to be, a format for developers to write
specifications in.

Let's take a look at the most obvious of the problems in the above:












Now, I'm still very new to maven, but it strikes me that what the above
is saying is (in Pythonic code, but feel free to convert to your own):

import git
gh-pages-dir = ""
git(dir=gh-pages-dir, "add .")
git(dir=gh-pages-dir, "commit")
git(dir=gh-pages-dir, "push origin gh-pages")

I'm sure there are errors in the translation--but I'm equally sure that
if these errors were corrected, they would not substantially alter the
ratio of XML to Pythonic code. Ruby and even Perl would do just as well.


So here's a challenge to the (very intelligent) folks at apache. Open
your minds to the fact that XML is not only the Final Solution, but
isn't even close to the best solution, and start producing some products
that are configurable without an entire manual in front of oneself. I
realize that arriving at an optimal solution is not really possible, but
XML is so suboptimal as to beggar belief.

I am just so sick of using crappy "solutions" (read: XML) layered over
top of what could be good solutions.

Sorry, had to vent. Who knows, maybe it'll do some good?

Ken McDonald


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Wendy Smoak]

On Tue, Oct 12, 2010 at 8:35 PM, Kenneth McDonald
 wrote:
> Yes, I realize this is flamebait, but after trying to puzzle out the 
> following maven plugin:

You are complaining about using Ant to execute Git to do something
inside a Maven build?  Yeah, that's going to be ugly.

In the event you actually want to improve this, you might look to see
if "mvn site-deploy" can work with a git url in
distributionManagement/site/url.  I know it's possible to publish
sites to Subversion, but I've never tried it with Git.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Andrew Close]

wow, you're wish has almost been granted.
check out polyglot maven.

On Tue, Oct 12, 2010 at 7:35 PM, Kenneth McDonald
 wrote:
> Yes, I realize this is flamebait, but after trying to puzzle out the 
> following maven plugin:
>
>            
>                maven-antrun-plugin
>                1.6
>                
>                    
>                        deploy
>                        deploy-gh-pages
>                        
>                            run
>                        
>                        
>                            
>                                
>                                
>                                    
>                                
>                                
>                                    
>                                
>                                
>                                    
>                                
>                            
>                        
>                    
>                
>            
>
> I simply can't resist. Whoever in their right mind decided software 
> developers to think that requiring other developers to write config files in 
> XML was a proper decision?
>
> Python, Ruby, and (yes even Perl) have had had much more elegant and concise 
> ways of managing complex data structures for years now. And there's a reason 
> JSON has become so popular--primarily because XML is not, and was never 
> intended to be, a format for developers to write specifications in.
>
> Let's take a look at the most obvious of the problems in the above:
>
>                                
>                                
>                                    
>                                
>                                
>                                    
>                                
>                                
>                                    
>                                
>
> Now, I'm still very new to maven, but it strikes me that what the above is 
> saying is (in Pythonic code, but feel free to convert to your own):
>
> import git
> gh-pages-dir = ""
> git(dir=gh-pages-dir, "add .")
> git(dir=gh-pages-dir, "commit")
> git(dir=gh-pages-dir, "push origin gh-pages")
>
> I'm sure there are errors in the translation--but I'm equally sure that if 
> these errors were corrected, they would not substantially alter the ratio of 
> XML to Pythonic code. Ruby and even Perl would do just as well.
>
> So here's a challenge to the (very intelligent) folks at apache. Open your 
> minds to the fact that XML is not only the Final Solution, but isn't even 
> close to the best solution, and start producing some products that are 
> configurable without an entire manual in front of oneself. I realize that 
> arriving at an optimal solution is not really possible, but XML is so 
> suboptimal as to beggar belief.
>
> I am just so sick of using crappy "solutions" (read: XML) layered over top of 
> what could be good solutions.
>
> Sorry, had to vent. Who knows, maybe it'll do some good?
>
> Ken McDonald
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>



-- 
Andrew Close

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven is a swamp

[Kenneth McDonald]

Yes, I realize this is flamebait, but after trying to puzzle out the following 
maven plugin:


maven-antrun-plugin
1.6


deploy
deploy-gh-pages

run



















I simply can't resist. Whoever in their right mind decided software developers 
to think that requiring other developers to write config files in XML was a 
proper decision?

Python, Ruby, and (yes even Perl) have had had much more elegant and concise 
ways of managing complex data structures for years now. And there's a reason 
JSON has become so popular--primarily because XML is not, and was never 
intended to be, a format for developers to write specifications in.

Let's take a look at the most obvious of the problems in the above:












Now, I'm still very new to maven, but it strikes me that what the above is 
saying is (in Pythonic code, but feel free to convert to your own):

import git
gh-pages-dir = ""
git(dir=gh-pages-dir, "add .")
git(dir=gh-pages-dir, "commit")
git(dir=gh-pages-dir, "push origin gh-pages")

I'm sure there are errors in the translation--but I'm equally sure that if 
these errors were corrected, they would not substantially alter the ratio of 
XML to Pythonic code. Ruby and even Perl would do just as well. 

So here's a challenge to the (very intelligent) folks at apache. Open your 
minds to the fact that XML is not only the Final Solution, but isn't even close 
to the best solution, and start producing some products that are configurable 
without an entire manual in front of oneself. I realize that arriving at an 
optimal solution is not really possible, but XML is so suboptimal as to beggar 
belief.

I am just so sick of using crappy "solutions" (read: XML) layered over top of 
what could be good solutions.

Sorry, had to vent. Who knows, maybe it'll do some good?

Ken McDonald


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org