Re: Trouble building Maven 2 trunk

[Mark Lundquist]

Brett Porter wrote:

The parent POM has been released, so we need to update that to 4  
instead of 4-SNAPSHOT...


- Brett


Hey thanks Brett & Vincent... OK, looks like that happened, I picked it 
up w/ "svn up".  Still no go.  So then I changed it back to 4-SNAPSHOT 
and tried again with -Papache... no love there either, so I reverted 
back to HEAD (4).  So here's what it it does now:


+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from: 
'/Users/ml/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from: 
'/usr/local/maven-2.0.4/conf/plugin-registry.xml'

[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM: org.apache.maven:maven-parent::4 of 
project: null:maven:pom:2.1-SNAPSHOT in relative path: ../pom/maven/pom.xml
[DEBUG] Parent-POM: org.apache.maven:maven-parent::4 not found in 
relative path: ../pom/maven/pom.xml
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::4 for 
project: null:maven:pom:2.1-SNAPSHOT from the repository.
[DEBUG] Searching for parent-POM: org.apache:apache::3 of project: 
org.apache.maven:maven-parent:pom:4 in relative path: ../asf/pom.xml
[DEBUG] Parent-POM: org.apache:apache::3 not found in relative path: 
../asf/pom.xml
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project: 
org.apache.maven:maven-parent:pom:4 from the repository.
[INFO] 


[ERROR] FATAL ERROR
[INFO] 


[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven:maven-parent:pom:4

Reason: Cannot find parent: org.apache:apache for project: 
org.apache.maven:maven-parent:pom:4




help! :-)
—ml—


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release JAR Plugin

[Jason van Zyl]

On 27 Aug 06, at 4:11 PM 27 Aug 06, Dennis Lundberg wrote:

Just curious, but are you testing features that we don't have  
tests for or just giving it a sanity check?


Just a sanity check to see that it works on a real project.



Cool.

I've released everything needed for the JAR plugin, but I think I  
need to let the codehaus repo sync first and tomorrow I'll whip up a  
little script to mimic a new user and make sure everything is coming  
down properly. So the JAR plugin should be released tomorrow.



--
Dennis Lundberg


Jason.

+1 for a release

--Dennis Lundberg

 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Jason van Zyl
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Documentation threads and outstanding tasks

[Brett Porter]

We have a proposal for a new navigation for commenting on:
http://mail-archives.apache.org/mod_mbox/maven-dev/200608.mbox/% 
[EMAIL PROTECTED]


Also my earlier proposal of the same nature:
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/% 
[EMAIL PROTECTED]


Roadmap: survey questions for getting a clearer idea of what to do next.
http://mail-archives.apache.org/mod_mbox/maven-dev/200608.mbox/% 
[EMAIL PROTECTED]


Proposal for changes to the plugin listing page:
http://mail-archives.apache.org/mod_mbox/maven-dev/200607.mbox/% 
[EMAIL PROTECTED]


Applying a uniform skin to the plugin sites:
http://mail-archives.apache.org/mod_mbox/maven-dev/200608.mbox/% 
[EMAIL PROTECTED]


A big long thread on documentation:
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/% 
[EMAIL PROTECTED]


A plugin documentation standard:
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/% 
[EMAIL PROTECTED]

( I think this is on the web site now?)

A list of outstanding questions about documentation:
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/% 
[EMAIL PROTECTED]


Specific tasks (all in JIRA now, I think):
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/% 
[EMAIL PROTECTED]


Then there's the threads in June "making docs and tests suck less"  
and "making the web site suck less".


I think that's enough to get everyone started :)

- Brett



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Preventing archetype resources being parsed

[Brett Porter]

I think there is a known issue abut this in JIRA.

Please ask questions on the users@maven.apache.org list so that we  
can keep this list for discussing development of Maven itself... thanks!


- Brett

On 25/08/2006, at 8:29 PM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:



Anyone knows if it is possible of preventing archetype resources being
subject to parsing.

I have developed an archetypeArtifact for creating a web application
skeleton based on an inhouse pattern. The project contains  
several .java
files, - and also graphics. The problem is that all files defined  
in the
archetype.xml are subject to Velocity template parsing. Is there  
any way

to prevent files being subject to Velocity parsing??

Geir

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Snapshot Locations for maven-plugins a maven-assembly-plugin

[Brett Porter]

http://maven.apache.org/guides/development/guide-testing-development- 
plugins.html


On 25/08/2006, at 10:47 PM, Alexis Midon wrote:


Hi all,

I'd like to use a snapshot version of the assembly plugin, but I  
can't found

out a snapshot repository.
Can someone tell me if such a repo is available or should I build a  
snapshot

by myself?

Thanks in advance,

Alexis


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RANT] Maven is both heaven and hell

