-
Schmant: A new build tool (34 messages)
- Posted by: Karl Gustafsson
- Posted on: March 29 2007 12:39 EDT
The first public release of Schmant, a build tool for Java projects, was made a couple of days ago. This article tries to give a short overview of Schmant's features. They are all described in greater detail along with plenty of code examples at http://www.schmant.org First of all, Schmant is designed to be a better alternative to Apache Ant. It uses the scripting support in Java 6 to let users program build scripts instead of having to write XML files. Apart from that, it has the same philosophy as Ant has: provide a set of tools (tasks) that build scripts can use and an environment to run the scripts in. Some notable features are: * Task executors that can be used to run tasks in parallel execution threads. * Operations on projects in project repositories (today: Java projects in Eclipse Workspaces) such as dependency handling between projects and filtering by project types or names. * EntityFS entities and tools can be used with the tasks. * Build scripts have access to all Java classes, as well as any number of user-supplied classes. Schmant has been used successfully in a couple of projects, but it is still in a fairly early stage of development. It does not have nearly as many tasks as Ant has yet and the documentation can certainly be improved. The good thing about that is that it is not yet too late to make improvements in the design or to propose new features. After reading about Schmant, would you consider using it as the build tool for your next Java project? Are there any important features missing?Threaded Messages (34)
- Re: Schmant: A new build tool by Jesse Kuhnert on March 29 2007 15:26 EDT
- Um, yuck? by Sam Pullara on March 29 2007 17:25 EDT
-
Re: Um, yuck? by Konstantin Ignatyev on March 29 2007 05:44 EDT
-
Welcome to Apache MAVEN by Sergiy Litsenko on March 29 2007 07:45 EDT
-
Re: Welcome to Apache MAVEN by Konstantin Ignatyev on March 30 2007 10:47 EDT
- Welcome to Apache MAVEN by Sergiy Litsenko on March 30 2007 08:35 EDT
-
Re: Welcome to Apache MAVEN by Peter Monks on March 30 2007 10:00 EDT
-
Re: Re: Welcome to Apache MAVEN by Steven Boscarine on April 02 2007 03:52 EDT
-
Re: Re: Welcome to Apache MAVEN by Konstantin Ignatyev on April 02 2007 05:13 EDT
-
Welcome to Apache MAVEN by Sergiy Litsenko on April 02 2007 07:22 EDT
-
Re: Welcome to Apache MAVEN by Konstantin Ignatyev on April 03 2007 12:22 EDT
-
Re: Welcome to Apache MAVEN by Sergiy Litsenko on April 03 2007 07:57 EDT
-
Re: Welcome to Apache MAVEN by Konstantin Ignatyev on April 03 2007 10:16 EDT
- Re: Welcome to Apache MAVEN by Sergiy Litsenko on April 04 2007 01:45 EDT
-
Re: Welcome to Apache MAVEN by Konstantin Ignatyev on April 03 2007 10:16 EDT
-
Re: Welcome to Apache MAVEN by Sergiy Litsenko on April 03 2007 07:57 EDT
-
Re: Welcome to Apache MAVEN by Konstantin Ignatyev on April 03 2007 12:22 EDT
-
Welcome to Apache MAVEN by Sergiy Litsenko on April 02 2007 07:22 EDT
-
Re: Re: Welcome to Apache MAVEN by Konstantin Ignatyev on April 02 2007 05:13 EDT
-
Re: Re: Welcome to Apache MAVEN by Steven Boscarine on April 02 2007 03:52 EDT
-
Re: Welcome to Apache MAVEN by Konstantin Ignatyev on March 30 2007 10:47 EDT
-
Welcome to Apache MAVEN by Sergiy Litsenko on March 29 2007 07:45 EDT
-
Re: Um, yuck? by Konstantin Ignatyev on March 29 2007 05:44 EDT
- Um, yuck? by Sam Pullara on March 29 2007 17:25 EDT
- ant schmant by Dushyanth Inguva on March 29 2007 17:47 EDT
- I'm not shocked. by Richard Burton on April 03 2007 13:34 EDT
- Lisp it by Ricky Clarkson on March 29 2007 19:07 EDT
- Sorry for OT+flamebait, couldn't help it... by Jing Xue on April 03 2007 16:52 EDT
- Re: Sorry for OT+flamebait, couldn't help it... by Konstantin Ignatyev on April 03 2007 07:42 EDT
- Re: Sorry for OT+flamebait, couldn't help it... by Ricky Clarkson on April 03 2007 08:00 EDT
- Sorry for OT+flamebait, couldn't help it... by Jing Xue on April 03 2007 16:52 EDT
- Ant currently supports scripting by Andrew O'Malley on March 30 2007 01:51 EDT
- Ugh... by Nathan Good on March 30 2007 08:55 EDT
- Re: Ugh... by Mike Heath on March 30 2007 12:49 EDT
-
Try again by Joe Attardi on March 30 2007 04:43 EDT
-
Re: Try again by Karl Gustafsson on March 31 2007 03:06 EDT
- Re: Try again by Konstantin Ignatyev on April 02 2007 03:07 EDT
-
Re: Try again by Karl Gustafsson on March 31 2007 03:06 EDT
- Re: Ugh... by Nathan Good on April 02 2007 09:07 EDT
-
Try again by Joe Attardi on March 30 2007 04:43 EDT
- Re: Ugh... by Charlie Collins on April 02 2007 14:35 EDT
- Re: Ugh... by bruno CHEVALIER on April 03 2007 04:55 EDT
- Re: Ugh... by Mike Heath on March 30 2007 12:49 EDT
- Try groovy ant builder by Alexander Shvets on March 30 2007 10:56 EDT
- Re: Try groovy ant builder by bruno CHEVALIER on April 03 2007 05:05 EDT
- Look at Virtual Ant by Prashant Deva on March 31 2007 19:22 EDT
- Nice Hack but.. by Lyndon Samson on April 02 2007 01:30 EDT
- Yet another build tool by Prashanth Muthyala on April 18 2007 17:04 EDT
-
Re: Schmant: A new build tool[ Go to top ]
- Posted by: Jesse Kuhnert
- Posted on: March 29 2007 15:26 EDT
- in response to Karl Gustafsson
I love it! Great idea. -
Um, yuck?[ Go to top ]
- Posted by: Sam Pullara
- Posted on: March 29 2007 17:25 EDT
- in response to Jesse Kuhnert
This looks horrendous. I'd sooner write my build scripts in Java wrapped around Ant tasks. -
Re: Um, yuck?[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: March 29 2007 17:44 EDT
- in response to Sam Pullara
This looks horrendous. I'd sooner write my build scripts in Java wrapped around Ant tasks.
+1 With Java driven Ant I at least have intelli-sense and code completion and all the standard modern IDE goodies; Shmant does not allow that and it does not provide true scripting environment where script can be written as we go and runtime state can be investigated; even build.xml is better because XML declarations provide DSL for build process and it has some intelli-sense and code completion support from DTD ========== I do not thing we need Ant replacement that badly: I think it would be nice if some repository of standard Ant scripts was created accompanied by repository of custom tasks. It we have such repo then typical Ant files would be one-liners <include source="std-war-build.xml" ... </b> -
Welcome to Apache MAVEN[ Go to top ]
- Posted by: Sergiy Litsenko
- Posted on: March 29 2007 19:45 EDT
- in response to Konstantin Ignatyev
I think it would be nice if some repository of standard Ant scripts was created accompanied by repository of custom tasks.
Welcome to Apache MAVEN :) http://maven.apache.org/guides/getting-started/index.html In addition to possibility of using ANT tasks and many other things it also can produce ANT build scripts using Maven 2 Ant Plugin http://maven.apache.org/plugins/maven-ant-plugin Other core plugins - http://maven.apache.org/plugins/index.html
It we have such repo then typical Ant files would be one-liners -
Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: March 30 2007 10:47 EDT
- in response to Sergiy Litsenko
Do you really suppose I am so ignorant that I do not know about Maven? That is insulting. Maven has good ideas behind but their implementation is far from being usable IMO ( well what could I expect from author of Jelly ;) ). In general Maven feels a lot like M$ thingies: easy to get started - but hard to progress, difficult to get things the way I want them to be, even reasonable things, plus unpredictable breaks and version hypersesnsitivity. It feels "wizardish" if you will. Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins. It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago. That is why I prefer Ant - it makes things more traceable and obvious - all we need IMO is to create a little bit of convenience around it: repository of standard build scripts and custom tasks. -
Welcome to Apache MAVEN[ Go to top ]
- Posted by: Sergiy Litsenko
- Posted on: March 30 2007 20:35 EDT
- in response to Konstantin Ignatyev
Do you really suppose I am so ignorant that I do not know about Maven? That is insulting.
Come on, we're discussing build tools only not your or someone else personality - I'm not supposing anything like that or even think about that. Lets move to the topic.Maven has good ideas behind but their implementation is far from being usable IMO
As you've said - IYO. I find it personally saving time and reducing maintenance nightmare when you have dozens of "build.xml" files and "lib" dirs. And many projects at Apache found that too.( well what could I expect from author of Jelly ;) ).
What's wrong with Jelly? You're having too many problems with tools and libs ;) Perhaps it wasn't that good idea for developing Maven 1 plugins using Jelly, but the tool alone is powerful and simple XML based scripting and processing engine.difficult to get things the way I want them to be
Maven brings standartization to the project directory, repository of artifacts, naming of goals/tarject/phases. Most of the software project information is specified in the single XML file, and easy to reuse by plugins. If you want quite opposite things - like having your own project directory structure, your own build process, your own repository of artifacts - and all of these for EVERY project - then good like managing it, and probably you don't need Maven for that.Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins.
Lets take a look on very popular Spring framework, release 2.0 (October 2006) that uses ANT: .... lib (contains all third-party libraries needed for running the samples and/or building the framework) |--jakarta-commons ... commons-collections.jar commons-digester.jar commons-io.jar commons-httpclient.jar ... What versions jakarta-commons libs used to build the project? Ohhhh, this ANT build system totally depends on "LIB" content ;) In the strict SCM environments that is very important to have exact knowledge of what 3rd party lib version used. While I can go to the lib's origin site and compare file sizes and other things - I don't have a luxury of such time spent on such obvious things ;) Maven takes declarative approach and uses information from the POM to make your local repository in synch with your intranet (or remote public) repository.It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago.
Wrong! Instead of "SNAPHOT" versions you need to include required versions to the tag for your dependencies.That is why I prefer Ant - it makes things more traceable and obvious
IMO, it's quite opposite - MAVEN brings it declaratively withing single POM (Project Object Model) file. ANT is brilliant build tool but once someone played enough with LEGO style of build, someone will want standartization - like project directory structure, repositories of artifacts, standart goals and lifecycles like compile-test-package-...all we need IMO is to create a little bit of convenience around it: repository of standard build scripts and custom tasks
That's what I'm talking about ;) - MAVEN already provides it out of box - and I don't need to spend my time designing/creating these "standard build scripts and custom tasks" - they are widely accepted and available and I don't have a "Not Invented Here (NIH)" disease ;) http://en.wikipedia.org/wiki/Not_Invented_Here Maven can call any ANT task if needed - so no previous efforts are lost. Or even more - MAVEN can generate ANT script from POM or Eclipse project files. -
Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Peter Monks
- Posted on: March 30 2007 22:00 EDT
- in response to Konstantin Ignatyev
Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins.
You only get this kind of behaviour if you're relying solely on uncontrolled repositories (eg. the various public repositories). If you configure your own repository (perhaps with the support of a tool like m2proxy or Artifactory) and pay some attention to what goes into it, then you won't have these problems. It's a shame that this misconception has somehow become entrenched in the minds of the uninitiated / ill-informed. I've found Maven to provide pretty compelling productivity improvements over other Java build systems, but the widely held negative perception of it makes it a tough sell. Cheers, Peter
It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago. -
Re: Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Steven Boscarine
- Posted on: April 02 2007 15:52 EDT
- in response to Peter Monks
May I suggest specifying version numbers? That's a much easier solution. Configuring your own repositories is a good option if you're worried about someone changing the contents of a library and a version without incrementing the version number. However, I've been using maven2 for over a year and have never experienced issues with repeatability of builds. Have you actually experienced this issue Konstantin? I'm very surprised that you claim issues in repeatability of builds and that maven2 is very Microsoft-like. I don't wish to "insult" you as the previous poster did, but from those two claims alone, I'd wonder if you and I were even talking about the same tool. My experience on using it in production for an enterprise project has been that maven is indispensable for it's dependency management alone. The more your project depends on open source components, the more you need a way of managing all the shared dependencies that crop up when you use hibernate, jsf, spring, etc. I also like that it's standardized project layout and can create WTP projects. It is a huge timesaver and it's dependency management is a major safety net for my projects. To put things in perspective, I recently worked on a 20 developer project (which I consider to be very large). Every developer took over 4 hours to setup and build the project for the first time...after installing & configuring the JDK, database, eclipse, etc. With maven2, the process consists of the following: 1. download code from source control 2. run "mvn eclipse:eclipse" 3. import the project created 4. start coding. Your project has been created for you and all libraries have been setup. That was almost as easy as using Grails. : ) After using maven2, and reviewing schmant's examples, I don't yet see any compelling reason to use schmant. I'm sure this will be valuable to someone, but maven2 is just too hard to beat. I've written many ANT scripts in the past, but I don't think I'll be writing any in the future thanks to maven.Another huge red flag: build content, possibility and repeatability depends on repository content. That is because of ranges in the dependency version definitions and plugins.
It means that if new version was uploaded to repository - I can not repeat my week ago's build the way it was done a week ago.
You only get this kind of behaviour if you're relying solely on uncontrolled repositories (eg. the various public repositories). If you configure your own repository (perhaps with the support of a tool like m2proxy or Artifactory) and pay some attention to what goes into it, then you won't have these problems. -
Re: Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: April 02 2007 17:13 EDT
- in response to Steven Boscarine
May I suggest specifying version numbers?....
That is right way to do, but half of the solution IMO :) There should be standard ways of getting to know if update is available, trying the version etc.Have you actually experienced this issue Konstantin? I'm very surprised that you claim issues in repeatability of builds and that maven2 is very Microsoft-like.
Those are two different issues: unrepeatability of builds ( when versions are specified as ranges ) and Wizard-like (MS-style) feel of Maven. Yes, I did experience unrepeatability of builds because dependencies versions were specified as ranges like (1.0,). Any system that uses this type of version definitions, it is not specific to Maven, but it looks like encouraged and widely used practice. That is pragmatic way of simplifying dependencies management but it bites from time to time. Because the same kind of version definitions is applied to Maven plugins - they bite too. On wizardish feel - Ant might be verbose but it easy to track why things happen in a certain way and change to someone liking, Maven is different - it works nicely when it works but if it doesn't then it is really hard to figure out what goes wrong and how to fix it. -
Welcome to Apache MAVEN[ Go to top ]
- Posted by: Sergiy Litsenko
- Posted on: April 02 2007 19:22 EDT
- in response to Konstantin Ignatyev
Yes, I did experience unrepeatability of builds because dependencies versions were specified as ranges like (1.0,)... it looks like encouraged and widely used practice. That is pragmatic way of simplifying dependencies management but it bites from time to time.
The versioning issue is actually not related to Maven - the same thing may happen with any build system including ANT. Maven doesn't encourages using version ranges, however it supports it. It is responsibility of a developer to make sure that the build is reproducable - see also http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+ResolutionAnt might be verbose but it easy to track why things happen in a certain way and change to someone liking, Maven is different - it works nicely when it works but if it doesn't then it is really hard to figure out what goes wrong and how to fix it.
Maven has similar to ANT built-in support for producing extended output using command-line options plus supports help plugin: Command-line options: -X,--debug Produce execution debug output -e,--errors Produce execution error messages Maven Help Plugin(http://maven.apache.org/plugins/maven-help-plugin): mvn help:effective-pom displays the effective POM for the current build, with the active profiles factored in. help:active-profiles lists the profiles which are currently active for the build. help:effective-settings prints out the calculated settings for the project, given any profile enhancement and the inheritance of the global settings into the user-level settings. -
Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: April 03 2007 12:22 EDT
- in response to Sergiy Litsenko
The versioning issue is actually not related to Maven - the same thing may happen with any build system including ANT.
Did not I say the same? (Ant does not have dependencies management on its own) HoweverMaven doesn't encourages using version ranges, however it supports it.
It does use ranges and thus endorses and encourages them. And it (and other tools) does not provide any sane alternative for version management and updates. Since Maven does not help with robust dependencies management I personally prefer Ant+Ivy, not ideal, but in the end is more robust and manageable than Maven. That may change in the future.... -
Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Sergiy Litsenko
- Posted on: April 03 2007 19:57 EDT
- in response to Konstantin Ignatyev
Did not I say the same? (Ant does not have dependencies management on its own)
Yes but custom task can do it - such as Antlib for Maven 2.0It does use ranges and thus endorses and encourages them.
I'm afraid, I disagree. There is big difference between "supports version ranges" and "encourages using them" Neigher Maven runtime nor its documentation does NOT encourages using version ranges. Please provide any examples from http://maven.apache.org that show opposite. If developer decides to use version ranges - it is developer responsibility to understand all consequences of such decision (such as mismatches between facade interfaces).Since Maven does not help with robust dependencies management ...
I'm sorry that you feel that way but it's just IYO -
Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: April 03 2007 22:16 EDT
- in response to Sergiy Litsenko
Yes but custom task can do it - such as Antlib for Maven 2.0
This particular library is creation of Maven folks and carry all the same baggage...Neigher Maven runtime nor its documentation does NOT encourages using version ranges. Please provide any examples from http://maven.apache.org that show opposite.
http://maven.apache.org/ref/2.0.4/maven-model/maven.html ranges are not discouraged and Maven does not provide any alternative for version management, but should IMO, as any other dependencies managers should. -
Re: Welcome to Apache MAVEN[ Go to top ]
- Posted by: Sergiy Litsenko
- Posted on: April 04 2007 01:45 EDT
- in response to Konstantin Ignatyev
http://maven.apache.org/ref/2.0.4/maven-model/maven.html
From the reference you've mentioned: dependency version The version of the dependency, e.g. 3.2.1. In Maven 2, this can also be specified as a range of versions. plugin The version (or valid range of verisons) of the plugin to be used. I'm not sure where you've found encouragement to use range of versions. Alternative and best pracitice is blady simple - use EXPLICIT versions of artifacts in dependencies. It is the same as within ANT (lib dir). If you're decided to use transitive way - that fine - but don't blame Maven for that.
ranges are not discouraged and Maven does not provide any alternative for version management, but should IMO, as any other dependencies managers should. -
ant schmant[ Go to top ]
- Posted by: Dushyanth Inguva
- Posted on: March 29 2007 17:47 EDT
- in response to Karl Gustafsson
ant schmant... i use javac ;-) -
I'm not shocked.[ Go to top ]
- Posted by: Richard Burton
- Posted on: April 03 2007 13:34 EDT
- in response to Dushyanth Inguva
Mr. Inguva, can you please explain your statement? I'm willing to bet you use to work for a company that used VSS. Best regards, Richard L. Burton III -
Lisp it[ Go to top ]
- Posted by: Ricky Clarkson
- Posted on: March 29 2007 19:07 EDT
- in response to Karl Gustafsson
This article, at least until it starts talking about macros, is quite relevant to this. Lisp makes me wonder why XML was invented, and why almost every other programming language ever was invented. Then I remember the power of marketing. Anyway, here's the article: http://www.defmacro.org/ramblings/lisp.html (scroll down to Ant Reloaded if you're impatient - hell, if you're impatient, just don't bother doing anything. You know where the power button is). -
Sorry for OT+flamebait, couldn't help it...[ Go to top ]
- Posted by: Jing Xue
- Posted on: April 03 2007 16:52 EDT
- in response to Ricky Clarkson
... Lisp makes me wonder why XML was invented, and why almost every other programming language ever was invented. Then I remember the power of marketing.
That's what LISP people think. Everyone else thinks it's the power of the market. :-) -
Re: Sorry for OT+flamebait, couldn't help it...[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: April 03 2007 19:42 EDT
- in response to Jing Xue
Others think that it is power of ignorance and product of education by "ZZZZ For Dummies in 24 hours" series of books.... Lisp makes me wonder why XML was invented, and why almost every other programming language ever was invented. Then I remember the power of marketing.
That's what LISP people think. Everyone else thinks it's the power of the market. :-) -
Re: Sorry for OT+flamebait, couldn't help it...[ Go to top ]
- Posted by: Ricky Clarkson
- Posted on: April 03 2007 20:00 EDT
- in response to Jing Xue
That's what LISP people think.
Thanks for the compliment. -
Ant currently supports scripting[ Go to top ]
- Posted by: Andrew O'Malley
- Posted on: March 30 2007 01:51 EDT
- in response to Karl Gustafsson
Ant provides support for scripting already. See http://ant.apache.org/manual/OptionalTasks/script.html. This mechanism allows any target to be implemented in a number of scripting languages, including JavaScript. You then have access to all ant tasks, built in or otherwise. It also supports JVMs prior to 1.6. Here is an example from the docs: <!--?xml version="1.0" encoding="ISO-8859-1"?--> <script language="javascript"> <![CDATA[ // import statements // importPackage(java.io); importClass(java.io.File); // Access to Ant-Properties by their names dir = project.getProperty("fs.dir"); includes = MyProject.getProperty("fs.includes"); excludes = self.getProject() .getProperty("fs.excludes"); // Create a <fileset dir="" includes=""/> fs = project.createDataType("fileset"); fs.setDir( new File(dir) ); fs.setIncludes(includes); fs.setExcludes(excludes); // Get the files (array) of that fileset ds = fs.getDirectoryScanner(project); srcFiles = ds.getIncludedFiles(); // iterate over that array for (i=0; i<srcFiles.length; i++) { // get the values via Java API var basedir = fs.getDir(project); var filename = srcFiles[i]; var file = new File(basedir, filename); var size = file.length(); // create and use a Task via Ant API echo = MyProject.createTask("echo"); echo.setMessage(filename + ": " + size + " byte"); echo.perform(); } ]]></script> -
Ugh...[ Go to top ]
- Posted by: Nathan Good
- Posted on: March 30 2007 08:55 EDT
- in response to Karl Gustafsson
What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing. I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting. One more frustration. One more reason to throw my hands up and say, "To heck with this, I'll use something where every time I turn around I don't have to evaluate 10 alternatives for doing the same thing..." (read: *choose* vendor lock-in) For the love of the Java community and all other things, integrate with or work on what's already there. -
Re: Ugh...[ Go to top ]
- Posted by: Mike Heath
- Posted on: March 30 2007 12:49 EDT
- in response to Nathan Good
What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing.
I agree. Why would anyone want to try and innovate? We already have Ant and Maven and we'll never need anything different. Pick the one you like. We don't want to have to choose anything else. I can't believe anyone would even try to do anything new. Obviously new and different ways of doing things are so bad Bad BAD!
I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting.
One more frustration. -
Try again[ Go to top ]
- Posted by: Joe Attardi
- Posted on: March 30 2007 16:43 EDT
- in response to Mike Heath
How is this innovative at all? As Andrew O'Malley pointed out, Ant already has support for scripting, whereas Schmant seems to have a dependency on Java 6. I don't see the usefulness of this build tool. Well, at least it's not another web framework.
I agree. Why would anyone want to try and innovate? We already have Ant and Maven and we'll never need anything different. Pick the one you like. We don't want to have to choose anything else. I can't believe anyone would even try to do anything new. Obviously new and different ways of doing things are so bad Bad BAD! -
Re: Try again[ Go to top ]
- Posted by: Karl Gustafsson
- Posted on: March 31 2007 03:06 EDT
- in response to Joe Attardi
How is this innovative at all? As Andrew O'Malley pointed out, Ant already has support for scripting, whereas Schmant seems to have a dependency on Java 6.
Yes, and you can turn a car into an aeroplane by bolting on a pair of wings. The reason for me to build Schmant was that I could not make Ant do what I wanted it to. I probably could have tried harder, but it was not the first time that I had that problem. Before, I always ended up turning myself inside out just to create a solution that never failed to feel ... wrong. This time around, I wanted to do something different.
Schmant's dependency on Java 6 is a runtime dependency. You can build code for any old Java that you like. You could even use it to compile C code if you wanted to (and was prepared to implement a couple of tasks too).I don't see the usefulness of this build tool. Well, at least it's not another web framework.
Then don't use it... -
Re: Try again[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: April 02 2007 15:07 EDT
- in response to Karl Gustafsson
If you are not interested in people using your tool then do not publish your code and do not advertise it. Otherwise please be prepared to to explain your reasons over and over again. And especially in case of offering a total replacement for something that works reasonably well.I don't see the usefulness of this build tool. Well, at least it's not another web framework.
Then don't use it... -
Re: Ugh...[ Go to top ]
- Posted by: Nathan Good
- Posted on: April 02 2007 09:07 EDT
- in response to Mike Heath
I agree. Why would anyone want to try and innovate?
That is not at all what I said or meant. I didn't say that innovation was a bad thing ("fragmentation" != "innovation"). I feel quite the contrary.We already have Ant and Maven and we'll never need anything different. Pick the one you like. We don't want to have to choose anything else.
So for the sake of what you call "innovation" we can't work on those projects to submit our own improvements? I fail to see how improving existing things can't be innovative.I can't believe anyone would even try to do anything new. Obviously new and different ways of doing things are so bad Bad BAD!
So why even use Java? Why use HTML? Why use a web browser? They're not new, so surely you can write different implementations of these yourself. Is that what you need to do to be good? Is that what innovation means? -
Re: Ugh...[ Go to top ]
- Posted by: Charlie Collins
- Posted on: April 02 2007 14:35 EDT
- in response to Nathan Good
What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing.
I completely disagree with this all too common sentiment. There are "too many" choices and "fragementation." No, there are difficult problems to solve and different people address them in different ways. Having choices is not a bad thing. Sure it means you have to make an informed decision about what to use sometimes, but that is not bad either. This is the same rant as there are "too many Linux distros" and so on. Some flavors are better than others, some address different areas of concern, some people may want to go a completely different direction. There are *also* people contributing to Ant, having *both* is not bad. Artificial selection will cause some projects to rise to the top, and others to wane, based on the overall merits. Saying "work on what's already there" is oversimplified, and the whole throw my hands up and "choose vendor lock in" is just laziness (which will bite you later, one way or another). (And don't get me wrong, sometimes the approaches of two projects are NOT all that different, and it would make more sense to merge them. Having separate projects just because of political or personality issues, or lack of communication, is bad. But having fewer projects just because of "too many choices" is also bad. Schmant, though I have not looked into it, does not sound like it falls into the duplicate category at all - even though it is addressing the same problem domain.)
I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting.
One more frustration.
One more reason to throw my hands up and say, "To heck with this, I'll use something where every time I turn around I don't have to evaluate 10 alternatives for doing the same thing..." (read: *choose* vendor lock-in)
For the love of the Java community and all other things, integrate with or work on what's already there. -
Re: Ugh...[ Go to top ]
- Posted by: bruno CHEVALIER
- Posted on: April 03 2007 04:55 EDT
- in response to Nathan Good
What the Java community didn't need was another build tool. Ant has a lot of momentum and is supported in many IDEs already. Why do we need another one? The better alternative would be for a team to offer tasks that can be used in Ant to supply features they think are missing.
+1 Why another one?
I wish more people in the Java community would see how this type of fragmentation is BAD for the community as a whole. If I was a n00b, this just would be one more tool that I would have to spend time evaluating and documenting.
One more frustration.
One more reason to throw my hands up and say, "To heck with this, I'll use something where every time I turn around I don't have to evaluate 10 alternatives for doing the same thing..." (read: *choose* vendor lock-in)
For the love of the Java community and all other things, integrate with or work on what's already there. -
Try groovy ant builder[ Go to top ]
- Posted by: Alexander Shvets
- Posted on: March 30 2007 10:56 EDT
- in response to Karl Gustafsson
1. Do not be dependent on Javax-scripting - it's only Java 6 solution. 2. Pick any scripting language engine (e.g. js.jar), add your libraries (schmant.jar, entityfs.jar) and use it from schmant.bat. Or even better put ant.jar and the rest of requied libraries on CLASSPATH and use it from schmant.bat. Ant has some API which could be invoked from JS or BSH or Groovy etc. in same way as your API. Like this (in beanshell): String repositoryHome = System.getProperty("repository.home"); addClassPath(repositoryHome + "/org/apache/ant/ant/1.7.0/ant-1.7.0.jar"); addClassPath(repositoryHome + "/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar"); // run-ant.bsh import org.apache.tools.ant.Project; import org.apache.tools.ant.ProjectHelper; import org.apache.tools.ant.BuildLogger; import org.apache.tools.ant.DefaultLogger; Project project = new Project(); project.init(); BuildLogger logger = new DefaultLogger(); logger.setMessageOutputLevel(Project.MSG_INFO); logger.setOutputPrintStream(System.out); logger.setErrorPrintStream(System.err); project.addBuildListener(logger); File buildFile = new File("build.xml"); ProjectHelper.getProjectHelper().parse(project, buildFile); project.executeTarget(project.getDefaultTarget()); 3. Use groovy ant builder, like this: // build.groovy /* <?xml version="1.0"?> */ class Build { def ant = new AntBuilder() def base_dir = "./" def src_dir = base_dir + "src" def lib_dir = base_dir + "lib" def build_dir = base_dir + "classes" def dist_dir = base_dir + "dist" def file_name = "whoami" def classpath; Build() { ant.mkdir(dir: "${lib_dir}") classpath = ant.path { fileset(dir: "${lib_dir}"){ include(name: "*.jar") } pathelement(path: "${build_dir}") } } void clean() { delete(dir: "${build_dir}") delete(dir: "${dist_dir}") } void build() { ant.mkdir(dir: "${lib_dir}") ant.mkdir(dir: "${src_dir}") ant.mkdir(dir: "${build_dir}") ant.javac(destdir: "${build_dir}", srcdir: "${src_dir}", classpath: "${classpath}") } void jar() { clean() build() ant.mkdir(dir: "${dist_dir}") ant.jar(destfile: "${dist_dir}/${file_name}.jar", basedir: "${build_dir}") } void run(args) { if ( args.size() > 0 ) { invokeMethod(args[0], null ) } else { build() } } static void main(args) { def b = new Build() b.run(args) } } best regards, Alexander Shvets. -
Re: Try groovy ant builder[ Go to top ]
- Posted by: bruno CHEVALIER
- Posted on: April 03 2007 05:05 EDT
- in response to Alexander Shvets
A complicated solution for Groovy addicts only! The ant scripting is not limited to java6. It is using the java6 scripting and Apache BSF for prior jdks -
Look at Virtual Ant[ Go to top ]
- Posted by: Prashant Deva
- Posted on: March 31 2007 19:22 EDT
- in response to Karl Gustafsson
Look at Virtual Ant, way more intuitive and way easier to use. http://www.placidsystems.com/virtualant/ -
Nice Hack but..[ Go to top ]
- Posted by: Lyndon Samson
- Posted on: April 02 2007 01:30 EDT
- in response to Karl Gustafsson
I think a build tool is the perfect place for a clearly define d DSL. Allowing any and all languages to participate in a build is probably not a good move. -
Yet another build tool[ Go to top ]
- Posted by: Prashanth Muthyala
- Posted on: April 18 2007 17:04 EDT
- in response to Karl Gustafsson
Ant is doing really good and is extendable, i think there is really no need of a new build tool. Its not that WE DONT NEED but ant is more preferrable among the developers due to its manageability using xml and properties files. It is easy enough to read and its platform independent, so i dont think we need a new build tool for any reason, except for another option. May be you can spice up this tool for some more interactive and broad use.