[POLL] Why switch to Maven?

[Eric Redmond <er...@gmail.com>]

Hi all Maven users!

I'm beginning a study to outline the real reasons that people have for
avoiding Maven. My questions to you all are:
What were your anxieties about using Maven? If you use Maven: what helped
you make the decision? If you don't: why did you avoid it?

Here are some that I have heard in the past:

* Lack of good documentation.
* Community unwilling to help me with my problems.
* Not "industry supported" or "mainstream" enough.
* I don't like conforming to the Maven project layout.
* My project is too complex to switch.
* There are not enough plugins available.
* We already have a large investement in tool X.
* I have to build native/non-Java code.

Any more reasons? Care to expand these ideas?
Thanks for your help!
____
Eric Redmond
http://codehaus.org/~eredmond

Re: [POLL] Why switch to Maven?

[Jimisola Laursen <li...@jimisola.com>]

> I agree. I don't want my site (Propellors) to be widely used... it's just
my
> own private wiki for organizing my ideas. If you notice, the page isn't
> even
> editable by the general public.

It not being editable makes it a lot easier :)

Would you consider moving your recipes to
http://docs.codehaus.org/display/MAVENUSER?

I doubt I'll find time during the week, but I could start to structure it
(the FAQ) up during the weekend.

Regards,
Jimisola

-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6069566
Sent from the Maven - Users forum at Nabble.com.


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

Re: [POLL] Why switch to Maven?

[Eric Redmond <er...@gmail.com>]

I agree. I don't want my site (Propellors) to be widely used... it's just my
own private wiki for organizing my ideas. If you notice, the page isn't even
editable by the general public.

On 8/30/06, Jimisola Laursen <li...@jimisola.com> wrote:
>
>
> (slightly of the initial topic but...)
>
> Hold on, hold on...
>
> Can't we try to keep the documentation in one place? And thereby make it
> easier to find.
>
> I think that Maven Recipes is great idea, but (always a but) it's off
> Maven's site.
>
> There is a FAQ in the Codehaus Wiki that can be edited by users:
>
> http://docs.codehaus.org/display/MAVENUSER/FAQs
>
> However, I think that the FAQ is a bit unstructured and needs some work
> (see
> my previous post "Time to put some structure to Maven User FAQ on Wiki?"
> on
> Maven User:
>
> http://www.nabble.com/Time-to-put-some-structure-to-Maven-User-FAQ-on-Wiki--tf2174095.html#a6012932
> )
>
> So, why not continue on documentation there the Maven Recipes there
> instead.
>
> Start something like "Maven User Documentation by Maven Users":
>
> - FAQ (the FAQ can link to Maven Recipies when needed)
> - Maven Recipies
> - ...
>
> Finally, a lot of people - including myself - seem to have been struggling
> somewhat setting up Maven. Usually looking for documentation in 3-4
> different places etc. I think that we all can agree on that,
> but what is that we are looking for? These things should go into "Maven
> User
> Documentation by Maven Users" and hopefully some of things will highlight
> common issues for the Maven Team and allow them to improve official
> documentation, the book etc.
>
> Regards,
> Jimisola
>
>
> Brett Porter wrote:
> >
> > That's quite cool, and along the lines of what we discussed setting up
> > as the cookbook which would be blended into the site in the doc
> > discussions back in June on the dev@ list (I've reposted some links
> > for that recently if folks are interested in helping out with docs).
> >
> >
> http://mail-archives.apache.org/mod_mbox/maven-dev/200608.mbox/%3cFA7FB3F2-C1BD-4792-99F6-5F130DC20A38@apache.org%3e
> >
> > On 30/08/06, Rune Flobakk <rf...@online.no> wrote:
> >> Eric Redmond wrote:
> >> > I've began brainstorming on my little private wiki, if you care to
> >> peek:
> >> > http://www.propellors.net/wiki/index.php?title=Maven_Recipes
> >>
> >> Thanks for this link! Saved for future reference :)
> >>
> >>
> >> Rune
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Apache Maven - http://maven.apache.org
> > "Better Builds with Maven" book - http://library.mergere.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6068869
> Sent from the Maven - Users forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Eric Redmond
http://codehaus.org/~eredmond

Re: [POLL] Why switch to Maven?

[Jimisola Laursen <li...@jimisola.com>]

(slightly of the initial topic but...)

Hold on, hold on...

Can't we try to keep the documentation in one place? And thereby make it
easier to find.

I think that Maven Recipes is great idea, but (always a but) it's off
Maven's site.

There is a FAQ in the Codehaus Wiki that can be edited by users:

http://docs.codehaus.org/display/MAVENUSER/FAQs

However, I think that the FAQ is a bit unstructured and needs some work (see
my previous post "Time to put some structure to Maven User FAQ on Wiki?" on
Maven User:
http://www.nabble.com/Time-to-put-some-structure-to-Maven-User-FAQ-on-Wiki--tf2174095.html#a6012932)

So, why not continue on documentation there the Maven Recipes there instead.

Start something like "Maven User Documentation by Maven Users":

 - FAQ (the FAQ can link to Maven Recipies when needed)
 - Maven Recipies
 - ...

Finally, a lot of people - including myself - seem to have been struggling
somewhat setting up Maven. Usually looking for documentation in 3-4
different places etc. I think that we all can agree on that,
but what is that we are looking for? These things should go into "Maven User
Documentation by Maven Users" and hopefully some of things will highlight
common issues for the Maven Team and allow them to improve official
documentation, the book etc.

Regards,
Jimisola


Brett Porter wrote:
> 
> That's quite cool, and along the lines of what we discussed setting up
> as the cookbook which would be blended into the site in the doc
> discussions back in June on the dev@ list (I've reposted some links
> for that recently if folks are interested in helping out with docs).
> 
> http://mail-archives.apache.org/mod_mbox/maven-dev/200608.mbox/%3cFA7FB3F2-C1BD-4792-99F6-5F130DC20A38@apache.org%3e
> 
> On 30/08/06, Rune Flobakk <rf...@online.no> wrote:
>> Eric Redmond wrote:
>> > I've began brainstorming on my little private wiki, if you care to
>> peek:
>> > http://www.propellors.net/wiki/index.php?title=Maven_Recipes
>>
>> Thanks for this link! Saved for future reference :)
>>
>>
>> Rune
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> 
> 
> -- 
> Apache Maven - http://maven.apache.org
> "Better Builds with Maven" book - http://library.mergere.com/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6068869
Sent from the Maven - Users forum at Nabble.com.


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

Re: [POLL] Why switch to Maven?

[Jan Vissers <Ja...@cumquat.nl>]

"Maven to me (still) looks like a great tool for single module 
applications/libraries - but not so much for big(ger) multi module apps. "
--> When reporting is concerned.

Jan Vissers wrote:
> The really bad documentation is already mentioned, and rightly so!
> Also, I feel for multi module projects (every meaningful JEE project) 
> the reporting part is really awful.
> There is no consistency in the reporting plugins.
>
> Maven to me (still) looks like a great tool for single module 
> applications/libraries - but not so much for big(ger) multi module apps.
>
> Eric Redmond wrote:
>> Hi all Maven users!
>>
>> I'm beginning a study to outline the real reasons that people have for
>> avoiding Maven. My questions to you all are:
>> What were your anxieties about using Maven? If you use Maven: what 
>> helped
>> you make the decision? If you don't: why did you avoid it?
>>
>> Here are some that I have heard in the past:
>>
>> * Lack of good documentation.
>> * Community unwilling to help me with my problems.
>> * Not "industry supported" or "mainstream" enough.
>> * I don't like conforming to the Maven project layout.
>> * My project is too complex to switch.
>> * There are not enough plugins available.
>> * We already have a large investement in tool X.
>> * I have to build native/non-Java code.
>>
>> Any more reasons? Care to expand these ideas?
>> Thanks for your help!
>> ____
>> Eric Redmond
>> http://codehaus.org/~eredmond
>>
>
>
> ---------------------------------------------------------------------
> 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: [POLL] Why switch to Maven?

[Jan Vissers <Ja...@cumquat.nl>]

The really bad documentation is already mentioned, and rightly so!
Also, I feel for multi module projects (every meaningful JEE project) 
the reporting part is really awful.
There is no consistency in the reporting plugins.

Maven to me (still) looks like a great tool for single module 
applications/libraries - but not so much for big(ger) multi module apps.

Eric Redmond wrote:
> Hi all Maven users!
>
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what helped
> you make the decision? If you don't: why did you avoid it?
>
> Here are some that I have heard in the past:
>
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
>
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond
>


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

Re: [POLL] Why switch to Maven?

[Eric Redmond <er...@gmail.com>]

On 8/30/06, Pierre-Yves Saumont <py...@volga.fr> wrote:
>
> I switched to Maven 2 because I was tired of Ant.
>
> When one looks at a good Java project, one can find its way easyly
> because there are well known architecturing and coding standards. There
> are no such things with Ant. I remember trying to find my way in Ant
> scripts calling other Ant scripts, and that was kind of a nightmare.
> (Even with scripts I had written myself few monthes before :-)
>
> Maven is exactly what I need. The maven way to do things might not be
> the best way, but it is consistent. Consistency is much more valuable
> than anything else. It is what I like the most in Java, and it is what I
> like in Maven.
>
> The big problem is documentation. The Merger book is a good
> introduction, but it does not help very much to do your own work because
> as soon as you need something a bit different from the example, your are
> alone.
>
> I learned the most from two chanels : The Maven 1 documentation (many
> things work the same) and looking at Poms in other projects. (For
> example Wicket).
>
> What is urgently needed (IMO) is a Reference documentation with the list
> of all configuration options and all possible values.
>
> I decided to spend 6 week to learn Wicket, Maven 2 and EJB3 before I
> start my next project. Until now, I am very satisfied with Wicket and
> Maven 2. What I miss the most is aggregation. Some reports seems not to
> aggregate at all, somes have problems (aggregating Javadoc AND Xref). I
> also have problems to understand complicated transitive dependencies (I
> ou're using JBoss, you better be sure that there is not a wrong version
> of a jar in the classpath ;-)


Yeah, I have endless problems fighting with JBoss. So much so, that I
created a plugin at work that does the following:

product:deploy-files:
Recurse through a project (well, directory structure) and deploy all
jars,wars,ears (anything requested) to a repository w/ the same groupId and
version number (presumably the gID/version of the project, such as jboss:
4.0.4)

product:product / deploy
Generates an assembly for the remaining files (xml, directories, etc) and
builds a zip of the product with a pom, so you can deploy it to a reposiory.

product:install
Grabs the product (zip) from the repository and unpackages it to the given
directory.

What I was thinking here was a sort of "Mavenized" APT or MSI for installing
specific versions of an entire product. I'm not certain if it is an
abomination against nature, or has any merit at all (naturally, there can be
problems with exact copies of artifacts under different coordinates, eg.,
jboss:junit:4.0.4 vs junit:junit:4.0 ).


Pierre-Yves
>
> Eric Redmond a écrit :
> > Hi all Maven users!
> >
> > I'm beginning a study to outline the real reasons that people have for
> > avoiding Maven. My questions to you all are:
> > What were your anxieties about using Maven? If you use Maven: what
> helped
> > you make the decision? If you don't: why did you avoid it?
> >
> > Here are some that I have heard in the past:
> >
> > * Lack of good documentation.
> > * Community unwilling to help me with my problems.
> > * Not "industry supported" or "mainstream" enough.
> > * I don't like conforming to the Maven project layout.
> > * My project is too complex to switch.
> > * There are not enough plugins available.
> > * We already have a large investement in tool X.
> > * I have to build native/non-Java code.
> >
> > Any more reasons? Care to expand these ideas?
> > Thanks for your help!
> > ____
> > Eric Redmond
> > http://codehaus.org/~eredmond
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Eric Redmond
http://codehaus.org/~eredmond

Re: [POLL] Why switch to Maven?

[Wilfred Springer <wi...@tomtom.com>]

With all people being unsatisfied with the Maven documentation, it
sounds like an excellent opportunity for a new open source project; it
would allow lots of people to scratch their itch.

And the cool thing is, we could create the book entirely using Maven and
the Docbkx Maven Plugin 
<shameless-advertisement>http://www.agilejava.com/docbkx/</shameless-advertisement>. We would just have a boodstrapping problem: in order to make the Docbkx Maven Plugin available for erveryone it would need to be uploaded to the Maven repository, but that appears to be quite hard: it involves using rsync instead of the bundle plugin, and using rsync to synchronize with the central repository isn't documented anywhere.....


ed, 2006-08-30 at 12:57 +0200, Pierre-Yves Saumont wrote:

> I switched to Maven 2 because I was tired of Ant.
> 
> When one looks at a good Java project, one can find its way easyly 
> because there are well known architecturing and coding standards. There 
> are no such things with Ant. I remember trying to find my way in Ant 
> scripts calling other Ant scripts, and that was kind of a nightmare. 
> (Even with scripts I had written myself few monthes before :-)
> 
> Maven is exactly what I need. The maven way to do things might not be 
> the best way, but it is consistent. Consistency is much more valuable 
> than anything else. It is what I like the most in Java, and it is what I 
> like in Maven.
> 
> The big problem is documentation. The Merger book is a good 
> introduction, but it does not help very much to do your own work because 
> as soon as you need something a bit different from the example, your are 
> alone.
> 
> I learned the most from two chanels : The Maven 1 documentation (many 
> things work the same) and looking at Poms in other projects. (For 
> example Wicket).
> 
> What is urgently needed (IMO) is a Reference documentation with the list 
> of all configuration options and all possible values.
> 
> I decided to spend 6 week to learn Wicket, Maven 2 and EJB3 before I 
> start my next project. Until now, I am very satisfied with Wicket and 
> Maven 2. What I miss the most is aggregation. Some reports seems not to 
> aggregate at all, somes have problems (aggregating Javadoc AND Xref). I 
> also have problems to understand complicated transitive dependencies (I 
> ou're using JBoss, you better be sure that there is not a wrong version 
> of a jar in the classpath ;-)
> 
> Pierre-Yves
> 
> Eric Redmond a écrit :
> > Hi all Maven users!
> > 
> > I'm beginning a study to outline the real reasons that people have for
> > avoiding Maven. My questions to you all are:
> > What were your anxieties about using Maven? If you use Maven: what helped
> > you make the decision? If you don't: why did you avoid it?
> > 
> > Here are some that I have heard in the past:
> > 
> > * Lack of good documentation.
> > * Community unwilling to help me with my problems.
> > * Not "industry supported" or "mainstream" enough.
> > * I don't like conforming to the Maven project layout.
> > * My project is too complex to switch.
> > * There are not enough plugins available.
> > * We already have a large investement in tool X.
> > * I have to build native/non-Java code.
> > 
> > Any more reasons? Care to expand these ideas?
> > Thanks for your help!
> > ____
> > Eric Redmond
> > http://codehaus.org/~eredmond
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