[Brett Porter]

On 28/08/2006, at 7:14 AM, Wendell Beckwith wrote:

Take toady's latest example, say you want to remove an ant build  
file and do
things the maven way, so you decide to use the dependency plugin.   
The web

site examples have the group and artifactId being

org.apache.maven.plugin
dependency-maven-plugin


The dependency plugin was accepted to this project, but hasn't yet  
been released here. IMO, we should remove it from the plugin list or  
put it in a separate section as it shouldn't be considered ready for  
use here yet.


Still, please do file bugs against it where there are documentation  
issues.




1.) Publish a project plan and commit to periodic milestones.


Yes, we need a roadmap. Development on the Maven core has been on the  
backkburner as we fix peoples pressing issues and work on the plugins  
and, funnily enough, the documentation. As you'll have seen on this  
list recently, John has been putting a lot of topics together for  
discussion and they come up from time to time and get recorded. At  
some point in the near future we'll have a roadmap for 2.1 out.


A lot of plugins still are attached to beta APIs even when there  
are 2 or

more released versions of the artifact available.


Specific examples? I don't see this in any plugins that aren't  
themselves beta plugins.



For each milestone
release all code should be compiled with the latest as the rule  
rather than

the exception.


I'm not really sure what this achieves for the end user, and whether  
you are talking about just maven, or all its plugins too. I assume  
you are referring to us learning from Callisto here, which I've  
already ranted about on my blog, but I'd be interested to hear from  
someone who is closer to that community that knows the tangible  
benefits it brough.



The plan will let the community know what's coming and when
we can expect every milestone build between now and the release.   
The plan

is not static as you can updated whenever you want.


Yes, that's a good idea.



2.) Produce nightly and weekly integration builds.


We already do. We could do it better. I've brought this topic up a  
couple of times on the Continuum list.



Maybe this is
happening, but how would I know?  Both the Maven 2 and Continuum  
websites

have a dead link to the Continuous Integration server,
http://maven.zones.apache.org:8080/continuum.maven.zones.apache.org:8080/continuum>


This seems to be the problem. Our nightly builds are produced from an  
old system that we were intending to move to Continuum so hadn't  
published links to. On the Continuum side, we had to move the server  
"temporarily" due to resource constraints and the links haven't been  
updated yet. Please file an issue for these.




3. Update the website regularly.
Just split the thing down the middle into released info (doc,  
tutorials,
examples, etc) and development current info which at a minimum  
would be the

last stable milestone.


There's been significant discussion on this on the list already which  
I can give you pointers to if you need them, but I'm not rehashing  
them again. I'm happy with the plan we have.


Unfortunately, when people have put forward proposals recently  
they've been met with silence. We need more participation to get this  
moving.



However, could it
not be more efficient to release them in mass, especially if they  
have been

continuously updated to current API's/fixes.


Our experience is the opposite. We did this in Maven 1 and plugin  
releases were always stuck behind a core release. It takes a lot more  
effort to release every plugin at once.


The APIs are not a moving target. I like that we can push out a  
single plugin when it has fixes, and that old plugins continue to  
work with new releases of Maven.


On the other hand, it means we need a greater eye over everything to  
make sure plugins do get released regularly. This needs work.



Now I don't get to bitch, hit send and walk away, so what areas of the
website/documentation are available for a person who has some free  
time.

