Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hilco Wijbenga]

On Tue, Jul 19, 2022 at 10:15 AM Karl Heinz Marbaise  wrote:
> On 19.07.22 19:10, Tamás Cservenák wrote:
> > Actually, yes, I keep forgetting about release flag: so, if running on
> > LTS, user can do:
> > - use compiler "release" flag to target any Java from 8 to 17 (up to
> > current LTS it runs on)
>
> You can build for target JDK 7 with JDK17 via --release ...
> and also not ONLY on LTS release of JDK you can use also non LTS
> versions for that...

This only affects the generated bytecode, though? If you use anything
only available in a later JDK then your app/library will fail at
runtime, i.e. once it hits something that is actually _running_ the
older JDK.

Perhaps things have improved in this area but when we tried this
(years ago), it was a pain.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: POM 5: The problems with mixins

[Hilco Wijbenga]

On 4 December 2016 at 14:56, Stephen Connolly
 wrote:
> I'm currently trying to figure out how to make mixins possible in POM 5.

This is wonderful news!

> Mixins basically bring a form of multiple inheritance to the POM... which
> leads to the problems of how to solve conflicts.

Why allow both inheritance and mixins? Why not simply allow only one
or the other? Or rather, allow inheritance only until mixins enter the
picture. So you could have a grandparent POM (without mixins), a
parent POM (without mixins), and then a child POM (potentially with
mixins). I don't really see the value in inheritance if mixins are
available. (But I can see why it would be nice to try and re-use an
existing company POM or similar.)

That still leaves the problem of including contradicting mixins. I
would simply disallow any contradictions. Keep it as simple as
possible, you can always make it more complex later. It is already
going to be quite difficult to clearly explain any encountered
problems to the user without any additional complexity.

Some more thoughts:

1. Mixin A says A but Mixin B says
B. Maven should disallow that. The solution for
this would be to reference a property. Then both A and B could simply
state ${element.value}. Obviously, this may clash
(there may have been a very good reason for requiring "A" or "B") but
it is now up to the user to set ${element.value} appropriately or
change the combination of mixins. I don't see how Maven would be able
to resolve this.

2. Mixin A says  but Mixin B says
. Again, this should not be allowed.
Maven can't possibly tell whether the order is relevant.

I have been thinking of a tool to do exactly this. It would use mixins
to generate the entire POM. With the above restrictions it seems
possible to achieve a real "define it once" type of build. Obviously,
it would be much nicer if Maven simply supported this natively. :-)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Git as the canonical SCM

[Hilco Wijbenga]

On 4 September 2012 14:29, Mark Struberg strub...@yahoo.de wrote:
 just take as example that you like to checkout all maven core plugins in one 
 go because you like to do some refactoring/checks/upgrade.
 That would require you to go into each plugin project and get the stuff from 
 there. And where would you put the aggregator pom for CI and development 
 builds?

 Same applies to all other projects which are kind of 'aggregator' like 
 maven-core, shared, etc

You might want to have a look at git subtree. While it's currently in
contrib, it *is* distributed with Git (since 1.7.11).

Having said that, nothing is stopping you from simply using a single
Git repository. :-)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects

[Hilco Wijbenga]

On 27 April 2012 01:34, Vincent Latombe vincent.lato...@gmail.com wrote:
 I would be very interested to have [1] implemented. Our use case is to
 compile a subpart of our aggregator + all associated dependencies. The
 current behaviour requires us to provide *all* individual modules, which
 defeats the purpose of aggregators.

 I've made a patch proposal a while ago [2] but got so far no feedback
 (positive or negative). I know that you don't monitor pull requests on GH
 for Maven, but since in my company we start having serious needs for this,
 I'd like to take the necessary steps for this to be integrated. I'm
 guessing some ITs will be required, but I just want to know if the change
 sounds like a reasonable one (given that is changing a bit the semantic of
 the '-pl' option).

 Thanks for your feedback,

What about -am and -amd? (I have not actually used these switches, nor
-pl, so this is really a question. It's just that mvn -h seems to
imply they all work together.)

 [1] http://jira.codehaus.org/browse/MNG-4637
 [2] https://github.com/apache/maven-3/pull/2

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects

[Hilco Wijbenga]

On 27 April 2012 13:29, Jesse Glick jesse.gl...@oracle.com wrote:
 On 04/27/2012 01:39 PM, Hilco Wijbenga wrote:

 What about -am and -amd?

 -am does work together with -pl. Vincent's issue is that -pl must be given a
 full list of submodules; just passing an aggregator is not enough. For
 example, take

 top
 +- libs
 |  +- lib1
 |  +- lib2
 +- apps
   +- app1
   |  +- mod1  [lib1]
   |  +- mod2  []
   +- app2
      +- mod1  []
      +- mod2  [lib2]

 where top, libs, apps, app1, and app2 are aggregator projects. Now say you
 want to build the first application. What should you do?

 1. 'cd apps/app1  mvn' will not work unless lib1 has been previously
 built; -am does not help.

 2. 'mvn -pl apps/app1 -am' will just install app1-$version.pom; it does not
 recurse into mod1  mod2. (*)

 3. 'mvn -pl apps/app1,apps/app1/mod1,apps/app1/mod2 -am' works (builds also
 lib1) but requires you on the command line to determine what the submodules
 of apps/app1 are.

Great, thanks! That makes it a lot clearer.

 My own MNG-5059 [1] is a little related: the Maven CLI offers only limited
 options for building a set of modules. Perhaps there should be a DSL for
 selecting subsets of a reactor tree in various ways and building the subsets
 thus calculated to particular phases, all within a single CLI invocation.
 The old reactor:make could be revamped to do this, I guess, leaving M3's
 built-in options just for the simplest cases.

I guess this could be part of Maven Shell?

