Not happy with maven

[Martin von Gagern <Ma...@gmx.net>]

Hi everybody!

I've been using Maven 2 for a few projects now, and found that, although
it provides some nice features, it doesn't seem to be the right tool for
most of my applications. I'll write down some of my experiences here, so
that they might help improving development tools in general.

I'm an individual Java programmer interested in developing open source
applications. I don't work for any company, therefore copany
repositories don't apply to me. Most of my projects are swing GUI
applications intended to be run by users on their local computers, so
integration tests are mostly irrelevant, and the possibilities for
automatic testing are limited as well.

This mail is not intended to start a flame war. I know there are people
using maven and happy with it, and for good reasons. I might even
continue using it for my library projects.

I guess many of the issues I don't like about maven could be helped with
more knowledge about Maven, customized plugins, hackish workarounds, or
any other kind of additional work. It's the sum of all together and the
amount of work required which lead me away from Maven. I list these
issues in no particular order.


MAVEN REPOSITORY AS ONLY SOURCE OF DEPENDENCIES

While the large repository used by maven is a great thing, one of the
most prominent advantages of Maven, it is in no way complete. Whenever I
want to make use of some library not available in a common repository, I
first have to get it into some repository I control, then have to get
that repository into the pom of my project, and at some point have to
grant public access to that repository if I want to share with other
developers. I would much prefer some kind of lib directory, where I
could simply drop the library and start using it, to see if it is fit
for the job I want to use it for in the first place. Then if I decide to
keep it, I would rather add some instructions to my repository about how
to get this library from its official source. Such instructions might
involve downloading some bundle, checking its md5sum in case its file
name contains no version number, extracting it, maybe running some
installer and interactively accepting some license, stuff like that. I'd
rather include such descriptions with the dependency than have an extra
file that describes how to set things up for maven.


ORDER OF TASKS

The maven POM seems to lack a clear concept of task order. This seems
especially important in the packaging phase. Suppose I produce a jar
which I want to pack200, jarsign, gpgsign, include in an assembly, and
gpgsign that assembly again. Clearly order matters a lot. While I
believe it might be possible to get the order correct in Maven as well,
there is no intuitive way to express this order when conceptually all
you do is load a bunch of plugins.


TOO SLOW

Maven is simply to slow, especially while starting up. WHile developing,
I often want to edit the code, compile the code, and run the code, all
in a tight loop. When over 50% of the time is spent starting that maven
monster, that's no efficient use of time. As Maven seems to lack a
simple "run" target, running the code usually means either some
complicated java invocation, or a packaged jart with the dependencies
included in its Classpath, which means executing the package phase and
before that the test phase, leading to even longer build times.


SECURITY CONCERNS

Maven does a lot of things automatically. While this is a good thing if
I simply want to grab a piece of code and build it, it can be annoying
under security aspects. I can't specify repositories for specific
artifacts only. So whenever I want to grab a dependency from a given
repository, I'll have to include it in the POM, and it will be queried
for every artifact Maven wants to download or update. So a malicious
repository could introduce malicious artifacts into my local repository,
affecting all my other projects as well.

Another aspect of this security issue is the fact that there seems to be
no way to ask the user for a password for e.g. jarsigner and hand that
to jarsigner by some means other than a command line argument. On a
multi-user *nix machine, users can see what commands other users are
running, and I don't like them seeing my keystore passphrase. And
storing these passphrases in a file for maven seems comparably evil.


TERRIBLE COMMAND LINE INTERFACE

I know, many developers are using IDEs and probably wouldn't even notice
such issues. But I still prefer to edit my source code in an editor and
build its artefacts from the command line. If I do so with maven I find
the output from the help commands which might be good for machines to
read, but is plainly annoying to me. I find all messages preceeded by
the message category and thus hard to read. I find absolute file names
all over the place, leading to excessively long lines. On the whole,
maven doesn't look well suited to command line operations.

When I compare this to command line tools like e.g. bzr, where I can get
exhaustive and easy to read help for every command, this feels like a
different thing altogether.


JNI ISSUES

