You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ashley Williams <ag...@mac.com> on 2005/09/20 15:19:22 UTC
[m2] reasons for sticking with maven
Sincere apologies to the dev team if this email seems like a troll, I
absolutely don't mean it to be. I'm aware that they continue to do
outstanding work and are few in number.
The more I use Maven the more I get a feel for the size and shape of
it and find myself looking for features that aren't there. Since I
joined the community I've posted questions on what I consider to be
the most important aspects of a build system namely (yes in this order):
1. Usability from Ant - there are hundreds of Ant targets out there
that are useful for me today. I can't justify waiting for them to be
rewritten as Maven equivalents not only because I need functionality
today, but also because I don't see why I have to abandon my
experience with ant.
2. Usability from Eclipse - when will I be able to ditch the command
line and create and manage projects entirely from eclipse
3. Need to do a myriad of simple things such as automatically run
java command or deploy to tomcat. I used to do this all the time in
my ant scripts, ie run my build.xml script and at the end it would
run my app on completion. It's a credit to those on this list who
reply with ideas and workarounds - however this is kind of related to
2 above, where there are lots of ant tasks out there that are tested
to death and that I should be able to use today.
4. Online documentation. Simple example was trying to get the
assembly plugin to work which Daniel Shomer had to look into the
source code to advise me of what to do. This is just one example of
many.
5. Other project structures. Sometimes I will encounter a project
where all the source code is in one tree (beginning with com/). I'm
not saying its any better than one directory per artifact, but I am
saying I encounter such projects in my career and as such I know I
wouldn't be able to use maven.
6. Contribute to the code. I have tried to get a foot in the door in
order to fix some of my own critisisms, but the lack of javadocs mean
that I really can't do this other than for some simple plugins. That
is unless I had lots of time to spare which I don't. In turn that
makes me concerned how the project will attract other developers to
move things along quickly.
I realize there may be workarounds for some of the above, but I
couldn't stick my neck on the line for a dev team and recommend
sharing of eclipse hack scripts etc as a way of working. I'm also
putting my selfish hat on and say that I'd like to do the above
without defending it - there are a few threads on this list already
that deal with the pros and cons.
***************************************
Now I'll turn my attention to Ivy. I've began to look at this product
and it seems to offer many of the features of Maven including
1. transitive dependencies
2. compatibility with the ibiblio repository
and in addition
1. the online docs are excellent even if they are in broken english
2. Can manage projects from with eclipse, since they are just ant
projects (with simple projects, haven't tried anything tricky)
3. Can manage maven style module directory structures or single
source trees. Obviously being Ant, it can manage any structure you
like, but these are the only two sane ones I know.
Yes there is stuff that it doesn't have such as a built in lifecycle,
but with what I've learnt from the maven layout, I feel I could quite
easily replicate that in ant in a reusable way. That said I would
prefer not to have to. I suppose I'm looking for reassurance as to
why Maven is the way to go because there seems to be considerable
overlap with Ivy.
****************************************
I realize that I am being very selfish here, but I have to think very
carefully about what I invest my time in. Maven has all the hallmarks
of being that software that I felt was missing during my career,
which is why I care enough about it to spare the time for these
critisisms. I just want to be sure it has a chance of gaining
critical mass.
Maybe the gatekeeper/guardian of this project needs to write some
sort of Jerry Maguire style memo that says what Maven's purpose is
and plans are so that we can all keep focused on that.
Maybe my views aren't representative of a large enough demographic in
which case this email will just slip away into obscurity, but either
way thanks for reading and please don't take it as a troll
-AW
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Brett Porter <br...@gmail.com>.
Ugh, what a long thread to wake up to when you've got a headache :)
I think there have been some very good answers here already, but I'll add my
own thoughts for completeness.
On 9/20/05, Ashley Williams <ag...@mac.com> wrote:
>
> Sincere apologies to the dev team if this email seems like a troll, I
> absolutely don't mean it to be. I'm aware that they continue to do
> outstanding work and are few in number.
Thanks, much appreciated. Constructive criticism is always welcome :)
1. Usability from Ant - there are hundreds of Ant targets out there
> that are useful for me today. I can't justify waiting for them to be
> rewritten as Maven equivalents not only because I need functionality
> today, but also because I don't see why I have to abandon my
> experience with ant.
So far we've only addressed usability OF Ant. You can run ant scripts at
phases of the lifecycle using antrun, you can write java plugins that use
the Ant API, and Chris and John are putting together Ant plugins. You can
already sort of do this with Marmalade (at least that was the intent).
The key is that you still get the reusable infrastructure that Maven
provides which is what we view as the most important feature of Maven (yes,
its not dependency management!)
Funnily enough, before I logged in this morning, I was pondering starting
the long overdue discussion with the Ant team on how we can best work
together to move forward. Ant and Maven are completely different
applications, but they could share a lot of code at the task/plugin level.
As Jason said, we've been working to do this in the form of common libraries
as they are also usable outside of both Ant and Maven, and it'd be good to
get a shared direction happening there.
Using Maven from Ant? I'm not sure if that is what you meant, but that would
be possible too and there is an open JIRA. So far, just dependency
management is available.
2. Usability from Eclipse - when will I be able to ditch the command
> line and create and manage projects entirely from eclipse
I'm really surprised this is #2, but as others have pointed out its high on
our list too. But we need to finish Maven first, then work on integration.
3. Need to do a myriad of simple things such as automatically run
> java command or deploy to tomcat. I used to do this all the time in
> my ant scripts, ie run my build.xml script and at the end it would
> run my app on completion. It's a credit to those on this list who
> reply with ideas and workarounds - however this is kind of related to
> 2 above, where there are lots of ant tasks out there that are tested
> to death and that I should be able to use today.
Are you sure they are tested to death? :)
But as stated in 1), you should be able to do this just fine. The important
thing is that you are encouraged to spend the small amount of time making it
reusable for other projects of your own, and hopefully if something
comprehensive is put together then it is shared with all Maven users.
4. Online documentation. Simple example was trying to get the
> assembly plugin to work which Daniel Shomer had to look into the
> source code to advise me of what to do. This is just one example of
> many.
Yep, we're working on it. I don't think the emphasis should be on javadocs
(With the exception of the plugins, where that is what generates the plugin
reference). Short howtos are the approach we are taking for the Maven doco
itself. Contributions are welcome, there is a wanted list on the web site.
5. Other project structures. Sometimes I will encounter a project
> where all the source code is in one tree (beginning with com/). I'm
> not saying its any better than one directory per artifact, but I am
> saying I encounter such projects in my career and as such I know I
> wouldn't be able to use maven.
Oh well, its not a silver bullet. There are probably a lot of other things
you can't do with that structured project, and maybe you don't need to. If
at some point the benefits of restructuring and using Maven outweigh the
costs, then go for it - in the mean time, use whatever is already there.
There's no way this would make it to #5 on my wish list :)
6. Contribute to the code. I have tried to get a foot in the door in
> order to fix some of my own critisisms, but the lack of javadocs mean
> that I really can't do this other than for some simple plugins. That
> is unless I had lots of time to spare which I don't. In turn that
> makes me concerned how the project will attract other developers to
> move things along quickly.
Yes, we're working on that too. We've had several new contributors, but
there are some barriers to entry. Specific pointers to things that are too
hard are good.
Now I'll turn my attention to Ivy. I've began to look at this product
> and it seems to offer many of the features of Maven including
>
> 1. transitive dependencies
many != 1 :)
As Jason said, apples and oranges. Ivy is a very good dependency manager. So
is Maven. Ivy doesn't do anything else. Maven does.
2. compatibility with the ibiblio repository
otherwise known as leveraging all our hard work :)
The Maven team and community (through upload requests) created and maintain
that repository, and established automated sync processes with open source
organisations and hope to grow that.
BTW, we offered for Ivy to use our metadata as well, and had some
discussions, but they declined. So as of today they still have 29 artifacts
usable OOTB (the same as when Ivy 1.0 was released). Maven adds that many
every day, usable now. Some of it has some crud to clean up, but we're
working on that this month too. Ivy has a sandbox with more - no idea how
much or how usable it is - it basically seems to be the result of the spring
build.
Here's a short feature comparison, just in terms of dependency management
tasks (excluding all the other things maven brings). These are things Ivy
don't actually list on their comparison page that you later refer to, but
are lumped under "transitive dependencies". In all other aspects I consider
Maven to be as good as or better than Ivy (with the exception of no eclipse
plugin :)
Dependency ranges:
- Ivy supports simple notation of 2.1+ which is equivalent to Maven's [2.1,
3.0)
- Maven supports any range you can specify, using set notation, eg [1.0,1.4
),(1.4,2.0) which is the latest 1.x version that fits, but I don't want 1.4.
I expect this would be rarely used, but it is powerful.
Versions:
- Ivy supports string comparison for determining the greater version
- Maven supports a defined ordering (so 0.10.0 > 0.9.0) modelled on best
practices. If the version doesn't match that pattern, it uses string
comparison. We intend to make this strategy pluggable.
Different conflict resolution techniques:
- Ivy seems to support a few here: all, latest-time, latest-revision, fixed
- Maven is yet to support this completely, but essentially supports
"nearest" and "fixed". Nearest is the closest in the graph, which becomes
fixed when it is in the current POM. All (you can't use 2 versions at once)
and latest-time (we don't use file timestamps, but instead snapshot
metadata) don't make sense in Maven. The others we intend to add are
"newest" (latest-revision), "oldest" and "fail" (if they don't all match,
fail), as well as making it pluggable. It narrowly missed beta-1 and should
be in the 2.0 release (one of the few new features to add in a beta cycle
because the infrastructure is already there and it won't break
compatbility).
"Continuous Integration" support:
- Ivy supports publishing an integration build (like Maven's snapshots)
- Maven supports a wide range of options controlling the use of snapshots,
frequency of receiving updates, timestamping and build numbering
Profile support:
- Ivy supports "configurations" - hard coded ids that can be used to enable
certain dependency sets.
- Maven defines a consistent profile layer, that can be activated by not
only ids, but by pluggable activators including the JDK version, operating
system, and other environmental factors such as the user building the
project. This applies to the whole project build process, not just
dependencies.
Scope support:
- Ivy requires the use of overloaded configurations for this
- Maven builds the notion of the lifecycle in to dependency management, so
can do intelligent scoping of the dependencies (eg, compile scope
dependencies are also available for runtime and tests)
Filtering:
- I couldn't find Ivy support for this, but since you create the metadata
yourself most of the time it isn't surprising.
- Maven allows you to exclude dependencies from the tree. It also allows you
to apply a particular version or scope to a dependency.
Multiple project support:
- I thought I saw mention of very basic support of this, but couldn't find
it on the web site.
- Maven allows you to build multiple projects at once, and the results are
used as the dependncies encountered in other projects. The order of the
builds is determined by the dependencies.
System scoped dependencies:
- Ivy has no support for this (you would likely declare it yourself anyway)
- Maven supports this for things like tools.jar.
I should note that this is just friendly competition for us - please don't
take it as an us vs them. If Ivy and Ant does what you need, go for it. But
perhaps through our lack of documentation (which this should now be turned
in to!), many people don't realise that Maven meets and exceeds the
capabilities of Ivy in all areas bar one on which it is very close.
and in addition
>
> 1. the online docs are excellent even if they are in broken english
Yes, its important. They only got that way after they declared 1.0 though.
Give us the same benefit of the doubt that we'll get there :)
2. Can manage projects from with eclipse, since they are just ant
> projects (with simple projects, haven't tried anything tricky)
This isn't a feature of Ivy. You can generate Ant scripts from Maven too, or
use the Maven ant tasks for dependency management.
3. Can manage maven style module directory structures or single
> source trees. Obviously being Ant, it can manage any structure you
> like, but these are the only two sane ones I know.
Again, this isn't a feature of Ivy. You can generate Ant scripts from Maven
too, or use the Maven ant tasks for dependency management.
Yes there is stuff that it doesn't have such as a built in lifecycle,
> but with what I've learnt from the maven layout, I feel I could quite
> easily replicate that in ant in a reusable way.
Yes, you could. And it would be different to everyone else's. And then,
every time you need a new feature, or tool integration into that cycle, you
could implement that too. Do you have time?
That said I would
> prefer not to have to. I suppose I'm looking for reassurance as to
> why Maven is the way to go because there seems to be considerable
> overlap with Ivy.
Yes, there is considerable overlap. Maven completely overlaps it :) That's
about 15-20% of Maven's functionality, though, as I've said above.
I realize that I am being very selfish here, but I have to think very
> carefully about what I invest my time in. Maven has all the hallmarks
> of being that software that I felt was missing during my career,
> which is why I care enough about it to spare the time for these
> critisisms. I just want to be sure it has a chance of gaining
> critical mass.
I'm not sure what you mean by critical mass? We've exceeded a lot of the
milestones we'd have thought unachievable in the past and it has grown much
more strongly than expected in recent months. We've got a lot of work to do,
and we welcome help. But we're still on the upward curve.
Maybe the gatekeeper/guardian of this project needs to write some
> sort of Jerry Maguire style memo that says what Maven's purpose is
> and plans are so that we can all keep focused on that.
We try to educate all new committers in the ideals of the project, and I
think we all agree on therm, which is why among the developers there is
rarely friction. As an open source project, there is no gatekeeper/guardian.
Everyone that participates gets a say. That includes you :)
Hope this was of assistance!
Thanks,
Brett
Re: [m2] reasons for sticking with maven
Posted by Ashley Williams <ag...@mac.com>.
On 20 Sep 2005, at 16:15, John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Comments are inline. Please bear with me, I think my responses are as
> lengthy as your original email! :(
>
> Cheers,
>
> John
>
> Ashley Williams wrote:
> | Sincere apologies to the dev team if this email seems like a
> troll, I
> | absolutely don't mean it to be. I'm aware that they continue to do
> | outstanding work and are few in number.
> |
> | The more I use Maven the more I get a feel for the size and shape
> of it
> | and find myself looking for features that aren't there. Since I
> joined
> | the community I've posted questions on what I consider to be the
> most
> | important aspects of a build system namely (yes in this order):
> |
> | 1. Usability from Ant - there are hundreds of Ant targets out there
> | that are useful for me today. I can't justify waiting for them to be
> | rewritten as Maven equivalents not only because I need functionality
> | today, but also because I don't see why I have to abandon my
> experience
> | with ant.
>
> I've already addressed this with you and others on this list. I've
> mentioned that I'm fully in favor of this sort of integration, and I
> have some starting points from Chris that I'll be putting in to allow
> this sort of thing. You don't have to wait for all of Ant's API to be
> replicated; you only have to wait for me to get this one change in
> place. :)
>
I'm extremely pleased to hear this. I meet all sorts on this list and
I don't know
which contributors are most responsible for steering the project or
are just
giving there opinion on what they would like to happen. Maybe the
roadmap could be maintained a little to show which suggestions have
actually
been taken on board.
> |
> | 2. Usability from Eclipse - when will I be able to ditch the command
> | line and create and manage projects entirely from eclipse
>
> This depends on people with Eclipse development experience (not
> experience using Eclipse) picking up the task and running with it.
> We're
> trying to get something together in the way of a more concerted
> effort,
> but I'm sure you'll agree that getting a stable API was the first
> thing
> to do, since otherwise the Eclipse integration project would have to
> track a moving target. Now that we've got a beta-1 release, we can
> start
> thinking about this.
>
> |
> | 3. Need to do a myriad of simple things such as automatically
> run java
> | command or deploy to tomcat. I used to do this all the time in
> my ant
> | scripts, ie run my build.xml script and at the end it would run
> my app
> | on completion. It's a credit to those on this list who reply
> with ideas
> | and workarounds - however this is kind of related to 2 above, where
> | there are lots of ant tasks out there that are tested to death
> and that
> | I should be able to use today.
>
> The funny thing about Maven 2 is that it facilitates external plugin
> development. You can load a plugin from a repository hosted anywhere.
> Personally, I feel strongly that executing random commands from within
> the build process is a Bad Thing,
I can already do that with a mojo - I can write any old java and
attach it
to any old lifecycle phase. BUT I would love to get up to that same
mischief
using the language/syntax of Ant rather than Java!
> and a thing that is bad and common
> with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
> It's not a launching platform, and it's not a tool to be used to run
> your coffee maker. Executing random commands from a configuration in a
> POM is:
>
> a. unscaleable, since that runtime config is not encapsulated for
> reuse
>
> b. bound to partition your build logic into multiple pieces, which now
> have to be maintained from multiple sources.
>
> In Ant, you can do anything you please, including things that don't
> relate to the process of building software. It's important to keep a
> clear idea of the problem domain we're trying to address here.
> Having said that, there's nothing stopping you from hosting your own
> maven-foo-plugin on Sourceforge or somesuch. If you find what you
> perceive to be a hole in our plugin offering, and cannot convince
> us to
> fill it, there's nothing stopping you from scratching your own
> itch. We
> currently have maven-execute-plugin on the mojos project, but I'd
> really
> like to see it deprecated and eliminated eventually.
>
> |
> | 4. Online documentation. Simple example was trying to get the
> assembly
> | plugin to work which Daniel Shomer had to look into the source
> code to
> | advise me of what to do. This is just one example of many.
>
> You're not the first to point this out, and properly so. Just this
> week,
> one of the devs started fulltime on fixing this. Documentation has
> lagged for a few reasons, which I don't offer as excuses. First, the
> devs have been trying to stabilize the featureset and functionality
> before we try to document it. This is sort of a chicken-egg scenario,
> because (as was pointed out) its easier to maintain a clear design
> between multiple devs when you have documentation, but
> documentation of
> an evolving API gets stale quickly.
>
> Now that you've read the source code for the assembly plugin, will you
> contribute some documentation?
> |
> | 5. Other project structures. Sometimes I will encounter a
> project where
> | all the source code is in one tree (beginning with com/). I'm not
> | saying its any better than one directory per artifact, but I am
> saying
> | I encounter such projects in my career and as such I know I
> wouldn't be
> | able to use maven.
>
> This project can get a little preachy, and I'm no exception. We
> tend to
> believe that we've seen a lot of use cases (many on this list), and
> that
> our standard layout is the most elegant solution THAT WE'VE FOUND SO
> FAR. I emphasize that, because it's important to acknowledge that
> today's gospel is tomorrow's quaint idea. We're focusing on providing
> support for that standard layout/model right now, but we will be
> adding
> support for other project layouts when we learn of deficiencies.
> What we
> most need is use cases. If you have a specific one, can you share it?
> Where, specifically, are you having trouble with meshing your
> layout and
> the POM?
>
I'm only suggesting one other layout - everything under com/... and only
because it's a 'code layout design pattern' I come across often.
Compared
to my other points, this one isn't important for me. I do like the
fact that
Maven gets preachy because it means that I know what to expect from
project to project. However I still feel entitled to point out where
I feel Maven
could be a little more generous!
> |
> | 6. Contribute to the code. I have tried to get a foot in the door in
> | order to fix some of my own critisisms, but the lack of javadocs
> mean
> | that I really can't do this other than for some simple plugins.
> That is
> | unless I had lots of time to spare which I don't. In turn that
> makes me
> | concerned how the project will attract other developers to move
> things
> | along quickly.
>
> I addressed this a little bit above, but I believe Maven 2 is still
> climbing that maturity curve. We're climbing fast, but there are bound
> to be places that need attention. Javadocs may help, but an
> architectural overview and set of mini HOW-TOs may go a lot further.
> There are very few methods in the code that aren't self-
> explanatory, at
> least at a high level.
> However, I still agree that javadocs would be a
> good thing. Unfortunately, as you've so eloquently pointed out,
> there is
> a long line of Good Things waiting for attention
At the very least couldn't we javadoc the mojo properties so that the
plugins
on the maven website have actual descriptions? I'm guessing you eat your
own dogfood and autogen your webpages from the mojo code.
> ...this is where we have
> to prioritize, and choose which ones we will attend to first. We've
> chosen code/feature stability, and API stability heretofore, but we're
> starting to focus on POM usability, additional plugin languages, and
> documentation now that we're in bugfix mode.
>
> If you've spent any time in the sources, and found that you understood
> even a small portion when you were done, would you be willing to write
> some of these javadocs and submit a patch? Every contribution, however
> small, will push us closer to the level of maturity you desire.
>
See my comment later. But personally I would never javadoc somebody
elses
code unless I was getting paid a lot of money for it. Seriously the
most likely
way for code to get javadoced is for the coder to do it themselves,
in my opinion.
Take from that the unfortunate corollary.
> |
> | I realize there may be workarounds for some of the above, but I
> | couldn't stick my neck on the line for a dev team and recommend
> sharing
> | of eclipse hack scripts etc as a way of working. I'm also
> putting my
> | selfish hat on and say that I'd like to do the above without
> defending
> | it - there are a few threads on this list already that deal with
> the
> | pros and cons.
> |
> | ***************************************
> |
> | Now I'll turn my attention to Ivy. I've began to look at this
> product
> | and it seems to offer many of the features of Maven including
> |
> | 1. transitive dependencies
>
> If I understand correctly, Ivy depends on profile name consistency for
> transitivity to function properly...
>
> | 2. compatibility with the ibiblio repository
>
> Maven 2 has this compat as well, and can probably supply the same
> level
> of functionality as Ivy given the quality of metadata in the m1
> repository. You can specify a repository with <layout>legacy</layout>
> and it should work. But we're hoping for much more than this.
>
> |
> | and in addition
> |
> | 1. the online docs are excellent even if they are in broken english
>
> Ivy is an overlay for Ant, meant only to provide transitive dependency
> resolution and compat with the m1 repository. This means it's a
> relatively small project, and therefore have the ability to climb that
> maturity curve faster.
>
> As a side note, Ant 1.7 will be using Maven 2.0's artifact-handling
> API.
> This, after Ivy has been out there available for integration for some
> time now. Why is that, do you think?
>
> | 2. Can manage projects from with eclipse, since they are just ant
> | projects (with simple projects, haven't tried anything tricky)
>
> What level of integration do you need here? Would it be feasible, for
> example, to create a set of command-line execution profiles in
> Eclipse,
> to call various m2 targets? I've done this successfully with svn,
> when I
> found subclipse to be far too sluggish and flaky.
>
> | 3. Can manage maven style module directory structures or single
> source
> | trees. Obviously being Ant, it can manage any structure you
> like, but
> | these are the only two sane ones I know.
>
> If I understand correctly, the m2 eclipse plugin does have some
> support
> for this, although I'm not the best person to speak about it. To some
> extent, solutions to this will be compromised by Eclipse's lack of
> nested project support...which in some cases can lead to set-semantics
> when collecting dependencies for a hierarchy of projects...which
> can in
> turn lead to sources compiling in Eclipse but not in Maven, since the
> dependency declarations are not the same. The eclipse integration has
> been escalated as a priority recently, but we're not likelly to have
> anything for at least a few weeks. We understand the market share that
> Eclipse commands, and its value for integration...unfortunately, we
> haven't had the time to devote to external m2 integations up to now.
>
> |
> | Yes there is stuff that it doesn't have such as a built in
> lifecycle,
> | but with what I've learnt from the maven layout, I feel I could
> quite
> | easily replicate that in ant in a reusable way. That said I would
> | prefer not to have to. I suppose I'm looking for reassurance as
> to why
> | Maven is the way to go because there seems to be considerable
> overlap
> | with Ivy.
>
> 'Considerable' is a tad exaggerated, IMHO. Maven gives you
> reusability,
> not only of plugin functionality, but also of project information (the
> POM specifies most of what plugins need, so project configuration
> scales
> better than Ant for the marginal plugin). It also provides a single,
> simple lifecycle that ensures a sane progression from task to task in
> order. This lifecycle is the same for everything you will build, since
> plugins bind to the lifecycle behind the scenes.
>
> If you attempted to build a lifecycle on top of Ant, I think you'd
> find
> ~ a couple of things to be true:
>
> 1. it's not as simple as it seems, particularly if you build multiple
> types of projects (EJB, EAR, WAR, JAR, DLL, RPM, ...)
>
> 2. unless you attempt to open source your own solution - which
> means it
> will have to have general applicability, which itself is not a trivial
> goal - you will have to maintain your lifecycle layer in addition to
> your actual build scripts. Tracking something like this against
> updates
> in Ant and Ivy is not trivial...I tried something similar before Maven
> came along. The problem is that maintaining this lifecycle layer will
> not directly impact your company's bottom line, so they will be
> reluctant to give you much slack time to maintain it.
>
It would be great to see this sort of information on the Maven
Website - I'm guessing
there are others who are looking at both Ivy and Maven. Go to the Ivy
website
and the guys there are favorably comparing their product with Maven.
> |
> | ****************************************
> |
> | I realize that I am being very selfish here, but I have to think
> very
> | carefully about what I invest my time in. Maven has all the
> hallmarks
> | of being that software that I felt was missing during my career,
> which
> | is why I care enough about it to spare the time for these
> critisisms. I
> | just want to be sure it has a chance of gaining critical mass.
> |
> | Maybe the gatekeeper/guardian of this project needs to write
> some sort
> | of Jerry Maguire style memo that says what Maven's purpose is
> and plans
> | are so that we can all keep focused on that.
> |
> | Maybe my views aren't representative of a large enough
> demographic in
> | which case this email will just slip away into obscurity, but either
> | way thanks for reading and please don't take it as a troll
>
> I appreciate you taking the time to articulate your concerns. There is
> no doubt in my mind that many of the points you raise will resound
> with
> users, both current and potential. However, I have a question for you:
>
> How long did you spend on this email?
>
> It's fairly involved, and judging by the time I've spent
> responding, it
> took some effort. Did you do this in the course of your workday? If
> so,
> can you afford this amount of time a couple times a week? I'd like to
> encourage you to spend this amount of time exploring our APIs, writing
> javadocs (or whatever doco, etc. you see fit) and submitting patches.
> This much effort from a few users like you would really make a
> difference fast, IMO.
>
> Just something to think about. Even small patches will eventually
> add up.
>
You've guessed that I've got time on my hands! However only because
I'm between contracts
and so I'm spending some time looking at those projects that have always
interested me, maven being top of the list (but there are others).
Outside of office hours my commitments
mean that I have little time to make meaningful contributions to
opensource projects.
I did try to make an exception for Maven, but I haven't been able to
get up to
speed with the Maven code base quickly enough, which was one of my
gripes.
> - -john
>
> |
> | -AW
> |
> |
> ---------------------------------------------------------------------
> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMCeJK3h2CZwO/4URAhfPAKCD1iOtdPe2NO0j8KY6vg0L7oUW4ACgnZpk
> 7bbtGsKkiZKm8o/wOqY4Sjo=
> =JcXf
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
If you're forced to run unit tests via a main() invocation, why not
> write a unit-test plugin that calls this type of test, and formats
> errors/output so it can be integrated into the unit tests reporting
> features, rather than write a plugin that's sole aim is one-off, custom
> configuration on a per-POM basis, and has no hope of ever being reusable
> or scalable?
Oh, this is simple because I have encountered it before. The main reason I
have to have a separate process is because some developers are not
enlightened enough to just throw an exception and instead they'll dump
something in a log and them call System.exit(). Thus, I can't run their code
in my process. Another case is where a you need to run a process across a
series of resources (i.e. files) one at a time, perhaps for code generation.
Some processes may load native libraries and you can't have then loading a
library more than once in a process's lifetime, so you again need to run
this in a separate process.
I guess I don't understand what's wrong with writing mojos to wrap
> specific command-line-driven use cases...?
>
> - -john
>
> Wendell Beckwith wrote:
> | Probably because I'm not aware of what your talking about. Nonetheless,
> | while there may be another way of doing what I need, the ability to
> simple
> | specify a command line to a java process that is something that has
> | tremendous capability. Can users overdo it sure, but in an effort to
> protect
> | clueless users from themselves, should we prevent more advances
> users/plugin
> | developers from achieving their needs. I'm a big eclipse and firefox
> user,
> | but I don't dictate that everyone on my team has to do as I do because I
> | believe it is the "one true way" for IDEs and web browsing.
> |
> | Wb
> |
> | On 9/20/05, Vincent Massol <vm...@pivolis.com> wrote:
> |
> |>
> |>
> |>>-----Original Message-----
> |>>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
> |>>Sent: mardi 20 septembre 2005 19:15
> |>>To: Maven Users List
> |>>Subject: Re: [m2] reasons for sticking with maven
> |>>
> |>>John is basically stating the very thing that I'm against in the
> |>
> |>statement
> |>
> |>>below. I have a 3rd party command line utility from
> |>>www.agitar.com <http://www.agitar.com> <http://www.agitar.com><
> http://www.agitar.com>,
> |>>that basically does unit tests against our code. I want to write (and
> |>
> |>have
> |>
> |>>started writing) an M2 plugin to execute the java command line for the
> |>>agitation process from my plugin. All I need now to complete my plugin
> |>>besides more hours in a day is a plugin that will allow me to execute a
> |>>java
> |>>command line. Now my plugin will integrate with the maven lifecycle
> |>
> |>during
> |>
> |>>the test phase. However, first I'm told to use the maven-execute-plugin
> |>>and
> |>>then another dev states that it's bad and wants to see it eliminated,
> |>
> |>I'm
> |>
> |>>left thinking WTF!? This *helps* me adopt maven and the process, not
> |>>hinders
> |>>it. My whole purpose for writing the plugin was so that I could make
> the
> |>>plugin once and the other groups here and else where since I would open
> |>>source it would be able to reuse it. Is this not what maven is for?
> |>
> |>Just to muddy the waters: why don't you use commons-exec from your
> |>plugin's
> |>java code to execute your process?
> |>
> |>[snip]
> |>
> |>Thanks
> |>-Vincent
> |>
> |>
> |>---------------------------------------------------------------------
> |>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> |>For additional commands, e-mail: users-help@maven.apache.org
> |>
> |>
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMEkBK3h2CZwO/4URAkV4AJ91AZVpovMtVrVziGZGb1dBKOQv2wCfSrY9
> oShApxHT8sNeu/om38WwQKY=
> =kv4h
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] reasons for sticking with maven
Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Tue, 2005-09-20 at 14:30 -0400, John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> so, all that remains is to write that API that you need :-)
>
> I've been thinking that we may need a sub-project within maven (with
> separated release cycle) to address plugin utility
> libraries...constructing a classloader from the project dependencies,
> executing main() methods in an isolated classloader, etc.
>
> The plugins are going to start writing their own parallel infrastructure
> (and have in some cases) unless we can centralize it in a series of
> plugin support artifacts.
>
> WDYT? Do you want to start a design doc for that API you need? just a
> statement of the different things it needs to do would be a good start...
You have my preliminary +1 at least.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
so, all that remains is to write that API that you need :-)
I've been thinking that we may need a sub-project within maven (with
separated release cycle) to address plugin utility
libraries...constructing a classloader from the project dependencies,
executing main() methods in an isolated classloader, etc.
The plugins are going to start writing their own parallel infrastructure
(and have in some cases) unless we can centralize it in a series of
plugin support artifacts.
WDYT? Do you want to start a design doc for that API you need? just a
statement of the different things it needs to do would be a good start...
- --john
Wendell Beckwith wrote:
| YES!! That is exactly what I need/want. Sorry if I wasn't clear
before, but
| I'm definitely not for the embedding of command lines in he pom. Now
that I
| understand where you're coming from, I can completely agree with you that
| embedding this stuff in a pom would definitely lead to cut-n-paste code
| which s why I'm actively moving nearly 100 dev's from ant to maven 2
| starting with my project.
|
| Wb
|
| On 9/20/05, John Casey <jd...@commonjava.org> wrote:
|
| that sounds perfectly sane, except it sounds like you only need an API
| for calling a java main() method and handling output than an actual
| plugin. Once you have that API, you're set, it sounds like...then your
| plugin can depend on that api, and give it the stream consumers for
| sterr/stout and stream provider for stdin, I guess.
|
| I suppose I misunderstood where you were going with the
| maven-java-plugin. You're after more of a main() support API than an
| actual java-plugin, since you're writing the plugin yourself. Correct?
|
| -john
|
| Wendell Beckwith wrote:
| | I just re-read you email and I'm confused by your comment, please
| clarify if
| | possible. But isn't what I've been hopefully explaining is the
| creation of a
| | mojo that wraps a command line process. I have written the mojos
| (agitate
| | and dashboard) an users only need to reference the plugin in their build
| | element. If the defaults are right for them, say they have a 80% code
| | coverage target instead of the default of 70% then they can add a
| <coverage>
| | element to the <configuration> element for the plugin. Now the plugin
| takes
| | the prams and puts then in the correct order and that is where I'm
| currently
| | am. I would like to have a maven-java-plugin or something like it that
| my
| | plugin can depend on to actually execute the process and tie its output
| | stdout and stderr back to my process. That's all I need. I'm not
| advocating
| | giving users the ability to execute any java command from their pom.
| |
| | This is my 1st m2 plugin so if I'm now one of those clueless users, then
| | please correct me where I'm wrong.
| |
| | Wb
| | On 9/20/05, John Casey <jd...@commonjava.org> wrote:
| |
| |>-----BEGIN PGP SIGNED MESSAGE-----
| |>Hash: SHA1
| |>
| |>
| |>I guess I don't understand what's wrong with writing mojos to wrap
| |>specific command-line-driven use cases...?
| |>
| |>- -john
| |>
| |
| |
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFU/K3h2CZwO/4URAqnnAKCs5kWQ/8rkJHwUP4F8ZpMI07Lq4ACeNmbg
ygQnRvqcld3CuQ/4MuZZfbU=
=LOuS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
YES!! That is exactly what I need/want. Sorry if I wasn't clear before, but
I'm definitely not for the embedding of command lines in he pom. Now that I
understand where you're coming from, I can completely agree with you that
embedding this stuff in a pom would definitely lead to cut-n-paste code
which s why I'm actively moving nearly 100 dev's from ant to maven 2
starting with my project.
Wb
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> that sounds perfectly sane, except it sounds like you only need an API
> for calling a java main() method and handling output than an actual
> plugin. Once you have that API, you're set, it sounds like...then your
> plugin can depend on that api, and give it the stream consumers for
> sterr/stout and stream provider for stdin, I guess.
>
> I suppose I misunderstood where you were going with the
> maven-java-plugin. You're after more of a main() support API than an
> actual java-plugin, since you're writing the plugin yourself. Correct?
>
> - -john
>
> Wendell Beckwith wrote:
> | I just re-read you email and I'm confused by your comment, please
> clarify if
> | possible. But isn't what I've been hopefully explaining is the
> creation of a
> | mojo that wraps a command line process. I have written the mojos
> (agitate
> | and dashboard) an users only need to reference the plugin in their build
> | element. If the defaults are right for them, say they have a 80% code
> | coverage target instead of the default of 70% then they can add a
> <coverage>
> | element to the <configuration> element for the plugin. Now the plugin
> takes
> | the prams and puts then in the correct order and that is where I'm
> currently
> | am. I would like to have a maven-java-plugin or something like it that
> my
> | plugin can depend on to actually execute the process and tie its output
> | stdout and stderr back to my process. That's all I need. I'm not
> advocating
> | giving users the ability to execute any java command from their pom.
> |
> | This is my 1st m2 plugin so if I'm now one of those clueless users, then
> | please correct me where I'm wrong.
> |
> | Wb
> | On 9/20/05, John Casey <jd...@commonjava.org> wrote:
> |
> |>-----BEGIN PGP SIGNED MESSAGE-----
> |>Hash: SHA1
> |>
> |>
> |>I guess I don't understand what's wrong with writing mojos to wrap
> |>specific command-line-driven use cases...?
> |>
> |>- -john
> |>
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFEWK3h2CZwO/4URAveWAKCDHwHQN8WHKYx0V7YtI1mto4x4mgCdG+v9
> pTLGzK9uJsmhto/wMtt1+vo=
> =NYSU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
that sounds perfectly sane, except it sounds like you only need an API
for calling a java main() method and handling output than an actual
plugin. Once you have that API, you're set, it sounds like...then your
plugin can depend on that api, and give it the stream consumers for
sterr/stout and stream provider for stdin, I guess.
I suppose I misunderstood where you were going with the
maven-java-plugin. You're after more of a main() support API than an
actual java-plugin, since you're writing the plugin yourself. Correct?
- -john
Wendell Beckwith wrote:
| I just re-read you email and I'm confused by your comment, please
clarify if
| possible. But isn't what I've been hopefully explaining is the
creation of a
| mojo that wraps a command line process. I have written the mojos (agitate
| and dashboard) an users only need to reference the plugin in their build
| element. If the defaults are right for them, say they have a 80% code
| coverage target instead of the default of 70% then they can add a
<coverage>
| element to the <configuration> element for the plugin. Now the plugin
takes
| the prams and puts then in the correct order and that is where I'm
currently
| am. I would like to have a maven-java-plugin or something like it that my
| plugin can depend on to actually execute the process and tie its output
| stdout and stderr back to my process. That's all I need. I'm not
advocating
| giving users the ability to execute any java command from their pom.
|
| This is my 1st m2 plugin so if I'm now one of those clueless users, then
| please correct me where I'm wrong.
|
| Wb
| On 9/20/05, John Casey <jd...@commonjava.org> wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>
|>I guess I don't understand what's wrong with writing mojos to wrap
|>specific command-line-driven use cases...?
|>
|>- -john
|>
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFEWK3h2CZwO/4URAveWAKCDHwHQN8WHKYx0V7YtI1mto4x4mgCdG+v9
pTLGzK9uJsmhto/wMtt1+vo=
=NYSU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Tue, 2005-09-20 at 14:17 -0400, John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> it's not a command line execution...it's a java main() call...right?
Oh, if so I misunderstood, oh well.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
any time.
Wendell Beckwith wrote:
| I will look into commons-exec since I wasn't aware of it and thnx for all
| the help.
|
| Wb
|
|
| On 9/20/05, John Casey <jd...@commonjava.org> wrote:
|
| Ok, fair enough...but the maven process should probably install a
| security manager to restrict who can call System.exit(..) (i.e. no-one
| can! :)
|
| But there is still the potential for issues surrounding
| OutOfMemoryError's and the like. If you're going the route of using a
| separate java process, then you should check into commons-exec. I
| haven't used it, but if it's the stuff extracted from Ant (and plexus,
| actually), then it'll be suitable.
|
| -john
|
| Wendell Beckwith wrote:
| | True, it is a java main() call because the use ZeroG's LaunchAnywhere.
| | LaunchAnywhere creates a native executable that reads a config file that
| | lists the classpath, args and the main class to execute. However because
| I
| | didn't write the code nor do have the source code, I don't know if the
| code
| | somewhere will call System.exit(). If it does then my maven process is
| dead,
| | which is why I want the ability to run this java main() in a separate
| | process. Makes sense?
| |
| | Wb
| |
| | On 9/20/05, John Casey <jd...@commonjava.org> wrote:
| |
| | it's not a command line execution...it's a java main() call...right?
| |
| | Trygve Laugstøl wrote:
| | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
| | |
| | |>I just re-read you email and I'm confused by your comment, please
| | clarify if
| | |>possible. But isn't what I've been hopefully explaining is the
| | creation of a
| | |>mojo that wraps a command line process. I have written the mojos
| | (agitate
| | |>and dashboard) an users only need to reference the plugin in their
| build
| | |>element. If the defaults are right for them, say they have a 80% code
| | |>coverage target instead of the default of 70% then they can add a
| | <coverage>
| | |>element to the <configuration> element for the plugin. Now the plugin
| | takes
| | |>the prams and puts then in the correct order and that is where I'm
| | currently
| | |>am. I would like to have a maven-java-plugin or something like it that
| | my
| | |>plugin can depend on to actually execute the process and tie its
| output
| | |>stdout and stderr back to my process. That's all I need. I'm not
| | advocating
| | |>giving users the ability to execute any java command from their pom.
| | |
| | |
| | | For now, until all the hot air in commons-exec stabilizes take a look
| at
| | | plexus-utils and the org.codehaus.plexus.util.cli package. For a
| simple
| | | example take a look at [1].
| | |
| | | [1]:
| | |
| |
| |
|
|
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
| | |
| | | --
| | | Trygve
| | |
| | |
| | | ---------------------------------------------------------------------
| | | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| | | For additional commands, e-mail: users-help@maven.apache.org
| | |
| | |
| | |
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
|
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFgcK3h2CZwO/4URAqg6AKCq6uJle+9PgQ+6gti1z0VqYTpkCACcCm04
YnPgnOM3sD7nf+8iecubZys=
=BS9H
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
I will look into commons-exec since I wasn't aware of it and thnx for all
the help.
Wb
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ok, fair enough...but the maven process should probably install a
> security manager to restrict who can call System.exit(..) (i.e. no-one
> can! :)
>
> But there is still the potential for issues surrounding
> OutOfMemoryError's and the like. If you're going the route of using a
> separate java process, then you should check into commons-exec. I
> haven't used it, but if it's the stuff extracted from Ant (and plexus,
> actually), then it'll be suitable.
>
> - -john
>
> Wendell Beckwith wrote:
> | True, it is a java main() call because the use ZeroG's LaunchAnywhere.
> | LaunchAnywhere creates a native executable that reads a config file that
> | lists the classpath, args and the main class to execute. However because
> I
> | didn't write the code nor do have the source code, I don't know if the
> code
> | somewhere will call System.exit(). If it does then my maven process is
> dead,
> | which is why I want the ability to run this java main() in a separate
> | process. Makes sense?
> |
> | Wb
> |
> | On 9/20/05, John Casey <jd...@commonjava.org> wrote:
> |
> | it's not a command line execution...it's a java main() call...right?
> |
> | Trygve Laugstøl wrote:
> | | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
> | |
> | |>I just re-read you email and I'm confused by your comment, please
> | clarify if
> | |>possible. But isn't what I've been hopefully explaining is the
> | creation of a
> | |>mojo that wraps a command line process. I have written the mojos
> | (agitate
> | |>and dashboard) an users only need to reference the plugin in their
> build
> | |>element. If the defaults are right for them, say they have a 80% code
> | |>coverage target instead of the default of 70% then they can add a
> | <coverage>
> | |>element to the <configuration> element for the plugin. Now the plugin
> | takes
> | |>the prams and puts then in the correct order and that is where I'm
> | currently
> | |>am. I would like to have a maven-java-plugin or something like it that
> | my
> | |>plugin can depend on to actually execute the process and tie its
> output
> | |>stdout and stderr back to my process. That's all I need. I'm not
> | advocating
> | |>giving users the ability to execute any java command from their pom.
> | |
> | |
> | | For now, until all the hot air in commons-exec stabilizes take a look
> at
> | | plexus-utils and the org.codehaus.plexus.util.cli package. For a
> simple
> | | example take a look at [1].
> | |
> | | [1]:
> | |
> |
> |
>
> http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
> | |
> | | --
> | | Trygve
> | |
> | |
> | | ---------------------------------------------------------------------
> | | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | | For additional commands, e-mail: users-help@maven.apache.org
> | |
> | |
> | |
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFXBK3h2CZwO/4URAvkbAJ4ir8+/w7fgWCTfH6XA0bgXLW2rmQCeKqh+
> 6H/krj8A/paO61kOgt4MHNU=
> =Lywd
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, fair enough...but the maven process should probably install a
security manager to restrict who can call System.exit(..) (i.e. no-one
can! :)
But there is still the potential for issues surrounding
OutOfMemoryError's and the like. If you're going the route of using a
separate java process, then you should check into commons-exec. I
haven't used it, but if it's the stuff extracted from Ant (and plexus,
actually), then it'll be suitable.
- -john
Wendell Beckwith wrote:
| True, it is a java main() call because the use ZeroG's LaunchAnywhere.
| LaunchAnywhere creates a native executable that reads a config file that
| lists the classpath, args and the main class to execute. However because I
| didn't write the code nor do have the source code, I don't know if the
code
| somewhere will call System.exit(). If it does then my maven process is
dead,
| which is why I want the ability to run this java main() in a separate
| process. Makes sense?
|
| Wb
|
| On 9/20/05, John Casey <jd...@commonjava.org> wrote:
|
| it's not a command line execution...it's a java main() call...right?
|
| Trygve Laugstøl wrote:
| | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
| |
| |>I just re-read you email and I'm confused by your comment, please
| clarify if
| |>possible. But isn't what I've been hopefully explaining is the
| creation of a
| |>mojo that wraps a command line process. I have written the mojos
| (agitate
| |>and dashboard) an users only need to reference the plugin in their build
| |>element. If the defaults are right for them, say they have a 80% code
| |>coverage target instead of the default of 70% then they can add a
| <coverage>
| |>element to the <configuration> element for the plugin. Now the plugin
| takes
| |>the prams and puts then in the correct order and that is where I'm
| currently
| |>am. I would like to have a maven-java-plugin or something like it that
| my
| |>plugin can depend on to actually execute the process and tie its output
| |>stdout and stderr back to my process. That's all I need. I'm not
| advocating
| |>giving users the ability to execute any java command from their pom.
| |
| |
| | For now, until all the hot air in commons-exec stabilizes take a look at
| | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
| | example take a look at [1].
| |
| | [1]:
| |
|
|
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
| |
| | --
| | Trygve
| |
| |
| | ---------------------------------------------------------------------
| | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| | For additional commands, e-mail: users-help@maven.apache.org
| |
| |
| |
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFXBK3h2CZwO/4URAvkbAJ4ir8+/w7fgWCTfH6XA0bgXLW2rmQCeKqh+
6H/krj8A/paO61kOgt4MHNU=
=Lywd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
True, it is a java main() call because the use ZeroG's LaunchAnywhere.
LaunchAnywhere creates a native executable that reads a config file that
lists the classpath, args and the main class to execute. However because I
didn't write the code nor do have the source code, I don't know if the code
somewhere will call System.exit(). If it does then my maven process is dead,
which is why I want the ability to run this java main() in a separate
process. Makes sense?
Wb
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> it's not a command line execution...it's a java main() call...right?
>
> Trygve Laugstøl wrote:
> | On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
> |
> |>I just re-read you email and I'm confused by your comment, please
> clarify if
> |>possible. But isn't what I've been hopefully explaining is the
> creation of a
> |>mojo that wraps a command line process. I have written the mojos
> (agitate
> |>and dashboard) an users only need to reference the plugin in their build
> |>element. If the defaults are right for them, say they have a 80% code
> |>coverage target instead of the default of 70% then they can add a
> <coverage>
> |>element to the <configuration> element for the plugin. Now the plugin
> takes
> |>the prams and puts then in the correct order and that is where I'm
> currently
> |>am. I would like to have a maven-java-plugin or something like it that
> my
> |>plugin can depend on to actually execute the process and tie its output
> |>stdout and stderr back to my process. That's all I need. I'm not
> advocating
> |>giving users the ability to execute any java command from their pom.
> |
> |
> | For now, until all the hot air in commons-exec stabilizes take a look at
> | plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
> | example take a look at [1].
> |
> | [1]:
> |
>
> http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
> |
> | --
> | Trygve
> |
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMFI/K3h2CZwO/4URAvoXAKCpFFlfc7CDSG35HygJdqAN0aHfbgCeMMzA
> bc1WTt3I4WBoJycsmRICNXc=
> =rA82
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
it's not a command line execution...it's a java main() call...right?
Trygve Laugstøl wrote:
| On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
|
|>I just re-read you email and I'm confused by your comment, please
clarify if
|>possible. But isn't what I've been hopefully explaining is the
creation of a
|>mojo that wraps a command line process. I have written the mojos (agitate
|>and dashboard) an users only need to reference the plugin in their build
|>element. If the defaults are right for them, say they have a 80% code
|>coverage target instead of the default of 70% then they can add a
<coverage>
|>element to the <configuration> element for the plugin. Now the plugin
takes
|>the prams and puts then in the correct order and that is where I'm
currently
|>am. I would like to have a maven-java-plugin or something like it that my
|>plugin can depend on to actually execute the process and tie its output
|>stdout and stderr back to my process. That's all I need. I'm not
advocating
|>giving users the ability to execute any java command from their pom.
|
|
| For now, until all the hot air in commons-exec stabilizes take a look at
| plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
| example take a look at [1].
|
| [1]:
|
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
|
| --
| Trygve
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMFI/K3h2CZwO/4URAvoXAKCpFFlfc7CDSG35HygJdqAN0aHfbgCeMMzA
bc1WTt3I4WBoJycsmRICNXc=
=rA82
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Tue, 2005-09-20 at 13:09 -0500, Wendell Beckwith wrote:
> I just re-read you email and I'm confused by your comment, please clarify if
> possible. But isn't what I've been hopefully explaining is the creation of a
> mojo that wraps a command line process. I have written the mojos (agitate
> and dashboard) an users only need to reference the plugin in their build
> element. If the defaults are right for them, say they have a 80% code
> coverage target instead of the default of 70% then they can add a <coverage>
> element to the <configuration> element for the plugin. Now the plugin takes
> the prams and puts then in the correct order and that is where I'm currently
> am. I would like to have a maven-java-plugin or something like it that my
> plugin can depend on to actually execute the process and tie its output
> stdout and stderr back to my process. That's all I need. I'm not advocating
> giving users the ability to execute any java command from their pom.
For now, until all the hot air in commons-exec stabilizes take a look at
plexus-utils and the org.codehaus.plexus.util.cli package. For a simple
example take a look at [1].
[1]:
http://svn.apache.org/viewcvs.cgi/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/utils/shell/DefaultShellCommandHelper.java?rev=227315&view=markup
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
I just re-read you email and I'm confused by your comment, please clarify if
possible. But isn't what I've been hopefully explaining is the creation of a
mojo that wraps a command line process. I have written the mojos (agitate
and dashboard) an users only need to reference the plugin in their build
element. If the defaults are right for them, say they have a 80% code
coverage target instead of the default of 70% then they can add a <coverage>
element to the <configuration> element for the plugin. Now the plugin takes
the prams and puts then in the correct order and that is where I'm currently
am. I would like to have a maven-java-plugin or something like it that my
plugin can depend on to actually execute the process and tie its output
stdout and stderr back to my process. That's all I need. I'm not advocating
giving users the ability to execute any java command from their pom.
This is my 1st m2 plugin so if I'm now one of those clueless users, then
please correct me where I'm wrong.
Wb
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I guess I don't understand what's wrong with writing mojos to wrap
> specific command-line-driven use cases...?
>
> - -john
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
No one is saying you have to follow the party line here. You're free to
develop your own maven plugins to solve any problem you like, even run
your toaster if you want. Maven will load your plugin, provided you add
your groupId to the list of pluginGroups in the settings.xml. We just
don't want to be in the business of building a tool to allow non-build
activities, because it muddies up our concept of what's really involved
with building software. There are multiple boundary considerations for
this process, where integrating with maven makes sense, but let's be
frank here...they aren't really _build_ process activities.
If you're forced to run unit tests via a main() invocation, why not
write a unit-test plugin that calls this type of test, and formats
errors/output so it can be integrated into the unit tests reporting
features, rather than write a plugin that's sole aim is one-off, custom
configuration on a per-POM basis, and has no hope of ever being reusable
or scalable?
I guess I don't understand what's wrong with writing mojos to wrap
specific command-line-driven use cases...?
- -john
Wendell Beckwith wrote:
| Probably because I'm not aware of what your talking about. Nonetheless,
| while there may be another way of doing what I need, the ability to simple
| specify a command line to a java process that is something that has
| tremendous capability. Can users overdo it sure, but in an effort to
protect
| clueless users from themselves, should we prevent more advances
users/plugin
| developers from achieving their needs. I'm a big eclipse and firefox user,
| but I don't dictate that everyone on my team has to do as I do because I
| believe it is the "one true way" for IDEs and web browsing.
|
| Wb
|
| On 9/20/05, Vincent Massol <vm...@pivolis.com> wrote:
|
|>
|>
|>>-----Original Message-----
|>>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
|>>Sent: mardi 20 septembre 2005 19:15
|>>To: Maven Users List
|>>Subject: Re: [m2] reasons for sticking with maven
|>>
|>>John is basically stating the very thing that I'm against in the
|>
|>statement
|>
|>>below. I have a 3rd party command line utility from
|>>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
|>>that basically does unit tests against our code. I want to write (and
|>
|>have
|>
|>>started writing) an M2 plugin to execute the java command line for the
|>>agitation process from my plugin. All I need now to complete my plugin
|>>besides more hours in a day is a plugin that will allow me to execute a
|>>java
|>>command line. Now my plugin will integrate with the maven lifecycle
|>
|>during
|>
|>>the test phase. However, first I'm told to use the maven-execute-plugin
|>>and
|>>then another dev states that it's bad and wants to see it eliminated,
|>
|>I'm
|>
|>>left thinking WTF!? This *helps* me adopt maven and the process, not
|>>hinders
|>>it. My whole purpose for writing the plugin was so that I could make the
|>>plugin once and the other groups here and else where since I would open
|>>source it would be able to reuse it. Is this not what maven is for?
|>
|>Just to muddy the waters: why don't you use commons-exec from your
|>plugin's
|>java code to execute your process?
|>
|>[snip]
|>
|>Thanks
|>-Vincent
|>
|>
|>---------------------------------------------------------------------
|>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
|>For additional commands, e-mail: users-help@maven.apache.org
|>
|>
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMEkBK3h2CZwO/4URAkV4AJ91AZVpovMtVrVziGZGb1dBKOQv2wCfSrY9
oShApxHT8sNeu/om38WwQKY=
=kv4h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
Probably because I'm not aware of what your talking about. Nonetheless,
while there may be another way of doing what I need, the ability to simple
specify a command line to a java process that is something that has
tremendous capability. Can users overdo it sure, but in an effort to protect
clueless users from themselves, should we prevent more advances users/plugin
developers from achieving their needs. I'm a big eclipse and firefox user,
but I don't dictate that everyone on my team has to do as I do because I
believe it is the "one true way" for IDEs and web browsing.
Wb
On 9/20/05, Vincent Massol <vm...@pivolis.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
> > Sent: mardi 20 septembre 2005 19:15
> > To: Maven Users List
> > Subject: Re: [m2] reasons for sticking with maven
> >
> > John is basically stating the very thing that I'm against in the
> statement
> > below. I have a 3rd party command line utility from
> > www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
> > that basically does unit tests against our code. I want to write (and
> have
> > started writing) an M2 plugin to execute the java command line for the
> > agitation process from my plugin. All I need now to complete my plugin
> > besides more hours in a day is a plugin that will allow me to execute a
> > java
> > command line. Now my plugin will integrate with the maven lifecycle
> during
> > the test phase. However, first I'm told to use the maven-execute-plugin
> > and
> > then another dev states that it's bad and wants to see it eliminated,
> I'm
> > left thinking WTF!? This *helps* me adopt maven and the process, not
> > hinders
> > it. My whole purpose for writing the plugin was so that I could make the
> > plugin once and the other groups here and else where since I would open
> > source it would be able to reuse it. Is this not what maven is for?
>
> Just to muddy the waters: why don't you use commons-exec from your
> plugin's
> java code to execute your process?
>
> [snip]
>
> Thanks
> -Vincent
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was actually referring to a couple of implementation patterns.
1. Wrap a command-line invocation.
~ Using commons-exec or any other Runtime.exec() wrapper, you can build
a mojo that will pull in parameters from the Maven build process, format
the command line, and execute...hopefully with output/error handling for
that specific command.
2. Provide a plugin wrapper for an Ant script.
~ Using a given Ant script, bundle that script into a maven plugin whose
functionality is centered on that single script. Again, maven provides
the parameters from the build process, and passes them to the
script/target in that plugin's embedded Ant script. Again, output/errors
are handled in a way that is tuned to the task at hand.
It's important to understand the specificity of these solutions. If
you're using a general directly-embedded-Ant-inside-the-POM solution,
you cannot handle output or errors in an intelligent manner. Same with a
command-line-inside-the-POM solution. Moreover, in each of these inline
solutions, your specific command-line or Ant invocation is confined to
that POM and possibly its descendents, via inheritance. You cannot reuse
this configuration outside the POM without incurring the costs of
maintenance associated with cut-and-paste programming of any kind (i.e.
multiple maintenance points, propagation of erroneous code, etc.).
I'm not familiar with the plugin you've written, but I think the above
statements apply generally. If you're already following those
principles, I'd like to see what you have. I've been heads-down lately,
so I may have missed the thread in which you were talking about it...
Of course, using (or abusing) the maven plugin framework, you can do
almost anything. Just don't ask me to maintain it or support it... :)
Cheers,
john
Wendell Beckwith wrote:
| Just for clarification are you suggesting that a plugin that needs to
| execute a java process should be designed as an ant script, and the plugin
| would simply pass parameters to the ant script? I ask because I don't see
| how this is less maintenance than my current plugin that provides
| intelligent defaults in the mojo and just needs to pass theses parameters
| along with any the user changed to the java process. Whenever there are
| plugin changes, I still go to the mojo in my design or an ant script
in your
| design, correct?
|
| Wb
|
|
| On 9/20/05, John Casey <jd...@commonjava.org> wrote:
|
| I've actually done something just like this in the past, in order to
| call a Make-based build. IMO, you want to wrap a command line call in a
| plugin, to formalize the parameters - required and optional - which
| constitutes a valid invocation of that executable. Otherwise, it's prone
| to breaking, misuse, and cut-and-paste maintenance style. In short, it
| isn't robust, and doesn't scale well. Anything where execution logic is
| embedded in the POM will suffer from this, IMO - including the antrun
| and execute plugins in the mojos project. A better solution for Ant
| would be to build the plugin around the Ant script/scriptlet, and bundle
| that script into the plugin jar...then parameterize the input
| configuration. Then, the script can climb the maturity curve, and is
| truly reused with a single point of maintenance.
|
| -john
|
| Vincent Massol wrote:
| |
| |>-----Original Message-----
| |>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
| |>Sent: mardi 20 septembre 2005 19:15
| |>To: Maven Users List
| |>Subject: Re: [m2] reasons for sticking with maven
| |>
| |>John is basically stating the very thing that I'm against in the
| statement
| |>below. I have a 3rd party command line utility from
| |>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
| |>that basically does unit tests against our code. I want to write (and
| have
| |>started writing) an M2 plugin to execute the java command line for the
| |>agitation process from my plugin. All I need now to complete my plugin
| |>besides more hours in a day is a plugin that will allow me to execute a
| |>java
| |>command line. Now my plugin will integrate with the maven lifecycle
| during
| |>the test phase. However, first I'm told to use the maven-execute-plugin
| |>and
| |>then another dev states that it's bad and wants to see it eliminated,
| I'm
| |>left thinking WTF!? This *helps* me adopt maven and the process, not
| |>hinders
| |>it. My whole purpose for writing the plugin was so that I could make the
| |>plugin once and the other groups here and else where since I would open
| |>source it would be able to reuse it. Is this not what maven is for?
| |
| |
| | Just to muddy the waters: why don't you use commons-exec from your
| plugin's
| | java code to execute your process?
| |
| | [snip]
| |
| | Thanks
| | -Vincent
| |
| |
| | ---------------------------------------------------------------------
| | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| | For additional commands, e-mail: users-help@maven.apache.org
| |
| |
| |
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDME03K3h2CZwO/4URAhpLAKCF8cAMIq3yB7kFag2+Ux7EcKt2IgCdFLqX
gF7ejHUha8PofCo/AKsDPYQ=
=1Rse
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Antfile plugin
Posted by Chris Berry <ch...@gmail.com>.
This is it....
Cheers,
-- Chris
allows use of Ant build files
-----------------------------
Key: MNG-897
URL: http://jira.codehaus.org/browse/MNG-897
Project: Maven 2
Type: Improvement
Components: maven-ant-plugin
Versions: 2.0-alpha-3
Reporter: Chris Berry
Attachments: antfile.zip
Cheers,
-- Chris
On 9/21/05, Ashley Williams <ag...@mac.com> wrote:
>
> On 21 Sep 2005, at 09:26, Ashley Williams wrote:
>
> > Hi Chris,
> >
> > I've mislaid the link to your plugin - can you post it up again??
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Antfile plugin
Posted by Ashley Williams <ag...@mac.com>.
On 21 Sep 2005, at 09:26, Ashley Williams wrote:
> Hi Chris,
>
> I've mislaid the link to your plugin - can you post it up again??
>
> On 20 Sep 2005, at 21:55, Chris Berry wrote:
>
>
>> Yes, it is the equivalent. But one thing confuses me, it's not about
>> executing a java process (per se) -- it's about executing Ant. And
>> it's not about maintenance. I think the heart of the discussion is
>> reuse. Not reinventing what Ant already does. Providing a mechanism
>> for reuse and versioning of Ant scripts. Reusing Ant scripts (or
>> pieces of them) from existing builds, when converting to Maven.
>>
>> To the plugin developer, they can simply build an Ant script as they
>> always do, and a simple Mojo that passes parameters (and defaults)
>> from the POM in to the Ant script and executes it. Obviously, I could
>> have done it all within the Mojo myself, or I could have called Ant
>> programmatically, or I could just script the Ant. There are many ways
>> to get there.
>>
>> To the plugin user, they don't know which technique is in use, and
>> shouldn't care...
>>
>> On 9/20/05, Wendell Beckwith <wb...@gmail.com> wrote:
>>
>>
>>> Just for clarification are you suggesting that a plugin that
>>> needs to
>>> execute a java process should be designed as an ant script, and
>>> the plugin
>>> would simply pass parameters to the ant script? I ask because I
>>> don't see
>>> how this is less maintenance than my current plugin that provides
>>> intelligent defaults in the mojo and just needs to pass theses
>>> parameters
>>> along with any the user changed to the java process. Whenever
>>> there are
>>> plugin changes, I still go to the mojo in my design or an ant
>>> script in your
>>> design, correct?
>>>
>>> Wb
>>>
>>>
>>> On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>>>
>>>
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> I've actually done something just like this in the past, in
>>>> order to
>>>> call a Make-based build. IMO, you want to wrap a command line
>>>> call in a
>>>> plugin, to formalize the parameters - required and optional - which
>>>> constitutes a valid invocation of that executable. Otherwise,
>>>> it's prone
>>>> to breaking, misuse, and cut-and-paste maintenance style. In
>>>> short, it
>>>> isn't robust, and doesn't scale well. Anything where execution
>>>> logic is
>>>> embedded in the POM will suffer from this, IMO - including the
>>>> antrun
>>>> and execute plugins in the mojos project. A better solution for Ant
>>>> would be to build the plugin around the Ant script/scriptlet,
>>>> and bundle
>>>> that script into the plugin jar...then parameterize the input
>>>> configuration. Then, the script can climb the maturity curve,
>>>> and is
>>>> truly reused with a single point of maintenance.
>>>>
>>>> - -john
>>>>
>>>> Vincent Massol wrote:
>>>> |
>>>> |>-----Original Message-----
>>>> |>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
>>>> |>Sent: mardi 20 septembre 2005 19:15
>>>> |>To: Maven Users List
>>>> |>Subject: Re: [m2] reasons for sticking with maven
>>>> |>
>>>> |>John is basically stating the very thing that I'm against in the
>>>> statement
>>>> |>below. I have a 3rd party command line utility from
>>>> |>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
>>>> |>that basically does unit tests against our code. I want to
>>>> write (and
>>>> have
>>>> |>started writing) an M2 plugin to execute the java command line
>>>> for the
>>>> |>agitation process from my plugin. All I need now to complete
>>>> my plugin
>>>> |>besides more hours in a day is a plugin that will allow me to
>>>> execute a
>>>> |>java
>>>> |>command line. Now my plugin will integrate with the maven
>>>> lifecycle
>>>> during
>>>> |>the test phase. However, first I'm told to use the maven-
>>>> execute-plugin
>>>> |>and
>>>> |>then another dev states that it's bad and wants to see it
>>>> eliminated,
>>>> I'm
>>>> |>left thinking WTF!? This *helps* me adopt maven and the
>>>> process, not
>>>> |>hinders
>>>> |>it. My whole purpose for writing the plugin was so that I
>>>> could make the
>>>> |>plugin once and the other groups here and else where since I
>>>> would open
>>>> |>source it would be able to reuse it. Is this not what maven is
>>>> for?
>>>> |
>>>> |
>>>> | Just to muddy the waters: why don't you use commons-exec from
>>>> your
>>>> plugin's
>>>> | java code to execute your process?
>>>> |
>>>> | [snip]
>>>> |
>>>> | Thanks
>>>> | -Vincent
>>>> |
>>>> |
>>>> |
>>>> -------------------------------------------------------------------
>>>> --
>>>> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> | For additional commands, e-mail: users-help@maven.apache.org
>>>> |
>>>> |
>>>> |
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.2.6 (GNU/Linux)
>>>>
>>>> iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
>>>> 3JIbhwsALTmuwn5OB/7gG9k=
>>>> =WOfH
>>>> -----END PGP SIGNATURE-----
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Antfile plugin
Posted by Ashley Williams <ag...@mac.com>.
Hi Chris,
I've mislaid the link to your plugin - can you post it up again??
On 20 Sep 2005, at 21:55, Chris Berry wrote:
> Yes, it is the equivalent. But one thing confuses me, it's not about
> executing a java process (per se) -- it's about executing Ant. And
> it's not about maintenance. I think the heart of the discussion is
> reuse. Not reinventing what Ant already does. Providing a mechanism
> for reuse and versioning of Ant scripts. Reusing Ant scripts (or
> pieces of them) from existing builds, when converting to Maven.
>
> To the plugin developer, they can simply build an Ant script as they
> always do, and a simple Mojo that passes parameters (and defaults)
> from the POM in to the Ant script and executes it. Obviously, I could
> have done it all within the Mojo myself, or I could have called Ant
> programmatically, or I could just script the Ant. There are many ways
> to get there.
>
> To the plugin user, they don't know which technique is in use, and
> shouldn't care...
>
> On 9/20/05, Wendell Beckwith <wb...@gmail.com> wrote:
>
>> Just for clarification are you suggesting that a plugin that needs to
>> execute a java process should be designed as an ant script, and
>> the plugin
>> would simply pass parameters to the ant script? I ask because I
>> don't see
>> how this is less maintenance than my current plugin that provides
>> intelligent defaults in the mojo and just needs to pass theses
>> parameters
>> along with any the user changed to the java process. Whenever
>> there are
>> plugin changes, I still go to the mojo in my design or an ant
>> script in your
>> design, correct?
>>
>> Wb
>>
>>
>> On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>>
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I've actually done something just like this in the past, in order to
>>> call a Make-based build. IMO, you want to wrap a command line
>>> call in a
>>> plugin, to formalize the parameters - required and optional - which
>>> constitutes a valid invocation of that executable. Otherwise,
>>> it's prone
>>> to breaking, misuse, and cut-and-paste maintenance style. In
>>> short, it
>>> isn't robust, and doesn't scale well. Anything where execution
>>> logic is
>>> embedded in the POM will suffer from this, IMO - including the
>>> antrun
>>> and execute plugins in the mojos project. A better solution for Ant
>>> would be to build the plugin around the Ant script/scriptlet, and
>>> bundle
>>> that script into the plugin jar...then parameterize the input
>>> configuration. Then, the script can climb the maturity curve, and is
>>> truly reused with a single point of maintenance.
>>>
>>> - -john
>>>
>>> Vincent Massol wrote:
>>> |
>>> |>-----Original Message-----
>>> |>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
>>> |>Sent: mardi 20 septembre 2005 19:15
>>> |>To: Maven Users List
>>> |>Subject: Re: [m2] reasons for sticking with maven
>>> |>
>>> |>John is basically stating the very thing that I'm against in the
>>> statement
>>> |>below. I have a 3rd party command line utility from
>>> |>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
>>> |>that basically does unit tests against our code. I want to
>>> write (and
>>> have
>>> |>started writing) an M2 plugin to execute the java command line
>>> for the
>>> |>agitation process from my plugin. All I need now to complete my
>>> plugin
>>> |>besides more hours in a day is a plugin that will allow me to
>>> execute a
>>> |>java
>>> |>command line. Now my plugin will integrate with the maven
>>> lifecycle
>>> during
>>> |>the test phase. However, first I'm told to use the maven-
>>> execute-plugin
>>> |>and
>>> |>then another dev states that it's bad and wants to see it
>>> eliminated,
>>> I'm
>>> |>left thinking WTF!? This *helps* me adopt maven and the
>>> process, not
>>> |>hinders
>>> |>it. My whole purpose for writing the plugin was so that I could
>>> make the
>>> |>plugin once and the other groups here and else where since I
>>> would open
>>> |>source it would be able to reuse it. Is this not what maven is
>>> for?
>>> |
>>> |
>>> | Just to muddy the waters: why don't you use commons-exec from your
>>> plugin's
>>> | java code to execute your process?
>>> |
>>> | [snip]
>>> |
>>> | Thanks
>>> | -Vincent
>>> |
>>> |
>>> |
>>> --------------------------------------------------------------------
>>> -
>>> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> | For additional commands, e-mail: users-help@maven.apache.org
>>> |
>>> |
>>> |
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.6 (GNU/Linux)
>>>
>>> iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
>>> 3JIbhwsALTmuwn5OB/7gG9k=
>>> =WOfH
>>> -----END PGP SIGNATURE-----
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Chris Berry <ch...@gmail.com>.
Yes, it is the equivalent. But one thing confuses me, it's not about
executing a java process (per se) -- it's about executing Ant. And
it's not about maintenance. I think the heart of the discussion is
reuse. Not reinventing what Ant already does. Providing a mechanism
for reuse and versioning of Ant scripts. Reusing Ant scripts (or
pieces of them) from existing builds, when converting to Maven.
To the plugin developer, they can simply build an Ant script as they
always do, and a simple Mojo that passes parameters (and defaults)
from the POM in to the Ant script and executes it. Obviously, I could
have done it all within the Mojo myself, or I could have called Ant
programmatically, or I could just script the Ant. There are many ways
to get there.
To the plugin user, they don't know which technique is in use, and
shouldn't care...
On 9/20/05, Wendell Beckwith <wb...@gmail.com> wrote:
> Just for clarification are you suggesting that a plugin that needs to
> execute a java process should be designed as an ant script, and the plugin
> would simply pass parameters to the ant script? I ask because I don't see
> how this is less maintenance than my current plugin that provides
> intelligent defaults in the mojo and just needs to pass theses parameters
> along with any the user changed to the java process. Whenever there are
> plugin changes, I still go to the mojo in my design or an ant script in your
> design, correct?
>
> Wb
>
>
> On 9/20/05, John Casey <jd...@commonjava.org> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I've actually done something just like this in the past, in order to
> > call a Make-based build. IMO, you want to wrap a command line call in a
> > plugin, to formalize the parameters - required and optional - which
> > constitutes a valid invocation of that executable. Otherwise, it's prone
> > to breaking, misuse, and cut-and-paste maintenance style. In short, it
> > isn't robust, and doesn't scale well. Anything where execution logic is
> > embedded in the POM will suffer from this, IMO - including the antrun
> > and execute plugins in the mojos project. A better solution for Ant
> > would be to build the plugin around the Ant script/scriptlet, and bundle
> > that script into the plugin jar...then parameterize the input
> > configuration. Then, the script can climb the maturity curve, and is
> > truly reused with a single point of maintenance.
> >
> > - -john
> >
> > Vincent Massol wrote:
> > |
> > |>-----Original Message-----
> > |>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
> > |>Sent: mardi 20 septembre 2005 19:15
> > |>To: Maven Users List
> > |>Subject: Re: [m2] reasons for sticking with maven
> > |>
> > |>John is basically stating the very thing that I'm against in the
> > statement
> > |>below. I have a 3rd party command line utility from
> > |>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
> > |>that basically does unit tests against our code. I want to write (and
> > have
> > |>started writing) an M2 plugin to execute the java command line for the
> > |>agitation process from my plugin. All I need now to complete my plugin
> > |>besides more hours in a day is a plugin that will allow me to execute a
> > |>java
> > |>command line. Now my plugin will integrate with the maven lifecycle
> > during
> > |>the test phase. However, first I'm told to use the maven-execute-plugin
> > |>and
> > |>then another dev states that it's bad and wants to see it eliminated,
> > I'm
> > |>left thinking WTF!? This *helps* me adopt maven and the process, not
> > |>hinders
> > |>it. My whole purpose for writing the plugin was so that I could make the
> > |>plugin once and the other groups here and else where since I would open
> > |>source it would be able to reuse it. Is this not what maven is for?
> > |
> > |
> > | Just to muddy the waters: why don't you use commons-exec from your
> > plugin's
> > | java code to execute your process?
> > |
> > | [snip]
> > |
> > | Thanks
> > | -Vincent
> > |
> > |
> > | ---------------------------------------------------------------------
> > | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > | For additional commands, e-mail: users-help@maven.apache.org
> > |
> > |
> > |
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.6 (GNU/Linux)
> >
> > iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
> > 3JIbhwsALTmuwn5OB/7gG9k=
> > =WOfH
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
Just for clarification are you suggesting that a plugin that needs to
execute a java process should be designed as an ant script, and the plugin
would simply pass parameters to the ant script? I ask because I don't see
how this is less maintenance than my current plugin that provides
intelligent defaults in the mojo and just needs to pass theses parameters
along with any the user changed to the java process. Whenever there are
plugin changes, I still go to the mojo in my design or an ant script in your
design, correct?
Wb
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've actually done something just like this in the past, in order to
> call a Make-based build. IMO, you want to wrap a command line call in a
> plugin, to formalize the parameters - required and optional - which
> constitutes a valid invocation of that executable. Otherwise, it's prone
> to breaking, misuse, and cut-and-paste maintenance style. In short, it
> isn't robust, and doesn't scale well. Anything where execution logic is
> embedded in the POM will suffer from this, IMO - including the antrun
> and execute plugins in the mojos project. A better solution for Ant
> would be to build the plugin around the Ant script/scriptlet, and bundle
> that script into the plugin jar...then parameterize the input
> configuration. Then, the script can climb the maturity curve, and is
> truly reused with a single point of maintenance.
>
> - -john
>
> Vincent Massol wrote:
> |
> |>-----Original Message-----
> |>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
> |>Sent: mardi 20 septembre 2005 19:15
> |>To: Maven Users List
> |>Subject: Re: [m2] reasons for sticking with maven
> |>
> |>John is basically stating the very thing that I'm against in the
> statement
> |>below. I have a 3rd party command line utility from
> |>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
> |>that basically does unit tests against our code. I want to write (and
> have
> |>started writing) an M2 plugin to execute the java command line for the
> |>agitation process from my plugin. All I need now to complete my plugin
> |>besides more hours in a day is a plugin that will allow me to execute a
> |>java
> |>command line. Now my plugin will integrate with the maven lifecycle
> during
> |>the test phase. However, first I'm told to use the maven-execute-plugin
> |>and
> |>then another dev states that it's bad and wants to see it eliminated,
> I'm
> |>left thinking WTF!? This *helps* me adopt maven and the process, not
> |>hinders
> |>it. My whole purpose for writing the plugin was so that I could make the
> |>plugin once and the other groups here and else where since I would open
> |>source it would be able to reuse it. Is this not what maven is for?
> |
> |
> | Just to muddy the waters: why don't you use commons-exec from your
> plugin's
> | java code to execute your process?
> |
> | [snip]
> |
> | Thanks
> | -Vincent
> |
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
> 3JIbhwsALTmuwn5OB/7gG9k=
> =WOfH
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've actually done something just like this in the past, in order to
call a Make-based build. IMO, you want to wrap a command line call in a
plugin, to formalize the parameters - required and optional - which
constitutes a valid invocation of that executable. Otherwise, it's prone
to breaking, misuse, and cut-and-paste maintenance style. In short, it
isn't robust, and doesn't scale well. Anything where execution logic is
embedded in the POM will suffer from this, IMO - including the antrun
and execute plugins in the mojos project. A better solution for Ant
would be to build the plugin around the Ant script/scriptlet, and bundle
that script into the plugin jar...then parameterize the input
configuration. Then, the script can climb the maturity curve, and is
truly reused with a single point of maintenance.
- -john
Vincent Massol wrote:
|
|>-----Original Message-----
|>From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
|>Sent: mardi 20 septembre 2005 19:15
|>To: Maven Users List
|>Subject: Re: [m2] reasons for sticking with maven
|>
|>John is basically stating the very thing that I'm against in the statement
|>below. I have a 3rd party command line utility from
|>www.agitar.com<http://www.agitar.com>,
|>that basically does unit tests against our code. I want to write (and have
|>started writing) an M2 plugin to execute the java command line for the
|>agitation process from my plugin. All I need now to complete my plugin
|>besides more hours in a day is a plugin that will allow me to execute a
|>java
|>command line. Now my plugin will integrate with the maven lifecycle during
|>the test phase. However, first I'm told to use the maven-execute-plugin
|>and
|>then another dev states that it's bad and wants to see it eliminated, I'm
|>left thinking WTF!? This *helps* me adopt maven and the process, not
|>hinders
|>it. My whole purpose for writing the plugin was so that I could make the
|>plugin once and the other groups here and else where since I would open
|>source it would be able to reuse it. Is this not what maven is for?
|
|
| Just to muddy the waters: why don't you use commons-exec from your
plugin's
| java code to execute your process?
|
| [snip]
|
| Thanks
| -Vincent
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
3JIbhwsALTmuwn5OB/7gG9k=
=WOfH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [m2] reasons for sticking with maven
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Wendell Beckwith [mailto:wbeckwith@gmail.com]
> Sent: mardi 20 septembre 2005 19:15
> To: Maven Users List
> Subject: Re: [m2] reasons for sticking with maven
>
> John is basically stating the very thing that I'm against in the statement
> below. I have a 3rd party command line utility from
> www.agitar.com<http://www.agitar.com>,
> that basically does unit tests against our code. I want to write (and have
> started writing) an M2 plugin to execute the java command line for the
> agitation process from my plugin. All I need now to complete my plugin
> besides more hours in a day is a plugin that will allow me to execute a
> java
> command line. Now my plugin will integrate with the maven lifecycle during
> the test phase. However, first I'm told to use the maven-execute-plugin
> and
> then another dev states that it's bad and wants to see it eliminated, I'm
> left thinking WTF!? This *helps* me adopt maven and the process, not
> hinders
> it. My whole purpose for writing the plugin was so that I could make the
> plugin once and the other groups here and else where since I would open
> source it would be able to reuse it. Is this not what maven is for?
Just to muddy the waters: why don't you use commons-exec from your plugin's
java code to execute your process?
[snip]
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Wendell Beckwith <wb...@gmail.com>.
John is basically stating the very thing that I'm against in the statement
below. I have a 3rd party command line utility from
www.agitar.com<http://www.agitar.com>,
that basically does unit tests against our code. I want to write (and have
started writing) an M2 plugin to execute the java command line for the
agitation process from my plugin. All I need now to complete my plugin
besides more hours in a day is a plugin that will allow me to execute a java
command line. Now my plugin will integrate with the maven lifecycle during
the test phase. However, first I'm told to use the maven-execute-plugin and
then another dev states that it's bad and wants to see it eliminated, I'm
left thinking WTF!? This *helps* me adopt maven and the process, not hinders
it. My whole purpose for writing the plugin was so that I could make the
plugin once and the other groups here and else where since I would open
source it would be able to reuse it. Is this not what maven is for?
Wb
On 9/20/05, John Casey <jd...@commonjava.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
[Snipped]
|
> | 3. Need to do a myriad of simple things such as automatically run java
> | command or deploy to tomcat. I used to do this all the time in my ant
> | scripts, ie run my build.xml script and at the end it would run my app
> | on completion. It's a credit to those on this list who reply with ideas
> | and workarounds - however this is kind of related to 2 above, where
> | there are lots of ant tasks out there that are tested to death and that
> | I should be able to use today.
>
> The funny thing about Maven 2 is that it facilitates external plugin
> development. You can load a plugin from a repository hosted anywhere.
> Personally, I feel strongly that executing random commands from within
> the build process is a Bad Thing, and a thing that is bad and common
> with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
> It's not a launching platform, and it's not a tool to be used to run
> your coffee maker. Executing random commands from a configuration in a
> POM is:
>
> a. unscaleable, since that runtime config is not encapsulated for reuse
>
> b. bound to partition your build logic into multiple pieces, which now
> have to be maintained from multiple sources.
>
> In Ant, you can do anything you please, including things that don't
> relate to the process of building software. It's important to keep a
> clear idea of the problem domain we're trying to address here.
>
> Having said that, there's nothing stopping you from hosting your own
> maven-foo-plugin on Sourceforge or somesuch. If you find what you
> perceive to be a hole in our plugin offering, and cannot convince us to
> fill it, there's nothing stopping you from scratching your own itch. We
> currently have maven-execute-plugin on the mojos project, but I'd really
> like to see it deprecated and eliminated eventually.
>
>
Re: [m2] reasons for sticking with maven
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comments are inline. Please bear with me, I think my responses are as
lengthy as your original email! :(
Cheers,
John
Ashley Williams wrote:
| Sincere apologies to the dev team if this email seems like a troll, I
| absolutely don't mean it to be. I'm aware that they continue to do
| outstanding work and are few in number.
|
| The more I use Maven the more I get a feel for the size and shape of it
| and find myself looking for features that aren't there. Since I joined
| the community I've posted questions on what I consider to be the most
| important aspects of a build system namely (yes in this order):
|
| 1. Usability from Ant - there are hundreds of Ant targets out there
| that are useful for me today. I can't justify waiting for them to be
| rewritten as Maven equivalents not only because I need functionality
| today, but also because I don't see why I have to abandon my experience
| with ant.
I've already addressed this with you and others on this list. I've
mentioned that I'm fully in favor of this sort of integration, and I
have some starting points from Chris that I'll be putting in to allow
this sort of thing. You don't have to wait for all of Ant's API to be
replicated; you only have to wait for me to get this one change in place. :)
|
| 2. Usability from Eclipse - when will I be able to ditch the command
| line and create and manage projects entirely from eclipse
This depends on people with Eclipse development experience (not
experience using Eclipse) picking up the task and running with it. We're
trying to get something together in the way of a more concerted effort,
but I'm sure you'll agree that getting a stable API was the first thing
to do, since otherwise the Eclipse integration project would have to
track a moving target. Now that we've got a beta-1 release, we can start
thinking about this.
|
| 3. Need to do a myriad of simple things such as automatically run java
| command or deploy to tomcat. I used to do this all the time in my ant
| scripts, ie run my build.xml script and at the end it would run my app
| on completion. It's a credit to those on this list who reply with ideas
| and workarounds - however this is kind of related to 2 above, where
| there are lots of ant tasks out there that are tested to death and that
| I should be able to use today.
The funny thing about Maven 2 is that it facilitates external plugin
development. You can load a plugin from a repository hosted anywhere.
Personally, I feel strongly that executing random commands from within
the build process is a Bad Thing, and a thing that is bad and common
with Ant. Maven - and also Ant, to a lesser extent - is a build tool.
It's not a launching platform, and it's not a tool to be used to run
your coffee maker. Executing random commands from a configuration in a
POM is:
a. unscaleable, since that runtime config is not encapsulated for reuse
b. bound to partition your build logic into multiple pieces, which now
have to be maintained from multiple sources.
In Ant, you can do anything you please, including things that don't
relate to the process of building software. It's important to keep a
clear idea of the problem domain we're trying to address here.
Having said that, there's nothing stopping you from hosting your own
maven-foo-plugin on Sourceforge or somesuch. If you find what you
perceive to be a hole in our plugin offering, and cannot convince us to
fill it, there's nothing stopping you from scratching your own itch. We
currently have maven-execute-plugin on the mojos project, but I'd really
like to see it deprecated and eliminated eventually.
|
| 4. Online documentation. Simple example was trying to get the assembly
| plugin to work which Daniel Shomer had to look into the source code to
| advise me of what to do. This is just one example of many.
You're not the first to point this out, and properly so. Just this week,
one of the devs started fulltime on fixing this. Documentation has
lagged for a few reasons, which I don't offer as excuses. First, the
devs have been trying to stabilize the featureset and functionality
before we try to document it. This is sort of a chicken-egg scenario,
because (as was pointed out) its easier to maintain a clear design
between multiple devs when you have documentation, but documentation of
an evolving API gets stale quickly.
Now that you've read the source code for the assembly plugin, will you
contribute some documentation?
|
| 5. Other project structures. Sometimes I will encounter a project where
| all the source code is in one tree (beginning with com/). I'm not
| saying its any better than one directory per artifact, but I am saying
| I encounter such projects in my career and as such I know I wouldn't be
| able to use maven.
This project can get a little preachy, and I'm no exception. We tend to
believe that we've seen a lot of use cases (many on this list), and that
our standard layout is the most elegant solution THAT WE'VE FOUND SO
FAR. I emphasize that, because it's important to acknowledge that
today's gospel is tomorrow's quaint idea. We're focusing on providing
support for that standard layout/model right now, but we will be adding
support for other project layouts when we learn of deficiencies. What we
most need is use cases. If you have a specific one, can you share it?
Where, specifically, are you having trouble with meshing your layout and
the POM?
|
| 6. Contribute to the code. I have tried to get a foot in the door in
| order to fix some of my own critisisms, but the lack of javadocs mean
| that I really can't do this other than for some simple plugins. That is
| unless I had lots of time to spare which I don't. In turn that makes me
| concerned how the project will attract other developers to move things
| along quickly.
I addressed this a little bit above, but I believe Maven 2 is still
climbing that maturity curve. We're climbing fast, but there are bound
to be places that need attention. Javadocs may help, but an
architectural overview and set of mini HOW-TOs may go a lot further.
There are very few methods in the code that aren't self-explanatory, at
least at a high level. However, I still agree that javadocs would be a
good thing. Unfortunately, as you've so eloquently pointed out, there is
a long line of Good Things waiting for attention...this is where we have
to prioritize, and choose which ones we will attend to first. We've
chosen code/feature stability, and API stability heretofore, but we're
starting to focus on POM usability, additional plugin languages, and
documentation now that we're in bugfix mode.
If you've spent any time in the sources, and found that you understood
even a small portion when you were done, would you be willing to write
some of these javadocs and submit a patch? Every contribution, however
small, will push us closer to the level of maturity you desire.
|
| I realize there may be workarounds for some of the above, but I
| couldn't stick my neck on the line for a dev team and recommend sharing
| of eclipse hack scripts etc as a way of working. I'm also putting my
| selfish hat on and say that I'd like to do the above without defending
| it - there are a few threads on this list already that deal with the
| pros and cons.
|
| ***************************************
|
| Now I'll turn my attention to Ivy. I've began to look at this product
| and it seems to offer many of the features of Maven including
|
| 1. transitive dependencies
If I understand correctly, Ivy depends on profile name consistency for
transitivity to function properly...
| 2. compatibility with the ibiblio repository
Maven 2 has this compat as well, and can probably supply the same level
of functionality as Ivy given the quality of metadata in the m1
repository. You can specify a repository with <layout>legacy</layout>
and it should work. But we're hoping for much more than this.
|
| and in addition
|
| 1. the online docs are excellent even if they are in broken english
Ivy is an overlay for Ant, meant only to provide transitive dependency
resolution and compat with the m1 repository. This means it's a
relatively small project, and therefore have the ability to climb that
maturity curve faster.
As a side note, Ant 1.7 will be using Maven 2.0's artifact-handling API.
This, after Ivy has been out there available for integration for some
time now. Why is that, do you think?
| 2. Can manage projects from with eclipse, since they are just ant
| projects (with simple projects, haven't tried anything tricky)
What level of integration do you need here? Would it be feasible, for
example, to create a set of command-line execution profiles in Eclipse,
to call various m2 targets? I've done this successfully with svn, when I
found subclipse to be far too sluggish and flaky.
| 3. Can manage maven style module directory structures or single source
| trees. Obviously being Ant, it can manage any structure you like, but
| these are the only two sane ones I know.
If I understand correctly, the m2 eclipse plugin does have some support
for this, although I'm not the best person to speak about it. To some
extent, solutions to this will be compromised by Eclipse's lack of
nested project support...which in some cases can lead to set-semantics
when collecting dependencies for a hierarchy of projects...which can in
turn lead to sources compiling in Eclipse but not in Maven, since the
dependency declarations are not the same. The eclipse integration has
been escalated as a priority recently, but we're not likelly to have
anything for at least a few weeks. We understand the market share that
Eclipse commands, and its value for integration...unfortunately, we
haven't had the time to devote to external m2 integations up to now.
|
| Yes there is stuff that it doesn't have such as a built in lifecycle,
| but with what I've learnt from the maven layout, I feel I could quite
| easily replicate that in ant in a reusable way. That said I would
| prefer not to have to. I suppose I'm looking for reassurance as to why
| Maven is the way to go because there seems to be considerable overlap
| with Ivy.
'Considerable' is a tad exaggerated, IMHO. Maven gives you reusability,
not only of plugin functionality, but also of project information (the
POM specifies most of what plugins need, so project configuration scales
better than Ant for the marginal plugin). It also provides a single,
simple lifecycle that ensures a sane progression from task to task in
order. This lifecycle is the same for everything you will build, since
plugins bind to the lifecycle behind the scenes.
If you attempted to build a lifecycle on top of Ant, I think you'd find
~ a couple of things to be true:
1. it's not as simple as it seems, particularly if you build multiple
types of projects (EJB, EAR, WAR, JAR, DLL, RPM, ...)
2. unless you attempt to open source your own solution - which means it
will have to have general applicability, which itself is not a trivial
goal - you will have to maintain your lifecycle layer in addition to
your actual build scripts. Tracking something like this against updates
in Ant and Ivy is not trivial...I tried something similar before Maven
came along. The problem is that maintaining this lifecycle layer will
not directly impact your company's bottom line, so they will be
reluctant to give you much slack time to maintain it.
|
| ****************************************
|
| I realize that I am being very selfish here, but I have to think very
| carefully about what I invest my time in. Maven has all the hallmarks
| of being that software that I felt was missing during my career, which
| is why I care enough about it to spare the time for these critisisms. I
| just want to be sure it has a chance of gaining critical mass.
|
| Maybe the gatekeeper/guardian of this project needs to write some sort
| of Jerry Maguire style memo that says what Maven's purpose is and plans
| are so that we can all keep focused on that.
|
| Maybe my views aren't representative of a large enough demographic in
| which case this email will just slip away into obscurity, but either
| way thanks for reading and please don't take it as a troll
I appreciate you taking the time to articulate your concerns. There is
no doubt in my mind that many of the points you raise will resound with
users, both current and potential. However, I have a question for you:
How long did you spend on this email?
It's fairly involved, and judging by the time I've spent responding, it
took some effort. Did you do this in the course of your workday? If so,
can you afford this amount of time a couple times a week? I'd like to
encourage you to spend this amount of time exploring our APIs, writing
javadocs (or whatever doco, etc. you see fit) and submitting patches.
This much effort from a few users like you would really make a
difference fast, IMO.
Just something to think about. Even small patches will eventually add up.
- -john
|
| -AW
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMCeJK3h2CZwO/4URAhfPAKCD1iOtdPe2NO0j8KY6vg0L7oUW4ACgnZpk
7bbtGsKkiZKm8o/wOqY4Sjo=
=JcXf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jason van Zyl <ja...@maven.org> writes:
[...]
>> 5. Other project structures. Sometimes I will encounter a project
>> where all the source code is in one tree (beginning with com/). I'm
>> not saying its any better than one directory per artifact, but I am
>> saying I encounter such projects in my career and as such I know I
>> wouldn't be able to use maven.
>That's a choice you'll have to make. Many people have found making the
>switch to our default ways of doing things has numerous benefits. If
>it's not something you can do then we understand but we feel coherency,
>consistency, and comprehension win out over other concerns. Make a good
>plugin and all Maven users benefit. Make a one off script for your own
>setup and you've just isolated yourself from a great source of potential
>help. Making a decent plugin might take you an extra 20% in time but the
>ultimate savings in time has shown itself in our community over and over
>again.
>We also know that new projects are starting all the time and this is the
>ideal time to try Maven. For people who have different structures, you
>will probably also find that their build now works and in these cases I
>would never recommend switching from Make or Ant unless you are having
>serious problems with maintenance.
[...]
This is something that I've begged to differ with you ever since
maven-0.1. If you use maven only in "new projects", then yes, the
maven structure does work. It leads to largely spread out docs because
projects are cut into pieces held together by the reactor, but yes,
the overall project works fine.
However, there are two factors that don't seem to be on your radar
since day one of maven:
- legacy code and code structures
- company rules
Both of them void the "best possible layout" approach. Because these
criterias win in 99% of the use cases with legacy code.
If you are a contractor and want to introduce maven and start with
"but we have to reorganize our whole 2,000,000 lines enterprise
critical EAR application to fit the layout of a build tool", you won't
get far. Been there, done that, got burned. Used ant.
A simple example: Turbine (I know that you are familiar with it. ;-) )
Turbine consists of a source tree in src/java and some automatically
generated classes that are generated at jar build time. Everything
ends up in a single jar. The current approach is:
- copy everything from src/java to target/src (maven.xml preGoal)
- build the autogenerated classes into target/src (maven.xml preGoal)
- build the project from target/src (regular java:compile)
-> works.
But: does not work with Eclipse at the same time, because the
subversion controlled tree is at a different location as the actual
build tree.
Point eclipse at target/src: No Subversion.
Point Eclipse at src/java: Missing classes.
-> Catch-22
Easiest solution: Tell maven to have a source tree in src/java and
another in target/autogenerated. Tailor the build process to compile
one jar from two source locations.
Impossible (or only possible with a hack as described in
http://maven.apache.org/faq.html#multiple-source-directories) with
maven 1. Is it technically impossible? I don't think so.
My whole point was (and is and I got flamed by a number of maven
people because I still insist on it):
Maven is a build tool. This means, in architectural terms, it is putty
or plaster, intended to keep the parts and bricks together from which
I build my house. It is an integral part of the house but it must not
dictate the shape in which I build my house.
Currently, maven is plaster that contains various small and medium
sized rocks. Due to this, I can't put all the parts of my house
together in the way that I intend. I have to work around these
rocks. Or I switch plaster brands.
I've actually looked at ivy some time ago and dismissed it as "yes, it
can resolve dependencies. Full stop". Maven is so much more than
that. I'm _happy_ that I don't have to write ant build.xml files any
more.
I would very much prefer m2 to be "real" plaster. :-)
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Ashley Williams <ag...@mac.com>.
I appreciate your response and I hope this information is useful to
others as well
as myself. With regards to comparing Ivy to Maven you might be right
in saying it's
comparing apples to oranges. Nevertheless it sure doesn't look that
way to the
newbie and I would say that you've made that
comparison - which would interest lots of people. Maybe its worth
putting
it up on your website as the Ivy guys have done.
http://www.jayasoft.fr/org/modules/ivy/comparison.php
Maybe also a fleshed out roadmap would help with info that currently
only exists on this
mailing list.
With both Ant and Maven out there, I believe that Maven needs more of
a sales pitch
to compete for eyeballs - although I realize this would be low on
your list.
Thanks
-AW
On 20 Sep 2005, at 16:49, Jason van Zyl wrote:
> On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote:
>
>
>> 1. Usability from Ant - there are hundreds of Ant targets out there
>> that are useful for me today. I can't justify waiting for them to be
>> rewritten as Maven equivalents not only because I need functionality
>> today, but also because I don't see why I have to abandon my
>> experience with ant.
>>
>
> We are rapidly trying to make Ant functionality available in m2 by
> creating a plugin type that allows you to script up plugins using
> Ant's
> familiar XML scripting. If you can't wait and have a pending project
> then your stance is understandable.
>
> For the time being you can take advantage of what we've made available
> via Ant tasks.
>
>
>> 2. Usability from Eclipse - when will I be able to ditch the command
>> line and create and manage projects entirely from eclipse
>>
>
> This is something that is actively being pursued and something will
> materialize sooner rather then later. We understand the critical
> nature
> of tool integration. The importance is not lost on us, we understand.
>
>
>> 3. Need to do a myriad of simple things such as automatically run
>> java command or deploy to tomcat. I used to do this all the time in
>> my ant scripts, ie run my build.xml script and at the end it would
>> run my app on completion. It's a credit to those on this list who
>> reply with ideas and workarounds - however this is kind of related to
>> 2 above, where there are lots of ant tasks out there that are tested
>> to death and that I should be able to use today.
>>
>
> Here our aims are different. We don't want everyone scripting up
> everything in their own way. It may be convenient in the short term
> but
> we would prefer to wait for someone to create a coherent,
> consistent way
> to launch an appserver for testing so that it benefits all Maven
> users.
> We feel in the long run this approach serves the community better but
> this notion is often at odds with folks who needs to get things done
> Right Now(tm).
>
>
>> 4. Online documentation. Simple example was trying to get the
>> assembly plugin to work which Daniel Shomer had to look into the
>> source code to advise me of what to do. This is just one example of
>> many.
>>
>
> The documentation is admittedly lacking. I am actually working pretty
> much full-time on writing doco for the release so this is not lost
> on us
> either. We know that documentation is critical for successful
> widespread
> adoption.
>
>
>> 5. Other project structures. Sometimes I will encounter a project
>> where all the source code is in one tree (beginning with com/). I'm
>> not saying its any better than one directory per artifact, but I am
>> saying I encounter such projects in my career and as such I know I
>> wouldn't be able to use maven.
>>
>
> That's a choice you'll have to make. Many people have found making the
> switch to our default ways of doing things has numerous benefits. If
> it's not something you can do then we understand but we feel
> coherency,
> consistency, and comprehension win out over other concerns. Make a
> good
> plugin and all Maven users benefit. Make a one off script for your own
> setup and you've just isolated yourself from a great source of
> potential
> help. Making a decent plugin might take you an extra 20% in time
> but the
> ultimate savings in time has shown itself in our community over and
> over
> again.
>
> We also know that new projects are starting all the time and this
> is the
> ideal time to try Maven. For people who have different structures, you
> will probably also find that their build now works and in these
> cases I
> would never recommend switching from Make or Ant unless you are having
> serious problems with maintenance.
>
>
>> 6. Contribute to the code. I have tried to get a foot in the door in
>> order to fix some of my own critisisms, but the lack of javadocs mean
>> that I really can't do this other than for some simple plugins. That
>> is unless I had lots of time to spare which I don't. In turn that
>> makes me concerned how the project will attract other developers to
>> move things along quickly.
>>
>
> We have actually attracted more developers in the last 6 months then
> ever before. We've got 4-5 new developers on the maven project and at
> least as many on the Mojo project. So things are actually looking
> great
> in terms of community involvement and I think it's only going to
> grow as
> we approach a final release. There is currently a barrier to entry but
> we've managed to overcome that and we're working on making getting
> involved easier:
>
> http://maven.apache.org/maven2/developers/development-guide.html
>
>
>> I realize there may be workarounds for some of the above, but I
>> couldn't stick my neck on the line for a dev team and recommend
>> sharing of eclipse hack scripts etc as a way of working. I'm also
>> putting my selfish hat on and say that I'd like to do the above
>> without defending it - there are a few threads on this list already
>> that deal with the pros and cons.
>>
>> ***************************************
>>
>> Now I'll turn my attention to Ivy. I've began to look at this product
>> and it seems to offer many of the features of Maven including
>>
>> 1. transitive dependencies
>> 2. compatibility with the ibiblio repository
>>
>
> But this is a mere fraction of what Maven tries to accomplish. I don't
> think you can really compare the two. Ivy provides a very small subset
> of Maven's capabilities.
>
>
>> and in addition
>>
>> 1. the online docs are excellent even if they are in broken english
>>
>
> Docs are docs, it's true. But we'll be in better shape for the final
> release.
>
>
>> 2. Can manage projects from with eclipse, since they are just ant
>> projects (with simple projects, haven't tried anything tricky)
>> 3. Can manage maven style module directory structures or single
>> source trees. Obviously being Ant, it can manage any structure you
>> like, but these are the only two sane ones I know.
>>
>
> Eclipse support is coming, I promise :-)
>
> As far as allowing any structure, that's just not what Maven is about.
> We don't encourage that and never will. We just feel in the long
> run the
> build is not what developers should be focusing on. The build should
> apply standard patterns much like all other aspects of software
> development and the focus should be on enriching your application.
> That's where the value lies.
>
> Anyone who uses Maven can talk to anyone else who uses Maven and
> understand much of what the other is talking about because we
> employ and
> encourage these best practices. If you have an entirely isolated setup
> your chances of getting help are limited and you will remain isolated.
> We try to carry the whole notion of patterns into the build
> infrastructure so people save their valuable time by being able to
> communicate effectively about specifics of a build.
>
>
>> Yes there is stuff that it doesn't have such as a built in lifecycle,
>> but with what I've learnt from the maven layout, I feel I could quite
>> easily replicate that in ant in a reusable way.
>>
>
> We know from painful experience that is not the case. I know of many
> attempts to replicate what Maven does in many organizations and
> very few
> of them still live on today. A great deal of consideration went into
> m2's lifecycle and I sincerely doubt it could be easily replicated.
>
>
>> That said I would
>> prefer not to have to. I suppose I'm looking for reassurance as to
>> why Maven is the way to go because there seems to be considerable
>> overlap with Ivy.
>>
>
> Maven and Ivy are not really comparable. Apples and Oranges. Ivy
> simply
> does dependency management and nothing else.
>
>
>> ****************************************
>>
>> I realize that I am being very selfish here, but I have to think very
>> carefully about what I invest my time in. Maven has all the hallmarks
>> of being that software that I felt was missing during my career,
>> which is why I care enough about it to spare the time for these
>> critisisms. I just want to be sure it has a chance of gaining
>> critical mass.
>>
>
> Everyone's time is important and deciding what to spend your time
> on is
> critical. We know that Maven has some shortcomings (just look at our
> JIRA!) but issues are being fixed at a breakneck pace. We think that
> with the release of 2.0 we're going to have something pretty good.
>
>
>> Maybe the gatekeeper/guardian of this project needs to write some
>> sort of Jerry Maguire style memo that says what Maven's purpose is
>> and plans are so that we can all keep focused on that.
>>
>
> What kind of demo do you suggest? I've never seen Jerry Maguire :-)
>
>
>> Maybe my views aren't representative of a large enough demographic in
>> which case this email will just slip away into obscurity, but either
>> way thanks for reading and please don't take it as a troll
>>
>
> Lots of folks have talked about the things you're talking about here.
> Everyone once in a while I respond just to refresh in my own mind why
> the project was started. It takes a while to get accustom to the way
> Maven works and what its goals are. In a nutshell Maven is an
> attempt to
> apply patterns to a build infrastructure in order to make things
> easier
> for everyone involved in Java (more languages later) software
> development.
>
>
>> -AW
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
> --
> jvz.
>
> Jason van Zyl
> jason at maven.org
> http://maven.apache.org
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
> -- Eric Hoffer, Reflections on the Human Condition
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] reasons for sticking with maven
Posted by Jason van Zyl <ja...@maven.org>.
On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote:
> 1. Usability from Ant - there are hundreds of Ant targets out there
> that are useful for me today. I can't justify waiting for them to be
> rewritten as Maven equivalents not only because I need functionality
> today, but also because I don't see why I have to abandon my
> experience with ant.
We are rapidly trying to make Ant functionality available in m2 by
creating a plugin type that allows you to script up plugins using Ant's
familiar XML scripting. If you can't wait and have a pending project
then your stance is understandable.
For the time being you can take advantage of what we've made available
via Ant tasks.
> 2. Usability from Eclipse - when will I be able to ditch the command
> line and create and manage projects entirely from eclipse
This is something that is actively being pursued and something will
materialize sooner rather then later. We understand the critical nature
of tool integration. The importance is not lost on us, we understand.
> 3. Need to do a myriad of simple things such as automatically run
> java command or deploy to tomcat. I used to do this all the time in
> my ant scripts, ie run my build.xml script and at the end it would
> run my app on completion. It's a credit to those on this list who
> reply with ideas and workarounds - however this is kind of related to
> 2 above, where there are lots of ant tasks out there that are tested
> to death and that I should be able to use today.
Here our aims are different. We don't want everyone scripting up
everything in their own way. It may be convenient in the short term but
we would prefer to wait for someone to create a coherent, consistent way
to launch an appserver for testing so that it benefits all Maven users.
We feel in the long run this approach serves the community better but
this notion is often at odds with folks who needs to get things done
Right Now(tm).
> 4. Online documentation. Simple example was trying to get the
> assembly plugin to work which Daniel Shomer had to look into the
> source code to advise me of what to do. This is just one example of
> many.
The documentation is admittedly lacking. I am actually working pretty
much full-time on writing doco for the release so this is not lost on us
either. We know that documentation is critical for successful widespread
adoption.
> 5. Other project structures. Sometimes I will encounter a project
> where all the source code is in one tree (beginning with com/). I'm
> not saying its any better than one directory per artifact, but I am
> saying I encounter such projects in my career and as such I know I
> wouldn't be able to use maven.
That's a choice you'll have to make. Many people have found making the
switch to our default ways of doing things has numerous benefits. If
it's not something you can do then we understand but we feel coherency,
consistency, and comprehension win out over other concerns. Make a good
plugin and all Maven users benefit. Make a one off script for your own
setup and you've just isolated yourself from a great source of potential
help. Making a decent plugin might take you an extra 20% in time but the
ultimate savings in time has shown itself in our community over and over
again.
We also know that new projects are starting all the time and this is the
ideal time to try Maven. For people who have different structures, you
will probably also find that their build now works and in these cases I
would never recommend switching from Make or Ant unless you are having
serious problems with maintenance.
> 6. Contribute to the code. I have tried to get a foot in the door in
> order to fix some of my own critisisms, but the lack of javadocs mean
> that I really can't do this other than for some simple plugins. That
> is unless I had lots of time to spare which I don't. In turn that
> makes me concerned how the project will attract other developers to
> move things along quickly.
We have actually attracted more developers in the last 6 months then
ever before. We've got 4-5 new developers on the maven project and at
least as many on the Mojo project. So things are actually looking great
in terms of community involvement and I think it's only going to grow as
we approach a final release. There is currently a barrier to entry but
we've managed to overcome that and we're working on making getting
involved easier:
http://maven.apache.org/maven2/developers/development-guide.html
> I realize there may be workarounds for some of the above, but I
> couldn't stick my neck on the line for a dev team and recommend
> sharing of eclipse hack scripts etc as a way of working. I'm also
> putting my selfish hat on and say that I'd like to do the above
> without defending it - there are a few threads on this list already
> that deal with the pros and cons.
>
> ***************************************
>
> Now I'll turn my attention to Ivy. I've began to look at this product
> and it seems to offer many of the features of Maven including
>
> 1. transitive dependencies
> 2. compatibility with the ibiblio repository
But this is a mere fraction of what Maven tries to accomplish. I don't
think you can really compare the two. Ivy provides a very small subset
of Maven's capabilities.
> and in addition
>
> 1. the online docs are excellent even if they are in broken english
Docs are docs, it's true. But we'll be in better shape for the final
release.
> 2. Can manage projects from with eclipse, since they are just ant
> projects (with simple projects, haven't tried anything tricky)
> 3. Can manage maven style module directory structures or single
> source trees. Obviously being Ant, it can manage any structure you
> like, but these are the only two sane ones I know.
Eclipse support is coming, I promise :-)
As far as allowing any structure, that's just not what Maven is about.
We don't encourage that and never will. We just feel in the long run the
build is not what developers should be focusing on. The build should
apply standard patterns much like all other aspects of software
development and the focus should be on enriching your application.
That's where the value lies.
Anyone who uses Maven can talk to anyone else who uses Maven and
understand much of what the other is talking about because we employ and
encourage these best practices. If you have an entirely isolated setup
your chances of getting help are limited and you will remain isolated.
We try to carry the whole notion of patterns into the build
infrastructure so people save their valuable time by being able to
communicate effectively about specifics of a build.
> Yes there is stuff that it doesn't have such as a built in lifecycle,
> but with what I've learnt from the maven layout, I feel I could quite
> easily replicate that in ant in a reusable way.
We know from painful experience that is not the case. I know of many
attempts to replicate what Maven does in many organizations and very few
of them still live on today. A great deal of consideration went into
m2's lifecycle and I sincerely doubt it could be easily replicated.
> That said I would
> prefer not to have to. I suppose I'm looking for reassurance as to
> why Maven is the way to go because there seems to be considerable
> overlap with Ivy.
Maven and Ivy are not really comparable. Apples and Oranges. Ivy simply
does dependency management and nothing else.
> ****************************************
>
> I realize that I am being very selfish here, but I have to think very
> carefully about what I invest my time in. Maven has all the hallmarks
> of being that software that I felt was missing during my career,
> which is why I care enough about it to spare the time for these
> critisisms. I just want to be sure it has a chance of gaining
> critical mass.
Everyone's time is important and deciding what to spend your time on is
critical. We know that Maven has some shortcomings (just look at our
JIRA!) but issues are being fixed at a breakneck pace. We think that
with the release of 2.0 we're going to have something pretty good.
> Maybe the gatekeeper/guardian of this project needs to write some
> sort of Jerry Maguire style memo that says what Maven's purpose is
> and plans are so that we can all keep focused on that.
What kind of demo do you suggest? I've never seen Jerry Maguire :-)
> Maybe my views aren't representative of a large enough demographic in
> which case this email will just slip away into obscurity, but either
> way thanks for reading and please don't take it as a troll
Lots of folks have talked about the things you're talking about here.
Everyone once in a while I respond just to refresh in my own mind why
the project was started. It takes a while to get accustom to the way
Maven works and what its goals are. In a nutshell Maven is an attempt to
apply patterns to a build infrastructure in order to make things easier
for everyone involved in Java (more languages later) software
development.
> -AW
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org