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" <che...@codelutin.com> wrote:
>
>> Le Wed, 13 Oct 2010 08:58:27 -0400,
>> Ron Wheeler <rwhee...@artifact-software.com> 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<kenneth.m.mcdon...@sbcglobal.net> a écrit :
>>>>
>>>>> Yes, I realize this is flamebait, but after trying to puzzle out
>>>>> the following maven plugin:
>>>>>
>>>>> <plugin>
>>>>> <artifactId>maven-antrun-plugin</artifactId>
>>>>> <version>1.6</version>
>>>>> <executions>
>>>>> <execution>
>>>>> <phase>deploy</phase>
>>>>> <id>deploy-gh-pages</id>
>>>>> <goals>
>>>>> <goal>run</goal>
>>>>> </goals>
>>>>> <configuration>
>>>>> <target>
>>>>> <property name="gh-pages-dir"
>>>>> location=""/> <exec executable="git" dir="${gh-pages-dir}">
>>>>> <arg line="add ."/>
>>>>> </exec>
>>>>> <exec executable="git"
>>>>> dir="${gh-pages-dir}"> <arg line="commit"/>
>>>>> </exec>
>>>>> <exec executable="git"
>>>>> dir="${gh-pages-dir}"> <arg line="push origin gh-pages"/>
>>>>> </exec>
>>>>> </target>
>>>>> </configuration>
>>>>> </execution>
>>>>> </executions>
>>>>> </plugin>
>>>>>
>>>>> 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:
>>>>>
>>>>> <property name="gh-pages-dir"
>>>>> location=""/> <exec executable="git" dir="${gh-pages-dir}">
>>>>> <arg line="add ."/>
>>>>> </exec>
>>>>> <exec executable="git"
>>>>> dir="${gh-pages-dir}"> <arg line="commit"/>
>>>>> </exec>
>>>>> <exec executable="git"
>>>>> dir="${gh-pages-dir}"> <arg line="push origin gh-pages"/>
>>>>> </exec>
>>>>>
>>>>> 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
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