In some cases I use libraries which employ JNI, or write JNI code
myself. Mavens lack of cross-compiler support severely limits the
development of JNI builds. Installing third party JNI artifacts in the
repository in such a way that they can be loaded seems difficult work at
best, if possible at all. Probably native libs would have to be copied
to some library dir from where they could be loaded. The fact that the
install:install-file mojo doesn't seem able to attach additional
artifacts further complicates issues, as I would need one POM per
os/arch combination, instead of a classifier.


DOM STRUCTURE

I believe that the DOM is mixing multiple things that don't belong into
one file in my opinion. The DOM contains information about what the
project is, like name, description, authors, license. This information
is intended for every user of the project. Next it contains information
about the plugins and their configuration, which describes how to build
the project and is thus intended for developers, including contributors,
and also for people who prefer building apps from source. And last there
is information about the deployment process and site generation, which
is relevant only to the official developers with write access to the
necessary infrastructure, and might contain internal information like
paths to local directories or similar. I believe these three aspects
should be split in two to three files. I'll grant you that the
distinction between build and deployment description isn't always a neat
line, and internal infrastructure can always be hidden in properties set
by private Maven configuration files.

On the other hand, the DOM is missing several top level elements I would
consider part of the project itself, not belonging to one of the
plugins. Foremost among these I would count file encoding. Why do I need
to configure it again and again for every plugin that operates on source
files, instead of specifying it once and for all, with the possibility
to override it on a per-file and per-plugin basis if need be? Yes, I can
have some common ancestor configure the plugins and use a common
property name for the encoding, but this kind of hacks seems to go
against the whole idea of POMs describing projects.


MODULES AND ARTIFACTS

Theoretically the pom describes a single module, and several files could
belong to this module. However, one of them is the "main artifact", the
others are "attached artifacts". This distinction seems somewhat
artificial. Furthermore, there is no single place within the dom where
all the possibly generated artifacts were listed. And interdependence
between artifacts (like one containing the other) are not expressed
either. I guess I would prefer clean instructions, like these source
files are processed by these build tools in order to produce these
artifacts.


LANGUAGE AND API VERSIONS

There are still systems out there that don't use Java 1.5, often can be
updated only at a cost or not at all, and therefore applications that
need to run on 1.4. On the other hand, I prefer to use the latest JDK
here for development, with all the latest features like -Xlint. (By the
way: as Maven claims to promote "best practises": I'd consider -Xlint
one of these.) I also would want to use Java 1.5 syntax for test cases,
as it is much shorter and clearer in many cases. So I'd like to compile
all my code using the latest javac, but substutute the bootclasspath of
a different Java API version when compiling the main project code, along
with providing the appropriate -source and -target switches. Not
possible in Maven, afaik. I'm not sure how these different APIs could be
managed by any build tool. I guess you could either provide information
where to look for these on common systems, like Windows, OS X, Solaris
and the major Linux distributions, while leaving the user an option to
specify non-standard paths per user or per system, not per project. An
alternative would be to ship stub JARs with the tool, containing all the
public interface of the official Java APIs but no executable code, thus
preserving space and avoiding licensing issues.


EXTENDING MAVEN

Many things in maven can be solved by writing your own plugins. I don't
like the plugin interface at all, though, especially the way
configuration works. Most Mojos use private variables for configuration,
something I would consider part of the public interface of the plugin.
This means you can't simply derive your own Mojo by subclassing some
existing one, as you can't get at those private variables. It also means
that you can have no getters and setters checking the access to these
variables. And if you want to use complex types for plugin
configuration, you have to state class names in the pom.xml. So most
plugins are configured with simple key/value pairs, with the values
being passed as text, even when they have some internal structure. That
pretty much ruins most benefits of XML. I think ant has done a much
beter job with their plugin interface, in all of these aspects.


CONTRIBUTING

I also tried to play my part in improving maven. In some places I
failed, as I couldn't find my way around the complicated network of tiny
modules depending on one another and the immensely bulky plexus
interactions between them. In other cases I succeeded to tweak my local
code here. Sometimes I could even get my maven to use my own snapshot
version of a plugin. I submitted patches to jira and in some cases I
didn't get even a reply till now, more than half a year later. That
doesn't exactly encourage working on maven to match it to my needs.


DOCUMENTATION

Maven documentation is difficult to find and to read. Help pages for
mojos consist mostly of machine-generated text, with often only a single
sentence of less about the role of each parameter. Most maven generated
project pages provide little information distributed over many pages.


CONCLUSION