Actually, I've been working on a Maven extension that uses checksums
to determine whether a particular project needs to be rebuilt (taking
all its dependencies into account). We are currently using a Bash
script for that purpose. It simply invokes Maven for each project that
needs to be (re)built but, obviously, doing this from Maven directly
is much easier, faster, and more reliable.

 (*) As Jason points out, existing systems may rely on an aggregator project
 passed to -pl being interpreted without recursion. In particular, NetBeans
 IDE priming builds rely on this behavior.

 [1] http://jira.codehaus.org/browse/MNG-5059


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects

[Hilco Wijbenga]

On 27 April 2012 17:51, Chris Graham chrisgw...@gmail.com wrote:
 On Sat, Apr 28, 2012 at 7:04 AM, Hilco Wijbenga 
 hilco.wijbe...@gmail.comwrote:


 Actually, I've been working on a Maven extension that uses checksums
 to determine whether a particular project needs to be rebuilt (taking
 all its dependencies into account). We are currently using a Bash
 script for that purpose. It simply invokes Maven for each project that
 needs to be (re)built but, obviously, doing this from Maven directly
 is much easier, faster, and more reliable.


 Use Hudson/Jenkins for this, that's what I use.

This is for local development. The build server isn't in the picture
yet. It would not be smart to have the build server skip parts of the
build anyway.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: discussion on MNG-4637 : -pl switch negates recursion into sub projects

[Hilco Wijbenga]

On 27 April 2012 18:20, Chris Graham chrisgw...@gmail.com wrote:
 On Sat, Apr 28, 2012 at 11:06 AM, Hilco Wijbenga
 hilco.wijbe...@gmail.comwrote:

  On 27 April 2012 17:51, Chris Graham chrisgw...@gmail.com wrote:
  On Sat, Apr 28, 2012 at 7:04 AM, Hilco Wijbenga 
 hilco.wijbe...@gmail.comwrote:
 
 
  Actually, I've been working on a Maven extension that uses checksums
  to determine whether a particular project needs to be rebuilt (taking
  all its dependencies into account). We are currently using a Bash
  script for that purpose. It simply invokes Maven for each project that
  needs to be (re)built but, obviously, doing this from Maven directly
  is much easier, faster, and more reliable.
 
 
  Use Hudson/Jenkins for this, that's what I use.

 This is for local development. The build server isn't in the picture
 yet. It would not be smart to have the build server skip parts of the
 build anyway.

 No, that's not true. If the project build resolution is deterministic, ie
 it will always result in the same build result. This is good or standard
 SCM practice.

What isn't true?

You are not seriously suggesting we now do all local development via
the build server, are you? That would be insanely inefficient. Not to
mention the total chaos that would ensue.

Local development is *local*, on your local machine, it hasn't reached
anything or anyone else yet. I don't think we are talking about the
same thing. :-) Or at least, I hope so. ;-)

 Jenkins fingerprinting (not that I've used that one much) or M2 job type
 (that I have almost always used) dependency analysis does exactly this.

In my experience, Jenkins' dependency analysis only works if nothing
(POM wise) has changed. As soon as you add/delete/move dependencies,
it gets confused and builds things in the wrong order resulting in
failed builds. Given that it doesn't know about all changes at the
same time, this is not entirely unexpected, I suppose. But now we're
veering off topic. :-)

 However, by definition, a release build, would (and should) result in a
 full build.

 -Chris

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven 3.0

[Hilco Wijbenga]

On 4 October 2010 05:16, Benjamin Bentmann benjamin.bentm...@udo.edu wrote:
 feedback on the RCs seems to be decreasing and I am currently not aware of
 any major regression so let's try and cross the finishing line of this
 marathon.

I seem to have a problem with a combination of Maven 2 and 3:

http://mail-archives.apache.org/mod_mbox/maven-users/201010.mbox/browser

In summary, it works with Maven 3 but not with Maven 2 (any more). It
was suggested I bring it up here. I would greatly appreciate your
comments (not here, of course, but on the users list).

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven core : Plexus vs Spring / OSGi ?

[Hilco Wijbenga]

On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
snip/
  And ultimately the container DI is not the important part but the
 implementations of our components. Using standard annotations for that is a
 good thing and that's not hard. XBR does full JEE injection and can manage
 any sort of annotation based DI because it's entirely agnostic. At any rate
 full support for that is now possible with XBR.

XBR? I did some googling but all I could find (aside from lots of TVs)
was a reference to an apparently brand new Maven 2.1 project. No
website or anything. Where can I find more information?

Cheers,
Hilco

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

Re: Maven Enforcer Plugin

[Hilco Wijbenga]

On Jan 10, 2008 6:33 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
 Hilco, I'll have to take a deeper look, it's possible that I missed some
 other cases. I had to manually read and interpret the poms since I
 couldn't get them unmolested from the core. Can you open a jira and
 attach a sample so I can debug it?

http://jira.codehaus.org/browse/MENFORCER-29

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

Maven Enforcer Plugin

[Hilco Wijbenga]

I ran into some issues with the Maven Enforcer plugin. Since I'm using
the latest and greatest straight from Subversion I didn't want to
create a JIRA ticket without first making sure that that would be
helpful.

Given that 1.0-alpha-3 doesn't support requirePluginVersions I want to
use 1.0-SNAPSHOT. However, I don't want to force other developers to
install the Enforcer locally (I haven't set up a mirror repository
yet) so I figured I'd use a profile. As it turns out, however, if I
put m-e-p in a profile like so

profile
  idenforce/id
  build
pluginManagement
  plugins
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.0-Local-1/version
  executions.../executions
/plugin
  /plugins
/pluginManagement
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0-Local-1/version
  /plugin
/plugins
  /build
/profile

and then run something like mvn compile -Penforce, it fails because
the Compiler plugin has not been explicitely set. Perfect.