Wilfred Springer | Software Architect | TomTom |
wilfred.springer@tomtom.com | +31 646 720 990

Re: [POLL] Why switch to Maven?

[Pierre-Yves Saumont <py...@volga.fr>]

I switched to Maven 2 because I was tired of Ant.

When one looks at a good Java project, one can find its way easyly 
because there are well known architecturing and coding standards. There 
are no such things with Ant. I remember trying to find my way in Ant 
scripts calling other Ant scripts, and that was kind of a nightmare. 
(Even with scripts I had written myself few monthes before :-)

Maven is exactly what I need. The maven way to do things might not be 
the best way, but it is consistent. Consistency is much more valuable 
than anything else. It is what I like the most in Java, and it is what I 
like in Maven.

The big problem is documentation. The Merger book is a good 
introduction, but it does not help very much to do your own work because 
as soon as you need something a bit different from the example, your are 
alone.

I learned the most from two chanels : The Maven 1 documentation (many 
things work the same) and looking at Poms in other projects. (For 
example Wicket).

What is urgently needed (IMO) is a Reference documentation with the list 
of all configuration options and all possible values.

I decided to spend 6 week to learn Wicket, Maven 2 and EJB3 before I 
start my next project. Until now, I am very satisfied with Wicket and 
Maven 2. What I miss the most is aggregation. Some reports seems not to 
aggregate at all, somes have problems (aggregating Javadoc AND Xref). I 
also have problems to understand complicated transitive dependencies (I 
ou're using JBoss, you better be sure that there is not a wrong version 
of a jar in the classpath ;-)

Pierre-Yves

Eric Redmond a écrit :
> Hi all Maven users!
> 
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what helped
> you make the decision? If you don't: why did you avoid it?
> 
> Here are some that I have heard in the past:
> 
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
> 
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond
> 


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

Re: Re: [POLL] Why switch to Maven?

[Torsten Curdt <tc...@apache.org>]

Ok ...well, then let me also sum up my pain points with maven2 over here.

o It updates itself and you might end up having different behaviours
across different installation. This should be fixable by an
appropriate release handling. SNAPSHOT dependencies should not be
allowed for a release plugin. The default should be: only update maven
plugins on explicit request.

o The stdout is just horrible and quite often disguises the actual
root cause of failures in noise. The log level is more annoying than
useful. There is a difference between a stdout and a log file. (What
is it with all these "------------------"?)

o It's just not clear what goals/plugins are available. Forcing
something like "svn help diff" style help for all plugins would be
nice, too.

o Reporting for multimodule projects is just horrible inconsistent and
doesn't even work with many plugins. IMO every report plugin should be
*required* to implement an appropriate interface to support report
aggregation.

o Too much magic in the reporting section. If you leave out all the
reports you get the default reports. You have to explicitly turn them
off. Not straight forward. Especially annoying in a multimodule setup.

o Downloads are not getting verified. I had it a couple of times that
a mirror was broken and instead of poms or jars I ended up with html
...which screwed up my local repo. Cleaning up the repo was tedious
...so I ended up deleting my whole .m2/repository folder and
re-download all!

o Single artifact per pom. This concept pushes projects that only want
modules based plugability into a multiproject setup, sometimes
creating unnatural separations. A common test module to work around
shared testcode is one example, this and attached artifacts further
blur the concept. A general over-modularization is what happens. (how
many maven artifacts are there?)

o Make surefire settings 'printSummary' -> false and 'reportFormat' ->
plain the default

o Absolutely don't understand why a parent pom cannot generate an artifact

o The eclipse plugin is a first step ...but needs further fixes and work.

o Would be great to do the downloads of all transitive deps before
*any* builds are starting. A bit more the "apt-get" style "I will
download these artifacts". Half way through the build trying and
failing to download an required artifact is annoying.


In general maven2 is a great idea but feels much more complex than
maven1 ...which is not exactly a good selling point. The
implementation itself is ok as long as you deal with small and easy
projects. Then it helps to save time. As soon as the projects become
bigger and more complex it becomes a pain to work with. Go an try to
build cocoon trunk for example.

In the end I am much less enthusiastic. I cannot say it helped me to
save much time anymore. (Spent way too many hours on the multiproject
stuff) But I like the ideas and as I don't really want to go back to
"ant" there is not much else I can do but sticking with maven. Just
hope things will get better ...soon.

cheers
--
Torsten

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

Re: [POLL] Why switch to Maven?

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

Jan Vissers wrote:

>>> Maven's key strength is to say "don't worry about trying to build a jar /
>>> war / ear / sync with eclipse / autorun tests / publish javadocs / etc /
>>> etc, because I already know how to do that, you go and do what you do
>>> best, work on the primary code".
> 
> I would like this approach very much, but...
> have you tried to publish javadocs/jxr/surefire/pmd... etc
> for a multimodule project in an aggregated fashion?

To me, the bigger picture of installing a long term effective build 
strategy is significantly more important than publishing aggregated 
reports, a problem likely to go away as soon as a bugfix is released.

I have also encountered significant problems with maven2, and have been 
quite critical about them, but the underlying design infrastructure 
underneath maven2 is sound, and this is very important for a project to 
be built on.

Regards,
Graham
--

Re: [POLL] Why switch to Maven?

[Ralph Pöllath <li...@poellath.org>]

On 30.08.2006, at 11:43, Emmanuel Venisse wrote:
> Jan Vissers a écrit :
>>>> Maven's key strength is to say "don't worry about trying to  
>>>> build a jar /
>>>> war / ear / sync with eclipse / autorun tests / publish  
>>>> javadocs / etc /
>>>> etc, because I already know how to do that, you go and do what  
>>>> you do
>>>> best, work on the primary code".
>> I would like this approach very much, but...
>> have you tried to publish javadocs/jxr/surefire/pmd... etc
>> for a multimodule project in an aggregated fashion?
>
> It's implemented in snapshot version of javadocs/jxr plugins

Sorry, but that doesn't help me now. Maven2 has officially been  
stable for months now, so I expect its advertised features to work  
out of the box. Same with Continuum BTW - I've looked at it several  
times since it went final 10 months ago, but it's just not there yet.

Is there a roadmap indicating when said functionality will be  
available in a stable release?

On 30.08.2006, at 07:37, Jan Vissers wrote:
> More and more I'm getting the feeling that ANT still isn't such a  
> bad idea for building software. You can do a lot of the convention  
> over configuration stuff for your own projects with ant and things  
> like macrodef, subant and antlib. For dependency management we're  
> currently using Ivy - which is pretty descent. What's more the  
> reporting just works, even aggregated  
> (pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss).

The difference is that in contrast to Maven2, Ant has been adopted by  
IDEs and tools. Ant is a de-facto standard, and Maven2 a self- 
declared standard. I'm not saying adoption isn't going to happen, but  
it will take time.

IDE integration is actually a key point for me personally. m2eclipse  
looks very promising, but it won't work right until some bugs in  
Maven2's embedder get fixed (or so I hear). Lots of people a  
desperately waiting for this, and nothing seems to happen. This is  
very frustrating.

On 30.08.2006, at 02:52, Tamás Cservenák wrote:
> The core (maven itself, not remote repo
> contents) was always sound. Just run M2 in isolated environment  
> with clean
> and properly filled POM's, without central and M2 will blow all  
> your needs!

Yeah right, all the problems are with plugins. Unfortunately, all the  
functionality I need is implemented in plugins! A rock stable core  
just won't help me if it doesn't do anything except orchestrate the  
unstable plugins.

The "everything is a plugin" architecture might be very nice on a  
technical level, but it can lead to the equivalent of DLL hell - just  
look at Eclipse! Eclipse is actually trying to improve this with  
Callisto, maybe a similar initiative would be appropriate for Maven2?

That said, I think that Maven2 really is a step forward and I'm not  
going back. Thanks to everyone working on Maven2 and sorry for  
sounding so negative!

Cheers,
-Ralph.


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

Re: [POLL] Why switch to Maven?

[Wim Deblauwe <wi...@gmail.com>]

>
> > I would like this approach very much, but...
> > have you tried to publish javadocs/jxr/surefire/pmd... etc
> > for a multimodule project in an aggregated fashion?
>
> It's implemented in snapshot version of javadocs/jxr plugins
>



I'm currently still on Maven 1, but I see this also as a Maven 2 problem:
plugins stay in snapshot state too long. I see many times questions asked on
the mailing list that are responded with "already fixed in the snapshot
version". Can't the Maven developers publish a new version faster? Maybe
they want to wait too long until *all known* bugs are fixed?

Wim

Re: [POLL] Why switch to Maven?

[Emmanuel Venisse <em...@venisse.net>]

Jan Vissers a écrit :
>>> Maven's key strength is to say "don't worry about trying to build a jar /
>>> war / ear / sync with eclipse / autorun tests / publish javadocs / etc /
>>> etc, because I already know how to do that, you go and do what you do
>>> best, work on the primary code".
> 
> I would like this approach very much, but...
> have you tried to publish javadocs/jxr/surefire/pmd... etc
> for a multimodule project in an aggregated fashion?

It's implemented in snapshot version of javadocs/jxr plugins

Emmanuel

> 
>> On Wed, August 30, 2006 7:37 am, Jan Vissers wrote:
>>
>>> I'm reading a lot of "we need about x weeks to convert to maven", "the
>>> learning curve is steep", "it is messy but it works", "if it cannot be
>>> done we can use ant"...
>>>
>>> More and more I'm getting the feeling that ANT still isn't such a bad
>>> idea for building software. You can do a lot of the convention over
>>> configuration stuff for your own projects with ant and things like
>>> macrodef, subant and antlib. For dependency management we're currently
>>> using Ivy - which is pretty descent. What's more the reporting just
>>> works, even aggregated
>>> (pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss).
>>>
>>> Can somebody tell me what the main reason would be for changing from ANT
>>> to Maven?
>>> I'm starting to get serious doubts.
>> I recently got involved in a project whose build system uses ant + ivy,
>> and to sum it up: what an inefficient mess.
>>
>> Within themselves, ant and ivy are worthy tools, that perform their tasks
>> well. The real problem is that once developers get hold of them, things
>> quickly go pear shaped.
>>
>> The key biggest problem with the ant + ivy combo is the fact that
>> developing the build system is a secondary concern, the primary concern
>> being developing the software itself. This causes numerous problems,
>> including:
>>
>> - ant scripts are often half finished.
>>
>> In this project, nobody bothered to take advantage of incremental builds.
>> Any attempt to build, will build clean - a huge time waster.
>>
>> - ant scripts are almost always riddled with hard coded paths, and
>> developer specific customisations.
>>
>> In this project, that means that every developer has to set up their
>> development environment the same way as the other developers, which may
>> seem perfectly acceptable to some, until you realise that developers don't
>> just work on one project.
>>
>> This makes it difficult / impossible to introduce continuous integration
>> techniques, despite this particular project desperately needing it.
>>
>> - ant scripts are often riddled with relative paths to other projects,
>> where it is assumed a sister project is checked out.
>>
>> Again, this prevents continuous integration from being possible.
>>
>> - ivy dependencies are often set up by developers who fiddle until they
>> work.
>>
>> In this project, the eclipse jars were removed from their plugins, had
>> their version numbers removed, and dumped into one big ivy dependency
>> called "eclipse". There is no way of knowing what jar offers what
>> functionality, because the jars are called sac.jar, core.jar, etc.
>>
>> Upgrading the jars (to take advantage of a bugfix, for example) in this
>> project is very impractical.
>>
>> To sum up the above:
>>
>> Giving developers the power to "do what they want", simply means that
>> developers are given the power to do something badly, or not at all.
>>
>> Build systems are always secondary to the primary code, and do not receive
>> proper attention from developers, and this wastes copious amounts of time,
>> and therefore money.
>>
>> Maven's key strength is to say "don't worry about trying to build a jar /
>> war / ear / sync with eclipse / autorun tests / publish javadocs / etc /
>> etc, because I already know how to do that, you go and do what you do
>> best, work on the primary code".
>>
>> Regards,
>> Graham
>> --
>>
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> 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: [POLL] Why switch to Maven?

[Jan Vissers <Ja...@cumquat.nl>]

>>Maven's key strength is to say "don't worry about trying to build a jar /
>>war / ear / sync with eclipse / autorun tests / publish javadocs / etc /
>>etc, because I already know how to do that, you go and do what you do
>>best, work on the primary code".

I would like this approach very much, but...
have you tried to publish javadocs/jxr/surefire/pmd... etc
for a multimodule project in an aggregated fashion?

> On Wed, August 30, 2006 7:37 am, Jan Vissers wrote:
>
>> I'm reading a lot of "we need about x weeks to convert to maven", "the
>> learning curve is steep", "it is messy but it works", "if it cannot be
>> done we can use ant"...
>>
>> More and more I'm getting the feeling that ANT still isn't such a bad
>> idea for building software. You can do a lot of the convention over
>> configuration stuff for your own projects with ant and things like
>> macrodef, subant and antlib. For dependency management we're currently
>> using Ivy - which is pretty descent. What's more the reporting just
>> works, even aggregated
>> (pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss).
>>
>> Can somebody tell me what the main reason would be for changing from ANT
>> to Maven?
>> I'm starting to get serious doubts.
>
> I recently got involved in a project whose build system uses ant + ivy,
> and to sum it up: what an inefficient mess.
>
> Within themselves, ant and ivy are worthy tools, that perform their tasks
> well. The real problem is that once developers get hold of them, things
> quickly go pear shaped.
>
> The key biggest problem with the ant + ivy combo is the fact that
> developing the build system is a secondary concern, the primary concern
> being developing the software itself. This causes numerous problems,
> including:
>
> - ant scripts are often half finished.
>
> In this project, nobody bothered to take advantage of incremental builds.
> Any attempt to build, will build clean - a huge time waster.
>
> - ant scripts are almost always riddled with hard coded paths, and
> developer specific customisations.
>
> In this project, that means that every developer has to set up their
> development environment the same way as the other developers, which may
> seem perfectly acceptable to some, until you realise that developers don't
> just work on one project.
>
> This makes it difficult / impossible to introduce continuous integration
> techniques, despite this particular project desperately needing it.
>
> - ant scripts are often riddled with relative paths to other projects,
> where it is assumed a sister project is checked out.
>
> Again, this prevents continuous integration from being possible.
>
> - ivy dependencies are often set up by developers who fiddle until they
> work.
>
> In this project, the eclipse jars were removed from their plugins, had
> their version numbers removed, and dumped into one big ivy dependency
> called "eclipse". There is no way of knowing what jar offers what
> functionality, because the jars are called sac.jar, core.jar, etc.
>
> Upgrading the jars (to take advantage of a bugfix, for example) in this
> project is very impractical.
>
> To sum up the above:
>
> Giving developers the power to "do what they want", simply means that
> developers are given the power to do something badly, or not at all.
>
> Build systems are always secondary to the primary code, and do not receive
> proper attention from developers, and this wastes copious amounts of time,
> and therefore money.
>
> Maven's key strength is to say "don't worry about trying to build a jar /
> war / ear / sync with eclipse / autorun tests / publish javadocs / etc /
> etc, because I already know how to do that, you go and do what you do
> best, work on the primary code".
>
> Regards,
> Graham
> --
>
>
>



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