I'm hesitant to signup for something big due to day job and night time
commitments, but I do have some time and I'd like guidance on what  
areas I
can invest it with respect to making maven better.  I just want the  
pain to
stop.  Maven's a great tool and we receive a lot of benefits from  
its use.
However, we likely could do more, faster if some serious sharp  
edges were

child proofed.


I'm happy to guide you into any area where you are interested to help  
out. So, is it documentation that you want to help with? We have a  
list of outstanding tasks which I can put in one place.


Or would you like to help pull together the roadmap for external  
consumption?


- Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Trouble building Maven 2 trunk

[Brett Porter]

The parent POM has been released, so we need to update that to 4  
instead of 4-SNAPSHOT...


- Brett

On 27/08/2006, at 8:12 AM, Mark Lundquist wrote:


Hi,

I did a clean checkout of components/, did "mvn -X install", and  
got the error trace shown below.  I've renamed my settings.xml out  
of the way, so it should be defaults for everything... any ideas?   
Am I doing something wrong?


thx,
Mark
--


+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from: '/Users/ 
ml/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from: '/usr/ 
local/maven-2.0.4/conf/plugin-registry.xml'

[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM: org.apache.maven:maven-parent::4- 
SNAPSHOT of project: null:maven:pom:2.1-SNAPSHOT in relative  
path: ../pom/maven/pom.xml
[DEBUG] Parent-POM: org.apache.maven:maven-parent::4-SNAPSHOT not  
found in relative path: ../pom/maven/pom.xml
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::4- 
SNAPSHOT for project: null:maven:pom:2.1-SNAPSHOT from the repository.

[DEBUG] Skipping disabled repository central
[DEBUG] maven-parent: using locally installed snapshot
[DEBUG] Skipping disabled repository central
[INFO]  
-- 
--

[ERROR] FATAL ERROR
[INFO]  
-- 
--

[INFO] Failed to resolve artifact.

GroupId: org.apache.maven
ArtifactId: maven-parent
Version: 4-SNAPSHOT

Reason: Unable to download the artifact from any repository

  org.apache.maven:maven-parent:pom:4-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


[INFO]  
-- 
--

[DEBUG] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find  
parent: org.apache.maven:maven-parent for project: null:maven:pom: 
2.1-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects 
(DefaultMaven.java:365)
at org.apache.maven.DefaultMaven.doExecute 
(DefaultMaven.java:278)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 
115)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced 
(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode 
(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException:  
Cannot find parent: org.apache.maven:maven-parent for project:  
null:maven:pom:2.1-SNAPSHOT
at  
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage 
(DefaultMavenProjectBuilder.java:1161)
at  
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal 
(DefaultMavenProjectBuilder.java:674)
at  
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFil 
eInternal(DefaultMavenProjectBuilder.java:416)
at org.apache.maven.project.DefaultMavenProjectBuilder.build 
(DefaultMavenProjectBuilder.java:192)
at org.apache.maven.DefaultMaven.getProject 
(DefaultMaven.java:515)
at org.apache.maven.DefaultMaven.collectProjects 
(DefaultMaven.java:447)
at org.apache.maven.DefaultMaven.getProjects 
(DefaultMaven.java:351)

... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM  
'org.apache.maven:maven-parent' not found in repository: Unable to  
download the artifact from any repository


  org.apache.maven:maven-parent:pom:4-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

at  
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepos 
itory(DefaultMavenProjectBuilder.java:513)
at  
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage 
(DefaultMavenProjectBuilder.java:1157)

... 17 more
Caused by:  
org.apache.maven.artifact.resolver.ArtifactNotFoundException:  
Unable to download the artifact from any repository


  org.apache.maven:maven-parent:pom:4-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

at  
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve 
(DefaultArtifactResolver.java:136)
at  
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve 
(DefaultArtifactResolver.java:63)
at  
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepos 
itory(DefaultMavenProjectBu

Re: Bad link on "About Maven 2.0" page

[Vincent Siveton]

2006/8/26, Mark Lundquist <[EMAIL PROTECTED]>:

Hi, I am totally new to the ways of Maven!  Anyway...

On http://maven.apache.org/about.html, under "Can I get involved", the
text "For more information, please see How to Help." contains a link to
a bad URI (http://maven.apache.org/contributing/help.html).  The link
should be to http://maven.apache.org/guides/development/guide-helping.html.


Fixed. Thanks!


Is this mailing list the right place to report this?


Yes or you could create an issue (better):
http://jira.codehaus.org/browse/MNG
and specify a documentation component.


Anyway... looking forward to learning Maven 2! :-)


Thanks!

Vincent


cheers,
—ml—





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Trouble building Maven 2 trunk

[Vincent Siveton]

Hi Mark,

Maven Parent POM v4 has been recently voted [1] and it is present on
the apache snapshot. Try to use apache snapshot in your settings [2].

HTH

Vincent

[1] 
http://www.nabble.com/-vote--Release-Maven-Parent-POM-v4-tf2082622.html#a5738057
[2] 
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html

2006/8/26, Mark Lundquist <[EMAIL PROTECTED]>:

Hi,

I did a clean checkout of components/, did "mvn -X install", and got the
error trace shown below.  I've renamed my settings.xml out of the way,
so it should be defaults for everything... any ideas?  Am I doing
something wrong?

thx,
Mark
--


+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from:
'/Users/ml/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'/usr/local/maven-2.0.4/conf/plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM:
org.apache.maven:maven-parent::4-SNAPSHOT of project:
null:maven:pom:2.1-SNAPSHOT in relative path: ../pom/maven/pom.xml
[DEBUG] Parent-POM: org.apache.maven:maven-parent::4-SNAPSHOT not found
in relative path: ../pom/maven/pom.xml
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::4-SNAPSHOT
for project: null:maven:pom:2.1-SNAPSHOT from the repository.
[DEBUG] Skipping disabled repository central
[DEBUG] maven-parent: using locally installed snapshot
[DEBUG] Skipping disabled repository central
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] Failed to resolve artifact.

GroupId: org.apache.maven
ArtifactId: maven-parent
Version: 4-SNAPSHOT

Reason: Unable to download the artifact from any repository

  org.apache.maven:maven-parent:pom:4-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)


[INFO]

[DEBUG] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
org.apache.maven:maven-parent for project: null:maven:pom:2.1-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
find parent: org.apache.maven:maven-parent for project:
null:maven:pom:2.1-SNAPSHOT
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1161)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.maven:maven-parent' not found in repository: Unable to
download the artifact from any repository

  org.apache.maven:maven-parent:pom:4-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:513)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1157)