However, once its version has been specified (and those for the Site,
Install, Deploy, Compiler, Jar, Surefire, Resources, and Clean
plugins), the Enforcer *still* complains ... about its own version!
Even though I've specified it in two places. Removing the profile part
and putting the Enforcer straight into the build.../build works,
though.

So this leads me to two questions:

1. Why do I have to specify seemingly unrelated plugins when only
requesting the Compiler plugin? (This is not a big deal, of course,
I'll have to set their versions anyway.)
2. Should the profile set up work?

Cheers,
Hilco

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

Re: Maven Enforcer Plugin

[Hilco Wijbenga]

Hi Brian,

On Jan 10, 2008 5:40 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
 The enforcer plugin requirePluginVersions rule intentionally scans
 everything in your pom inheritance to see anything that isn't defined.
 This also includes things you haven't declared but are being used by the
 standard lifecycle (compile,install etc etc). The alternative is that
 everytime you tried something new, it would complain about the version.

That's fine with me, like I said, I have to specify those versions
anyway. It just surprised me a bit.

 It also doesn't care if the profile is active or not, if you declare a
 plugin without a version anywhere...the enforcer will punch you in the
 face.

Yes, but what I don't understand is why I'm being punched in the face
when I've specified the version twice ... but in the profile. :-) And
it's complaining about its *own* version. Which, again, I *have*
specified.

 There is one known issue right now and that's when you run mvn site. It
 gets confused because mvn injects the reporting plugins into the project
 as plugins and since I'm not currently scanning the reporing
 declarations, it incorrectly says they aren't locked down. Once I get
 time to fix this, I'll be putting out 1.0.

Mmmmh, I didn't run into this when running mvn site?

Cheers,
Hilco

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

Re: Where are the ITs for 2.0.9-SNAPSHOT?

[Hilco Wijbenga]

On Jan 2, 2008 6:39 AM, Brian E. Fox [EMAIL PROTECTED] wrote:
 Yes I think it is. The original focus for that doc was how to create a
 new IT test, but it would be helpful to say how to run the current Its
 too...

For the record, I did get all the ITs to pass but when I was about to
add my comment I noticed that rerunning the same command simply didn't
run the ITs anymore. (It does lots of downloading but no running of
ITs.)

Until I understand why it works only sometimes I don't think I should
be commenting on anything. :-) I emptied my local repository and did a
mvn clean but that doesn't seem to make a difference. I don't get it
but I'm sure it's something really silly. ;-)

(The single IT from the doc works like a charm, of course.)

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

Where are the ITs for 2.0.9-SNAPSHOT?

[Hilco Wijbenga]

I would like to try and add some functionality to Maven so I tried to
create an IT first. That proved harder than I had expected because I
can't find them. :-)

I found /maven/core-integration-testing but this is for 2.1-SNAPSHOT
and I very much doubt these would work for 2.0.9-SNAPSHOT. (I haven't
actually tried though...)

Should I ignore 2.0.9 and focus on 2.1? If not, then where (or how?)
do I find the ITs for 2.0.9?

Cheers,
Hilco

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

Re: Where are the ITs for 2.0.9-SNAPSHOT?

[Hilco Wijbenga]

On Jan 1, 2008 8:02 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
 Take a look here:
 http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test

Awesome! That's very helpful. Thanks!

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

Re: Where are the ITs for 2.0.9-SNAPSHOT?

[Hilco Wijbenga]

On Jan 1, 2008 7:12 PM, Brett Porter [EMAIL PROTECTED] wrote:
 Those integration tests do work for 2.0.9 - take a look at maven-core-
 it-runner in the Maven 2.0.x source tree for one alternative for
 running them.

I just ran the tests and about 25% fail, all because Maven fails to
download artifacts (or so surefire-reports tells me). E.g.:

GroupId: org.apache.maven.its.plugins ArtifactId:
maven-it-plugin-touch Version: 2.1-SNAPSHOT

In my settings.xml I have

http://people.apache.org/repo/m2-snapshot-repository
and
http://snapshots.repository.codehaus.org

and I've activated the appropriat profiles (help:effective-pom lists
said repositories). Which repository am I missing?

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

Maven Enforcer Plugin

[Hilco Wijbenga]

Hi all,

The enforcer plugin has a powerful feature that checks whether the POM
lists a version for every plugin used. The current version
(1.0-alpha-3) doesn't seem to include this feature (even though the
plugin documentation indicates otherwise).

I see in JIRA that this feature is deemed not yet complete. It's also
listed as affecting version 1.0-alpha-3. I assume that should be
1.0-alpha-4?

Would it be possible to release 1.0-alpha-4? Or is this version not
yet ready for a release? Is the plugin in its current state usable
(i.e. what if I build it myself)?

Cheers,
Hilco

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

Re: Continuum CVS

[Hilco Wijbenga]

On 4/20/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:

Ok, so file an issue on Maven-SCM project (http://jira.codehaus.org/browse/SCM) 
and
we'll fix it.


http://jira.codehaus.org/browse/SCM-300

Continuum CVS

[Hilco Wijbenga]

Hi all,

We've been trying to set up Continuum and consequently we started
running some builds. It all worked nicely until the CVS server ran out
of inodes in its /tmp directory. It looks like it's not the normal
checkouts that people do that's causing this ... it appears to be
Continuum.

We tried a small build with Continuum and lo and behold: /tmp had a
new directory that was not deleted at the end of the checkout. So
we're fairly certain it's something Continuum related.

CVS creates a sort of cache directory (in /tmp) for each checkout (it
stores the CVS directories, not any of the files that are being
checked out) and this directory (and all of its *many* subdirectories)
are not being deleted. Apparently, it doesn't notice that the checkout
has finished. Something like a session not being closed. After three
days of this our server runs out of inodes and nothing works anymore.

Is this possible? Does Continuum have it's own built in CVS client?
Has anyone noticed anything like this?

We've created a cron job to remove these CVS directories from /tmp at
the end of the day so we have a workaround ... but *any* advice for a
better solution would be highly appreciated.

Cheers,
Hilco

Re: Continuum CVS

[Hilco Wijbenga]

On 4/19/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:

What is your continuum version?
Continuum 1.0.3 use the command line cvs client and since few days, continuum 
1.1
use a pure java cvs client.


Sorry, I shouldn't have left that little bit of information out. We're
running the latest and greatest ... straight from trunk. So Continuum
1.1-SNAPSHOT.

Cheers,
Hilco

Re: Continuum installation approach...

[Hilco Wijbenga]

On 2/28/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:

users download the war file and deploy it, they can use the standalone app too.


Is the WAR expected to run on any app server? Or are we going to
support a specific app server? Or a few?

What about databases? Are we going to assume Derby? I'd be fine with
that, just checking.

Re: Poll: release continuum alpha

[Hilco Wijbenga]

Yes, please release an alpha version.

Re: JBoss Support

[Hilco Wijbenga]

Nice work!

Re: JBoss Support

[Hilco Wijbenga]

On 2/15/07, Thierry Lach [EMAIL PROTECTED] wrote:

Can you post the contents of your derby-ds.xml file please?  I'm guessing
that the example I used for the Continuum+on_JBoss example isn't correct
enough for continuum.


See http://docs.codehaus.org/display/MAVENUSER/Archiva+on+JBoss

There used to be something similar for Continuum. I think your JNDI
name is wrong; all the silly stuff (comp/env/jdbc/) will be added by
JBoss ... IIRC, it's been a while. :-)

Re: JBoss Support

[Hilco Wijbenga]

On 2/14/07, Wendy Smoak [EMAIL PROTECTED] wrote:
 Hilco, the list is probably stripping attachments, so best thing to do
 is open a JIRA issue and attach your patch:
 http://jira.codehaus.org/browse/CONTINUUM


http://jira.codehaus.org/browse/CONTINUUM-1167

Re: Metrics Gathering Tracking

[Hilco Wijbenga]

On 1/18/07, Erik Bengtson [EMAIL PROTECTED] wrote:

Please let me know if there are metrics you would like to collect from the store
(JPOX).


I will make a list of the various metrics I was thinking of collecting.

We should probably define some sort of interface that anybody can
implement and add to the list whenever there's more metrics to be
gathered.

JBoss Support

[Hilco Wijbenga]

Hi all,

I've been bold enough to prepare a little patch that adds explicit
support for JBoss to the Continuum WAR.

The patch adds a jboss-web.xml file (this should be totally harmless)
and adds two resource-refs to web.xml. I get the impression that
this latter change is harmless as well, or would it break other app
servers?

Anyway, here's the patch. I hope it can get applied, otherwise I'll
just keep on doing it by hand. :-) With this applied the only thing
left to do is add a derby-ds.xml file to the JBoss deployment
directory. And make sure JBoss has a Derby driver, of course.

Cheers,
Hilco

JBoss Support

[Hilco Wijbenga]

Hi all,

I've been bold enough to prepare a little patch that adds explicit
support for JBoss to the Archiva WAR.

The patch adds a jboss-web.xml file (this should be totally harmless)
and adds a resource-ref to web.xml. I get the impression that this
latter change is harmless as well, or would it break other app
servers?

Anyway, here's the patch. I hope it can get applied, otherwise I'll
just keep on doing it by hand. :-) With this applied the only thing
left to do is add a derby-ds.xml file to the JBoss deployment
directory. And make sure JBoss has a Derby driver, of course.

Cheers,
Hilco

Re: Bug in VersionRange?

[Hilco Wijbenga]

On 11/6/06, Brett Porter [EMAIL PROTECTED] wrote:

That's the defined behaviour.


Ok, so using a spec of '1.0' is wrong? Should VersionRange not
complain then? I don't understand why '1.0' and '[1.0]' are not the
same.

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

Bug in VersionRange?

[Hilco Wijbenga]

Hi all,

I have a question about VersionRange in maven-artifact.

Calling createFromVersionSpec with a spec of '1.0' returns a
VersionRange with a recommendedVersion of '1.0' and a restriction list
consisting of Restriction.EVERYTHING. As a consequence calling
containsVersion always returns true.

With a spec of '[1.0]' things work as I would expect. Shouldn't '1.0'
and '[1.0]' yield the same VersionRange? I tried adding the right (in
my opinion) restriction in createFromVersionSpec but then the unit
tests fail because testRange in VersionRangeTest explicitly checks
that the VersionRange for '1.0' has Restriction.EVERYTHING.

What is the expected behaviour here?

Cheers,
Hilco

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

Re: Proposal for maven-qc-plugin / maven-qc-report-plugin

[Hilco Wijbenga]

Hi all,

Wow, that proved *much* easier than I had anticipated. I'm not sure if
everyone is equally happy with the approach I took, though...

I slightly changed my plans and tried to get PMD to run by just
invoking the maven-qc-plugin. I'm invoking mvn clean verify and the
PMD plugin is not configured to run anywhere (no executions).

I've got a lifecycle with id qc and a single phase: initialize.