Re: [POLL] Why switch to Maven?

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

On Wed, August 30, 2006 7:37 am, Jan Vissers wrote:

> I'm reading a lot of "we need about x weeks to convert to maven", "the
> learning curve is steep", "it is messy but it works", "if it cannot be
> done we can use ant"...
>
> More and more I'm getting the feeling that ANT still isn't such a bad
> idea for building software. You can do a lot of the convention over
> configuration stuff for your own projects with ant and things like
> macrodef, subant and antlib. For dependency management we're currently
> using Ivy - which is pretty descent. What's more the reporting just
> works, even aggregated
> (pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss).
>
> Can somebody tell me what the main reason would be for changing from ANT
> to Maven?
> I'm starting to get serious doubts.

I recently got involved in a project whose build system uses ant + ivy,
and to sum it up: what an inefficient mess.

Within themselves, ant and ivy are worthy tools, that perform their tasks
well. The real problem is that once developers get hold of them, things
quickly go pear shaped.

The key biggest problem with the ant + ivy combo is the fact that
developing the build system is a secondary concern, the primary concern
being developing the software itself. This causes numerous problems,
including:

- ant scripts are often half finished.

In this project, nobody bothered to take advantage of incremental builds.
Any attempt to build, will build clean - a huge time waster.

- ant scripts are almost always riddled with hard coded paths, and
developer specific customisations.

In this project, that means that every developer has to set up their
development environment the same way as the other developers, which may
seem perfectly acceptable to some, until you realise that developers don't
just work on one project.

This makes it difficult / impossible to introduce continuous integration
techniques, despite this particular project desperately needing it.

- ant scripts are often riddled with relative paths to other projects,
where it is assumed a sister project is checked out.

Again, this prevents continuous integration from being possible.

- ivy dependencies are often set up by developers who fiddle until they work.

In this project, the eclipse jars were removed from their plugins, had
their version numbers removed, and dumped into one big ivy dependency
called "eclipse". There is no way of knowing what jar offers what
functionality, because the jars are called sac.jar, core.jar, etc.

Upgrading the jars (to take advantage of a bugfix, for example) in this
project is very impractical.

To sum up the above:

Giving developers the power to "do what they want", simply means that
developers are given the power to do something badly, or not at all.

Build systems are always secondary to the primary code, and do not receive
proper attention from developers, and this wastes copious amounts of time,
and therefore money.

Maven's key strength is to say "don't worry about trying to build a jar /
war / ear / sync with eclipse / autorun tests / publish javadocs / etc /
etc, because I already know how to do that, you go and do what you do
best, work on the primary code".

Regards,
Graham
--



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

Re: [POLL] Why switch to Maven?

[Jan Vissers <Ja...@cumquat.nl>]

I'm reading a lot of "we need about x weeks to convert to maven", "the 
learning curve is steep", "it is messy but it works", "if it cannot be 
done we can use ant"...

More and more I'm getting the feeling that ANT still isn't such a bad 
idea for building software. You can do a lot of the convention over 
configuration stuff for your own projects with ant and things like 
macrodef, subant and antlib. For dependency management we're currently 
using Ivy - which is pretty descent. What's more the reporting just 
works, even aggregated 
(pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss).

Can somebody tell me what the main reason would be for changing from ANT 
to Maven?
I'm starting to get serious doubts.

Eric Redmond wrote:
> Hi all Maven users!
>
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what helped
> you make the decision? If you don't: why did you avoid it?
>
> Here are some that I have heard in the past:
>
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
>
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond
>


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

Re: [POLL] Why switch to Maven?

[RedBugz Software <re...@gmail.com>]

On 8/29/06, Eric Redmond <er...@gmail.com> wrote:
>
> Here are some that I have heard in the past:
>
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
>
> Any more reasons? Care to expand these ideas?
>

Things that keep getting in my way:
- IDE support!! (or lack thereof), apparently the m2eclipse team can't seem
to get a decent Maven embedder to build on, and the embedder seems to run
differently than m2. Getting consistent builds from both an IDE (without
using external tools) and automated build tool is problematic
- plugins aren't mature enough, too many bugs, not enough documentation, or
it's hard to find the documentation because you're not sure if the problem
is in maven core or a maven plugin, so you wander all over the place looking
for answers
- M2 does not seem ready for what I would call casual users, those who want
to just download, setup some basic config and go. If I may make a poor and
overdone analogy, but it's more like Linux than Mac--more figuring out stuff
on your own with lots of config of disconnected parts instead of "it just
works" all together and integrated.
- seems like archetypes should be used more and easier to use, but they're
not. There seems to be a lack of good working example projects (beyond the
trivial), though maybe I'm just not looking in the right places
- for some corporate developers surrounded by firewalls, proxies,
locked-down environments, bureaucracy, inane policies, access controls all
over the place, non-standard configurations, lots of integration with legacy
stuff, etc., you just can't quite get enough set up easily before you give
up and decide to try again in 6 months :(

M2 seems to work well for simple and straightforward projects where the
basic POM is mostly sufficient. For those very large and complicated
projects there seems to be enough win to actually dive in and spend the time
getting to know M2 intimately so the ROI is worth it. Most of the projects I
work on are somewhere in between, just complicated enough that they don't
work out of the box, but not quite complicated enough to justify spending
the hours it takes to figure out how to get it to work in our particular
environment.

I understand it's open source and I don't like complaining when I'm not able
to step in and contribute to the solutions, so I end up just not using it
much even though I want to. Over time, I'm sure I'll use it more as I learn
it bit by bit or the functionality gets more robust.

Logan

Re: [POLL] Why switch to Maven?

[Jason van Zyl <ja...@maven.org>]

On 29 Aug 06, at 1:55 PM 29 Aug 06, Eric Redmond wrote:

> Hi all Maven users!
>
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what  
> helped
> you make the decision? If you don't: why did you avoid it?
>

This is very cool, thanks Eric for being curious.

After reading a bunch of comments I just wanted to say a couple of  
things.

As far as the documentation goes, yes the organization is abysmal and  
the content is lacking. For the plugin we have created the docck  
plugin which makes sure there is a minimum standard with respect to  
plugin documentation and a lot of the plugins have been improved and  
we're in the process of publishing it all.

As far as plugin releases go there are a couple new efforts that  
we've started. The first thing we've done, with the help of David  
Blevins and his Swizzle code, is to produce a little report like this:

http://people.apache.org/~jvanzyl/report.txt

This will be spruced up but it gives an idea of how many votes each  
plugin project has. We can see the biggies are the Eclipse, Release,  
Surefire, and Assembly plugins. Fabrizio is working on the Eclipse  
plugin, Jeremy is working on the Release plugin, John is working on  
the Assembly plugin and I'm going to try and release the Surefire  
plugin next week. We haven't effectively used the voting mechanism in  
JIRA but we'll generate this report each week so your votes will be  
counted and we will use those as a guide to select what we should  
focus on.

We have also open up an Apache wide sandbox where any Apache  
committer who wants to help out can do so easily. Jeremy is using  
this mechanism to work on the release plugin for us, and Jochen is  
working on the Changes plugin for us. So hopefully those of you who  
are Apache committers can just jump in and help out. For plugins at  
the Mojo@Codehaus project we have also setup a sandbox to try and  
absorb user contributions more easily.

The documentation will take a more organized effort but we are trying  
to improve the situation.

Thanks,

Jason van Zyl
jason@maven.org




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

Re: directory v. outputDirectory

[dan tran <da...@gmail.com>]

you are always welcome to provide patch ;-)


1. svn repo

2 and 3 point to the same snapshot repository

-D


On 9/6/06, Jimisola Laursen <li...@jimisola.com> wrote:
>
>
> Hi!
>
> Asked in the #maven recently about the maven-dependency-plugin.
> There are a lot of reported issues, but there don't seem to be any
> development activity according to Jira's "Recently resolved". Does anyone
> here now?
> I have a particular interest in "Make (sure) dependency:resolve outputs
> absolute filename (or at least make it configurable)"
> (http://jira.codehaus.org/browse/MDEP-29) to allow us to use the plugin to
> create our installer.
> It might be that it already works that way, but I haven't been able to
> find
> 2.0-SNAPSHOT before.
>
> Also, may I ask about the difference in the two (2!) repos that have been
> mentioned and the people one:
>
> 1.
>
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin/
> 2. http://people.apache.org/maven-snapshot-repository/
> 3. http://svn.apache.org/maven-snapshot-repository
>
> Regards,
> Jimisola
>
>
>
> dan tran wrote:
> >
> > a snapshot of this plugin is at
> >
> > http://people.apache.org/maven-snapshot-repository/
> >
> > you can build the plugin yourself as well.
> >
> > -D
> >
> >
> > On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
> >>
> >> Failed to resolve this artifact
> >>
> >>       <groupId>org.apache.maven.plugins</groupId>
> >>       <artifactId>maven-dependency-plugin</artifactId>
> >>       <version>2.0-SNAPSHOT</version>
> >>
> >> Brad
> >>
> >> > -----Original Message-----
> >> > From: dan tran [mailto:dantran@gmail.com]
> >> > Sent: Tuesday, September 05, 2006 5:23 PM
> >> > To: Maven Users List
> >> > Subject: Re: directory v. outputDirectory
> >> >
> >> >
> >> > please note that depenency-maven-plugin has been accepted
> >> > into apache.  It
> >> > is now at
> >> >
> >> > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-depe
> >> > ndency-plugin/
> >> >
> >> > The more ppl using this new plugin, the more chance we can
> >> > get it released
> >> > ;-)
> >> >
> >> > -D
> >> >
> >> > On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
> >> > >
> >> > > org.codehaus.plugins:dependency-maven-plugin works.
> >> > >
> >> > > Thanks.
> >> > >
> >> > > Brad
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: dantran@gmail.com [mailto:dantran@gmail.com]
> >> > > > Sent: Tuesday, September 05, 2006 1:30 PM
> >> > > > To: Maven Users List
> >> > > > Subject: Re: directory v. outputDirectory
> >> > > >
> >> > > >
> >> > > > Brad, you can use a combination of assembly and dependency
> >> > > > plugin to copy
> >> > > > final built artfacts into a single
> >> > > > directory the way you want it it and have assembly to zip(
> >> > > > tgz, etc) them
> >> > > > up.
> >> > > >
> >> > > > Use a separate maven project for that purpose.
> >> > > >
> >> > > > -Dan
> >> > > >
> >> > > >
> >> > > > On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
> >> > > > >
> >> > > > > Can you define multiple source directories?
> >> > > > >
> >> > > > > I am guessing that transitive dependencies aren't
> >> > getting linked in?
> >> > > > >
> >> > > > > D-
> >> > > > >
> >> > > > > -----Original Message-----
> >> > > > > From: Brad Harper
> >> > > > > Sent: Tuesday, September 05, 2006 12:25 PM
> >> > > > > To: users
> >> > > > > Subject: RE: directory v. outputDirectory
> >> > > > >
> >> > > > > The libraries will be built as a mixture of .lib and
> >> > .dll files (on
> >> > > > > Windows)
> >> > > > > and .a and .so archives (on *nix platforms).
> >> > > > >
> >> > > > > Brad
> >> > > > >
> >> > > > > > -----Original Message-----
> >> > > > > > From: Douglas Ferguson
> >> > > > > > Sent: Tuesday, September 05, 2006 11:36 AM
> >> > > > > > To: users
> >> > > > > > Subject: RE: directory v. outputDirectory
> >> > > > > >
> >> > > > > >
> >> > > > > > What format must the archive be in?
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > -----Original Message-----
> >> > > > > > From: Brad Harper
> >> > > > > > Sent: Tuesday, September 05, 2006 10:02 AM
> >> > > > > > To: users
> >> > > > > > Subject: RE: directory v. outputDirectory
> >> > > > > >
> >> > > > > > Dan:
> >> > > > > >
> >> > > > > > My intent is to have copies of a set of archive libraries
> >> > > > collected
> >> > > > > > into a single directory. The libraries are sibling
> >> > > > modules of a parent
> >> > > > > > project.
> >> > > > > >
> >> > > > > > Each library could be copied into the target area as it
> >> > > > is built, or
> >> > > > > > the libraries could be copied (from their respective
> >> > > > projects) by the
> >> > > > > > parent project in a roll-up operation.
> >> > > > > >
> >> > > > > > I considered running the assembly plugin in the
> >> > parent project,
> >> > > > > > but the archive libraries cannot be in a
> >> > .zip/.tar/.tgz format.
> >> > > > > >
> >> > > > > > Brad
> >> > > > > >
> >> > > > > > > -----Original Message-----
> >> > > > > > > From: dan tran [mailto:dantran@gmail.com]
> >> > > > > > > Sent: Saturday, September 02, 2006 12:32 AM
> >> > > > > > > To: Maven Users List
> >> > > > > > > Subject: Re: directory v. outputDirectory
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > native-maven-plugin''s outputDirectory purposely set to
> >> > > > > > > readonly so that all
> >> > > > > > > outputs ( .o, .dll, etc) stay inside
> >> > > > > > > target directory. and mvn clean can clear them as well.
> >> > > > > > >
> >> > > > > > > Why do you want the output files outside of project?
> >> > > > > > perhaps there is
> >> > > > > > > another way to accomplish
> >> > > > > > > what you need after the build.
> >> > > > > > >
> >> > > > > > > -D
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > What's the difference between
> >> > > > > > > >
> >> > > > > > > >   <build>
> >> > > > > > > >      <directory>
> >> > > > > > > >      <outputDirectory>
> >> > > > > > > >      ...
> >> > > > > > > >
> >> > > > > > > > I'm using maven-native-plugin, which has identical
> >> > > > configuration
> >> > > > > > > > elements, but I'm prevented from using them, i.e.
> >> > > > > > > >
> >> > > > > > > >   <build>
> >> > > > > > > >     <plugins>
> >> > > > > > > >       <plugin>
> >> > > > > > > >          <configure>
> >> > > > > > > >             <directory>
> >> > > > > > > >             <outputDirectory>
> >> > > > > > > >
> >> > > > > > > > by errors complaining about over-written
> >> > read-only parameters.
> >> > > > > > > >
> >> > > > > > > > It would be OK if libraries (modules) were to build
> >> > > > in their own
> >> > > > > > > > target/ sub-directories, but I'd like to move a
> >> > copy of the
> >> > > > > > > resulting
> >> > > > > > > > libraries into a central location higher in the
> >> > > > project hierarchy.
> >> > > > > > > >
> >> > > > > > > > Brad
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > >
> >> > ---------------------------------------------------------------------
> >> > > > > > > > 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
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > ---------------------------------------------------------------------
> >> > > > > 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
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6180108
> Sent from the Maven - Users forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: directory v. outputDirectory