... 17 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to download the artifact from any repository

  org.apache.maven:maven-parent:pom:4-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:136)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolv

Re: [RANT] Maven is both heaven and hell

[Graham Leggett]

Jason Dillon wrote:

I'm curious... what "key maven1 features" are you referring to that have 
not been completed in maven2?


Some specific ones that bit us were the inability to embed dependencies 
into EJBs, and the EAR plugin's inability to handle Jboss specific 
artifacts, like HAR files. We also had problems with the VSS SCM plugin, 
which is present, but doesn't work. These are specific examples that 
spring to mind, there were others as well.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RANT] Maven is both heaven and hell

[Jason Dillon]

I'm curious... what "key maven1 features" are you referring to that  
have not been completed in maven2?


--jason


On Aug 27, 2006, at 2:52 PM, Graham Leggett wrote:


Wendell Beckwith wrote:

> You're like
original band members, but it hurts to say that you all are  
getting your
asses handed to you by orgs like Spring and Eclipse.  There just  
doing a far

better job on the dcomentation and website.


Having used maven1 for a long time (and having been blown away by  
the concept of a build system that "already knew how to do stuff in  
a mutually agreed way", replacing "yet another half written custom  
ant script"), I decided that it was time to sell the current  
project team on the idea of maven2.


The conclusion of the attempt to use maven2 is that it is simply  
not finished yet. Some features taken for granted in maven1 are  
missing/incomplete, and the documentation is missing/incomplete.


I think the maven2 project is showing signs of the second system  
effect - maven1 was carefully and thoughtfully constructed,  
documentation carefully and thoughtfully created. And - it helped  
that maven1 was largely complete before people discovered the  
concept of an intelligent build system.


maven2 seems to have been built with enthusiasm - but crucial  
elements (like key maven1 features, and documentation) have not  
been completed.


Luckily, there is no evidence of the second system effect in the  
design of maven2 (IMHO of course), the problems are in the finish  
of the software, meaning that fixing this means altering the focus  
from new features to finishing existing ones, and completing the  
documentation (as opposed to revisiting a design, or rewriting code).


The reason this is important is this:

maven1 was a complete no brainer to sell to projects. Once I had  
shown people that there was no need to construct ant scripts to do  
everyday tasks, maven1 "just knew" how to do things, and this was a  
huge win, case closed.


On the particular project I am on now, maven1 was considered and  
rejected for not supporting transitive dependencies (fair enough)  
so they cooked up their own half working ant scripts, using ivy to  
handle dependencies. maven2 does support transitive dependencies,  
so in theory it should have been a no brainer sell, as before. But  
in reality my testing the waters has uncovered a miriad of  
problems, leading us to suggest that maven2 initially just be used  
to generate documentation (mvn site).


I agree with comments that the documentation needs urgent work, and  
I as a new user of maven2, have been trying to add what I consider  
missing information from a new user point of view to JIRA (ie, what  
information would have helped me use maven2, that was missing or  
incomplete).


If users could channel issues causing them frustration with the  
docs into concise JIRA reports "I am trying to perform task X but  
the docs don't tell me how" (which needs to be done at the time,  
because after you finally figured out the problem, suddenly that  
JIRA report doesn't seem so urgent any more), it will go a long way  
to indicate to developers where there are gaps that need filling.


Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RANT] Maven is both heaven and hell