On the whole, I spent way too much time tweaking Maven, time I'd rather
spend working on my project code. I now decided to abandon maven, at
least for my end user applications. I'm not sure what I'll be using
instead. Maybe some form of ant, with or without ivy, with or without
build files generated from xslt. I also started thinking about writing
my own build tool. If I do, I might use a Java interface to it instead
of an XML interface. After all, we are all Java developers and know how
to speak Java; why should we need to learn a new language for our build
tools? But that's a different topic.

Greetings,
 Martin von Gagern

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

Re: Not happy with maven

[nicolas de loof <ni...@apache.org>]

Just my pesonnal conviction :
Maven is not the golden bullet tool. It has many issues (some you describe),
and can't cover all requirements.
Many project choosed some complex building (like the sign / assembly process
you describe) that does not match maven conventions.

Maven is a toll for project that can share some basic convention, and then
get benefict for many other tool to plug naturally in project structure. For
this reason, it works fine for business projects where same conventions on
all project = more productivity.

Just my 2 cents,

Anyway, thanks for your feedback,

Nicolas.

2008/11/19 Martin von Gagern <Ma...@gmx.net>

> Hi everybody!
>
> I've been using Maven 2 for a few projects now, and found that, although
> it provides some nice features, it doesn't seem to be the right tool for
> most of my applications. I'll write down some of my experiences here, so
> that they might help improving development tools in general.
>
> I'm an individual Java programmer interested in developing open source
> applications. I don't work for any company, therefore copany
> repositories don't apply to me. Most of my projects are swing GUI
> applications intended to be run by users on their local computers, so
> integration tests are mostly irrelevant, and the possibilities for
> automatic testing are limited as well.
>
> This mail is not intended to start a flame war. I know there are people
> using maven and happy with it, and for good reasons. I might even
> continue using it for my library projects.
>
> I guess many of the issues I don't like about maven could be helped with
> more knowledge about Maven, customized plugins, hackish workarounds, or
> any other kind of additional work. It's the sum of all together and the
> amount of work required which lead me away from Maven. I list these
> issues in no particular order.
>
>
> MAVEN REPOSITORY AS ONLY SOURCE OF DEPENDENCIES
>
> While the large repository used by maven is a great thing, one of the
> most prominent advantages of Maven, it is in no way complete. Whenever I
> want to make use of some library not available in a common repository, I
> first have to get it into some repository I control, then have to get
> that repository into the pom of my project, and at some point have to
> grant public access to that repository if I want to share with other
> developers. I would much prefer some kind of lib directory, where I
> could simply drop the library and start using it, to see if it is fit
> for the job I want to use it for in the first place. Then if I decide to
> keep it, I would rather add some instructions to my repository about how
> to get this library from its official source. Such instructions might
> involve downloading some bundle, checking its md5sum in case its file
> name contains no version number, extracting it, maybe running some
> installer and interactively accepting some license, stuff like that. I'd
> rather include such descriptions with the dependency than have an extra
> file that describes how to set things up for maven.
>
>
> ORDER OF TASKS
>
> The maven POM seems to lack a clear concept of task order. This seems
> especially important in the packaging phase. Suppose I produce a jar
> which I want to pack200, jarsign, gpgsign, include in an assembly, and
> gpgsign that assembly again. Clearly order matters a lot. While I
> believe it might be possible to get the order correct in Maven as well,
> there is no intuitive way to express this order when conceptually all
> you do is load a bunch of plugins.
>
>
> TOO SLOW
>
> Maven is simply to slow, especially while starting up. WHile developing,
> I often want to edit the code, compile the code, and run the code, all
> in a tight loop. When over 50% of the time is spent starting that maven
> monster, that's no efficient use of time. As Maven seems to lack a
> simple "run" target, running the code usually means either some
> complicated java invocation, or a packaged jart with the dependencies
> included in its Classpath, which means executing the package phase and
> before that the test phase, leading to even longer build times.
>
>
> SECURITY CONCERNS
>
> Maven does a lot of things automatically. While this is a good thing if
> I simply want to grab a piece of code and build it, it can be annoying
> under security aspects. I can't specify repositories for specific
> artifacts only. So whenever I want to grab a dependency from a given
> repository, I'll have to include it in the POM, and it will be queried
> for every artifact Maven wants to download or update. So a malicious
> repository could introduce malicious artifacts into my local repository,
> affecting all my other projects as well.
>
> Another aspect of this security issue is the fact that there seems to be
> no way to ask the user for a password for e.g. jarsigner and hand that
> to jarsigner by some means other than a command line argument. On a
> multi-user *nix machine, users can see what commands other users are
> running, and I don't like them seeing my keystore passphrase. And
> storing these passphrases in a file for maven seems comparably evil.
>
>
> TERRIBLE COMMAND LINE INTERFACE
>
> I know, many developers are using IDEs and probably wouldn't even notice
> such issues. But I still prefer to edit my source code in an editor and
> build its artefacts from the command line. If I do so with maven I find
> the output from the help commands which might be good for machines to
> read, but is plainly annoying to me. I find all messages preceeded by
> the message category and thus hard to read. I find absolute file names
> all over the place, leading to excessively long lines. On the whole,
> maven doesn't look well suited to command line operations.
>
> When I compare this to command line tools like e.g. bzr, where I can get
> exhaustive and easy to read help for every command, this feels like a
> different thing altogether.
>
>
> JNI ISSUES
>
> In some cases I use libraries which employ JNI, or write JNI code
> myself. Mavens lack of cross-compiler support severely limits the
> development of JNI builds. Installing third party JNI artifacts in the
> repository in such a way that they can be loaded seems difficult work at
> best, if possible at all. Probably native libs would have to be copied
> to some library dir from where they could be loaded. The fact that the
> install:install-file mojo doesn't seem able to attach additional
> artifacts further complicates issues, as I would need one POM per
> os/arch combination, instead of a classifier.
>
>
> DOM STRUCTURE
>
> I believe that the DOM is mixing multiple things that don't belong into
> one file in my opinion. The DOM contains information about what the
> project is, like name, description, authors, license. This information
> is intended for every user of the project. Next it contains information
> about the plugins and their configuration, which describes how to build
> the project and is thus intended for developers, including contributors,
> and also for people who prefer building apps from source. And last there
> is information about the deployment process and site generation, which
> is relevant only to the official developers with write access to the
> necessary infrastructure, and might contain internal information like
> paths to local directories or similar. I believe these three aspects
> should be split in two to three files. I'll grant you that the
> distinction between build and deployment description isn't always a neat
> line, and internal infrastructure can always be hidden in properties set
> by private Maven configuration files.
>
> On the other hand, the DOM is missing several top level elements I would
> consider part of the project itself, not belonging to one of the
> plugins. Foremost among these I would count file encoding. Why do I need
> to configure it again and again for every plugin that operates on source
> files, instead of specifying it once and for all, with the possibility
> to override it on a per-file and per-plugin basis if need be? Yes, I can
> have some common ancestor configure the plugins and use a common
> property name for the encoding, but this kind of hacks seems to go
> against the whole idea of POMs describing projects.
>
>
> MODULES AND ARTIFACTS
>
> Theoretically the pom describes a single module, and several files could
> belong to this module. However, one of them is the "main artifact", the
> others are "attached artifacts". This distinction seems somewhat
> artificial. Furthermore, there is no single place within the dom where
> all the possibly generated artifacts were listed. And interdependence
> between artifacts (like one containing the other) are not expressed
> either. I guess I would prefer clean instructions, like these source
> files are processed by these build tools in order to produce these
> artifacts.
>
>
> LANGUAGE AND API VERSIONS
>
> There are still systems out there that don't use Java 1.5, often can be
> updated only at a cost or not at all, and therefore applications that
> need to run on 1.4. On the other hand, I prefer to use the latest JDK
> here for development, with all the latest features like -Xlint. (By the
> way: as Maven claims to promote "best practises": I'd consider -Xlint
> one of these.) I also would want to use Java 1.5 syntax for test cases,
> as it is much shorter and clearer in many cases. So I'd like to compile
> all my code using the latest javac, but substutute the bootclasspath of
> a different Java API version when compiling the main project code, along
> with providing the appropriate -source and -target switches. Not
> possible in Maven, afaik. I'm not sure how these different APIs could be
> managed by any build tool. I guess you could either provide information
> where to look for these on common systems, like Windows, OS X, Solaris
> and the major Linux distributions, while leaving the user an option to
> specify non-standard paths per user or per system, not per project. An
> alternative would be to ship stub JARs with the tool, containing all the
> public interface of the official Java APIs but no executable code, thus
> preserving space and avoiding licensing issues.
>
>
> EXTENDING MAVEN
>
> Many things in maven can be solved by writing your own plugins. I don't
> like the plugin interface at all, though, especially the way
> configuration works. Most Mojos use private variables for configuration,
> something I would consider part of the public interface of the plugin.
> This means you can't simply derive your own Mojo by subclassing some
> existing one, as you can't get at those private variables. It also means
> that you can have no getters and setters checking the access to these
> variables. And if you want to use complex types for plugin
> configuration, you have to state class names in the pom.xml. So most
> plugins are configured with simple key/value pairs, with the values
> being passed as text, even when they have some internal structure. That
> pretty much ruins most benefits of XML. I think ant has done a much
> beter job with their plugin interface, in all of these aspects.
>
>
> CONTRIBUTING
>
> I also tried to play my part in improving maven. In some places I
> failed, as I couldn't find my way around the complicated network of tiny
> modules depending on one another and the immensely bulky plexus
> interactions between them. In other cases I succeeded to tweak my local
> code here. Sometimes I could even get my maven to use my own snapshot
> version of a plugin. I submitted patches to jira and in some cases I
> didn't get even a reply till now, more than half a year later. That
> doesn't exactly encourage working on maven to match it to my needs.
>
>
> DOCUMENTATION
>
> Maven documentation is difficult to find and to read. Help pages for
> mojos consist mostly of machine-generated text, with often only a single
> sentence of less about the role of each parameter. Most maven generated
> project pages provide little information distributed over many pages.
>
>
> CONCLUSION
>
> On the whole, I spent way too much time tweaking Maven, time I'd rather
> spend working on my project code. I now decided to abandon maven, at
> least for my end user applications. I'm not sure what I'll be using
> instead. Maybe some form of ant, with or without ivy, with or without
> build files generated from xslt. I also started thinking about writing
> my own build tool. If I do, I might use a Java interface to it instead
> of an XML interface. After all, we are all Java developers and know how
> to speak Java; why should we need to learn a new language for our build
> tools? But that's a different topic.
>
> Greetings,
>  Martin von Gagern
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Not happy with maven