[Jimisola Laursen <li...@jimisola.com>]

Hi!

Asked in the #maven recently about the maven-dependency-plugin.
There are a lot of reported issues, but there don't seem to be any
development activity according to Jira's "Recently resolved". Does anyone
here now?
I have a particular interest in "Make (sure) dependency:resolve outputs
absolute filename (or at least make it configurable)"
(http://jira.codehaus.org/browse/MDEP-29) to allow us to use the plugin to
create our installer.
It might be that it already works that way, but I haven't been able to find
2.0-SNAPSHOT before.

Also, may I ask about the difference in the two (2!) repos that have been
mentioned and the people one:

 1.
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin/
 2. http://people.apache.org/maven-snapshot-repository/
 3. http://svn.apache.org/maven-snapshot-repository

Regards,
Jimisola



dan tran wrote:
> 
> a snapshot of this plugin is at
> 
> http://people.apache.org/maven-snapshot-repository/
> 
> you can build the plugin yourself as well.
> 
> -D
> 
> 
> On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
>>
>> Failed to resolve this artifact
>>
>>       <groupId>org.apache.maven.plugins</groupId>
>>       <artifactId>maven-dependency-plugin</artifactId>
>>       <version>2.0-SNAPSHOT</version>
>>
>> Brad
>>
>> > -----Original Message-----
>> > From: dan tran [mailto:dantran@gmail.com]
>> > Sent: Tuesday, September 05, 2006 5:23 PM
>> > To: Maven Users List
>> > Subject: Re: directory v. outputDirectory
>> >
>> >
>> > please note that depenency-maven-plugin has been accepted
>> > into apache.  It
>> > is now at
>> >
>> > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-depe
>> > ndency-plugin/
>> >
>> > The more ppl using this new plugin, the more chance we can
>> > get it released
>> > ;-)
>> >
>> > -D
>> >
>> > On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
>> > >
>> > > org.codehaus.plugins:dependency-maven-plugin works.
>> > >
>> > > Thanks.
>> > >
>> > > Brad
>> > >
>> > > > -----Original Message-----
>> > > > From: dantran@gmail.com [mailto:dantran@gmail.com]
>> > > > Sent: Tuesday, September 05, 2006 1:30 PM
>> > > > To: Maven Users List
>> > > > Subject: Re: directory v. outputDirectory
>> > > >
>> > > >
>> > > > Brad, you can use a combination of assembly and dependency
>> > > > plugin to copy
>> > > > final built artfacts into a single
>> > > > directory the way you want it it and have assembly to zip(
>> > > > tgz, etc) them
>> > > > up.
>> > > >
>> > > > Use a separate maven project for that purpose.
>> > > >
>> > > > -Dan
>> > > >
>> > > >
>> > > > On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
>> > > > >
>> > > > > Can you define multiple source directories?
>> > > > >
>> > > > > I am guessing that transitive dependencies aren't
>> > getting linked in?
>> > > > >
>> > > > > D-
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: Brad Harper
>> > > > > Sent: Tuesday, September 05, 2006 12:25 PM
>> > > > > To: users
>> > > > > Subject: RE: directory v. outputDirectory
>> > > > >
>> > > > > The libraries will be built as a mixture of .lib and
>> > .dll files (on
>> > > > > Windows)
>> > > > > and .a and .so archives (on *nix platforms).
>> > > > >
>> > > > > Brad
>> > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Douglas Ferguson
>> > > > > > Sent: Tuesday, September 05, 2006 11:36 AM
>> > > > > > To: users
>> > > > > > Subject: RE: directory v. outputDirectory
>> > > > > >
>> > > > > >
>> > > > > > What format must the archive be in?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Brad Harper
>> > > > > > Sent: Tuesday, September 05, 2006 10:02 AM
>> > > > > > To: users
>> > > > > > Subject: RE: directory v. outputDirectory
>> > > > > >
>> > > > > > Dan:
>> > > > > >
>> > > > > > My intent is to have copies of a set of archive libraries
>> > > > collected
>> > > > > > into a single directory. The libraries are sibling
>> > > > modules of a parent
>> > > > > > project.
>> > > > > >
>> > > > > > Each library could be copied into the target area as it
>> > > > is built, or
>> > > > > > the libraries could be copied (from their respective
>> > > > projects) by the
>> > > > > > parent project in a roll-up operation.
>> > > > > >
>> > > > > > I considered running the assembly plugin in the
>> > parent project,
>> > > > > > but the archive libraries cannot be in a
>> > .zip/.tar/.tgz format.
>> > > > > >
>> > > > > > Brad
>> > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: dan tran [mailto:dantran@gmail.com]
>> > > > > > > Sent: Saturday, September 02, 2006 12:32 AM
>> > > > > > > To: Maven Users List
>> > > > > > > Subject: Re: directory v. outputDirectory
>> > > > > > >
>> > > > > > >
>> > > > > > > native-maven-plugin''s outputDirectory purposely set to
>> > > > > > > readonly so that all
>> > > > > > > outputs ( .o, .dll, etc) stay inside
>> > > > > > > target directory. and mvn clean can clear them as well.
>> > > > > > >
>> > > > > > > Why do you want the output files outside of project?
>> > > > > > perhaps there is
>> > > > > > > another way to accomplish
>> > > > > > > what you need after the build.
>> > > > > > >
>> > > > > > > -D
>> > > > > > >
>> > > > > > >
>> > > > > > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > What's the difference between
>> > > > > > > >
>> > > > > > > >   <build>
>> > > > > > > >      <directory>
>> > > > > > > >      <outputDirectory>
>> > > > > > > >      ...
>> > > > > > > >
>> > > > > > > > I'm using maven-native-plugin, which has identical
>> > > > configuration
>> > > > > > > > elements, but I'm prevented from using them, i.e.
>> > > > > > > >
>> > > > > > > >   <build>
>> > > > > > > >     <plugins>
>> > > > > > > >       <plugin>
>> > > > > > > >          <configure>
>> > > > > > > >             <directory>
>> > > > > > > >             <outputDirectory>
>> > > > > > > >
>> > > > > > > > by errors complaining about over-written
>> > read-only parameters.
>> > > > > > > >
>> > > > > > > > It would be OK if libraries (modules) were to build
>> > > > in their own
>> > > > > > > > target/ sub-directories, but I'd like to move a
>> > copy of the
>> > > > > > > resulting
>> > > > > > > > libraries into a central location higher in the
>> > > > project hierarchy.
>> > > > > > > >
>> > > > > > > > Brad
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > >
>> > ---------------------------------------------------------------------
>> > > > > > > > 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
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > ---------------------------------------------------------------------
>> > > > > 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
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6180108
Sent from the Maven - Users forum at Nabble.com.


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

Re: directory v. outputDirectory

[dan tran <da...@gmail.com>]

a snapshot of this plugin is at

http://people.apache.org/maven-snapshot-repository/

you can build the plugin yourself as well.

-D


On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
>
> Failed to resolve this artifact
>
>       <groupId>org.apache.maven.plugins</groupId>
>       <artifactId>maven-dependency-plugin</artifactId>
>       <version>2.0-SNAPSHOT</version>
>
> Brad
>
> > -----Original Message-----
> > From: dan tran [mailto:dantran@gmail.com]
> > Sent: Tuesday, September 05, 2006 5:23 PM
> > To: Maven Users List
> > Subject: Re: directory v. outputDirectory
> >
> >
> > please note that depenency-maven-plugin has been accepted
> > into apache.  It
> > is now at
> >
> > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-depe
> > ndency-plugin/
> >
> > The more ppl using this new plugin, the more chance we can
> > get it released
> > ;-)
> >
> > -D
> >
> > On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
> > >
> > > org.codehaus.plugins:dependency-maven-plugin works.
> > >
> > > Thanks.
> > >
> > > Brad
> > >
> > > > -----Original Message-----
> > > > From: dantran@gmail.com [mailto:dantran@gmail.com]
> > > > Sent: Tuesday, September 05, 2006 1:30 PM
> > > > To: Maven Users List
> > > > Subject: Re: directory v. outputDirectory
> > > >
> > > >
> > > > Brad, you can use a combination of assembly and dependency
> > > > plugin to copy
> > > > final built artfacts into a single
> > > > directory the way you want it it and have assembly to zip(
> > > > tgz, etc) them
> > > > up.
> > > >
> > > > Use a separate maven project for that purpose.
> > > >
> > > > -Dan
> > > >
> > > >
> > > > On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
> > > > >
> > > > > Can you define multiple source directories?
> > > > >
> > > > > I am guessing that transitive dependencies aren't
> > getting linked in?
> > > > >
> > > > > D-
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brad Harper
> > > > > Sent: Tuesday, September 05, 2006 12:25 PM
> > > > > To: users
> > > > > Subject: RE: directory v. outputDirectory
> > > > >
> > > > > The libraries will be built as a mixture of .lib and
> > .dll files (on
> > > > > Windows)
> > > > > and .a and .so archives (on *nix platforms).
> > > > >
> > > > > Brad
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Douglas Ferguson
> > > > > > Sent: Tuesday, September 05, 2006 11:36 AM
> > > > > > To: users
> > > > > > Subject: RE: directory v. outputDirectory
> > > > > >
> > > > > >
> > > > > > What format must the archive be in?
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brad Harper
> > > > > > Sent: Tuesday, September 05, 2006 10:02 AM
> > > > > > To: users
> > > > > > Subject: RE: directory v. outputDirectory
> > > > > >
> > > > > > Dan:
> > > > > >
> > > > > > My intent is to have copies of a set of archive libraries
> > > > collected
> > > > > > into a single directory. The libraries are sibling
> > > > modules of a parent
> > > > > > project.
> > > > > >
> > > > > > Each library could be copied into the target area as it
> > > > is built, or
> > > > > > the libraries could be copied (from their respective
> > > > projects) by the
> > > > > > parent project in a roll-up operation.
> > > > > >
> > > > > > I considered running the assembly plugin in the
> > parent project,
> > > > > > but the archive libraries cannot be in a
> > .zip/.tar/.tgz format.
> > > > > >
> > > > > > Brad
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: dan tran [mailto:dantran@gmail.com]
> > > > > > > Sent: Saturday, September 02, 2006 12:32 AM
> > > > > > > To: Maven Users List
> > > > > > > Subject: Re: directory v. outputDirectory
> > > > > > >
> > > > > > >
> > > > > > > native-maven-plugin''s outputDirectory purposely set to
> > > > > > > readonly so that all
> > > > > > > outputs ( .o, .dll, etc) stay inside
> > > > > > > target directory. and mvn clean can clear them as well.
> > > > > > >
> > > > > > > Why do you want the output files outside of project?
> > > > > > perhaps there is
> > > > > > > another way to accomplish
> > > > > > > what you need after the build.
> > > > > > >
> > > > > > > -D
> > > > > > >
> > > > > > >
> > > > > > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > What's the difference between
> > > > > > > >
> > > > > > > >   <build>
> > > > > > > >      <directory>
> > > > > > > >      <outputDirectory>
> > > > > > > >      ...
> > > > > > > >
> > > > > > > > I'm using maven-native-plugin, which has identical
> > > > configuration
> > > > > > > > elements, but I'm prevented from using them, i.e.
> > > > > > > >
> > > > > > > >   <build>
> > > > > > > >     <plugins>
> > > > > > > >       <plugin>
> > > > > > > >          <configure>
> > > > > > > >             <directory>
> > > > > > > >             <outputDirectory>
> > > > > > > >
> > > > > > > > by errors complaining about over-written
> > read-only parameters.
> > > > > > > >
> > > > > > > > It would be OK if libraries (modules) were to build
> > > > in their own
> > > > > > > > target/ sub-directories, but I'd like to move a
> > copy of the
> > > > > > > resulting
> > > > > > > > libraries into a central location higher in the
> > > > project hierarchy.
> > > > > > > >
> > > > > > > > Brad
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > 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: directory v. outputDirectory

[Brad Harper <br...@epsiia.com>]

Failed to resolve this artifact

       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-dependency-plugin</artifactId>
       <version>2.0-SNAPSHOT</version>

Brad