[Graham Leggett]

Wendell Beckwith wrote:

> You're like

original band members, but it hurts to say that you all are getting your
asses handed to you by orgs like Spring and Eclipse.  There just doing a 
far

better job on the dcomentation and website.


Having used maven1 for a long time (and having been blown away by the 
concept of a build system that "already knew how to do stuff in a 
mutually agreed way", replacing "yet another half written custom ant 
script"), I decided that it was time to sell the current project team on 
the idea of maven2.


The conclusion of the attempt to use maven2 is that it is simply not 
finished yet. Some features taken for granted in maven1 are 
missing/incomplete, and the documentation is missing/incomplete.


I think the maven2 project is showing signs of the second system effect 
- maven1 was carefully and thoughtfully constructed, documentation 
carefully and thoughtfully created. And - it helped that maven1 was 
largely complete before people discovered the concept of an intelligent 
build system.


maven2 seems to have been built with enthusiasm - but crucial elements 
(like key maven1 features, and documentation) have not been completed.


Luckily, there is no evidence of the second system effect in the design 
of maven2 (IMHO of course), the problems are in the finish of the 
software, meaning that fixing this means altering the focus from new 
features to finishing existing ones, and completing the documentation 
(as opposed to revisiting a design, or rewriting code).


The reason this is important is this:

maven1 was a complete no brainer to sell to projects. Once I had shown 
people that there was no need to construct ant scripts to do everyday 
tasks, maven1 "just knew" how to do things, and this was a huge win, 
case closed.


On the particular project I am on now, maven1 was considered and 
rejected for not supporting transitive dependencies (fair enough) so 
they cooked up their own half working ant scripts, using ivy to handle 
dependencies. maven2 does support transitive dependencies, so in theory 
it should have been a no brainer sell, as before. But in reality my 
testing the waters has uncovered a miriad of problems, leading us to 
suggest that maven2 initially just be used to generate documentation 
(mvn site).


I agree with comments that the documentation needs urgent work, and I as 
a new user of maven2, have been trying to add what I consider missing 
information from a new user point of view to JIRA (ie, what information 
would have helped me use maven2, that was missing or incomplete).


If users could channel issues causing them frustration with the docs 
into concise JIRA reports "I am trying to perform task X but the docs 
don't tell me how" (which needs to be done at the time, because after 
you finally figured out the problem, suddenly that JIRA report doesn't 
seem so urgent any more), it will go a long way to indicate to 
developers where there are gaps that need filling.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