I have created two mojos: QcInitMojo (@phase post-integration-test;
@goal init) which adds a PluginExecution for PMD to the PMD plugin
(defined in a test project's POM). This PluginExecution has id qc,
phase initialize, and goal pmd.

The other mojo is QcMojo (@phase verify; @goal qc; @execute
phase=initialize lifecycle=qc).

In my test project's POM I have something similar to:
buildplugins
plugin
artifactIdmaven-qc-plugin/artifactId
executionsexecutiongoals
goalinit/goal
goalqc/goal
/goals/execution/executions
/plugin
plugin
artifactIdmaven-pmd-plugin/artifactId
/plugin
/plugins/build

So the init goal is run first (in the post-integration-test phase) and
adds an execution to the PMD plugin. Then in the verify phase the qc
goal is run and my qc lifecycle is executed. This lifecycle now runs
PMD.

This has led to a number of questions. Firstly, is this the way to go?
Or is it too hackish?

I noticed that I get a warning ([WARNING] Removing: qc from forked
lifecycle, to prevent recursive invocation.). Why? There does not
appear to be any risk of recursive invocation. Both my mojos run much
later than the initialize phase. I don't see this happening with the
Surefire mojo which I used as my example.

I also noticed that except for my mojos all info messages are logged
as [INFO], mine, however, are logged as [info] (lowercase). Why is
that happening?

Finally, why is getConfiguration defined as returning an Object?
Shouldn't that be an Xpp3Dom? I don't like having to upcast. :-(

All in all I'm quite optimistic about the whole idea. It actually
seems possible. :-) Keep up the good work Maven developers!

Cheers,
Hilco

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

Proposal for maven-qc-plugin / maven-qc-report-plugin

[Hilco Wijbenga]

Hi all,

A while ago I mentioned the idea of a quality number (without much
detail). It's a long weekend so I'd like to get started and see how
far I get. I'd appreciate comments!

--- maven-qc-plugin / maven-qc-report-plugin ---

1) General Idea
The maven-qc-plugin generates a quality number each time the build
reaches the verify phase. This quality number is a percentage where 0
denotes total chaos and 100 denotes absolute perfection (the user
defines what perfect is). The QN is the weighted sum of the results
of (e.g.) Surefire, IT, Cobertura, PMD, Checkstyle, FindBugs,
etcetera.

The maven-qc-report-plugin generates nice graphs. ;-)

2) How to calculate the QN?
Let's take Surefire, Cobertura, and PMD as an example. Others are similar.

surefire.x = (# tests - # failures) / # tests * surefire.weight
-- [0 .. surefire.weight]
cobertura.x = (Sum i : 1=i=# tests : coverage fraction of test i) /
# tests * cobertura.weight
-- [0 .. cobertura.weight] (coverage fraction = coverage percentage / 
100)
pmd.x = max(0, 1 - (Max # violations -  # violations) / max #
violations) * pmd.weight
-- [0 .. pmd.weight]

qn.x = (surefire.x + cobertura.x + pmd.x) / (surefire.weight +
cobertura.weight + pmd.weight)
-- [0 .. 1]

3) (maven-qc-plugin) Default Lifecycle

3a) Phase verify
One of two things can be checked here:
a.  surefire.x = previous(surefire.x) or fail
cobertura.x = previous(cobertura.x) or fail
pmd.x = previous(pmd.x) or fail
b.  qn.x = previous(qn.x) or fail
(if a succeeds, then b will succeed too)

3b) Phase install
a.  store Surefire, Cobertura, and PMD results (as a reference for
subsequent builds)
b.  store the calculated QN (as a reference for subsequent builds)

4) (maven-qc-report-plugin) Site Lifecycle

4a) Phase site
a.  graphs for surefire.x, cobertura.x, and pmd.x
b.  graph for qn.x

--- maven-qc-plugin / maven-qc-report-plugin ---

This will be my first plugin so I'm looking for some implementation
pointers, I guess.

I'm going to try and implement something that does nothing but force
the running of Surefire and Cobertura based on what's configured in
reporting.

The maven-qc-plugin will force Surefire and Cobertura to run and log a
message. What if Surefire or Cobertura are also configured in build?
Does that make any difference? Should it?

I noticed that nothing gets run during 'pre-site' so that means that
during 'site' the reporting plugins must force running their
respective tools to run? How do I make sure that both Surefire and
Cobertura have run before maven-qc-report-plugin gets going? I read
about @execute but that doesn't seem like the right approach. I could
bind maven-qc-report-plugin to 'post-site', I guess, but then I would
have to tell everyone to run 'mvn post-site' instead of 'mvn site'?
That doesn't seem like a nice solution either. (Does *anything* use
'pre-site' or 'post-site'?)

I'll do some more digging but if someone could point me in the right
direction...

Cheers,
Hilco

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

Re: bootstrap.sh

[Hilco Wijbenga]

Almost there!

The only thing that seems to be failing is one of the integration tests:

it0063... FAILED
- Standard Out -
Command: /home/maven/bin/maven/current/bin/mvn -e --no-plugin-registry
--batch-mode -Dmaven.repo.local=/home/maven/.m2/repository clean:clean
package

- Standard Error -
Exit code: 1


Error Stacktrace:

org.apache.maven.it.VerificationException
   at org.apache.maven.it.Verifier.executeGoals(Verifier.java:732)
   at org.apache.maven.it.Verifier.main(Verifier.java:964)
 Error Stacktrace
Log file contents:
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'clean'.
[INFO] 

[INFO] Building Unnamed - org.apache.maven.it:maven-core-it0063:jar:1.0
[INFO]task-segment: [clean:clean, package]
[INFO] 

[INFO] [clean:clean]
[INFO] Deleting directory
/home/maven/maven/components/maven-core-it/it0063/target
[INFO] Deleting directory
/home/maven/maven/components/maven-core-it/it0063/target/classes
[INFO] Deleting directory
/home/maven/maven/components/maven-core-it/it0063/target/test-classes
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 1 source file to
/home/maven/maven/components/maven-core-it/it0063/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/maven/maven/components/maven-core-it/it0063/src/main/java/org/apache/maven/it0001/Person.java:[3,27]
package com.sun.tools.javac does not exist


[INFO] 
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
   at 
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:747)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:380)
   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.plugin.CompilationFailureException:
Compilation failure
   at 
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505)
   at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111)
   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
   ... 17 more
[INFO] 
[INFO] Total time: 3 seconds
[INFO] Finished at: Fri Aug 25 02:00:21 GMT 2006
FATAL ERROR: Unable to configure the Maven application
Error stacktrace:
org.apache.maven.reactor.MavenExecutionException: Compilation failure
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:206)
   at 
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:747)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:380)
   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 

Re: bootstrap.sh

[Hilco Wijbenga]

On 8/24/06, Brett Porter [EMAIL PROTECTED] wrote:

What JDK / OS are you using?


blackdown-jdk-1.4.2.03 / GNU/LInux


Regardless, you have a successful Maven installation.


Yeah, I figured as much.

Cheers,
Hilco

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

Re: bootstrap.sh

[Hilco Wijbenga]

On 8/24/06, Brett Porter [EMAIL PROTECTED] wrote:

Ok, I can see why that would fail. Can you file an issue?


http://jira.codehaus.org/browse/MNG-2529

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

Re: bootstrap.sh

[Hilco Wijbenga]

On 8/22/06, Brett Porter [EMAIL PROTECTED] wrote:

I can only guess incomplete checkout. I've never seen anything like
it, and it should just work.


Well, don't I feel special. :-)

I removed everything and checked out again. I made sure I had the same
revision in every directory. Running bootstrap.sh results in the exact
same error as before.


However, installing Maven first is not cheating. I think it should be
the recommended way for building Maven unless you have a reason to
need to start from scratch. All the bootstrap does is build a
functional Maven, then use that to build itself again anyway.


It seems cleaner to use bootstrap.sh. Then again, if you prefer people
not use it then perhaps the possibility simply should not exist?

Cheers,
Hilco

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

Re: bootstrap.sh

[Hilco Wijbenga]

On 8/22/06, Arnaud Bailly [EMAIL PROTECTED] wrote:

Maybe you could try building maven setting the property
maven.online=false such that build does not try to download artifacts
from remote repos.

$ export MAVEN_OPTS=-Dmaven.online=false
$ sh bootstrap.sh


I tried this and it fails even quicker than the normal way. :-(

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

Re: bootstrap.sh

[Hilco Wijbenga]

Hi,

On 8/23/06, Kenney Westerhof [EMAIL PROTECTED] wrote:

You probably have a settings.xml with
localRepository~/.m2/repository/localRepository
in there.


Yup, that was the problem.

After about a dozen tries I seem to have a successful build ...
however ... Maven doesn't get installed so the integration tests all
fail. I get

snip/
it... FAILED
- Standard Out -
Command: /home/maven/bin/maven/current/bin/mvn -e --no-plugin-registry
--batch-mode -Dmaven.repo.local=/home/maven/.m2/repository clean:clean
package


Error Stacktrace:

org.apache.maven.it.VerificationException:
org.codehaus.plexus.util.cli.CommandLineException: Error while
executing process.
   at org.apache.maven.it.Verifier.executeGoals(Verifier.java:721)
   at org.apache.maven.it.Verifier.main(Verifier.java:964)
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error
while executing process.
   at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:645)
   at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:72)
   at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:59)
   at org.apache.maven.it.Verifier.executeGoals(Verifier.java:715)
   ... 1 more
Caused by: java.io.IOException: java.io.IOException:
/home/maven/bin/maven/current/bin/mvn: not found
   at java.lang.UNIXProcess.init(UNIXProcess.java:143)
   at java.lang.Runtime.execInternal(Native Method)
   at java.lang.Runtime.exec(Runtime.java:566)
   at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:640)
   ... 4 more
 Error Stacktrace
Log file contents:
0/101 passed
Failed tests: [it0105, snip/, it]

(note the /home/maven/bin/maven/current/bin/mvn: not found).

So the build knows where to look (as per the M2_HOME variable) but
Maven hasn't been installed there. I've rerun the build several times
just to be sure but no joy.

Cheers,
Hilco

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

Re: bootstrap.sh

[Hilco Wijbenga]

Mmmh, it's being installed to M2_HOME/../maven-2.1-SNAPSHOT instead of
simply M2_HOME. This is to avoid overwriting a previous installation?

Obviously, M2_HOME/../maven-2.1-SNAPSHOT/bin is not in $PATH... Am I
required to use an M2_HOME that ends with maven-2.1-SNAPSHOT?

On 8/23/06, Hilco Wijbenga [EMAIL PROTECTED] wrote:

Hi,

On 8/23/06, Kenney Westerhof [EMAIL PROTECTED] wrote:
 You probably have a settings.xml with
 localRepository~/.m2/repository/localRepository
 in there.

Yup, that was the problem.

After about a dozen tries I seem to have a successful build ...
however ... Maven doesn't get installed so the integration tests all
fail. I get

snip/
it... FAILED
- Standard Out -
Command: /home/maven/bin/maven/current/bin/mvn -e --no-plugin-registry
--batch-mode -Dmaven.repo.local=/home/maven/.m2/repository clean:clean
package

 Error Stacktrace:
org.apache.maven.it.VerificationException:
org.codehaus.plexus.util.cli.CommandLineException: Error while
executing process.
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:721)
at org.apache.maven.it.Verifier.main(Verifier.java:964)
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error
while executing process.
at 
org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:645)
at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:72)
at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:59)
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:715)
... 1 more
Caused by: java.io.IOException: java.io.IOException:
/home/maven/bin/maven/current/bin/mvn: not found
at java.lang.UNIXProcess.init(UNIXProcess.java:143)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Runtime.java:566)
at 
org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:640)
... 4 more
 Error Stacktrace
Log file contents:
0/101 passed
Failed tests: [it0105, snip/, it]

(note the /home/maven/bin/maven/current/bin/mvn: not found).