[Graham Leggett <mi...@sharp.fm>]

Martin von Gagern wrote:

> On the whole, I spent way too much time tweaking Maven, time I'd rather
> spend working on my project code.

One of the most fundamental things about maven that you need to do to 
have a pleasant user experience, is to submit to maven.

In other words, you shouldn't spend time tweaking maven, you should 
rather spend time tweaking your project to work using the standard way 
maven works.

This is a big ask for many people I know, people come to maven going 
"but I want it to work like this, and maven won't let me".

Standardisation means that if you follow the standards, there is a whole 
class of problems that are already solved. If your code is in a standard 
place, you no longer need to tell anybody, whether a computer or a 
human, where your code is, they already know. If your release procedures 
are standardised, you no longer need to tell anybody, whether a computer 
or a human, how to release your code or where it lives, they already know.

Standardisation however doesn't help you if you want to invent your own 
standard. If you invent your own standard, you have to write the code 
yourself, and for me personally, rewriting your own standard is a waste 
of time and money.

 > I now decided to abandon maven, at
 > least for my end user applications. I'm not sure what I'll be using
 > instead. Maybe some form of ant, with or without ivy, with or without
 > build files generated from xslt.

So you replace an exercise in messing around with maven with an exercise 
in messing around with ant.

I don't see how that will help you focus on development.