[RANT] Maven is both heaven and hell

[Wendell Beckwith]

I primarily deal with 2 open source organizations, Apache and Eclipse.  To a
lesser degree, I also interact with tigris.org for subversion and subclipse,
springframework.org for more and more each week it seems and a few other
".org" organizations.  I like to think I grok open source software and how
the communities functions.  I know no one owes me anything and that if I
find a bug or realize a good enhancement then its part of my community
commitment to create a reproducible bug report or even better a well thought
out patch to the current code.  In the long run, this will benefit me as
well as others, leading to a win-win for everyone involved.  To a large
extent the ASF helped start the open source community gig.  You're like
original band members, but it hurts to say that you all are getting your
asses handed to you by orgs like Spring and Eclipse.  There just doing a far
better job on the dcomentation and website.  This all my opinion, with the
collective opinions of a few others thrown in, but the truth is that it is
becoming flat out painful to deal with some ASF projects, Log4j and Maven in
particular.  Log4j has been circle jerking on how to releae the 1.3 version
of the code and maintain backwards compatibility.  It may be impractical to
impossible to do so, then rev the version to 2.0, jump to java 5 as a
minimum and completely do away with backwards compatibility.  But that's a
logging project issue now a maven one.  To paraphrase, the problem with
Maven is that there are "lies, damn lies and the maven documentation".

Take toady's latest example, say you want to remove an ant build file and do
things the maven way, so you decide to use the dependency plugin.  The web
site examples have the group and artifactId being

org.apache.maven.plugin
dependency-maven-plugin

That doesn't look right because most maven plugins are in the "
org.apache.maven.plugins" groupId.  You decide to follow the source repo
link and it takes you to the maven-dependency-plugin project.  Looking at
the project's pom confirms that the groupId is "org.apache.maven.plugins"
and that the artifactId is really "maven-dependency-plugin".  Well we solved
that, let's try and use it.  Unfortunately it is not available from any repo
I currently know of.  Damn this is inconvenient, but we'll just have to
build it from source.  Oh, wait after checking the project out it won't
build because it requires an unreleased
org.apache.maven.plugins:maven-plugins:pom:2-SNAPSHOT, SON OF A [EMAIL 
PROTECTED] I
just about wanted to bloody slot myself to stop the pain.

Now some things that I think would improve things is the adoption of some of
the things that I think make the Eclipse Foundation great.

1.) Publish a project plan and commit to periodic milestones.
A lot of plugins still are attached to beta APIs even when there are 2 or
more released versions of the artifact available.  For each milestone
release all code should be compiled with the latest as the rule rather than
the exception.  The plan will let the community know what's coming and when
we can expect every milestone build between now and the release.  The plan
is not static as you can updated whenever you want.

2.) Produce nightly and weekly integration builds.
For eclipse, devs have to move up to integration builds and if the builds
fail then work is done to fix and verify before moving on. It should be
simple for us (the community) to download a build at anytime from a standard
location.  We should also be able to view a report on the tests so that we
can detrmine if it is worth our time to pick it up or not.  Maybe this is
happening, but how would I know?  Both the Maven 2 and Continuum websites
have a dead link to the Continuous Integration server,
http://maven.zones.apache.org:8080/continuum.

3. Update the website regularly.
Just split the thing down the middle into released info (doc, tutorials,
examples, etc) and development current info which at a minimum would be the
last stable milestone.

I realize that there my be bylaw rules, etc. differences between the ASF and
EF.  Take voting for example.  I'm on the mailing list and there are votes
called for this plugin and that one from time to time.  However, could it
not be more efficient to release them in mass, especially if they have been
continuously updated to current API's/fixes.  Just call for a vote now that
in  weeks time we will release all core maven plugins for Maven 2.1 M3.
This has 2 immediate effects, 1.) the community knows exactly  (give or take
a day or two for last minute issues)  when the next milestone is and 2.)
other maven community plugin devs can plan their releases to sync with
yours.

Now I don't get to bitch, hit send and walk away, so what areas of the
website/documentation are available for a person who has some free time.
I'm hesitant to signup for something big due to day job and night time
commitments, but I do have some time and I'd like gui