> -----Original Message-----
> From: dan tran [mailto:dantran@gmail.com]
> Sent: Tuesday, September 05, 2006 5:23 PM
> To: Maven Users List
> Subject: Re: directory v. outputDirectory
> 
> 
> please note that depenency-maven-plugin has been accepted 
> into apache.  It
> is now at
> 
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-depe
> ndency-plugin/
> 
> The more ppl using this new plugin, the more chance we can 
> get it released
> ;-)
> 
> -D
> 
> On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
> >
> > org.codehaus.plugins:dependency-maven-plugin works.
> >
> > Thanks.
> >
> > Brad
> >
> > > -----Original Message-----
> > > From: dantran@gmail.com [mailto:dantran@gmail.com]
> > > Sent: Tuesday, September 05, 2006 1:30 PM
> > > To: Maven Users List
> > > Subject: Re: directory v. outputDirectory
> > >
> > >
> > > Brad, you can use a combination of assembly and dependency
> > > plugin to copy
> > > final built artfacts into a single
> > > directory the way you want it it and have assembly to zip(
> > > tgz, etc) them
> > > up.
> > >
> > > Use a separate maven project for that purpose.
> > >
> > > -Dan
> > >
> > >
> > > On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
> > > >
> > > > Can you define multiple source directories?
> > > >
> > > > I am guessing that transitive dependencies aren't 
> getting linked in?
> > > >
> > > > D-
> > > >
> > > > -----Original Message-----
> > > > From: Brad Harper
> > > > Sent: Tuesday, September 05, 2006 12:25 PM
> > > > To: users
> > > > Subject: RE: directory v. outputDirectory
> > > >
> > > > The libraries will be built as a mixture of .lib and 
> .dll files (on
> > > > Windows)
> > > > and .a and .so archives (on *nix platforms).
> > > >
> > > > Brad
> > > >
> > > > > -----Original Message-----
> > > > > From: Douglas Ferguson
> > > > > Sent: Tuesday, September 05, 2006 11:36 AM
> > > > > To: users
> > > > > Subject: RE: directory v. outputDirectory
> > > > >
> > > > >
> > > > > What format must the archive be in?
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brad Harper
> > > > > Sent: Tuesday, September 05, 2006 10:02 AM
> > > > > To: users
> > > > > Subject: RE: directory v. outputDirectory
> > > > >
> > > > > Dan:
> > > > >
> > > > > My intent is to have copies of a set of archive libraries
> > > collected
> > > > > into a single directory. The libraries are sibling
> > > modules of a parent
> > > > > project.
> > > > >
> > > > > Each library could be copied into the target area as it
> > > is built, or
> > > > > the libraries could be copied (from their respective
> > > projects) by the
> > > > > parent project in a roll-up operation.
> > > > >
> > > > > I considered running the assembly plugin in the 
> parent project,
> > > > > but the archive libraries cannot be in a 
> .zip/.tar/.tgz format.
> > > > >
> > > > > Brad
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: dan tran [mailto:dantran@gmail.com]
> > > > > > Sent: Saturday, September 02, 2006 12:32 AM
> > > > > > To: Maven Users List
> > > > > > Subject: Re: directory v. outputDirectory
> > > > > >
> > > > > >
> > > > > > native-maven-plugin''s outputDirectory purposely set to
> > > > > > readonly so that all
> > > > > > outputs ( .o, .dll, etc) stay inside
> > > > > > target directory. and mvn clean can clear them as well.
> > > > > >
> > > > > > Why do you want the output files outside of project?
> > > > > perhaps there is
> > > > > > another way to accomplish
> > > > > > what you need after the build.
> > > > > >
> > > > > > -D
> > > > > >
> > > > > >
> > > > > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > What's the difference between
> > > > > > >
> > > > > > >   <build>
> > > > > > >      <directory>
> > > > > > >      <outputDirectory>
> > > > > > >      ...
> > > > > > >
> > > > > > > I'm using maven-native-plugin, which has identical
> > > configuration
> > > > > > > elements, but I'm prevented from using them, i.e.
> > > > > > >
> > > > > > >   <build>
> > > > > > >     <plugins>
> > > > > > >       <plugin>
> > > > > > >          <configure>
> > > > > > >             <directory>
> > > > > > >             <outputDirectory>
> > > > > > >
> > > > > > > by errors complaining about over-written 
> read-only parameters.
> > > > > > >
> > > > > > > It would be OK if libraries (modules) were to build
> > > in their own
> > > > > > > target/ sub-directories, but I'd like to move a 
> copy of the
> > > > > > resulting
> > > > > > > libraries into a central location higher in the
> > > project hierarchy.
> > > > > > >
> > > > > > > Brad
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > 
> ---------------------------------------------------------------------
> > > > > > > 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
> > > >
> > > >
> > > >
> > > >
> > > 
> ---------------------------------------------------------------------
> > > > 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: directory v. outputDirectory

[dan tran <da...@gmail.com>]

please note that depenency-maven-plugin has been accepted into apache.  It
is now at

http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin/

The more ppl using this new plugin, the more chance we can get it released
;-)

-D

On 9/5/06, Brad Harper <br...@epsiia.com> wrote:
>
> org.codehaus.plugins:dependency-maven-plugin works.
>
> Thanks.
>
> Brad
>
> > -----Original Message-----
> > From: dantran@gmail.com [mailto:dantran@gmail.com]
> > Sent: Tuesday, September 05, 2006 1:30 PM
> > To: Maven Users List
> > Subject: Re: directory v. outputDirectory
> >
> >
> > Brad, you can use a combination of assembly and dependency
> > plugin to copy
> > final built artfacts into a single
> > directory the way you want it it and have assembly to zip(
> > tgz, etc) them
> > up.
> >
> > Use a separate maven project for that purpose.
> >
> > -Dan
> >
> >
> > On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
> > >
> > > Can you define multiple source directories?
> > >
> > > I am guessing that transitive dependencies aren't getting linked in?
> > >
> > > D-
> > >
> > > -----Original Message-----
> > > From: Brad Harper
> > > Sent: Tuesday, September 05, 2006 12:25 PM
> > > To: users
> > > Subject: RE: directory v. outputDirectory
> > >
> > > The libraries will be built as a mixture of .lib and .dll files (on
> > > Windows)
> > > and .a and .so archives (on *nix platforms).
> > >
> > > Brad
> > >
> > > > -----Original Message-----
> > > > From: Douglas Ferguson
> > > > Sent: Tuesday, September 05, 2006 11:36 AM
> > > > To: users
> > > > Subject: RE: directory v. outputDirectory
> > > >
> > > >
> > > > What format must the archive be in?
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Brad Harper
> > > > Sent: Tuesday, September 05, 2006 10:02 AM
> > > > To: users
> > > > Subject: RE: directory v. outputDirectory
> > > >
> > > > Dan:
> > > >
> > > > My intent is to have copies of a set of archive libraries
> > collected
> > > > into a single directory. The libraries are sibling
> > modules of a parent
> > > > project.
> > > >
> > > > Each library could be copied into the target area as it
> > is built, or
> > > > the libraries could be copied (from their respective
> > projects) by the
> > > > parent project in a roll-up operation.
> > > >
> > > > I considered running the assembly plugin in the parent project,
> > > > but the archive libraries cannot be in a .zip/.tar/.tgz format.
> > > >
> > > > Brad
> > > >
> > > > > -----Original Message-----
> > > > > From: dan tran [mailto:dantran@gmail.com]
> > > > > Sent: Saturday, September 02, 2006 12:32 AM
> > > > > To: Maven Users List
> > > > > Subject: Re: directory v. outputDirectory
> > > > >
> > > > >
> > > > > native-maven-plugin''s outputDirectory purposely set to
> > > > > readonly so that all
> > > > > outputs ( .o, .dll, etc) stay inside
> > > > > target directory. and mvn clean can clear them as well.
> > > > >
> > > > > Why do you want the output files outside of project?
> > > > perhaps there is
> > > > > another way to accomplish
> > > > > what you need after the build.
> > > > >
> > > > > -D
> > > > >
> > > > >
> > > > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > > > > >
> > > > > >
> > > > > > What's the difference between
> > > > > >
> > > > > >   <build>
> > > > > >      <directory>
> > > > > >      <outputDirectory>
> > > > > >      ...
> > > > > >
> > > > > > I'm using maven-native-plugin, which has identical
> > configuration
> > > > > > elements, but I'm prevented from using them, i.e.
> > > > > >
> > > > > >   <build>
> > > > > >     <plugins>
> > > > > >       <plugin>
> > > > > >          <configure>
> > > > > >             <directory>
> > > > > >             <outputDirectory>
> > > > > >
> > > > > > by errors complaining about over-written read-only parameters.
> > > > > >
> > > > > > It would be OK if libraries (modules) were to build
> > in their own
> > > > > > target/ sub-directories, but I'd like to move a copy of the
> > > > > resulting
> > > > > > libraries into a central location higher in the
> > project hierarchy.
> > > > > >
> > > > > > Brad
> > > > > >
> > > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > 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
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > 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: directory v. outputDirectory

[Brad Harper <br...@epsiia.com>]

org.codehaus.plugins:dependency-maven-plugin works.

Thanks.

Brad

> -----Original Message-----
> From: dantran@gmail.com [mailto:dantran@gmail.com]
> Sent: Tuesday, September 05, 2006 1:30 PM
> To: Maven Users List
> Subject: Re: directory v. outputDirectory
> 
> 
> Brad, you can use a combination of assembly and dependency 
> plugin to copy
> final built artfacts into a single
> directory the way you want it it and have assembly to zip( 
> tgz, etc) them
> up.
> 
> Use a separate maven project for that purpose.
> 
> -Dan
> 
> 
> On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
> >
> > Can you define multiple source directories?
> >
> > I am guessing that transitive dependencies aren't getting linked in?
> >
> > D-
> >
> > -----Original Message-----
> > From: Brad Harper
> > Sent: Tuesday, September 05, 2006 12:25 PM
> > To: users
> > Subject: RE: directory v. outputDirectory
> >
> > The libraries will be built as a mixture of .lib and .dll files (on
> > Windows)
> > and .a and .so archives (on *nix platforms).
> >
> > Brad
> >
> > > -----Original Message-----
> > > From: Douglas Ferguson
> > > Sent: Tuesday, September 05, 2006 11:36 AM
> > > To: users
> > > Subject: RE: directory v. outputDirectory
> > >
> > >
> > > What format must the archive be in?
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Brad Harper
> > > Sent: Tuesday, September 05, 2006 10:02 AM
> > > To: users
> > > Subject: RE: directory v. outputDirectory
> > >
> > > Dan:
> > >
> > > My intent is to have copies of a set of archive libraries 
> collected
> > > into a single directory. The libraries are sibling 
> modules of a parent
> > > project.
> > >
> > > Each library could be copied into the target area as it 
> is built, or
> > > the libraries could be copied (from their respective 
> projects) by the
> > > parent project in a roll-up operation.
> > >
> > > I considered running the assembly plugin in the parent project,
> > > but the archive libraries cannot be in a .zip/.tar/.tgz format.
> > >
> > > Brad
> > >
> > > > -----Original Message-----
> > > > From: dan tran [mailto:dantran@gmail.com]
> > > > Sent: Saturday, September 02, 2006 12:32 AM
> > > > To: Maven Users List
> > > > Subject: Re: directory v. outputDirectory
> > > >
> > > >
> > > > native-maven-plugin''s outputDirectory purposely set to
> > > > readonly so that all
> > > > outputs ( .o, .dll, etc) stay inside
> > > > target directory. and mvn clean can clear them as well.
> > > >
> > > > Why do you want the output files outside of project?
> > > perhaps there is
> > > > another way to accomplish
> > > > what you need after the build.
> > > >
> > > > -D
> > > >
> > > >
> > > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > > > >
> > > > >
> > > > > What's the difference between
> > > > >
> > > > >   <build>
> > > > >      <directory>
> > > > >      <outputDirectory>
> > > > >      ...
> > > > >
> > > > > I'm using maven-native-plugin, which has identical 
> configuration
> > > > > elements, but I'm prevented from using them, i.e.
> > > > >
> > > > >   <build>
> > > > >     <plugins>
> > > > >       <plugin>
> > > > >          <configure>
> > > > >             <directory>
> > > > >             <outputDirectory>
> > > > >
> > > > > by errors complaining about over-written read-only parameters.
> > > > >
> > > > > It would be OK if libraries (modules) were to build 
> in their own
> > > > > target/ sub-directories, but I'd like to move a copy of the
> > > > resulting
> > > > > libraries into a central location higher in the 
> project hierarchy.
> > > > >
> > > > > Brad
> > > > >
> > > > >
> > > >
> > > 
> ---------------------------------------------------------------------
> > > > > 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
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > 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: directory v. outputDirectory

[dan tran <da...@gmail.com>]

Brad, you can use a combination of assembly and dependency plugin to copy
final built artfacts into a single
directory the way you want it it and have assembly to zip( tgz, etc) them
up.

Use a separate maven project for that purpose.

-Dan


On 9/5/06, Douglas Ferguson <do...@epsiia.com> wrote:
>
> Can you define multiple source directories?
>
> I am guessing that transitive dependencies aren't getting linked in?
>
> D-
>
> -----Original Message-----
> From: Brad Harper
> Sent: Tuesday, September 05, 2006 12:25 PM
> To: users
> Subject: RE: directory v. outputDirectory
>
> The libraries will be built as a mixture of .lib and .dll files (on
> Windows)
> and .a and .so archives (on *nix platforms).
>
> Brad
>
> > -----Original Message-----
> > From: Douglas Ferguson
> > Sent: Tuesday, September 05, 2006 11:36 AM
> > To: users
> > Subject: RE: directory v. outputDirectory
> >
> >
> > What format must the archive be in?
> >
> >
> >
> > -----Original Message-----
> > From: Brad Harper
> > Sent: Tuesday, September 05, 2006 10:02 AM
> > To: users
> > Subject: RE: directory v. outputDirectory
> >
> > Dan:
> >
> > My intent is to have copies of a set of archive libraries collected
> > into a single directory. The libraries are sibling modules of a parent
> > project.
> >
> > Each library could be copied into the target area as it is built, or
> > the libraries could be copied (from their respective projects) by the
> > parent project in a roll-up operation.
> >
> > I considered running the assembly plugin in the parent project,
> > but the archive libraries cannot be in a .zip/.tar/.tgz format.
> >
> > Brad
> >
> > > -----Original Message-----
> > > From: dan tran [mailto:dantran@gmail.com]
> > > Sent: Saturday, September 02, 2006 12:32 AM
> > > To: Maven Users List
> > > Subject: Re: directory v. outputDirectory
> > >
> > >
> > > native-maven-plugin''s outputDirectory purposely set to
> > > readonly so that all
> > > outputs ( .o, .dll, etc) stay inside
> > > target directory. and mvn clean can clear them as well.
> > >
> > > Why do you want the output files outside of project?
> > perhaps there is
> > > another way to accomplish
> > > what you need after the build.
> > >
> > > -D
> > >
> > >
> > > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > > >
> > > >
> > > > What's the difference between
> > > >
> > > >   <build>
> > > >      <directory>
> > > >      <outputDirectory>
> > > >      ...
> > > >
> > > > I'm using maven-native-plugin, which has identical configuration
> > > > elements, but I'm prevented from using them, i.e.
> > > >
> > > >   <build>
> > > >     <plugins>
> > > >       <plugin>
> > > >          <configure>
> > > >             <directory>
> > > >             <outputDirectory>
> > > >
> > > > by errors complaining about over-written read-only parameters.
> > > >
> > > > It would be OK if libraries (modules) were to build in their own
> > > > target/ sub-directories, but I'd like to move a copy of the
> > > resulting
> > > > libraries into a central location higher in the project hierarchy.
> > > >
> > > > Brad
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

RE: directory v. outputDirectory

[Douglas Ferguson <do...@epsiia.com>]

Can you define multiple source directories?

I am guessing that transitive dependencies aren't getting linked in?

D-

-----Original Message-----
From: Brad Harper 
Sent: Tuesday, September 05, 2006 12:25 PM
To: users
Subject: RE: directory v. outputDirectory

The libraries will be built as a mixture of .lib and .dll files (on Windows)
and .a and .so archives (on *nix platforms).

Brad