Regards,
Graham
--

RE: Not happy with maven

[EJ Ciramella <ec...@upromise.com>]

I've been stewing on this for a bit and while I think some of these
things are a "didn't know better/didn't know about that option", there
are some valid complaints in here.

ORDER OF TASKS

There are plenty of plugins - both available via repo1 and internally
developed here that would be much better served if we could bind them to
a particular time frame of a lifecycle goal.  For example - why does the
packaging type of ear care if the ejbs have been built yet because it
has dependencies on them?  Too often I think it'd be nice to choose to
bind the beginning or end of a goal - say, end of package stage for
anything to do with an ear.  Or maybe you want something between
process-resources and compile.  Or at the end of compile only.

TOO SLOW

Even with minimal reporting plugins configured, a 10 min build can
double or triple in time if you run mvn site.  Some of this is due to
known bugs (re-running the tests with instrumented classes for example),
the rest I can't explain.

EXTENDING MAVEN

This is a mixed bag - I shouldn't have to resort to google code search
to see how some constants/properties/methods/classes/etc. are used.   It
should be clearly spelled out in the documentation (which is isn't).
Additionally, if you'd LIKE to extend maven, the best way to do so is to
set up your own repository - forget about the "provided" option (lots of
branching/deleting/etc of jars that you shouldn't have to manage in this
way).

CONTRIBUTING

I can't say I've filed a billion bugs against maven, but I will agree
that it's like throwing change into a wishing well.  When you do find an
issue, more often than not, you're asked to file a bug only to be told
to use the latest of some plugin and that has the fix/behaves better.
This leads to not specifying versions in the plugin configuration which
is VERY dangerous.  It's wild when a build starts failing and you know
nothing has changed w/r/t the assembly/packaging instructions that
you're aware of.

DOCUMENTATION

Still poor - why not enforce some standards here?  There are standards
everywhere else.  Look at the site:stage goal output:

http://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html

locales 	String 	- 	A comma separated list of locales
supported by Maven. The first valid token will be the default Locale for
this instance of the Java Virtual Machine.

Why not have those listed right there?  Not too long ago I asked about
how to specify a range or "latest" of a dependency - I was handed back a
link to a wiki I spent some time searching prior to asking the board.

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

Re: Not happy with maven

[Trevor Harmon <tr...@vocaro.com>]

On Nov 19, 2008, at 1:44 PM, Martin von Gagern wrote:

> I would much prefer some kind of lib directory, where I
> could simply drop the library and start using it, to see if it is fit
> for the job I want to use it for in the first place.

You can accomplish that by specifying the dependency with a "system"  
scope. You'd tell Maven about your lib directory using <systemPath>.

> The maven POM seems to lack a clear concept of task order. This seems
> especially important in the packaging phase. Suppose I produce a jar
> which I want to pack200, jarsign, gpgsign, include in an assembly, and
> gpgsign that assembly again. Clearly order matters a lot.

I've had the exact same concern. Anyone have an answer for this?

> Another aspect of this security issue is the fact that there seems  
> to be
> no way to ask the user for a password for e.g. jarsigner and hand that
> to jarsigner by some means other than a command line argument. On a
> multi-user *nix machine, users can see what commands other users are
> running, and I don't like them seeing my keystore passphrase.

One way to handle this is with the antrun plugin. You can use the  
input task to prompt for a password and assign it to a property:

   <input message="Password?" addproperty="jarsigner.password" />

> Why do I need
> to configure it again and again for every plugin that operates on  
> source
> files, instead of specifying it once and for all, with the possibility
> to override it on a per-file and per-plugin basis if need be? Yes, I  
> can
> have some common ancestor configure the plugins and use a common
> property name for the encoding, but this kind of hacks seems to go
> against the whole idea of POMs describing projects.

I'm a little confused. You say you want to specify file encoding in  
one place, but you don't want to specify it in a common ancestor. How  
do you envision this working?

> And interdependence
> between artifacts (like one containing the other) are not expressed
> either.

Isn't that what modules express?

> I guess I would prefer clean instructions, like these source
> files are processed by these build tools in order to produce these
> artifacts.

But that is precisely what a POM is. It defines what source files are  
to be processed, what build tools to use, and the artifacts that will  
be produced. It may not be explicit, instead defined in a parent POM  
or the Super POM, but that's only to eliminate redundancy. You just  
have to learn how to read a POM file.

> So I'd like to compile
> all my code using the latest javac, but substutute the bootclasspath  
> of
> a different Java API version when compiling the main project code,  
> along
> with providing the appropriate -source and -target switches. Not
> possible in Maven, afaik.

How about using the compiler plugin's bootclasspath compiler argument?

Trevor


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

Re: Not happy with maven (suggestion)

[Martin von Gagern <Ma...@gmx.net>]

Michael McCallum wrote:
> You have put a lot of effort into this email and its really important to spread the ideas around,
> could you put these issues into jira with suggested solutions? To give more visiblity.

I might, for some of them, if I find the time. I guess some of my ideas
concern things very basic to Maven, so I see little chance to get them
addressed. I'll think about that when I go over the list again.

Martin

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

Re: Not happy with maven (suggestion)

[Michael McCallum <gh...@apache.org>]

You have put a lot of effort into this email and its really important to spread the ideas around,
could you put these issues into jira with suggested solutions? To give more visiblity.

cheers

-- 
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org

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

Re: Not happy with maven

[Barrie Treloar <ba...@gmail.com>]

>> Regarding "writing your own build tool" -- I think this is probably a
>> bad idea, but of course, you are welcome to disagree. If you have
>> decided to abandon Maven, perhaps take a look at "buildr" and other
>> tools (you already mentioned ivy) that have taken ideas from Maven and
>> incorporated the Central repository as a source of dependency
>> artifacts etc.

Of course, you can stick with Maven where it works and then invoke ant
for those areas that maven doesn't yet support (or do well).

E.g. the signing of artifacts in a specified order should be a simple
thing for ant to do.

For jars that are not in the repository you could store them in the
projects lib/ directory and define a system scope with corresponding
systemPath.  This practice is discouraged and you would be better off
to submit the artifact for inclusion on the central repository and/or
convince the project maintainers to do this.

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

Re: Not happy with maven

[Martin von Gagern <Ma...@gmx.net>]

Wayne Fay wrote:
> We see "rants" like this every few months from someone. And the fact
> that this is your 4th email to this group suggests that you have
> generally been "going it alone" rather than leaning on this group as
> needed for help. (Note: this is not an open call for n00bs to blast
> this list with the most basic of queries.)
> 
> Obviously, the documentation etc can only take you so far. While this
> users list cannot answer every question you may have, I think your
> overall experience with Maven would have been improved if you had sent
> some of these questions/issues to this list previously looking for
> help rather than letting it all boil up for months and eventually
> releasing it in this email.

Maybe. My previous posts mentioned a few of these issues. For others I
found a way to hack things together, only didn't like its hackish
nature. For some more, I wrote patches or feature requests for jira.

> Regarding "writing your own build tool" -- I think this is probably a
> bad idea, but of course, you are welcome to disagree. If you have
> decided to abandon Maven, perhaps take a look at "buildr" and other
> tools (you already mentioned ivy) that have taken ideas from Maven and
> incorporated the Central repository as a source of dependency
> artifacts etc.

Thanks, I will.

Martin

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

Re: Not happy with maven

["David C. Hicks" <dh...@i-hicks.org>]

Wayne Fay wrote:
> Regarding "writing your own build tool" -- I think this is probably a
> bad idea, but of course, you are welcome to disagree.
There is a contingent at my office that believes they should write their 
own build system.  They manage a HUGE project using a directory full of 
Ant scripts.  It's insane.  I came along and started using Maven for the 
projects I was leading up.  Folks are beginning to take notice that, 
"Hey, he's getting builds to run smoothly without a ton of effort.  
What's that all about?"  Of course, I am of the "don't re-invent the 
wheel" school of thought.  I'm not going to waste my own time writing 
something that a lot of other really bright people have already put a 
lot of thought and effort into.  I don't see how I could possibly 
compete with that on my own.


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

Re: Not happy with maven

[Wayne Fay <wa...@gmail.com>]

> I guess many of the issues I don't like about maven could be helped with
> more knowledge about Maven, customized plugins, hackish workarounds, or
> any other kind of additional work. It's the sum of all together and the
> amount of work required which lead me away from Maven. I list these
> issues in no particular order.

We see "rants" like this every few months from someone. And the fact
that this is your 4th email to this group suggests that you have
generally been "going it alone" rather than leaning on this group as
needed for help. (Note: this is not an open call for n00bs to blast
this list with the most basic of queries.)

Obviously, the documentation etc can only take you so far. While this
users list cannot answer every question you may have, I think your
overall experience with Maven would have been improved if you had sent
some of these questions/issues to this list previously looking for
help rather than letting it all boil up for months and eventually
releasing it in this email.

Regarding "writing your own build tool" -- I think this is probably a
bad idea, but of course, you are welcome to disagree. If you have
decided to abandon Maven, perhaps take a look at "buildr" and other
tools (you already mentioned ivy) that have taken ideas from Maven and
incorporated the Central repository as a source of dependency
artifacts etc.

Wayne

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

Re: Not happy with maven

[Kent Närling <ke...@seamless.se>]

>
> MAVEN REPOSITORY AS ONLY SOURCE OF DEPENDENCIES


I don't see the big issue here , as others have pointed out you can solve
this with a system scope.
On the other hand, setting up your own repository is actually very simple
and gives a lot of advantages (like proper version tracking of the
dependencies etc)


> ORDER OF TASKS
>
I do agree that the logic of maven is sometimes unclear in this regard (and
others), however this is a type of problem common to many tools.
Also, as others have said, a simple antun task solves your example problem
quite nicely.


> TOO SLOW

Yes, if you use it in the way you described then I agree that it will be
slow.
On the other hand, if you use a sensible IDE like Eclipse or Netbeans, the
test cycle you describe will be MUCH shorter than ANY build tool! (you never
have to build just to test run)
If you don't want to use these nice IDE:s, then you really want to do it in
your specific way and then I definitely think maven is a bad pick for you.

We use Eclipse and then maven is simply the build tool when we run a FULL
build, either manually or in the build server.




> SECURITY CONCERNS
>
> for every artifact Maven wants to download or update. So a malicious
> repository could introduce malicious artifacts into my local repository,
> affecting all my other projects as well.

Well, if you use the public repositories directly then you decide to trust
them and then I guess you have to accept that.
One option I guess is to set up your own repository  as the ONLY repository
and them set it to mirror the central repositories selectively. Nexus has a
lot of configuration options regarding this at least.
Naturally this would require some work, but if you want to use open-source
components in your code, then you will have this problem anyway and either
have to accept it or manually manage and validate your repository .


> JNI ISSUES
>
> In some cases I use libraries which employ JNI, or write JNI code
> myself. Mavens lack of cross-compiler support severely limits the
> development of JNI builds. Installing third party JNI artifacts in the
> repository in such a way that they can be loaded seems difficult work at
> best, if possible at all. Probably native libs would have to be copied
> to some library dir from where they could be loaded. The fact that the
> install:install-file mojo doesn't seem able to attach additional
> artifacts further complicates issues, as I would need one POM per
> os/arch combination, instead of a classifier.


It is interesting that noone here has commented this so far?
I am no expert in this area (but we will need to look more at non-java
compilation soon), however I get the feeling that the non-java support in
maven is a bit less "mature" than the java side (for natural reasons maybe).
However AFAIK this should not be a problem with the maven architecture, but
more likely lack of plugins(mature) for the different aspects?
The dependencies and compilation should be solvable using classifiers and
profiles quite nicely? anyone more experienced care to comment on this? it
is an interesting problem...


>
>
> DOM STRUCTURE


Again interesting that this has not been commented by others yet.
I personally don't see the huge contradiction/ambiguity that you describe,
yes the POM IS wide, but that is something that is pretty obvious from the
scope of maven.

>
> plugins. Foremost among these I would count file encoding. Why do I need

I definitely see a point here, but this is a detail that should be fairly
easy and sensible to fix in future versions of maven?

>
> EXTENDING MAVEN
>
> Many things in maven can be solved by writing your own plugins. I don't
> like the plugin interface at all, though, especially the way


I have to say I like that it is VERY easy to get started writing your own
plugin, something that is not true for many other frameworks...
I do agree to your points regarding configuration and I hope your points
regarding this are taken as feedback for future versions as they are very
specific and constructive.


>
> DOCUMENTATION


> Maven documentation is difficult to find and to read. Help pages for
> mojos consist mostly of machine-generated text, with often only a single
> sentence of less about the role of each parameter. Most maven generated
> project pages provide little information distributed over many pages.


Amen to this!
I like maven a lot and have a lot of gratitute for the people writing
plugins etc but if it is one thing that is constantly frustrating is that
the documentation many times is lacking/confusing/hard to find etc etc
Granted, this IS a very common for many open-source projects, but given the
talent in the maven community and the efforts that have been attempted in
standardizing plugin documentation etc it is a pity.
It is particularly frustrating when you find a nice and relatively mature
plugin that HAS some documentation but it is very hard to find without
searching forums for links to it etc (eg docbkx plugin here)