So the build knows where to look (as per the M2_HOME variable) but
Maven hasn't been installed there. I've rerun the build several times
just to be sure but no joy.

Cheers,
Hilco



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

Re: bootstrap.sh

[Hilco Wijbenga]

Anyone?

Am I missing something obvious? Shouldn't this just work? Why doesn't
this bootstrap directory exist in the repositories?

I don't think I've skipped any steps in Guide to Building Maven 2.0.
I also tried the bootstrap.sh in maven-2.0.x with the exact same
result.

Perhaps I'm on the wrong mailing list? Or is this part of my
initiation? ;-) You are not going to make me cheat by first installing
Maven, are you?

On 8/21/06, Hilco Wijbenga [EMAIL PROTECTED] wrote:

Hi all,

I've checked out M2 in accordance with Guide to Building Maven 2.0:

svn co https://svn.apache.org/repos/asf/maven/trunks maven

[EMAIL PROTECTED] ~/maven/components $ env | grep M2_HOME
M2_HOME=/home/maven/bin/maven/current

[EMAIL PROTECTED] ~/maven/components $ echo $PATH
snip/:/home/maven/bin/maven/current/bin

But executing sh bootstrap.sh gets me

[EMAIL PROTECTED] ~/maven/components $ sh bootstrap.sh
snip/
Exception in thread main
org.apache.maven.bootstrap.download.DownloadFailedException: Failed to
download dependency:

Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]

Chain:

Model[org.apache.maven.bootstrap:bootstrap-installer:jar:2.1-SNAPSHOT]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:jar]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]
snip/

(the full log is below).

I had a look in the repository and there does not appear to be a
bootstrap directory in org/apache/maven?

I just ran svn up so I should be fully up-to-date. I didn't find any
JIRA issues about this. Any help would be appreciated.

Cheers,
Hilco

[EMAIL PROTECTED] ~/maven/components $ sh bootstrap.sh
Using settings from /home/maven/.m2/settings.xml
Using the following for your local repository: ~/.m2/repository
Using the following for your remote repository:
[http://repo1.maven.org/maven2,
http://cvs.apache.org/maven-snapshot-repository/]
Analysing dependencies ...


Building project in /home/maven/maven/components/bootstrap/bootstrap-mini
--
Cleaning /home/maven/maven/components/bootstrap/bootstrap-mini/target...
Compiling sources ...
Compiling 34 source files to
/home/maven/maven/components/bootstrap/bootstrap-mini/target/classes
Packaging resources ...
Packaging 
/home/maven/maven/components/bootstrap/bootstrap-mini/target/bootstrap-mini.jar
...
--
Installing: 
~/.m2/repository/org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.jar
Installing POM:
~/.m2/repository/org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.pom
Total time: 1 seconds
Finished at: Tue Aug 22 01:52:00 GMT 2006
Using settings from /home/maven/.m2/settings.xml
Using the following for your local repository: ~/.m2/repository
Using the following for your remote repository:
[http://repo1.maven.org/maven2,
http://cvs.apache.org/maven-snapshot-repository/]
Downloading 
http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/maven-metadata.xml
WARNING: remote metadata version not found, using local:
http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/maven-metadata.xml
(HTTP Error: 404 Not Found)
Downloading 
http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.pom
Artifact not found at
[http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.pom]
Error reading POM:
/home/maven/maven/components/bootstrap/bootstrap-installer/pom.xml
Exception in thread main
org.apache.maven.bootstrap.download.DownloadFailedException: Failed to
download dependency:

Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]

Chain:

Model[org.apache.maven.bootstrap:bootstrap-installer:jar:2.1-SNAPSHOT]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:jar]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]

from the following repositories:
at 
org.apache.maven.bootstrap.model.ProjectResolver.retrievePom(ProjectResolver.java:188)
at 
org.apache.maven.bootstrap.model.ProjectResolver.resolveDependencies(ProjectResolver.java:79)
at 
org.apache.maven.bootstrap.model.ModelReader.endElement(ModelReader.java:469)
at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1720)
at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667)
at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)
at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
at 
org.apache.maven.bootstrap.util.AbstractReader.parse(AbstractReader.java:60

bootstrap.sh

[Hilco Wijbenga]

Hi all,

I've checked out M2 in accordance with Guide to Building Maven 2.0:

svn co https://svn.apache.org/repos/asf/maven/trunks maven

[EMAIL PROTECTED] ~/maven/components $ env | grep M2_HOME
M2_HOME=/home/maven/bin/maven/current

[EMAIL PROTECTED] ~/maven/components $ echo $PATH
snip/:/home/maven/bin/maven/current/bin

But executing sh bootstrap.sh gets me

[EMAIL PROTECTED] ~/maven/components $ sh bootstrap.sh
snip/
Exception in thread main
org.apache.maven.bootstrap.download.DownloadFailedException: Failed to
download dependency:

Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]

Chain:

   Model[org.apache.maven.bootstrap:bootstrap-installer:jar:2.1-SNAPSHOT]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:jar]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]
snip/

(the full log is below).

I had a look in the repository and there does not appear to be a
bootstrap directory in org/apache/maven?

I just ran svn up so I should be fully up-to-date. I didn't find any
JIRA issues about this. Any help would be appreciated.

Cheers,
Hilco