> -----Original Message-----
> From: Douglas Ferguson 
> Sent: Tuesday, September 05, 2006 11:36 AM
> To: users
> Subject: RE: directory v. outputDirectory
> 
> 
> What format must the archive be in?
> 
> 
> 
> -----Original Message-----
> From: Brad Harper 
> Sent: Tuesday, September 05, 2006 10:02 AM
> To: users
> Subject: RE: directory v. outputDirectory
> 
> Dan:
> 
> My intent is to have copies of a set of archive libraries collected
> into a single directory. The libraries are sibling modules of a parent
> project.
> 
> Each library could be copied into the target area as it is built, or
> the libraries could be copied (from their respective projects) by the
> parent project in a roll-up operation.
> 
> I considered running the assembly plugin in the parent project,
> but the archive libraries cannot be in a .zip/.tar/.tgz format.
> 
> Brad
> 
> > -----Original Message-----
> > From: dan tran [mailto:dantran@gmail.com]
> > Sent: Saturday, September 02, 2006 12:32 AM
> > To: Maven Users List
> > Subject: Re: directory v. outputDirectory
> > 
> > 
> > native-maven-plugin''s outputDirectory purposely set to 
> > readonly so that all
> > outputs ( .o, .dll, etc) stay inside
> > target directory. and mvn clean can clear them as well.
> > 
> > Why do you want the output files outside of project? 
> perhaps there is
> > another way to accomplish
> > what you need after the build.
> > 
> > -D
> > 
> > 
> > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > >
> > >
> > > What's the difference between
> > >
> > >   <build>
> > >      <directory>
> > >      <outputDirectory>
> > >      ...
> > >
> > > I'm using maven-native-plugin, which has identical configuration
> > > elements, but I'm prevented from using them, i.e.
> > >
> > >   <build>
> > >     <plugins>
> > >       <plugin>
> > >          <configure>
> > >             <directory>
> > >             <outputDirectory>
> > >
> > > by errors complaining about over-written read-only parameters.
> > >
> > > It would be OK if libraries (modules) were to build in their own
> > > target/ sub-directories, but I'd like to move a copy of the 
> > resulting
> > > libraries into a central location higher in the project hierarchy.
> > >
> > > Brad
> > >
> > > 
> > 
> ---------------------------------------------------------------------
> > > 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



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

RE: directory v. outputDirectory

[Brad Harper <br...@epsiia.com>]

The libraries will be built as a mixture of .lib and .dll files (on Windows)
and .a and .so archives (on *nix platforms).

Brad

> -----Original Message-----
> From: Douglas Ferguson 
> Sent: Tuesday, September 05, 2006 11:36 AM
> To: users
> Subject: RE: directory v. outputDirectory
> 
> 
> What format must the archive be in?
> 
> 
> 
> -----Original Message-----
> From: Brad Harper 
> Sent: Tuesday, September 05, 2006 10:02 AM
> To: users
> Subject: RE: directory v. outputDirectory
> 
> Dan:
> 
> My intent is to have copies of a set of archive libraries collected
> into a single directory. The libraries are sibling modules of a parent
> project.
> 
> Each library could be copied into the target area as it is built, or
> the libraries could be copied (from their respective projects) by the
> parent project in a roll-up operation.
> 
> I considered running the assembly plugin in the parent project,
> but the archive libraries cannot be in a .zip/.tar/.tgz format.
> 
> Brad
> 
> > -----Original Message-----
> > From: dan tran [mailto:dantran@gmail.com]
> > Sent: Saturday, September 02, 2006 12:32 AM
> > To: Maven Users List
> > Subject: Re: directory v. outputDirectory
> > 
> > 
> > native-maven-plugin''s outputDirectory purposely set to 
> > readonly so that all
> > outputs ( .o, .dll, etc) stay inside
> > target directory. and mvn clean can clear them as well.
> > 
> > Why do you want the output files outside of project? 
> perhaps there is
> > another way to accomplish
> > what you need after the build.
> > 
> > -D
> > 
> > 
> > On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> > >
> > >
> > > What's the difference between
> > >
> > >   <build>
> > >      <directory>
> > >      <outputDirectory>
> > >      ...
> > >
> > > I'm using maven-native-plugin, which has identical configuration
> > > elements, but I'm prevented from using them, i.e.
> > >
> > >   <build>
> > >     <plugins>
> > >       <plugin>
> > >          <configure>
> > >             <directory>
> > >             <outputDirectory>
> > >
> > > by errors complaining about over-written read-only parameters.
> > >
> > > It would be OK if libraries (modules) were to build in their own
> > > target/ sub-directories, but I'd like to move a copy of the 
> > resulting
> > > libraries into a central location higher in the project hierarchy.
> > >
> > > Brad
> > >
> > > 
> > 
> ---------------------------------------------------------------------
> > > 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: directory v. outputDirectory

[Douglas Ferguson <do...@epsiia.com>]

What format must the archive be in?



-----Original Message-----
From: Brad Harper 
Sent: Tuesday, September 05, 2006 10:02 AM
To: users
Subject: RE: directory v. outputDirectory

Dan:

My intent is to have copies of a set of archive libraries collected
into a single directory. The libraries are sibling modules of a parent
project.

Each library could be copied into the target area as it is built, or
the libraries could be copied (from their respective projects) by the
parent project in a roll-up operation.

I considered running the assembly plugin in the parent project,
but the archive libraries cannot be in a .zip/.tar/.tgz format.

Brad

> -----Original Message-----
> From: dan tran [mailto:dantran@gmail.com]
> Sent: Saturday, September 02, 2006 12:32 AM
> To: Maven Users List
> Subject: Re: directory v. outputDirectory
> 
> 
> native-maven-plugin''s outputDirectory purposely set to 
> readonly so that all
> outputs ( .o, .dll, etc) stay inside
> target directory. and mvn clean can clear them as well.
> 
> Why do you want the output files outside of project? perhaps there is
> another way to accomplish
> what you need after the build.
> 
> -D
> 
> 
> On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> >
> >
> > What's the difference between
> >
> >   <build>
> >      <directory>
> >      <outputDirectory>
> >      ...
> >
> > I'm using maven-native-plugin, which has identical configuration
> > elements, but I'm prevented from using them, i.e.
> >
> >   <build>
> >     <plugins>
> >       <plugin>
> >          <configure>
> >             <directory>
> >             <outputDirectory>
> >
> > by errors complaining about over-written read-only parameters.
> >
> > It would be OK if libraries (modules) were to build in their own
> > target/ sub-directories, but I'd like to move a copy of the 
> resulting
> > libraries into a central location higher in the project hierarchy.
> >
> > Brad
> >
> > 
> ---------------------------------------------------------------------
> > 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: directory v. outputDirectory

[Brad Harper <br...@epsiia.com>]

Dan:

My intent is to have copies of a set of archive libraries collected
into a single directory. The libraries are sibling modules of a parent
project.

Each library could be copied into the target area as it is built, or
the libraries could be copied (from their respective projects) by the
parent project in a roll-up operation.

I considered running the assembly plugin in the parent project,
but the archive libraries cannot be in a .zip/.tar/.tgz format.

Brad

> -----Original Message-----
> From: dan tran [mailto:dantran@gmail.com]
> Sent: Saturday, September 02, 2006 12:32 AM
> To: Maven Users List
> Subject: Re: directory v. outputDirectory
> 
> 
> native-maven-plugin''s outputDirectory purposely set to 
> readonly so that all
> outputs ( .o, .dll, etc) stay inside
> target directory. and mvn clean can clear them as well.
> 
> Why do you want the output files outside of project? perhaps there is
> another way to accomplish
> what you need after the build.
> 
> -D
> 
> 
> On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
> >
> >
> > What's the difference between
> >
> >   <build>
> >      <directory>
> >      <outputDirectory>
> >      ...
> >
> > I'm using maven-native-plugin, which has identical configuration
> > elements, but I'm prevented from using them, i.e.
> >
> >   <build>
> >     <plugins>
> >       <plugin>
> >          <configure>
> >             <directory>
> >             <outputDirectory>
> >
> > by errors complaining about over-written read-only parameters.
> >
> > It would be OK if libraries (modules) were to build in their own
> > target/ sub-directories, but I'd like to move a copy of the 
> resulting
> > libraries into a central location higher in the project hierarchy.
> >
> > Brad
> >
> > 
> ---------------------------------------------------------------------
> > 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: directory v. outputDirectory

[dan tran <da...@gmail.com>]

native-maven-plugin''s outputDirectory purposely set to readonly so that all
outputs ( .o, .dll, etc) stay inside
target directory. and mvn clean can clear them as well.

Why do you want the output files outside of project? perhaps there is
another way to accomplish
what you need after the build.

-D


On 9/1/06, Brad Harper <br...@epsiia.com> wrote:
>
>
> What's the difference between
>
>   <build>
>      <directory>
>      <outputDirectory>
>      ...
>
> I'm using maven-native-plugin, which has identical configuration
> elements, but I'm prevented from using them, i.e.
>
>   <build>
>     <plugins>
>       <plugin>
>          <configure>
>             <directory>
>             <outputDirectory>
>
> by errors complaining about over-written read-only parameters.
>
> It would be OK if libraries (modules) were to build in their own
> target/ sub-directories, but I'd like to move a copy of the resulting
> libraries into a central location higher in the project hierarchy.
>
> Brad
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

RE: directory v. outputDirectory

[Douglas Ferguson <do...@epsiia.com>]

directory = target
outputDirectory = target/classes
 
 
 
----- Original Message -----
From: brad.harper@epsiia.com
Sent: Sat, 9/2/2006 2:15am
To: users 
Subject: directory v. outputDirectory 
 
 
What's the difference between

   <build>
      <directory>
      <outputDirectory>
      ...

I'm using maven-native-plugin, which has identical configuration
elements, but I'm prevented from using them, i.e.

   <build>
     <plugins>
       <plugin>
          <configure>
             <directory>
             <outputDirectory>

by errors complaining about over-written read-only parameters.

It would be OK if libraries (modules) were to build in their own
target/ sub-directories, but I'd like to move a copy of the resulting
libraries into a central location higher in the project hierarchy.

Brad

---------------------------------------------------------------------
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

directory v. outputDirectory

[Brad Harper <br...@epsiia.com>]

What's the difference between

   <build>
      <directory>
      <outputDirectory>
      ...

I'm using maven-native-plugin, which has identical configuration
elements, but I'm prevented from using them, i.e.

   <build>
     <plugins>
       <plugin>
          <configure>
             <directory>
             <outputDirectory>

by errors complaining about over-written read-only parameters.

It would be OK if libraries (modules) were to build in their own
target/ sub-directories, but I'd like to move a copy of the resulting
libraries into a central location higher in the project hierarchy.

Brad

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

Re: [POLL] Why switch to Maven?

[Ralph Pöllath <li...@poellath.org>]

On 31.08.2006, at 23:27, ArneD wrote:
>> After all, if can't trust your team to stick to approved
>> versions of artifacts how can you trust them to write your precious
>> business code?
>
> I think it's not a question of mistrusting people, but a question  
> of how can
> you help people to avoid mistakes. Even if they use a Maven-based  
> build for
> the first time and don't have a M.Sc. in Computer Science or x  
> years of
> experience.
>
> If the team *wants* to used unapproved versions of artifacts, of  
> course,
> they will be able to do it. But you should help them to not do it by
> mistake.

FWIW, wouldn't it be simple to write a plugin that compares all  
dependencies to a list of approved artifacts?

Cheers,
-Ralph.


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

Re: [POLL] Why switch to Maven?

[ArneD <pu...@degenring.de>]

> After all, if can't trust your team to stick to approved
> versions of artifacts how can you trust them to write your precious
> business code?
> 

I think it's not a question of mistrusting people, but a question of how can
you help people to avoid mistakes. Even if they use a Maven-based build for
the first time and don't have a M.Sc. in Computer Science or x years of
experience.

If the team *wants* to used unapproved versions of artifacts, of course,
they will be able to do it. But you should help them to not do it by
mistake.



> So, how to you verify instead of lock?
> You have a parent pom that declares and defines all versions of
> artifacts and plugins and in your module poms you declare that you
> want a plugin but you provide no version information.  Then your
> configuration team only needs to check the parent pom against the
> internal standards.
> 

Nice suggestion, I'll think about it for the customer's environment. Anyway,
if you talk about ease-of-use and quick adoption, this is not simple enough.
I am sure that these issues prevent some people from using Maven - and that
was Eric's question.



> NTLM support would help but hey, it's a closed proprietary
> undocumented authentication scheme from Microsoft, you can't expect
> everyone to support it. 
> 

Again, Eric's question was what is people preventing from using it. The
reality in many companies is, they do use NTLM.



> As a workaround you can use NTLMAPS on
> sourceforge as a local proxy for any apps that don't know how to
> support NTLM.
> 

Possible, but unnecessarily complicated, and far away from "out-of-the-box".

Regards,
Arne
-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6088629
Sent from the Maven - Users forum at Nabble.com.


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

Re: [POLL] Why switch to Maven?

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

> In the company that I helped setting up a Maven-based build environment, a
> public site like ibiblio.org is considered a potentially unsafe source. Like
> it or not. Only JARs that have been approved internally may be used for
> production. (BTW, this was within finance industry which is partly quite
> sensitive at such points.)
>
> Practically, that meant we had to set up an internal remote repository and
> deploy all existing JARs to it. This worked fine in the end, but felt
> difficult in the beginning - probably due to the lack of good documentation
> and examples.

All the deployed artifacts have md5 sums. Your department could have
validated that all artifacts used were safe and compared the md5 sums
with the ones used locally and the ones downloaded.

> > Why can't you solve this with an in-house remote repository, rather than
> > zipping up jars for local repos?
> >
>
> You can do it with an in-house remote plugin repository, but how would you
> populate it with all plugins that you need? Ok, you can set up a proxy for
> this purpose. Then, you somehow have to make sure that Maven downloads all
> relevant plugins (this is not trivial either). Afterwards you can disconnect
> the proxy from Internet, or use the proxy's cache as your internal plugin
> repository. (Keeping the proxy alive and connected to the Internet might be
> unacceptable because you want to evaluate new plugins before you release
> them for internal usage.)

This stems from an anal configuration management policy, one that does
not trust your development team to "do the right thing (tm)".  It is
locking things down to prevent people from doing the wrong thing
instead of trusting them to do the right thing and then verifying that
you are.  After all, if can't trust your team to stick to approved
versions of artifacts how can you trust them to write your precious
business code?

So, how to you verify instead of lock?
You have a parent pom that declares and defines all versions of
artifacts and plugins and in your module poms you declare that you
want a plugin but you provide no version information.  Then your
configuration team only needs to check the parent pom against the
internal standards.

