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


On 10/13/10 9:57 AM, "chemit" <[email protected]> wrote:

> Le Wed, 13 Oct 2010 08:58:27 -0400,
> Ron Wheeler <[email protected]> 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<[email protected]>  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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>> 
>>> 
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to