|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 34
Messages: 34
Messages: 34
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Schmant: A new build tool
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?
|
|
|
Message #230216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Um, yuck?
This looks horrendous. I'd sooner write my build scripts in Java wrapped around Ant tasks.
|
|
|
Message #230218
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Um, yuck?
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" ... >
|
|
|
Message #230221
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Lisp it
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).
|
|
|
Message #230236
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ant currently supports scripting
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"?>
<project name="MyProject" basedir="." default="main">
<property name="fs.dir" value="src"/>
<property name="fs.includes" value="**/*.txt"/>
<property name="fs.excludes" value="**/*.tmp"/>
<target name="main">
<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>
</target>
</project>
|
|
|
Message #230247
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ugh...
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.
|
|
|
Message #230254
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Welcome to Apache MAVEN
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.
|
|
|
Message #230257
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Try groovy ant builder
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"?>
<project name="DemoProject" basedir="." default="build">
<property name="src_dir" value="src"/>
<property name="lib_dir" value="lib"/>
<property name="build_dir" value="classes"/>
<property name="dist_dir" value="dist"/>
<property name="file_name" value="whoami"/>
<path id="master-classpath">
<fileset dir="${lib_dir}">
<include name="*.jar"/>
</fileset>
<pathelement path="${build_dir}"/>
</path>
<target name="clean">
<delete dir="${build_dir}"/>
<delete dir="${dist_dir}"/>
</target>
<target name="build" description="Compile main source tree java files">
<mkdir dir="${build_dir}"/>
<javac destdir="${build_dir}" debug="true" failonerror="true">
<src path="${src_dir}"/>
<classpath refid="master-classpath"/>
</javac>
</target>
<target name="dist" depends="clean, build">
<mkdir dir="${dist_dir}"/>
<jar basedir="${build_dir}" destfile="${dist_dir}/${file_name}.jar" />
</target>
</project>
*/
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.
|
|
|
Message #230269
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ugh...
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.
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!
</sarcasm>
|
|
|
Message #230294
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Try again
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!
</sarcasm>
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.
|
|
|
Message #230309
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to Apache MAVEN
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 <version> 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 <version> 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.
|
|
|
Message #230311
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Welcome to Apache 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.
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
|
|
|
Message #230320
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Try again
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...
|
|
|
Message #230348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice Hack but..
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.
|
|
|
Message #230368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ugh...
I agree. Why would anyone want to try and innovate?
<sigh/> 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!
</sarcasm>
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?
|
|
|
Message #230383
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ugh...
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.
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.)
|
|
|
Message #230384
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Try again
I don't see the usefulness of this build tool. Well, at least it's not another web framework.
Then don't use it...
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.
|
|
|
Message #230390
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re: Welcome to Apache 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.
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.
|
|
|
Message #230398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re: Welcome to Apache MAVEN
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.
|
|
|
Message #230401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to Apache MAVEN
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+Resolution
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.
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.
|
|
|
Message #230418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ugh...
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.
+1
Why another one?
|
|
|
Message #230419
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Try groovy ant builder
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
|
|
|
Message #230444
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Welcome to Apache MAVEN
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) However
Maven 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....
|
|
|
Message #230449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not shocked.
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
|
|
|
Message #230464
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sorry for OT+flamebait, couldn't help it...
... 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 <strong>the market</strong>. :-)
|
|
|
Message #230472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sorry for OT+flamebait, couldn't help it...
... 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 <strong>the market</strong>. :-)
Others think that it is power of ignorance and product of education by "ZZZZ For Dummies in 24 hours" series of books.
|
|
|
Message #230473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Welcome to Apache MAVEN
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.0
It 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
|
|
|
Message #230474
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Sorry for OT+flamebait, couldn't help it...
That's what LISP people think.
Thanks for the compliment.
|
|
|
Message #230478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Welcome to Apache MAVEN
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.
|
|
|
Message #230485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Welcome to Apache MAVEN
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.
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.
|
|
|
Message #231301
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yet another build tool
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