Re: [VOTE] Release JAR Plugin

[Dennis Lundberg]

Jason van Zyl wrote:

On 27 Aug 06, at 9:08 AM 27 Aug 06, Dennis Lundberg wrote:


Jason van Zyl wrote:

On 23 Aug 06, at 4:51 PM 23 Aug 06, Dennis Lundberg wrote:

Jason van Zyl wrote:

Hi,
There are 39 issues that have been resolved since the last release 
of the JAR plugin:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11137&fixfor=12241 
I've also applied the most recent patches for optional archive 
creation.

+1
Jason van Zyl
[EMAIL PROTECTED]


I'd like to give the latest version a spin before voting.

You happy with this now? I've applied Jochen's patch and made a note 
that the deletion code should use plexus-utils (which deals with 
problems on Windows and some bugs in a couple JDKs).


Yes, I've just finished testing the new signing features.



Just curious, but are you testing features that we don't have tests for 
or just giving it a sanity check?


Just a sanity check to see that it works on a real project.

--
Dennis Lundberg



Jason.


+1 for a release

--Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Is the maven-compiler-plugin really usable with alternate compilers?

[Wendell Beckwith]

I looked through the open issues and didn't see anything but is there any
known gotchas about using alternate compilers with the
maven-compiler-plugin, like it's not fully baked/supported yet?  Because as
issue http://jira.codehaus.org/browse/MCOMPILER-43, details it is unsafe to
use the eclipse compiler component as classes either don't get written or
disappear.

Wb

Re: [VOTE] Release JAR Plugin

[Jason van Zyl]

On 27 Aug 06, at 9:08 AM 27 Aug 06, Dennis Lundberg wrote:


Jason van Zyl wrote:

On 23 Aug 06, at 4:51 PM 23 Aug 06, Dennis Lundberg wrote:

Jason van Zyl wrote:

Hi,
There are 39 issues that have been resolved since the last  
release of the JAR plugin:
http://jira.codehaus.org/secure/IssueNavigator.jspa? 
reset=true&pid=11137&fixfor=12241 I've also applied the most  
recent patches for optional archive creation.

+1
Jason van Zyl
[EMAIL PROTECTED]


I'd like to give the latest version a spin before voting.

You happy with this now? I've applied Jochen's patch and made a  
note that the deletion code should use plexus-utils (which deals  
with problems on Windows and some bugs in a couple JDKs).


Yes, I've just finished testing the new signing features.



Just curious, but are you testing features that we don't have tests  
for or just giving it a sanity check?


Jason.


+1 for a release

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release JAR Plugin

[Dennis Lundberg]

Jason van Zyl wrote:

On 23 Aug 06, at 4:51 PM 23 Aug 06, Dennis Lundberg wrote:


Jason van Zyl wrote:

Hi,
There are 39 issues that have been resolved since the last release of 
the JAR plugin:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11137&fixfor=12241 
I've also applied the most recent patches for optional archive creation.

+1
Jason van Zyl
[EMAIL PROTECTED]


I'd like to give the latest version a spin before voting.



You happy with this now? I've applied Jochen's patch and made a note 
that the deletion code should use plexus-utils (which deals with 
problems on Windows and some bugs in a couple JDKs).


Yes, I've just finished testing the new signing features.

+1 for a release

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release JAR Plugin

[Jason van Zyl]

On 23 Aug 06, at 4:51 PM 23 Aug 06, Dennis Lundberg wrote:


Jason van Zyl wrote:

Hi,
There are 39 issues that have been resolved since the last release  
of the JAR plugin:
http://jira.codehaus.org/secure/IssueNavigator.jspa? 
reset=true&pid=11137&fixfor=12241 I've also applied the most  
recent patches for optional archive creation.

+1
Jason van Zyl
[EMAIL PROTECTED]


I'd like to give the latest version a spin before voting.



You happy with this now? I've applied Jochen's patch and made a note  
that the deletion code should use plexus-utils (which deals with  
problems on Windows and some bugs in a couple JDKs).



Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]