[EMAIL PROTECTED] ~/maven/components $ sh bootstrap.sh
Using settings from /home/maven/.m2/settings.xml
Using the following for your local repository: ~/.m2/repository
Using the following for your remote repository:
[http://repo1.maven.org/maven2,
http://cvs.apache.org/maven-snapshot-repository/]
Analysing dependencies ...


Building project in /home/maven/maven/components/bootstrap/bootstrap-mini
--
Cleaning /home/maven/maven/components/bootstrap/bootstrap-mini/target...
Compiling sources ...
Compiling 34 source files to
/home/maven/maven/components/bootstrap/bootstrap-mini/target/classes
Packaging resources ...
Packaging 
/home/maven/maven/components/bootstrap/bootstrap-mini/target/bootstrap-mini.jar
...
--
Installing: 
~/.m2/repository/org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.jar
Installing POM:
~/.m2/repository/org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.pom
Total time: 1 seconds
Finished at: Tue Aug 22 01:52:00 GMT 2006
Using settings from /home/maven/.m2/settings.xml
Using the following for your local repository: ~/.m2/repository
Using the following for your remote repository:
[http://repo1.maven.org/maven2,
http://cvs.apache.org/maven-snapshot-repository/]
Downloading 
http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/maven-metadata.xml
WARNING: remote metadata version not found, using local:
http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/maven-metadata.xml
(HTTP Error: 404 Not Found)
Downloading 
http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.pom
Artifact not found at
[http://cvs.apache.org/maven-snapshot-repository//org/apache/maven/bootstrap/bootstrap-mini/2.1-SNAPSHOT/bootstrap-mini-2.1-SNAPSHOT.pom]
Error reading POM:
/home/maven/maven/components/bootstrap/bootstrap-installer/pom.xml
Exception in thread main
org.apache.maven.bootstrap.download.DownloadFailedException: Failed to
download dependency:

Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]

Chain:

   Model[org.apache.maven.bootstrap:bootstrap-installer:jar:2.1-SNAPSHOT]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:jar]
Dependency[org.apache.maven.bootstrap:bootstrap-mini:2.1-SNAPSHOT:pom]

from the following repositories:
   at 
org.apache.maven.bootstrap.model.ProjectResolver.retrievePom(ProjectResolver.java:188)
   at 
org.apache.maven.bootstrap.model.ProjectResolver.resolveDependencies(ProjectResolver.java:79)
   at 
org.apache.maven.bootstrap.model.ModelReader.endElement(ModelReader.java:469)
   at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1720)
   at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667)
   at org.apache.crimson.parser.Parser2.parse(Parser2.java:337)
   at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
   at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
   at 
org.apache.maven.bootstrap.util.AbstractReader.parse(AbstractReader.java:60)
   at 
org.apache.maven.bootstrap.model.ModelReader.parseModel(ModelReader.java:113)
   at org.apache.maven.bootstrap.Bootstrap.readModel(Bootstrap.java:417)
   at org.apache.maven.bootstrap.Bootstrap.run(Bootstrap.java:141)
   at org.apache.maven.bootstrap.Bootstrap.main(Bootstrap.java:130)

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

Re: Extending reporting management

[Hilco Wijbenga]

Hi all,

I'm nowhere near being a veteran Maven user let alone competent at
making changes to Maven but a common API for reporting seems like an
important and extremely useful addition to Maven and I'd like to help
out.

On 8/16/06, Arnaud Bailly [EMAIL PROTECTED] wrote:
:
snip/
:

The basic idea I have in mind is thus to provide as a core maven
service a central information API that would be used by **all** reporting
plugins to attach information to structural elements of the
project. This information could be store as a RDF (see also
http://www.ilrt.bris.ac.uk/discovery/rdf/resources/) graph backed by
a suitable ontology and extensible at will. The RDF structure would
simplify most of the issues raised earlier in this text as it gives
standard tools to query, aggregate and transform informations stored
in the graph.


Sounds like a good idea.


Aggregating information, for example, is trivial and can
be done generically at *any* suitable level: If I need coverage percent
for each method, I can query nodes relating to methods for a
=test-coverage= predicate attached to this node and use the given
object's value. Or I can use the same information by aggregating
values at, for example, module scope, following links from module
nodes to =test-coverage= predicates they lead to.


I've been looking for something that would allow me to generate a
single quality number. E.g. a weighted sum of successful unit tests,
code coverage, checkstyle violations, PMD violations.


Another interesting aspect of this scheme is that RDF, having an
external XML representation, is amenable to XSLT transformation and
thus  can be used uniformly to generate human-readable reports without
resorting to specialized handling per plugin.


One look and feel for all reports would definitely be a good thing.
Especially, if the look-and-feel is easily changed to reflect the
company look-and-feel.


Furthermore, storing this information in a versionned database would
allow one to retrieve the *evolution* of the information attached to a
project over time and various builds. This functionality is today provided
by qalab plugin, once again in an *ad hoc* way.


Nothing beats graphs when trying to impress management. :-) I'd love
to be able to show progress in quality by means of the weighted sum I
mentioned above on a timeline.


Comments are of course welcomed and sought after.


Well, here you go. I hope you're not too disappointed it's a
not-even-a-contributor replying. :-)

As I mentioned at the top, I'd like to help out with this. I'll start
by getting a Xen box ready for some serious Maven development. ;-)
We'll see what happens.

Cheers,
Hilco

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

Re: Extending reporting management

[Hilco Wijbenga]

Hi Mike,

On 8/16/06, Mike Perham [EMAIL PROTECTED] wrote:

Hilco, your proposal sounds good in the context of a
single VM invocation when everything is in-memory.  How does this extend to
reporting over time?


I was referring to Arnaud's idea of a versioned database for such
data. Obviously, the data in the graph would have to come from
somewhere. :-)

Or did you mean the weighted sum thing? That was definitely meant as
part of a full build, you'd need all reporting done before this
weighted sum can be calculated.


Just as a compiled binary is a binary snapshot of
the code at a point in time, we need to take a report snapshot with all
this metadata persisted for reporting on a module over time.  Perhaps each
report could optionally generate their own OWL metadata which can be
packaged by site into a reporting archive JAR and stored in the repo for
each version of a module.  We would need a version-based reporting API to
trawl over those versions.


Yeah, I guess that would work too. What does OWL stand for?

Cheers,
Hilco

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