> When I wanted to use Maven-proxy for this purpose, I soon encountered
> problems because it did not support NTLM authentication, so I could not get
> through the firewall. So we helped us with zipping up a local repo as a
> workaround.

NTLM support would help but hey, it's a closed proprietary
undocumented authentication scheme from Microsoft, you can't expect
everyone to support it.  As a workaround you can use NTLMAPS on
sourceforge as a local proxy for any apps that don't know how to
support NTLM.

> Maybe it becomes clearer with an example: Let's say, your build uses plugin
> X which has a dependency to Xerces. So you will have Xerces in your local
> repository after running your build, because it is downloaded from the
> internal plugin repository to your local repository.
>
> Thereafter, you are able to declare a dependency to Xerces in your project,
> and the build will run through - even if Xerces has not been released to the
> internal remote repository, and there's no connection to the Internet.
>
> Builds should only be able to use artifacts that have explicitly been
> released to the internal remote repository. Nothing else. Even not JARs from
> an internal plugin repository.

Same argument as above.  Verify correctness don't try to enforce it.

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

Re: [POLL] Why switch to Maven?

[ArneD <pu...@degenring.de>]

cstamas wrote:
> 
> Right. Take Proximity for example, since it is not JUST proxy. If you
> visit
> the demo site, you will see that proximity is able to PROXY repositories
> but
> also to HOST them only. Furthermore, you can just "take offline" (offline
> ==
> do not touch remote peer!) or "take unavailable" (unavailable == refuse
> all
> requests) a repo from proximity by a switch.
> 

I agree, Proximity is promising, and I will definitely take a further look.
I first heard about it after initially setting up the Maven build
environment.

Eric's question was, what is people preventing from using Maven. The points
that I named did not prevent me from using Maven, neither from recommending
its usage. I just want to point out things that corporate users are
concerned of. All these things are solveable. The question is, how much do
you get out-of-the-box and how easy is it to use.



> And for Xerces example: IF you have a developer who declares an obiously
> existing (it's in repo downloaded from plugn repo) artifact which is
> obviously "forbidden" (it is not in company repo), than you have a HR
> problem. No software will ever overcome human stupidity. Nor IT rigidness.
> 

The reality in many companies is that you have people with very different
skills and experiences in IT departments. The idea of build automation is
not only to make life simpler, but also to help people to avoid mistakes.
Build automation should be easy-to-use for people even who use it the first
time. So, in the Xerces example, one might just not be aware of the fact
that Xerces is not in the company repository, but only in the plugin
repository.

Regards,
Arne
-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6088427
Sent from the Maven - Users forum at Nabble.com.


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

Re: [POLL] Why switch to Maven?

[Tamás Cservenák <t....@gmail.com>]

On 8/31/06, ArneD <public@degenring.de > wrote:
>
>
> ... Afterwards you can disconnect
> the proxy from Internet, or use the proxy's cache as your internal plugin
> repository. (Keeping the proxy alive and connected to the Internet might
> be
> unacceptable because you want to evaluate new plugins before you release
> them for internal usage.)


Why people think that some software can solve this autonomously? You will
anyway do some internal "company- wide" staging for plugin evaluation/JAR
introspection/ etc. So have a man put on this job and let he "filter" out
the unwanted stuff.

Keep inhouse repo server unplugged, you don't have to leave proxy "plugged
in".


When I wanted to use Maven-proxy for this purpose, I soon encountered
> problems because it did not support NTLM authentication, so I could not
> get
> through the firewall. So we helped us with zipping up a local repo as a
> workaround.


Firewall or proxy?

All  OSS based software will support NTLM as much as they can without PAYING
for specs. Proximity relies on Jakarta HttpClient, so it supports NTLM v1,
but not NTLM v2. Anyway, you can still enable DIGEST or BASIC auth on those
nasty M$ proxies to work in paralell with NTLM. Actually, IIS setup by
default enables NTLM, DIGEST and BASIC auths per default, in this order.
Here, you can force Proximity to use DIGEST or BASIC.


Anyway, I think that the whole task of setting up an internal plugin
> repository is too complicated. We don't want to use a proxy, so why do we
> have to set it up.


Right. Take Proximity for example, since it is not JUST proxy. If you visit
the demo site, you will see that proximity is able to PROXY repositories but
also to HOST them only. Furthermore, you can just "take offline" (offline ==
do not touch remote peer!) or "take unavailable" (unavailable == refuse all
requests) a repo from proximity by a switch.

Why is it better then hosting inhouse repo with plain Apache HTTPD? Well,
you have powerful artifact search, you have AccessManager, control over
availability per repository (and not per HTTPD server).... etc.

---
And for Xerces example: IF you have a developer who declares an obiously
existing (it's in repo downloaded from plugn repo) artifact which is
obviously "forbidden" (it is not in company repo), than you have a HR
problem. No software will ever overcome human stupidity. Nor IT rigidness.




~t~

Re: [POLL] Why switch to Maven?

[ArneD <pu...@degenring.de>]

Eric Redmond wrote:
> 
>> Especially in large companies, it is often unacceptable to let users
>> download artefacts directly from an Internet repository, even not through
>> a
>> proxy. Companies need to have full control over all artifacts used in
>> theirE
>> build processes, that means that only artefacts that have been explicitly
>> released by someone should be used.
> 
> 
> I don't understand  why a Proxy is unacceptible.  The administrator of the
> Proxy can - at any time- disconnect the Proxy from the internet.
> 

In the company that I helped setting up a Maven-based build environment, a
public site like ibiblio.org is considered a potentially unsafe source. Like
it or not. Only JARs that have been approved internally may be used for
production. (BTW, this was within finance industry which is partly quite
sensitive at such points.)

Practically, that meant we had to set up an internal remote repository and
deploy all existing JARs to it. This worked fine in the end, but felt
difficult in the beginning - probably due to the lack of good documentation
and examples.

The bigger problem was setting up an internal **plugin** repository:



>> This is especially true for setting up an internal plugin repository. We
>> did
>> not find a comfortable way to initially fill an internal plugin
>> repository.
>> You should be able to say "fill my plugin repository with all required
>> JARs
>> for the plugins x, y and z". Our workaround was to set up a Maven
>> reference
>> installation zip, that already has all required plugin JARs in its local
>> repository, so that users who unzip that archive have everything they
>> need.
> 
> 
> Why can't you solve this with an in-house remote repository, rather than
> zipping up jars for local repos?
> 

You can do it with an in-house remote plugin repository, but how would you
populate it with all plugins that you need? Ok, you can set up a proxy for
this purpose. Then, you somehow have to make sure that Maven downloads all
relevant plugins (this is not trivial either). Afterwards you can disconnect
the proxy from Internet, or use the proxy's cache as your internal plugin
repository. (Keeping the proxy alive and connected to the Internet might be
unacceptable because you want to evaluate new plugins before you release
them for internal usage.)

When I wanted to use Maven-proxy for this purpose, I soon encountered
problems because it did not support NTLM authentication, so I could not get
through the firewall. So we helped us with zipping up a local repo as a
workaround.

Anyway, I think that the whole task of setting up an internal plugin
repository is too complicated. We don't want to use a proxy, so why do we
have to set it up.

When talking about tools, companies are used to download the tool from the
vendor's site or install it from CD and then just use it. This is not
possible with Maven, you need an Internet connection during run-time, at
least until you have managed to set up an internal plugin repository.



>> Another point is, plugin JARs and production JARs should be separated.
>> This
>> is already possible for remote repositories, but it should be possible
>> for
>> the local repository as well. Tool JARs like xerces etc. are used both by
>> plugins and by projects. But just because some plugin needs a JAR file,
>> corporate users do not want to make that JAR available for builds.
>> Corporate
>> users just don't want to get tools mixed up with production software.
> 
> Why does your build software get mixed up with your production software?
> Using the release or dependency plugins will not bundle build tools with
> the
> jars to be released.
> 

Maybe it becomes clearer with an example: Let's say, your build uses plugin
X which has a dependency to Xerces. So you will have Xerces in your local
repository after running your build, because it is downloaded from the
internal plugin repository to your local repository.

Thereafter, you are able to declare a dependency to Xerces in your project,
and the build will run through - even if Xerces has not been released to the
internal remote repository, and there's no connection to the Internet.

Builds should only be able to use artifacts that have explicitly been
released to the internal remote repository. Nothing else. Even not JARs from
an internal plugin repository.



>> Anyway, Maven is a great piece of software, full of great ideas. But some
>> things still need to be improved before Maven has chances to achieve a
>> wide
>> acceptance.
> 
> 
> Unless I'm really misunderstanding the problems, I haven't seen a problem
> you've had that is inherent to Maven (except possibly by creating a mirror
> repository with a set of dependencies).
> 

Did my points get a little bit clearer now?

But don't get me wrong, I do not consider these points real showstoppers. We
did set up a Maven-based build environment succesfully in the end, and it
works quite well.

Regards,
Arne

-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6084903
Sent from the Maven - Users forum at Nabble.com.


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

Re: [POLL] Why switch to Maven?

[Eric Redmond <er...@gmail.com>]

On 8/31/06, ArneD <pu...@degenring.de> wrote:
>
>
>
> Eric Redmond wrote:
> >
> > Any more reasons? Care to expand these ideas?
> >
>
> Hi Eric,
>
> for corporate users, I believe there are some additional issues to the
> ones
> already named.
>
> Especially in large companies, it is often unacceptable to let users
> download artefacts directly from an Internet repository, even not through
> a
> proxy. Companies need to have full control over all artifacts used in
> their
> build processes, that means that only artefacts that have been explicitly
> released by someone should be used.


I don't understand  why a Proxy is unacceptible.  The administrator of the
Proxy can - at any time- disconnect the Proxy from the internet.

So when you start using Maven, you want
> to immediately set up an internal repository which, I believe, is still a
> too complicated task.


We did this by enacting a single build on our projects and let Proximity
fill itself. Once it has the artifacts it needs, disconnect it.

This is especially true for setting up an internal plugin repository. We did
> not find a comfortable way to initially fill an internal plugin
> repository.
> You should be able to say "fill my plugin repository with all required
> JARs
> for the plugins x, y and z". Our workaround was to set up a Maven
> reference
> installation zip, that already has all required plugin JARs in its local
> repository, so that users who unzip that archive have everything they
> need.


Why can't you solve this with an in-house remote repository, rather than
zipping up jars for local repos?

Another point is, plugin JARs and production JARs should be separated. This
> is already possible for remote repositories, but it should be possible for
> the local repository as well. Tool JARs like xerces etc. are used both by
> plugins and by projects. But just because some plugin needs a JAR file,
> corporate users do not want to make that JAR available for builds.
> Corporate
> users just don't want to get tools mixed up with production software.


Why does your build software get mixed up with your production software?
Using the release or dependency plugins will not bundle build tools with the
jars to be released.

Anyway, Maven is a great piece of software, full of great ideas. But some
> things still need to be improved before Maven has chances to achieve a
> wide
> acceptance.


Unless I'm really misunderstanding the problems, I haven't seen a problem
you've had that is inherent to Maven (except possibly by creating a mirror
repository with a set of dependencies). I'd chalk-up many of your problems
to lack of documentation or guidence, which we all agree is a problem.

I too handle large-scale corporate builds for a living, and that is part of
the reason for this poll. The problems I have had with Maven are few and far
between, mostly related to my own ignorance of where to look for help, or
bugs in the code. But I still hear from people  who refuse to use Maven and
I was intrigued as to why, since my own experience has been largely positive
- especially in the corporate space. I am finding more often than not that
people who have difficulty with Maven are attempting to use it it in
non-standard ways, or refuse to alter their project structures to match. Is
this a hubris of Maven or of the project developers? That is a question for
philosophers. What I do know is that Maven is a conceptual project
framework, as much as a software build system - just like Object Oriented
programming is as much conceptual construct, as it is a programming
language's tenet. Just as OO has evolved design patterns, and ant has best
practices, I feel that a lot of the problems with Maven are a lack of simple
"how-tos", largely due in part that its concepts are so new. Does than mean
that Maven is not worth using? I doubt it... as Russ mentioned above, Ant
can always be your stopgap.

Eric

Arne
>
> --
> View this message in context:
> http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6078097
> Sent from the Maven - Users forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: [POLL] Why switch to Maven?

[ArneD <pu...@degenring.de>]

Eric Redmond wrote:
> 
> Any more reasons? Care to expand these ideas?
> 

Hi Eric,

for corporate users, I believe there are some additional issues to the ones
already named.

Especially in large companies, it is often unacceptable to let users
download artefacts directly from an Internet repository, even not through a
proxy. Companies need to have full control over all artifacts used in their
build processes, that means that only artefacts that have been explicitly
released by someone should be used. So when you start using Maven, you want
to immediately set up an internal repository which, I believe, is still a
too complicated task.

This is especially true for setting up an internal plugin repository. We did
not find a comfortable way to initially fill an internal plugin repository.
You should be able to say "fill my plugin repository with all required JARs
for the plugins x, y and z". Our workaround was to set up a Maven reference
installation zip, that already has all required plugin JARs in its local
repository, so that users who unzip that archive have everything they need.

Another point is, plugin JARs and production JARs should be separated. This
is already possible for remote repositories, but it should be possible for
the local repository as well. Tool JARs like xerces etc. are used both by
plugins and by projects. But just because some plugin needs a JAR file,
corporate users do not want to make that JAR available for builds. Corporate
users just don't want to get tools mixed up with production software.

Anyway, Maven is a great piece of software, full of great ideas. But some
things still need to be improved before Maven has chances to achieve a wide
acceptance.

Arne

-- 
View this message in context: http://www.nabble.com/-POLL--Why-switch-to-Maven--tf2185174.html#a6078097
Sent from the Maven - Users forum at Nabble.com.


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

Re: [POLL] Why switch to Maven?

[christophe blin <cb...@tennaxia.com>]

Note : I already switched to maven2.

My main problem at the moment is the lack of documentation :
* Lack of good documentation => indeed this is a problem (especially for
some plugins and for the hacking of custom phase)
* I have to build native/non-Java code => it is also a problem I
encounter : I have some PHP code but I can not manage it with maven
(except for release management). If the documentation was better, I
surely could solve this issue though.

What helped to swith to maven was :
* incredible support for transitive dependencies (and so, how easy it is
to upgrade to a newer version of a dependency
* incredibly easy, when you start a project from scratch, to setup
(moreover, the maven layout is very good)

regards,
chris

Eric Redmond a écrit :
> Hi all Maven users!
>
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what helped
> you make the decision? If you don't: why did you avoid it?
>
> Here are some that I have heard in the past:
>
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
>
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond
>

-- 

_____________________________________________________________________
Tennaxia, www.tennaxia.com,
Pilotez vos obligations environnementales
_____________________________________________________________________
Siège social :
6, rue Léonard de Vinci - 53001 Laval Cedex -
Tél : 02 43 49 75 50 - Fax : 02 43 49 75 77
Agence Paris :
19, rue réaumur - 75003 Paris -
Tél : 01 42 77 04 19 - Fax : 08 25 19 19 61
Agence Lyon :
Parc du Chater - 63 rue de la garenne - 69340 FRANCHEVILLE -
Tél : 04 72 39 98 14 - Fax : 04 72 39 93 85
The information in this message sent by TENNAXIA is confidential 
and may be legally privileged. It is intended solely for the 
addressee(s). Access to this message by anyone else is unauthorized.
If you are not the intended recipient, please delete it and notify 
the sender : any disclosure, copying, distribution or any action 
taken or omitted to be taken in reliance on it, is prohibited and 
may be unlawful.


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

Re: [POLL] Why switch to Maven?

[Dion Gillard <di...@gmail.com>]

How about the uneasy transition for Maven 1.x projects.

On 8/30/06, Eric Redmond <er...@gmail.com> wrote:
> Hi all Maven users!
>
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what helped
> you make the decision? If you don't: why did you avoid it?
>
> Here are some that I have heard in the past:
>
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
>
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond
>
>


-- 
http://www.multitask.com.au/people/dion/
"If you even dream of beating me you'd better wake up and apologize" -
Muhammad Ali

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

Re: [POLL] Why switch to Maven?

[Scott Battaglia <sc...@rutgers.edu>]

I've just converted an application (JA-SIG CAS) from Maven 1 to Maven 2 
in a relatively short period of time (maybe about 2 days) and I'm 
completely enjoying my new Maven 2 experience :-)  Now, of course, I ran 
into the same documentation/plug-in configuration issues that everyone 
else probably did but overall I'm glad I made the switch.  Modules work 
much better in Maven 2 than the hackish way I had to get them in Maven 1 
and I'm more able to use the standard goals that having to write custom 
scripts.

My only problem now is figuring out the best way to let Eclipse handle 
the project and its modules (I don't like how the plug-in creates a 
"workspace").  That and the fact that not everything is in a Maven 
repository yet (Spring 2.0-rc3 among a couple of other things).

These are just my initial thoughts after using it for a short period of 
time.  They may change after I've actually tried to do a release ;-)

Scott Battaglia
Application Developer, Architecture & Engineering Team
Enterprise Systems and Services, Rutgers University
v: 732.445.0097 | f: 732.445.5493 | scott_battaglia@rutgers.edu 



Russ Tremain wrote:
> I am a proponent of Maven 2.
>
> We have converted a large, ant based build system, first to Maven 1.1,
> and now to Maven 2.
>
> There are many flaws.  There are many bugs.  Plugin configuration
> documentation is especially poor.  Configuration of plugins is
> inconsistent.  Etc., etc.  The maven 2 conversion was hard work,
> and took us about 20 person-weeks and many late nights.
>
> In other words, I consider Maven 2 to be bleeding edge, and yet
> you can still build a huge project with it (but there is a trick -
> see below).
>
> The growing pains will get better, especially if there is more
> discipline around plugin configuration and better testing of same.
> (I just spent 12 hours recovering from a plugin snapshot regression).
>
> So those are the bad things, but I have confidence that these issues
> will get resolved in fairly short order, especially if we all help
> by using Maven, reporting problems, and helping out where we can.
>
> The good thing is, we (software folks) work in a world
> of inter-dependent projects.  Maven solves that problem.  I think
> it is *the* problem that needs to be solved for software to progress
> faster.  How many of us have spent hours looking for the right version
> of this or that jar, and then checking it in as a binary in CVS or
> some other SCM?  Or developing one-off solutions to hand off kits
> to another project?  These configuration issues are productivity drains,
> and bug-engines, and contribute to the loss of portability of
> software workers among projects.
>
> So bottom line is: Maven 2 solves the dependency problem,
> and works now, even for complex projects.  The rest of the maven
> strong points (standard build lifecycle, standard source layout, etc.)
> are helpful, but in my opinion, the ability to look at a single XML file,
> and document all the external dependencies of the build system I'm creating, along with
> the ability to publish artifacts in a standard way, will ultimately carry
> the day.
>
> Now, here's the trick:  ant is the escape hatch.  If you can't yet
> do it with maven 2, you can do it with ant.  We still have a lot
> of ant code [1].  Some because a plugin was broken or lacking features,
> (the surefire and jar plugins were particular problems), some because we
> simply didn't have time to convert a set of working ant scripts, and some
> because we are waiting for a plugin to mature, so we can switch (jaxb comes to mind).
>
> Regards,
> -Russ
>
> [1] You can review a fairly large (93 poms) maven 2.0.4 open-source project here:
>
> 	https://open-esb.dev.java.net/
>
> The "m2.ant" files contain the ant code segments that were too large to inline in the poms.
>
> At 12:55 PM -0500 8/29/06, Eric Redmond wrote:
>   
>> Sorry, I forgot to mention, I'm focusing soley on Maven 2.x
>>
>> On 8/29/06, Eric Redmond <er...@gmail.com> wrote:
>>     
>>> Hi all Maven users!
>>>
>>> I'm beginning a study to outline the real reasons that people have for
>>> avoiding Maven. My questions to you all are:
>>> What were your anxieties about using Maven? If you use Maven: what helped
>>> you make the decision? If you don't: why did you avoid it?
>>>
>>> Here are some that I have heard in the past:
>>>
>>> * Lack of good documentation.
>>> * Community unwilling to help me with my problems.
>>> * Not "industry supported" or "mainstream" enough.
>>> * I don't like conforming to the Maven project layout.
>>> * My project is too complex to switch.
>>> * There are not enough plugins available.
>>> * We already have a large investement in tool X.
>>> * I have to build native/non-Java code.
>>>
>>> Any more reasons? Care to expand these ideas?
>>> Thanks for your help!
>>> ____
>>> Eric Redmond
>>> http://codehaus.org/~eredmond <http://codehaus.org/%7Eeredmond>
>>>
>>>       
>>
>> --
>> Eric Redmond
>> http://codehaus.org/~eredmond
>>     
>
>
> ---------------------------------------------------------------------
> 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: [POLL] Why switch to Maven?

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

On 8/30/06, Russ Tremain <Ru...@sun.com> wrote:
> I am a proponent of Maven 2.
[del]
> So bottom line is: Maven 2 solves the dependency problem,
> and works now, even for complex projects.  The rest of the maven
> strong points (standard build lifecycle, standard source layout, etc.)
> are helpful, but in my opinion, the ability to look at a single XML file,
> and document all the external dependencies of the build system I'm creating, along with
> the ability to publish artifacts in a standard way, will ultimately carry
> the day.
>
> Now, here's the trick:  ant is the escape hatch.  If you can't yet
> do it with maven 2, you can do it with ant.  We still have a lot
> of ant code [1].  Some because a plugin was broken or lacking features,
> (the surefire and jar plugins were particular problems), some because we
> simply didn't have time to convert a set of working ant scripts, and some
> because we are waiting for a plugin to mature, so we can switch (jaxb comes to mind).

I'll agree with Russ.

I found I was heading towards a cut-n-paste ant file where I only had
to configure a few project specific settings. But it was something I
had to maintain and extend when the project started using new
features.

With Maven's convention over configuration, all that cut-n-paste has
gone and I am left declaring what I want built and not how it gets
built.

Our project is an Eclipse Rich Client in a mobile car environment,
connecting over a wireless network to our JavaEE middle tier which
then goes off to our enterprise tier.
It's not trivial but it is also not terribly complicated.

It took me quite a while to read up on how to get maven to do stuff,
but any technology has a learning curve and as previously stated in
other topics that the learning curve is quite low if you just want the
basic compile, build jar life cycle.  When you start adding reporting,
other plugins like checkstyle, and assembling builds the learning
curve goes way up but it is not unmanageable. And for the most part
the existing Maven plugins do everything I want (with only some minor
bugs which were not difficult to provide patches for).

It has taken me between two to three months elapsed time (and maybe
about two months of solid effort) to get the build to this state by
building on a simple pom life cycle and slowly adding the pieces that
I needed to improve my build.  Having gone through this learning curve
I can jump start future projects by taking the parent pom's contents
and pasting it into a new project (at some stage I might consider
refactoring this into a common parent pom).
Would I have been better of with Ant? I don't think so, I especially
like that I have a local repository of jars that can be shared across
projects and that my internally developed projects can depend upon
each others binary builds with known versions instead of having to
build those projects from source.  For most of our developers it means
they only need the subset of modules they are working on and not the
whole project.

The only thing I have to sort out is how to get Maven to build Eclipse
plugins, and this is bleeding edge stuff that a number of people on
the list are starting to look at in earnest.
And as Russ points out, I have a workaround because I can use Ant until then.

Yes the documentation could use some more work (which is now
happening), but I usually find that a Nabble search of the dev or user
list after much reading finds me the answer I want and if necessary I
update the user wiki or provide documentation patches back. I wish
more users did the same.

All in all I have been very impressed with what I have been able to do
with Maven and I am left with a much more manageable build system as a
result.

Bae

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

Re: [POLL] Why switch to Maven?

[Russ Tremain <Ru...@Sun.COM>]

I am a proponent of Maven 2.

We have converted a large, ant based build system, first to Maven 1.1,
and now to Maven 2.

There are many flaws.  There are many bugs.  Plugin configuration
documentation is especially poor.  Configuration of plugins is
inconsistent.  Etc., etc.  The maven 2 conversion was hard work,
and took us about 20 person-weeks and many late nights.

In other words, I consider Maven 2 to be bleeding edge, and yet
you can still build a huge project with it (but there is a trick -
see below).

The growing pains will get better, especially if there is more
discipline around plugin configuration and better testing of same.
(I just spent 12 hours recovering from a plugin snapshot regression).

So those are the bad things, but I have confidence that these issues
will get resolved in fairly short order, especially if we all help
by using Maven, reporting problems, and helping out where we can.

The good thing is, we (software folks) work in a world
of inter-dependent projects.  Maven solves that problem.  I think
it is *the* problem that needs to be solved for software to progress
faster.  How many of us have spent hours looking for the right version
of this or that jar, and then checking it in as a binary in CVS or
some other SCM?  Or developing one-off solutions to hand off kits
to another project?  These configuration issues are productivity drains,
and bug-engines, and contribute to the loss of portability of
software workers among projects.

So bottom line is: Maven 2 solves the dependency problem,
and works now, even for complex projects.  The rest of the maven
strong points (standard build lifecycle, standard source layout, etc.)
are helpful, but in my opinion, the ability to look at a single XML file,
and document all the external dependencies of the build system I'm creating, along with
the ability to publish artifacts in a standard way, will ultimately carry
the day.

Now, here's the trick:  ant is the escape hatch.  If you can't yet
do it with maven 2, you can do it with ant.  We still have a lot
of ant code [1].  Some because a plugin was broken or lacking features,
(the surefire and jar plugins were particular problems), some because we
simply didn't have time to convert a set of working ant scripts, and some
because we are waiting for a plugin to mature, so we can switch (jaxb comes to mind).

Regards,
-Russ

[1] You can review a fairly large (93 poms) maven 2.0.4 open-source project here:

	https://open-esb.dev.java.net/

The "m2.ant" files contain the ant code segments that were too large to inline in the poms.

At 12:55 PM -0500 8/29/06, Eric Redmond wrote:
>Sorry, I forgot to mention, I'm focusing soley on Maven 2.x
>
>On 8/29/06, Eric Redmond <er...@gmail.com> wrote:
>>
>>Hi all Maven users!
>>
>>I'm beginning a study to outline the real reasons that people have for
>>avoiding Maven. My questions to you all are:
>>What were your anxieties about using Maven? If you use Maven: what helped
>>you make the decision? If you don't: why did you avoid it?
>>
>>Here are some that I have heard in the past:
>>
>>* Lack of good documentation.
>>* Community unwilling to help me with my problems.
>>* Not "industry supported" or "mainstream" enough.
>>* I don't like conforming to the Maven project layout.
>>* My project is too complex to switch.
>>* There are not enough plugins available.
>>* We already have a large investement in tool X.
>>* I have to build native/non-Java code.
>>
>>Any more reasons? Care to expand these ideas?
>>Thanks for your help!
>>____
>>Eric Redmond
>>http://codehaus.org/~eredmond <http://codehaus.org/%7Eeredmond>
>>
>
>
>
>--
>Eric Redmond
>http://codehaus.org/~eredmond


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

Re: [POLL] Why switch to Maven?

[Eric Redmond <er...@gmail.com>]

Sorry, I forgot to mention, I'm focusing soley on Maven 2.x

On 8/29/06, Eric Redmond <er...@gmail.com> wrote:
>
> Hi all Maven users!
>
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what helped
> you make the decision? If you don't: why did you avoid it?
>
> Here are some that I have heard in the past:
>
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
>
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond <http://codehaus.org/%7Eeredmond>
>



-- 
Eric Redmond
http://codehaus.org/~eredmond

Re: [POLL] Why switch to Maven?

[Stefan Magnus Landrø <st...@gjensidige.no>]

I've been reading through a lot of the replies to the Poll this morning.

It seems to me that we need a tool the does the following to be more 
productive with maven:

* Locates remote repositories, and potentially adds them to settings.xml 
or pom.xml
* Let's us upload 3rd party libraries to company-repository in seconds
* Provides access to documentation on plugins, and helps configuring them. 
I've spent lots of time searching for documentation and usage examples. 
* Helps you building the pom (/ poms in a multi-module environment). 
GUI-style. Something like the web.xml editors you can find in certain IDEs 
- just better ...

Stefan

"Eric Redmond" <er...@gmail.com> skrev 29.08.2006 19:55:12:

> Hi all Maven users!
> 
> I'm beginning a study to outline the real reasons that people have for
> avoiding Maven. My questions to you all are:
> What were your anxieties about using Maven? If you use Maven: what 
helped
> you make the decision? If you don't: why did you avoid it?
> 
> Here are some that I have heard in the past:
> 
> * Lack of good documentation.
> * Community unwilling to help me with my problems.
> * Not "industry supported" or "mainstream" enough.
> * I don't like conforming to the Maven project layout.
> * My project is too complex to switch.
> * There are not enough plugins available.
> * We already have a large investement in tool X.
> * I have to build native/non-Java code.
> 
> Any more reasons? Care to expand these ideas?
> Thanks for your help!
> ____
> Eric Redmond
> http://codehaus.org/~eredmond