Unreviewed PR for MNG-6405: basedir in MavenProject.deepCopy

[Jesse Glick]

I filed https://github.com/apache/maven/pull/225 a few months ago and
have not gotten any feedback. Is there anything I can do to move this
forward? This bug affects some uses of `flatten-maven-plugin`.

Thanks,
-Jesse

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

Re: current master performance regression

[Jesse Glick]

On 22 July 2014 09:00, Igor Fedorenko  wrote:
> Unfortunately, MNG-5312 didn't have any
> test case so I am wondering if Jesse or somebody else can provide more
> details about exact conditions that triggered MNG-5312 and, ideally,
> setup a regression test.

As noted in MNG-5312, I was able to reproduce this but only using a
customer’s proprietary source tree. (ZD-3844 is our internal reference
number.) There were many interrelated Maven modules, making heavy use
of import scope.

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

Re: Strategy for jmod (Jigsaw)?

[Jesse Glick]

On 05/16/2013 05:42 PM, Jörg Hohwiller wrote:

is there already some slight inital draft or idea for a strategy how maven x.y 
could deal with jigsaw?


I wrote up a very preliminary sketch about a year ago [1] but have not worked on it since then, and whatever worked then may or may not work with current drafts of 
Jigsaw. Feel free to fork it and develop it, if the approach matches your expectations.


The idea was to generate target/generated-sources/jmod/module-info.java from pom.xml, reusing standard Maven elements to the greatest extent possible, introducing 
plugin-specific configuration only for Jigsaw-specific metadata; and attach target/*.jmod as secondary artifacts. Then the generated module-info.java is just used as an 
input to javac, but you would not normally see it; you would continue to work in a traditional Maven way, just with a better runtime, and stronger compile-time validation 
of things like internal packages. You could even activate Jigsaw conditionally in a profile, so that the same source project could be built by a premodular JDK.


There are other possible approaches, of course. You could treat Jigsaw metadata as primary (versioned) sources, and install a Maven extension that would read 
src/main/java/module-info.java early in the lifecycle and generate synthetic dependencies in the Maven model so that pom.xml is used only for other metadata. My fear was 
that this (a) would be too “magical”, (b) would fail to work comfortably with other Maven features such as dependencyManagement and the release plugin.


(The comparison between Tycho and the Felix bundle plugin is instructive.)

Interoperability between Maven repositories and Jigsaw repositories is another topic, which I did not explore. You could imagine creating a unidirectional or 
bidirectional mirror between the two types of repository, either static (a batch translation) or dynamic (e.g. a Nexus plugin). Or you could imagine creating a Maven 
 which adds a new kind of repository to Aether, so that Maven projects could declare direct Jigsaw repository additions. If and when there are some live, 
realistic Jigsaw repositories, this will be more interesting to experiment with.



[1] https://bitbucket.org/jglick/jigsawmaven


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

Re: [RESULT][VOTE] Maven Shared Utils 0.3 and Maven Surefire 2.14

[Jesse Glick]

http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html still 
shows documentation for 2.13.


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

Re: [ANN] Apache Maven 3.0.5 released

[Jesse Glick]

FYI, I have found what is for me at least a critical regression in 3.0.5 
relating to HTTPS deployment:

https://jira.codehaus.org/browse/MNG-5443

(Sorry for not testing during voting period.)


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

GitHub mirroring confusion: maven-3 vs. maven

[Jesse Glick]

https://github.com/apache/maven-3 does not seem to contain recent changes, such as 3.0.5. https://github.com/apache/maven does seem to be properly mirrored, so maybe 
someone can delete or deprecate the old mirror?



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

Re: [VOTE] Apache Maven 3.0.5

[Jesse Glick]

On 02/19/2013 10:28 AM, Olivier Lamy wrote:

We fixed 1 issue:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=19088


I guess this means that fixes such as MNG-5312 are deferred to another release 
like 3.1.0?


[1] https://jira.codehaus.org/browse/MNG-5312


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

Re: EOL of 1.5 as minimum

[Jesse Glick]

On 02/06/2013 05:23 PM, Mark Struberg wrote:

What are the big features and possibilities we gain from 1.6?


The largest in this context would probably be:

- annotation processors
- script engine
- split bytecode verifier (thus quicker startup)

Java 7 is a bigger bump (NIO.2, try-with-resources, etc.).


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

Re: Need a small sax parser for m-s-u

[Jesse Glick]

On 01/13/2013 02:09 PM, Kristian Rosenvold wrote:

Anyone have any other suggestions?


http://piccolo.sourceforge.net/ is old but claims to be what you asked for. 
Central does not seem to have the most “recent” release unfortunately.


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

Re: [VOTE] Maven 3.1.0

[Jesse Glick]

On 11/28/2012 11:04 AM, Arnaud Héritier wrote:

there are only few bug fixes


For the affected users, MNG-5312 [1] is pretty serious.

[1] https://jira.codehaus.org/browse/MNG-5312


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

Re: Tentative release planning for 3.1.x

[Jesse Glick]

On 11/12/2012 02:00 PM, Dennis Lundberg wrote:

I had a quick look at the Windows ITs and the problem seems to be that
Maven/Jenkins is unable to delete files. This looks like a Windows path
length issue, because the path it complain about is 264 chars long.


JENKINS-15418 [1] was fixed in 1.489, FYI.

[1] https://issues.jenkins-ci.org/browse/JENKINS-15418


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

Re: Proposal for new git-workspace-plugin

[Jesse Glick]

On 09/13/2012 10:16 AM, Kristian Rosenvold wrote:

https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin


Interesting. I had a thought a while ago for an IDE to help you with similar tasks [1] but having it as a Maven plugin would arguably be better, especially if user 
interaction can be kept to a minimum.


[1] http://netbeans.org/bugzilla/show_bug.cgi?id=198781


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

Re: [VOTE] Move Maven projects sources to git

[Jesse Glick]

On 09/05/2012 08:39 AM, Olivier Lamy wrote:

I'm a bit curious to see if that will increase externals contributions.


I think plain Git is only marginally more friendly for external contributors than Subversion. Yes you can create a local branch and update it against trunk changes, but 
you still need to manually attach patches to JIRA; reviewing and updating patches this way is painful.


It is GitHub, principally pull requests but also the ability to comment on individual diff lines in any published revision, which is far and away better for 
collaboration. If Maven and satellite projects are moved to Git hosted on Apache servers only, I do not see contributions being much easier. The better approach to my 
mind would be to use GitHub-hosted repositories for all collaboration and ongoing development, and just mirror to Apache clones if necessary for legal reasons. Is that 
possible? If not, GitHub mirrors could still be used for pull requests, but the committer would have to do some manual synchronization.



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

Re: Pluggable dependency version

[Jesse Glick]

On 08/03/2012 09:15 AM, Anders Hammar wrote:

What's the benefit of this approach rather than just having the user adding the 
dependencies directly to the plugin (execution) declaration?


Linkage safety. If you have the-plugin built directly against 
the-build-tool@1.1.2, and the user configures it to run against 
the-build-tool@1.0-beta-3 or @1.6.3 etc., it
is hard to say in advance what will happen - it might work fine, or it might 
consistently throw errors due to signature changes in the-build-tool, or it 
might work in
most cases but throw errors in unusual circumstances when certain code paths 
are executed. Using an adapter allows the-plugin author to explicitly manage 
different
versions of the-build-tool. If the-build-tool has a very simple and stable 
interface it would be overkill.


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

Re: Pluggable dependency version

[Jesse Glick]

On 08/02/2012 04:58 AM, Anders Hammar wrote:

not have a dependency on some library in the plugin itself but rely on it being 
declared as a dependency in the Maven project where the plugin is bound. That 
made it
totally controllable by the project.


If the build-time code would not normally already be a dependency of the project - your main concern - then you could have the mojo configuration accept a parameter typed 
as a list of "dependencies". (org.apache.maven.model.Dependency[]?) These would then have to be resolved (transitively) against pluginRepositories, and used to construct 
a URL[] to pass to a URLClassLoader (possibly prepended to the project's regular dependencies). Thus the project could declare e.g.



  
some.framework
the-api
  
  
some.framework
the-impl
runtime
  


  

  some.framework
  the-plugin
  

  
some.framework
the-build-tool
  

  

  


Naturally you still need to be careful that a given version of the-plugin - specifically, that part of its code which will link against classes loaded by the 
URLClassLoader - is API-compatible with past, present, and foreseeable future versions of the-build-tool. If there are known breaking API changes, a single version of the 
plugin could also supply multiple adapters tuned to different version ranges of the-build-tool, or use reflection to try several method variants, or at least catch 
LinkageError and report the problem gracefully.


A mojo like this could be awkward to write from scratch; would be best to have an archetype for it. In particular, if you are using direct Java linkage between the-plugin 
code and the-build-tool (rather than, say, reflection), and the-plugin does not have a direct dependency on any version of the-build-tool (i.e.  is 
mandatory and not just an optional selection of an alternative version) and/or supports multiple incompatible version ranges of the-build-tool, then to build the-plugin 
itself you need a multimodule project:


the-plugin-parent
  the-build-tool-abstraction (jar)
  the-build-tool-adapter-v1 (jar) -> the-build-tool-abstraction, the-build-tool 
@ [1.0.0,2)
  the-build-tool-adapter-v2 (jar) -> the-build-tool-abstraction, the-build-tool 
@ [2.0.0,3)
  the-plugin (maven-plugin) -> the-build-tool-abstraction

Here the-plugin resolves  and determines which major version of the-build-tool is being requested ("1" or "2"). It then constructs a URLClassLoader 
parented to the plugin ClassLoader (or whatever loads classes from the-build-tool-abstraction) including everything from  (resolved from 
pluginRepositories) plus the appropriate the-build-tool-adapter-v* (also from pluginRepositories), creates an instance of an interface defined in 
the-build-tool-abstraction and implemented in the-build-tool-adapter-v* (selected via java.util.ServiceLoader, Plexus @Component, ClassLoader.loadClass("hardcoded"), 
etc.), and casts to the-build-tool-abstraction interface which the plugin can directly "see". Then it calls methods on this instance to run the build tool.


Even if you are sure the-build-tool will be API-compatible it is not wise to mash everything into one project. While the-plugin could declare a provided 
dependency on the-build-tool, as the developer of the-plugin you would need to be careful to keep track of which src/main/java/**/*.java are permitted to refer to types 
in the-build-tool and which are not; furthermore, the URLClassLoader would then need to override loadClass to _not_ delegate loading of these classes to its parent (since 
then they would be loaded by the plugin class loader and fail to resolve against the-build-tool). Using a multimodule project as sketched above documents and enforces the 
runtime structure and means that the URLClassLoader can use normal parent delegation.



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

Re: build extensions

[Jesse Glick]

On 08/01/2012 09:57 AM, Jesse Farinacci wrote:

http://maven.apache.org/examples/maven-3-lifecycle-extensions.html


Side note: this page fails to mention -Dmaven.ext.class.path=... as an alternative to adding to lib/ext/*.jar, which I guess would work (based on its recommendation from 
EventSpy).



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

Re: svn commit: r1367470 - /maven/plugin-tools/trunk/maven-plugin-plugin/src/site/apt/examples/using-annotations.apt.vm

[Jesse Glick]

On 07/31/2012 02:43 PM, Hervé BOUTEMY wrote:

compile is the default scope, isn't it?
Or do I miss something?


Perhaps provided was meant?


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

New plugin archetype (was: New annotation system)

[Jesse Glick]

On a related note, I think we need a new archetype for plugins; the existing 
maven-archetype-mojo 1.0 is out of date and not ready for annotations. 
Specifically needed:

1. Need a dep on maven-plugin-annotations.
2. Need to specify skipErrorNoDescriptorsFound.
3. Have to explicitly call descriptor goal - not part of default lifecycle (!).
4. Apparently need to tell maven-site-plugin to run maven-plugin-plugin.


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

Re: Java 7 parallel classloading performance ?

[Jesse Glick]

On 05/11/2012 04:15 AM, Kristian Rosenvold wrote:

I have been considering fixing classworlds and m3 core to exploit the
parallel classloading abilities of java 7. The idea would be to load
plugin classloaders in parallel to increase performance.


You can load classes in multiple threads in parallel in Java 6 too. No special trick, just fork some threads to initialize your plugins and join to wait for everything to 
be ready. Some of the initialization will involve class loading, and some will involve other tasks.


AFAIK the only change in Java 7 is that locking can be modified in a way that would avoid deadlocks in module systems which permit cyclic dependencies, such as OSGi. But 
that should never happen for Maven plugins anyway - the dependency graph should be a DAG.



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

Re: Plugins with Annotations ETA

[Jesse Glick]

On 05/09/2012 12:56 PM, Olivier Lamy wrote:

we still need to do some javadoc parsing for @deprecated


Just look for @Deprecated - the real annotation - instead. (Note that javac 
will warn you if you have the Javadoc tag without the annotation.)


@since and comments for class/field description. So if annotations comes from
reactor module (easy to scan sources) but if comes from a dependency I
try to get the sources from the artifact with try to resolve the same
artifact with classifier sources.


Would be simpler to define true annotations (marked @Documented) for the things you use, e.g. @Since or @Description. Then there is no need to look for sources of binary 
dependencies, and no need to parse them. You are also insulated against Java language changes, and can interoperate properly with other JVM languages compatible with JSR 175.



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

Re: 1.5 Annotations for Mojo

[Jesse Glick]

On 04/27/2012 01:34 PM, Ansgar Konermann wrote:

JFrog (the Artifactory guys) has already published a set of Java
1.5 annotations for mojo development, including a m-plugin-p extension to
use them.


Beware that (acc. to their documentation) the tool relies on APT, which is 
deprecated in JDK 6 and scheduled to be dropped from JDK 8.

New code should use JSR 269. A processor can perform semantic validation, and can also actually generate plugin.xml; if registered in META-INF/services no special mojo or 
compiler plugin configuration is needed to activate this. Generating synthetic classes is also quite easy - no need to deal with bytecode, just Java source.



-
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

[Jesse Glick]

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.

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.


(*) 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

Re: For a mojo with requiresProject=false, I would like to avoid Maven from loading the pom.xml from working directory

[Jesse Glick]

On 04/17/2012 03:24 AM, Vincent Latombe wrote:

Maven tries to parse the project and if it fails, it doesn't even call my mojo.


Same applies to 'mvn archetype:generate'. Seems to me that this is a bug more 
than an RFE.

Note that invocations of bin/mvn without a goal but with e.g. 
--encrypt-password do work even when $CWD/pom.xml exists and is invalid.


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

Re: MCOMPILER-165

[Jesse Glick]

On 02/17/2012 08:14 AM, Kristian Rosenvold wrote:

As long as the patch is to the appropriate
code style and containst test-cases,  we will review it.


Not true in the case of e.g. MCOMPILER-140.


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

Re: automatic proxy for surefire

[Jesse Glick]

On 02/17/2012 04:03 AM, Romain Manni-Bucau wrote:

proxy settings (understand proxy defined in settings.xml)


By the way has any thought been given to better supporting -Djava.net.useSystemProxies=true, i.e. automatic detection according to system settings? It works on most 
platforms for apps using java.net.HttpURLConnection but I do not think that works with Apache HttpClient without a bit of customization (which I suppose could live in 
wagon-http). Defining a proxy manually in settings.xml is a pain, especially for a laptop user moving in and out of corporate networks, and a stumbling block for new 
Maven users [1].


[1] http://netbeans.org/bugzilla/show_bug.cgi?id=194916


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

Re: [ANN] Apache Maven 3.0.4 released

[Jesse Glick]

FYI - should be bundled in the next NetBeans nightly development build.


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

Re: [CALL FOR TEST] Apache Maven 3.0.4-RC4 staged

[Jesse Glick]

FYI - again integrated into NetBeans development builds to spur testing.


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

Re: 'Get thee to the core' a concrete opportunity

[Jesse Glick]

On 12/08/2011 06:34 AM, Benson Margulies wrote:

In the test case, there's a maven plugin which declares various maven
2 components as provided dependencies, notably the
DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me
the source to the 2.2.1 version even though, since I'm running M3, I'm
using the M3 version.


FWIW - using a NetBeans 7.2 dev build (close to 7.1 RC2), I:

1. Opened the M3 root POM (File > Open Project) so the IDE knows where all the 
submodule projects are.

2. Opened the Maven Embedder module. Accept suggestion to prime.

3. Under File > Project Properties > Run, set Main Class to org.apache.maven.cli.MavenCli, and Arguments to "-f .../pom.xml clean install" for a project using 
nbm-maven-plugin 3.6 (more or less arbitrarily).


4. Opened sources for nbm-maven-plugin. Accept suggestion to prime. Go to Type on DefaultArtifactResolver offers both the 3.0.x source project version, and the 2.0.6 
repository version (since both are in classpath of an open project). Accept the first.


5. Set a breakpoint in the constructor (int threads = ...).

6. Debug Project on Maven Embedder.

7. Breakpoint hit in the correct DefaultArtifactResolver.java. Debug > Step Over shows threads=5 in the Variables view as expected (the 2.0.6 version has no such 
constructor code).


Alternately, if bundled Maven binary (currently 3.0.3) suffices:

3. [can be skipped but then Step Over will not work] Window > Debugging > Sources with test project selected, Add Source Root, select .../maven-compat/src/main/java/ 
(will be default filechooser location if DAR.java selected in editor).


6. Right-click test project, Custom > Goals..., "clean install" under Goals, 
jpda.listen=maven (i.e. launch Maven itself inside debugger) under Properties.


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

Re: [CALL FOR TEST] Apache Maven 3.0.4-RC3 staged

[Jesse Glick]

On 12/07/2011 02:04 PM, Olivier Lamy wrote:

please note it's *not* an official release so this will never be
distribute as an official Apache Maven release.
It's only a rc build to get feedbacks from users.


Yes of course. This is only temporary until another RC or a final build is 
published - sorry for not being clearer.


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

Re: [CALL FOR TEST] Apache Maven 3.0.4-RC3 staged

[Jesse Glick]

FYI - NetBeans nightly development builds [1] are now bundling RC3, to shake 
out problems in either the embedded APIs or general usage.

[1] http://bits.netbeans.org/download/trunk/nightly/latest/


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

Re: [VOTE] Release dependency plugin 2.4

[Jesse Glick]

On 11/15/2011 12:41 AM, Carlos Sanchez wrote:

Vote open for 72H.


What happened to this vote? Never finalized, and 2.4 is still unreleased?


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

Re: [VOTE] Apache Maven 3.0.4

[Jesse Glick]

+1 (non-binding). Tested integration into a NetBeans development build, and 
built some modules in Glassfish, so far without problem.


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

javax.script (was: [VOTE] Apache Maven Script Interpreter 1.0)

[Jesse Glick]

Did you consider using the standard javax.script.* API instead of some or all of these interfaces? That would permit automatic support for many languages by just dropping 
the JAR with the (non-Maven-specific) META-INF/services/javax.script.ScriptEngineFactory into the classpath/realm, and offers richer features such as precompilation.


The API is part of Java 6 but could easily be packaged as a standalone artifact 
for use with Java 5. Rhino (JS) is available automatically in JDK 6+.


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

Re: Meta information about dependencies in a pom?

[Jesse Glick]

On 11/09/2011 12:00 AM, Jason van Zyl wrote:

today we learned about the AbstractMavenLifecycleParticipant


Here's an example of how it works for matching the dependencies specified from 
a 3rd party source to the reactor.
[...]
It's using JSR330, but you can pull those out and use Plexus annotations if you 
need it to work in the short term.


A standalone example I just got to work: create a jar-packaging project with

@Component(role=AbstractMavenLifecycleParticipant.class)
public class WhateverNameYouLike extends AbstractMavenLifecycleParticipant {
@Requirement private Logger log;
@Override public void afterProjectsRead(MavenSession session) throws 
MavenExecutionException {
for (MavenProject p : session.getProjects()) {
log.info("tweaking " + p);
Dependency d = new Dependency();
d.setGroupId("org.apache.commons");
d.setArtifactId("commons-io");
d.setVersion("1.3.2");
p.getDependencies().add(d);
}
}
}

built with




org.codehaus.plexus
plexus-component-metadata
1.5.5



generate-metadata

generate-metadata







org.apache.maven
maven-core
3.0.3



Now create a quickstart project and edit the main method to say:

System.out.println(org.apache.commons.io.EndianUtils.swapInteger(1));

Once you tell it




...coordinates as for first project...




then it will compile (under 3.0.3) despite not itself declaring a dep on 
commons-io.

BTW I was not successful in using @javax.inject.Singleton in place of 
@Component.


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

Re: [PROPOSAL] Java 5 Annotations for Plugins

[Jesse Glick]

On 11/04/2011 07:13 AM, Stephen Connolly wrote:

you generate a class that extends
AbstractMojo, has the required injection fields for all the
@parameters and has an execute method that passes through all the
injection fields and then invokes the required method.


By the way this (as well as HelpMojo generation) could be done rather easily without ASM or any special goals in maven-plugin-plugin if you compile under Java 6: an 
annotation processor can generate Java sources which will also get compiled, as well as creating/updating META-INF/maven/plugin.xml. But I guess we cannot rely on this yet.


I do not think Phase should be an enum, just a list of String constants - you 
are permitted to define alternative lifecycles, right?


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

Re: antrun and ant-nodeps

[Jesse Glick]

On 10/28/2011 03:13 PM, Benson Margulies wrote:

There's no ant-nodeps for 1.8.2.


Correct, this JAR was removed in 1.8.2 since many of the "optional" tasks did not differ in any fundamental way from "core" tasks. The separated JARs are now reserved for 
bundled tasks which depend on third-party libraries.



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

Ping on MNG-5075 - "MavenProject.getParent throws undocumented ISE"

[Jesse Glick]

A patch with test has been attached to MNG-5075 [1] since April but there have been no comments. Are pull requests on GitHub preferred, or anything else I need to do? 
Pinging the list since I came across another case [2] of this bug needing to be worked around.


[1] https://jira.codehaus.org/browse/MNG-5075
[2] http://netbeans.org/bugzilla/show_bug.cgi?id=203346


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

Re: Maven and JigSaw thoughts

[Jesse Glick]

On 10/22/2011 05:00 AM, Mark Struberg wrote:

there is atm a strict 1:1 between a Modul and a ClassLoader.


This would not be true for the special case of JDK modules (what is now rt.jar + tools.jar); probably TBD whether "user" modules will be permitted to share class loaders 
for ease of migration of legacy apps. But in general, yes, each module would be associated with its own loader at runtime.



modules which need multiple classloaders (like EARs) or a specific deployment 
task (like WARs)


As far as I know, Java EE is not supported by the current Jigsaw work.


A Module is a JAR.


Actually a true Jigsaw module would be a *.jmod file - a new format capable of good compression and other advantages. There is also support for creating "legacy" *.jar 
files for use in premodular JVMs (just as an OSGi bundle can be used in degraded form without a container).



Thus also the notion of an 'attached artifact' is completely missing. If you 
need such a thing, you would need to stuff it into a jar and access it via
getResource().


Probably true, though this is already more or less the case at runtime: a premodular app cannot use attached artifacts at runtime (without embedding Maven code). At least 
the common case of System.loadLibrary would work more smoothly with a jmod (no need to extract to a temporary file).


On a related topic, it seems unclear how creation of modules from a Maven project should work. Suppose jmod. Should ${finalName}.jmod be the 
primary and only artifact? But then a "legacy" jar project will not be able to consume this module's classes in flat classpath mode, which would be 
a huge obstacle to adoption. Should ${finalName}.jar be the primary artifact with ${finalName}.jmod (*) a secondary artifact (**)? This would permit interoperability with 
jar-packaging projects but seems clumsy because the primary artifact would not be used at runtime in a module-aware app.


And should dependency artifact(s) be resolved to ${basedir}/target/classes/ inside a reactor build? Jigsaw should have support for "exploded modules" so this would be 
fine for compiling, and for running (e.g. in Surefire) most Java code; but not for testing code using JNI, unless the Surefire plugin can be taught to set 
$LD_LIBRARY_PATH / %Path% (***) intelligently.



What we could do is to populate the local jigsaw repo on mvn install. Or even 
provide a mechanism to do a mvn jigsaw:deploy for upstream jigsaw module repos.


Jigsaw already has a (prototype) repository connector which can read Maven 
repositories, so this might be unnecessary for most users.


As the dependency resolution is built into the java runtime, we don't need to 
do anything for resolving jigsaw modules.


This is actually the main problem as I see it: Jigsaw's javac expects src/main/java/module-info.java to have the exact list of Java dependencies (the -classpath argument 
is illegal in modular mode), which means that any part of Maven other than maven-compiler-plugin which needs to know the list of dependencies is going to be out of luck. 
Possible solutions:


1. Signal an error at build time if module-info.java is out of synch with 
pom.xml, and force the user to maintain both. Yuck.

2. Create target/generated-sources/jigsaw/module-info.java from pom.xml before calling javac. Not clear if this can work; and some module information (e.g. list of 
"exported" classes) would then have to be encoded somewhere in pom.xml (compare maven-bundle-plugin's ), which is not great.


3. Force Maven core to load (at least some) dependency information from 
module-info.java. I understand Tycho does something like this already.


Of course we could provide something like resolving
dependencies from an upstream jigsaw repo if those artifacts are not present in 
the local maven repo.


And/or provide a batch tool to create a Maven 2-format mirror of a Jigsaw repo.

[later]

the dependency matching (what happens if you have 2 transitive dependencies 
with different versions, version ranges, etc) must not happen at runtime


Final version resolution would happen at install time. Note that Jigsaw's decisions would not match Maven's in all scenarios; it might prefer the newest available version 
of a contentious dependency rather than the version "closest" to the top-level module of the app.



(*) Perhaps ${finalName}-something.jmod. It is not obvious from Maven's limited documentation whether a secondary artifact must have a classifier. nbm-maven-plugin 
(analogous in many ways to Jigsaw) creates secondary ${finalName}.nbm artifacts with no classifier, but this seems to cause subtle problems, especially in Maven Indexer.


(**) -Pdeployment could add *.deb and other native variants.


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

Re: Use of standards in the Maven core

[Jesse Glick]

Reposting to an old thread, since I am still running into what seems to be 
Maven 2 debris in the APIs.

On 11/19/2010 02:19 PM, Kristian Rosenvold wrote:

if it hurts you, make a patch; documentation upgrade, javadoc or code changes


The difficulty with submitting Javadoc changes is that if you need the Javadoc you probably are not going to be sure what it should say. :-) I considered submitting a 
pull request to github.com/apache/maven-3 basically documenting org.apache.maven.artifact.resolver.ArtifactResolutionRequest.setMirrors to say "do not trust that I do 
anything", but it is not obvious under which circumstances it actually does what it sounds like. A little story:


I had a call to org.apache.maven.repository.RepositorySystem.resolve. Undocumented, but it seems to download artifacts to the local repository (when not already present), 
a generally useful task. (While the interface is in Maven Core, the only impl is in Maven Compat and named - ominously - LegacyRepositorySystem. If it is supposed to be 
deprecated, there is no Javadoc saying so, or suggesting a replacement, so I stick with it for now.)


However yesterday I noticed that it was not working on an artifact in Central that I knew existed and in fact was very likely cached in my local Nexus. For reasons 
irrelevant here the remoteRepositories in the call included a definition of Central as http://central/ (taken from Nexus installation FAQs), but the actual URL should not 
have mattered since I have a mirror definition. Therefore my local mirror settings were being ignored.


Taking a look at the call to resolve, it is given an ArtifactResolutionRequest. I had a org.apache.maven.settings.Settings object handy with the right mirror definitions, 
so code completion and common sense would dictate that I should call request.setMirrors(settings.getMirrors())... but this had no effect.


Time for the debugger. I set the mirrors on the request and follow what happens. The list of mirrors is read in org.apache.maven.artifact.resolver.DefaultArtifactResolver 
but this line of code is never encountered. Instead, when request.isResolveRoot() returns true - the default value - an attempt is made to download the artifact _before_ 
considering the mirrors, which in this case fails and returns early from the resolve method. I could try to not "resolve the root", whatever that means (no Javadoc), but 
this just looks wrong. Anyway even if the request is not "resolving the root", the mirrors are considered only if the request also isResolveTransitively(), which I do not 
want in general.


So I set a breakpoint on org.apache.maven.artifact.resolver.ArtifactResolutionException. This gets thrown from another overload of "resolve" as a result of a 
org.sonatype.aether.resolution.ArtifactResolutionException, so set a breakpoint on that. This is thrown from org.sonatype.aether.impl.internal.DefaultArtifactResolver 
(now you see why I am giving fully-qualified class names), apparently due to a org.sonatype.aether.transfer.ArtifactTransferException which seems like the expected 
low-level error. When it gets thrown there is no sign of the mirrors, just http://central/; but local variables include a org.sonatype.aether.RepositorySystemSession 
which has a NullMirrorSelector, which must be wrong.


Presumably something was supposed to call org.sonatype.aether.util.DefaultRepositorySystemSession.setMirrorSelector; nothing in the call stack does so. So who calls this 
with a nontrivial selector? org.apache.maven.DefaultMaven.newRepositorySession does, and shows how it can be used. But where do I get that session? From prior experience 
I knew that org.apache.maven.plugin.LegacySupport.setSession is needed for many calls from Maven Compat. And indeed, http://hg.netbeans.org/main-silver/rev/9d464b81555e 
makes the mirror settings be honored, basically passing them in thread-local state.


So what is the upshot? Maybe org.apache.maven.repository.RepositorySystem.resolve needed to be deprecated to begin with. (Replaced perhaps by 
org.sonatype.aether.RepositorySystem.resolveArtifact?) It is used in one place in Maven Core - which, incidentally, does call request.setMirrors, but also 
setResolveRoot(false) and setResolveTransitively(true) and so conveniently triggering the conditions for the mirrors to be read! But this is in 
DefaultProjectDependenciesResolver, and ProjectDependenciesResolver is never called - while again in Core and not deprecated, meaning the mold may be deeper in the cheese.



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

Re: [VOTE] Release Maven Archetype Plugin version 2.1

[Jesse Glick]

Non-binding +1.


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

Re: Compiler plugin release

[Jesse Glick]

On 08/26/2011 01:51 AM, Kristian Rosenvold wrote:

aiming for a release sometime mid-next week


Please consider including the fix for MCOMPILER-140 if you cut a release. It 
has been sitting there with a patch for months with no activity.


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

Re: Thought: write some doc about how not to use snapshots?

[Jesse Glick]

On 08/25/2011 07:34 AM, Benson Margulies wrote:

I discovered yesterday that one team had taken this idea to its local
extreme, and were just using release versions, no -SNAPSHOTS at all.


Do you mean they were only using release versions in dependencies? This would make sense to me. If you want to test a multimodule change (such as API + usage), 
temporarily switch the dependency to a snapshot version, iteratively test the combined change, then commit and release the upstream module, update the dependency to the 
new release, and commit the downstream module. The rule then would be "no snapshot versions in dependencies may be committed except to experimental branches". (I assume 
using snapshot versions for plugins would be verboten as well, especially given MNG-1911; what about snapshot versions for parent links?)


Or do you mean they never used snapshot versions even for projects or even temporarily in dependencies? If so, how do you locally test a multimodule change without 
running the risk of clobbering a locally cached release with your own modified version just by running mvn install on upstream? I can imagine adding a (non-snapshot) 
qualifier to the affected module versions derived from a branch name or JIRA/Bugzilla identifier, e.g "1.3.FOO-114", which would then have little risk of accidental 
confusion with an unrelated patched version.


By the way it would seem safer if Maven refused to overwrite an artifact in the local repository that had been retrieved from a remote repository (as recorded by 
_maven.repositories), or conversely to download even an apparently newer remote update when there was already a locally built artifact. However this would prevent you 
from running e.g. 'svn co http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.0.3 . && mvn install' if you already happened to have 
~/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.jar for unrelated reasons. Perhaps a nonfatal warning could be issued when it looks like 
locally built and remotely downloaded artifacts might be colliding.


Also, is there a standard way of creating a special product build for integration testing that uses the latest committed versions of all components, especially if 
snapshot versions are not being used at all? What about running unit tests against the latest committed versions of the transitive dependency graph even when declared 
dependencies are much older? versions:use-latest-versions could I guess be run as a preparatory step for both, but it modifies the versionable pom.xml, which is 
unpleasant; nicer would be a special Maven flag (or -lib something?) which would replace the standard artifact resolver for the duration of a build.


A published "best practices" document on this topic would be very much appreciated, since the existing references leave this to your imagination. It would also be good if 
IDEs could assist developers with a standardized workflow, e.g.: https://netbeans.org/bugzilla/show_bug.cgi?id=198781



SNAPSHOTs are useful when there's a directed
graph of usage: one entity is publishing, and some other entities are
consuming, and they never switch places.


I think you mean that for a given artifact, SNAPSHOTs are only ever published 
by at most one entity, which additionally ensures that their versions are 
totally ordered?


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

Re: POM reader that preserves CDATA?

[Jesse Glick]

On 08/02/2011 06:00 PM, John Casey wrote:

Anyone maybe have an advanced POM reader/writer stashed somewhere that can 
preserve CDATA and the like?


http://code.google.com/p/decentxml/source/browse/trunk/src/test/java/de/pdark/decentxml/MavenSNR.java
 is said to.


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

Re: More POM5 writing

[Jesse Glick]

On 08/02/2011 08:39 AM, Jason van Zyl wrote:

The schema is being generated from the Modello model so if you see things that 
are incorrect...


For the record, XsdGenerator.java explains:

// Usually, would only do this if the field is not "required", but due to 
inheritance, it may be
// present, even if not here, so we need to let it slide


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

Re: More POM5 writing

[Jesse Glick]

On 08/02/2011 08:52 AM, Benson Margulies wrote:

Adding explicit elements next to xs:any is a far more user-friendly
extensibility mechanism than creating a hodgepodge of namespaces and
prefixes.


Agreed. But if ease of hand editing trumps validation and other tool support, 
do you really want to use namespaces at all?


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

Re: More POM5 writing

[Jesse Glick]

On 07/31/2011 05:12 PM, Benson Margulies wrote:

https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model


"It would [...] be a bad idea to try to use namespaces as a versioning technique." - if you want to allow Schema validation of the entire POM, I think you have to do 
this. Otherwise you cannot add new (optional) elements - lest older versions of Maven or plugins be confused by them - or remove obsolete elements - lest older POMs 
suddenly fail to validate. Code building a model from a range of versioned namespaces could choose to have a single model for all of them, if the differences are minor 
and easily dealt with in small if-then blocks, or could define new models for major revisions; this is awkward but probably no worse than handling "undeclared" changes to 
an existing schema.


Anyway having to type 4.0.0 is no better than xmlns="http://maven.apache.org/POM/4.0.0";, I think. At least the latter means that a 
Schema-aware XML editor/IDE can assist you.


What _is_ bad in Maven currently (at least as of 3.0.3) is that whereas modelVersion is required, you are permitted to write the POM with no namespace declaration at all. 
This means that any code inspecting or modifying a POM has to have a (rarely used) code branch to deal with no-namespace elements, which is cumbersome.


Worse, Maven seems to have a different idea of what valid content is than the schema says. For example, the schema says  
but Maven will report "'modelVersion' is missing." as a fatal error. Certainly there will be some semantic constraints that XML Schema cannot capture - e.g.  can 
be omitted from  if  specifies it - but these ought to be minimized.



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

Re: dependency plugin versus Aether

[Jesse Glick]

On 07/17/2011 05:30 PM, Benson Margulies wrote:

I can't even figure out which JIRA in MDEP corresponds to [the dependency 
plugin issue]. Could someone please send me a pointer?


Are you referring to http://jira.codehaus.org/browse/MSHARED-167 by any chance?


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

Re: [VOTE] Release Maven Dependency Plugin version 2.3

[Jesse Glick]

https://jira.codehaus.org/browse/MSHARED-167 remains unfixed in this release, despite Maven 3 and Aether having been out for a while. (Perhaps the issue should be moved 
to MDEP.)



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

Re: compiler plugin config in plugins -- recent parent change seems ineffectual

[Jesse Glick]

On 07/02/2011 08:04 PM, Benson Margulies wrote:

In maven-shade-plugin, I modified my local copy to point to
maven-plugins version 20 as parent. This in turn points to maven
parent 20. Which configures the compiler plugin for source level 1.5.


Perhaps you mean you pointed to maven-plugins-21.pom, which points to maven-parent-20.pom. And the latter does configure the compiler plugin to use 1.5, but 
(mysteriously) only for the quality-checks profile.


(All easily discoverable by opening trunk/maven-shade-plugin/pom.xml in NetBeans; an editor hint suggests upgrading the parent when the Central index is loaded, and the 
Navigator displays either the parent POM chain, or the effective model and its contributions from various ancestors.)



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

Re: peri

[Jesse Glick]

On 06/27/2011 06:54 PM, Stephen Connolly wrote:

Critically missing from my PoV are:


Consider also 'endorsed' (a serious issue for EE projects especially): 
http://jira.codehaus.org/browse/MNG-4752

Also some notes on a non-transitive compile scope: for NetBeans module development, module -> module deps are not considered transitive. (This is because a module API-1 
might happen to start using some other API-2 for its internal implementation, but this does not mean clients of API-1 should suddenly be exposed to API-2's classes.) The 
current Maven plugin deals with this by (1) writing the dependency metadata in the module manifest based on directly declared dependencies only, which is sort of ugly; 
(2) verifying _after_ compilation that the module's bytecode in fact only refers to classes among the declared dependencies (in case you accidentally compiled against a 
transitive dependency). The situation with OSGi is however more complex, as API-1 is allowed to reexport some of API-2's packages (generally because it refers to those 
types in its own API); ideally, Maven's computed classpath would include both directly declared dependencies and anything reexported by them.



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

Re: [VOTE] Release Maven Indexer version 4.1.1

[Jesse Glick]

Non-binding +1; no apparent problems in NetBeans integration during basic 
interactive tests.


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

Re: Moving forward with mixins

[Jesse Glick]

On 05/24/2011 01:30 AM, Brett Porter wrote:

Some notes on how I think it should work:
- templates should look like a normal POM (perhaps only differing in root 
element, and less strict validation requirements) [...]
- any POM element is valid, other than 
,
- templates need to be sourced from the repository [...]
- templates should have an extension "xml" in the repository. [...]


Maybe I am missing some unmentioned constraints, but the problem as I see it is just that the existing  mechanism does not support multiple inheritance. The 
sketch above sounds like something that is similar to regular inheritance, yet syntactically different, and requiring a new packaging etc. If the POM schema for the child 
(~ importer) needs to be extended anyway, why not make it look and work as much as possible like the existing mechanism?



  
 
  com.yoyodyne.poms
  general
  5


  com.yoyodyne.poms
  java
  2


  com.yoyodyne.poms
  jpa
  1

  
  com.yoyodyne.labs
  newstuff
  1.0
  


$repo/com/yoyodyne/poms/general/5/general-5.pom, $repo/com/yoyodyne/poms/java/2/java-2.pom, and $repo/com/yoyodyne/poms/jpa/1/jpa-1.pom (as well as anything they in turn 
declared via ) would be consulted for defaults in all the usual places, such as pluginManagement.


You would of course have to define some logic for picking which parent (or grandparent...) "wins" in case of a conflict on some item. I think the most natural choice is a 
depth-first search up through the parent graph, in the declared order. (Note that this implies that groupId, artifactId, and version may be inherited as before, but only 
from the first declared parent.)


The main drawback I can see is that you would not be able to inherit any elements the presence of which would cause an empty pom-packaging project (the mixin parent) to 
not be buildable. I think this is what you were getting at when you said "[t]he POM of the template must be separate to the template itself". For example, a parent could 
not actually declare a plugin if that plugin gave an error when relevant source files were missing (e.g. exec-maven-plugin). On the other hand, the parent could do all 
the interesting work in pluginManagement, and the child would just need to turn that plugin on (specifying only groupId and artifactId). Also, some plugins are harmless 
no-ops when present in a parent POM; and this is not an issue for plugins mentioned in the lifecycle, which would be enabled anyway.


You could escape this drawback, where it mattered, by making the actual mixin be a secondary pom-type artifact (attached with install:install-file, say). This *.pom would 
not be "executed" when installing the mixin, just copied. You would need to permit  as a child of  so this artifact could be selected.


Note: the functionality of scope=import in current versions of Maven, limited to supplying , would be subsumed by a feature like this. If you really 
wanted to avoid any XSD change to pom.xml you could just broaden the interpretation of scope=import (so it could inherit other configuration, and perhaps could be 
permitted in regular  outside of ), though the syntax would be less intuitive than .



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

Re: wagon-2.0 ?

[Jesse Glick]

On 05/24/2011 06:01 AM, Olivier Lamy wrote:

Something else I think in a 2.0 version is : upgrading to Apache HttpClient 4.x


 is critical for the lightweight wagon, by the way. And if you are trying to drop dependencies, see my comment in 
.



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

Anyone checking maven-compiler-plugin bugs?

[Jesse Glick]

http://jira.codehaus.org/browse/MCOMPILER-140 is a fairly basic bug in plexus-compiler-javac. It is known to break error hyperlinking for Windows users on IDEA (as of six 
months ago), and NetBeans 7.0 (until a planned workaround patch is released). I attached a proposed patch (including unit test) six weeks ago, but there has been no 
response. Ping?



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

Re: Need help getting our plugins to build successfully in Jenkins

[Jesse Glick]

On 04/22/2011 05:51 AM, Dennis Lundberg wrote:

There are a numbers of problems that prevents our plugins from building
successfully in the ASF Jenkins instance.


bui...@apache.org might be the better place to post, at least for issues 
related to the build server itself.


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

Re: Maven API to partially edit pom.xml

[Jesse Glick]

On 04/13/2011 07:56 AM, Julien HENRY wrote:

I would like to know if there is a standard Maven API to edit parts of a
pom.xml. I managed to parse a pom to a Model using ModelBuilder. Then I can do
some modifications and write Model to file using ModelWriter. But of course it
will completly rewrite the pom (loosing comments, writing unwanted tags like
default values, ...).


The main challenge is finding a library for high-fidelity XML round-trip structure editing, i.e. that preserves all details of whitespace and formatting for unmodified 
nodes. NetBeans has such a system (XAM/XDM) but the dependency tree is too deep for use in a Maven plugin. http://code.google.com/p/decentxml/ is the only such small 
library I can find. It has its own model rather than Document, DOMImplementationLS, etc., so your code would be tightly tied to that API. It does not appear to be 
published on Central and I am unsure how reliable it is, but it has a Maven POM utility already, and it seems to work as advertised in my testing - replacing a few 
element attribute values on some largish hand-edited XML files produced a minimal diff.



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

Re: [VOTE] Release Maven Surefire 2.8.1

[Jesse Glick]

On 04/12/2011 09:32 AM, Olivier Lamy wrote:

I'd like to release surefire 2.8.1


You may want to take a look at SUREFIRE-724 first. Not sure if this would be 
simple to fix, though.


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

Re: Inflexibility of --also-make w.r.t. unusual goals

[Jesse Glick]

On 04/05/2011 12:31 AM, Brett Porter wrote:

2. mvn --also-make-goals -pl submodule test-compile test

Does the issue make sense now, and is it worth filing a JIRA ticket for this?


It makes sense.


Filed then: http://jira.codehaus.org/browse/MNG-5059

Not sure how it would be implemented, however. The current list of options is not just a superficial piece of logic in org.apache.maven.cli but seems baked into how 
MavenExecutionRequest is defined.



I'm not sure how many people would use this - it's quite some entry complexity 
to gain a little more runtime efficiency.


I was thinking of using a feature like this from an IDE or other scripted 
environment, in which case a slightly more complex command is no obstacle.


I've always thought the solution to these type of problems was to invest more 
effort in incremental builds (don't run tests if no code + dependencies 
changed).


That would be useful too, but requires work on the part of plugins (here, 
Surefire).


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

Re: [VOTE] Release Maven Indexer version 4.1.0

[Jesse Glick]

On 03/31/2011 03:55 PM, Brian Demers wrote:

https://repository.apache.org/content/repositories/maven-056/


Non-binding +1 based on testing in NetBeans integration.


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

Re: Inflexibility of --also-make w.r.t. unusual goals

[Jesse Glick]

On 10/02/2010 07:27 AM, Brett Porter wrote:

mvn -am -pl main run

would automatically invoke just 'install' (or 'package') on the calculated 
dependencies.


I don't agree that "install" on one and package on the dependencies would make 
sense - this would put something in the repository that potentially doesn't
have its dependencies there, making it unusable by other projects.


You would rather install the dependencies, and run the selected project without its install phase, so the local repository would not be inconsistent. Or if the run goal 
could work with reactor artifacts, just compile or package on the dependencies would suffice, i.e. without anything getting installed in local.


Let me provide a simpler example using only standard jar packaging and its default plugins. If I have a tree of modules using snapshot dependencies internally, and wish 
to run unit tests on one of them while ensuring that the test classpath includes up-to-date class files from its snapshot dependencies, what should I run?


a. 'cd root/submodule; mvn test' will run tests for just submodule, but relies on JARs in the local repository for all the snapshot dependencies, which is no good; these 
JARs might be missing, or old.


b. 'cd root; mvn test' will run the tests for submodule correctly, but also 
tests in every other module.

c. 'cd root; mvn test -Dtest=sub/module/pkg/**' might run the right set of tests if you happen to have things in a particular package structure, but this is not general. 
Anyway Surefire will fail the build on upstream modules because it found no tests to execute.


d. 'cd root; mvn install -DskipTests -am -pl submodule; cd submodule; mvn test' will run just tests for submodule and with correct snapshot dependencies, but will be much 
slower as it builds JARs (and use of -DskipTests may be objectionable).


e. 'cd root; mvn test-compile -am -pl submodule; cd submodule; mvn test' will not work since the second Maven command is given no reactor, so it will not look up 
dependencies in target/classes but in the local repository.


There seems to be no decent solution using current --also-make. The solutions 
using the styles I proposed previously would look like:

1. mvn -am -pl submodule test-compile -then -pl submodule test

2. mvn --also-make-goals -pl submodule test-compile test

3. mvn --also-make-smart -pl submodule test [where test known to presuppose test-compile in dependents; compile would suffice if there were no deps on secondary test 
artifacts]


(An IDE user might ask the IDE to just run JUnit on submodule/src/test/java/**/*.java bypassing Maven and Surefire and using some IDE-specific compilation of dependencies 
from sources, if the IDE has been configured to run tests exactly the same way as the POM specifies Surefire should run them, but it would be best if command-line Maven 
could do this to begin with.)


Does the issue make sense now, and is it worth filing a JIRA ticket for this?


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

Re: '*.java ident' considered harmful

[Jesse Glick]

On 03/04/2011 12:29 PM, Benjamin Bentmann wrote:

As long as somebody else provides the patch, that's fine with me


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


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

'*.java ident' considered harmful

[Jesse Glick]

Is this line in .gitattributes for Maven 3 sources really necessary? Using $Id$ is ugly; right now seeing if I can work around a status bug in the NetBeans Git 
integration caused by it. Wouldn't it be better to just delete $Id$ from those SVN sources where it appears?



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

Re: [PLEASE TEST] Apache Maven 3.0.3-RC1

[Jesse Glick]

On 02/28/2011 07:09 AM, Benjamin Bentmann wrote:

Fixed in trunk by now.


Rev 1075309, which seems to be included in 3.0.3 final. Suggestion for 
tightening up RepositoryUtils.getLayout a bit:

1. Call repo.getLayout() outside the try block, since that is not expected to 
give an error. It is used twice anyway.

2. Catch AbstractMethodError, rather than LinkageError which could hide 
unrelated issues.

Cleaner would have been to introduce ArtifactRepositoryLayout3 (?) with the 
getId() method; then a simple instanceof check would suffice. But I guess it is 
too late for that.


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

Re: JIRA project for indexer?

[Jesse Glick]

On 12/07/2010 06:09 PM, Brian Fox wrote:

We'll take a pass and see which are applicable


That's what I meant; of course some will not be.


flag them in some way.


Such as closing them and refiling in MINDEXER? If someone bothered to report a bug, it seems like the least you can do. (And the reporter might not have sufficient 
permissions to close the old one; I know I don't.)



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

Re: JIRA project for indexer?

[Jesse Glick]

On 12/03/2010 10:09 AM, Brett Porter wrote:

I went ahead and created this. http://jira.codehaus.org/browse/MINDEXER


Consider moving at least the open issues relevant to the donated codebase from:

https://issues.sonatype.org/browse/NEXUS/component/10050

(For example, I would want to track NEXUS-3358 in the proper location.)


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

Re: [VOTE] Release Maven Indexer version 3.1.0

[Jesse Glick]

On 11/23/2010 02:06 PM, Brian Demers wrote:

Vote open for 72 hours.


Is this release still going ahead?


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

Re: [VOTE] Release Maven Indexer version 3.1.0

[Jesse Glick]

On 11/23/2010 03:08 PM, Jesse Glick wrote:

Not exactly a blocking issue for 3.1.0, since as a workaround I can
always avoid getWagonResourceFetcher and find the right Wagon myself


Specifically:

new WagonHelper.WagonFetcher(plexusContainer.lookup(Wagon.class, 
URI.create(repositoryUrl).getScheme()), listener, null, null)

Other than this minor issue which I guess could be corrected in 3.1.1, a non-binding +1 from me. The staged JARs appear to work fine embedded in NetBeans - downloading & 
unpacking remote indices, indexing local repo incl. custom fields, and searching indices in a variety of ways. And unlike 3.0.4 they do not need to be patched to avoid 
the IllegalAccessError with Lucene in its own ClassLoader.



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

Re: [VOTE] Release Maven Indexer version 3.1.0

[Jesse Glick]

On 11/23/2010 02:06 PM, Brian Demers wrote:

Staging repo: https://repository.apache.org/content/groups/maven_promotion-010/


Ironically enough, the index for this repo seems to be broken. :-) https://repository.apache.org/index.html#view-repositories;maven_promotion-010~browseindex gives a 500 
error, and when downloaded it seems to contain just an entry for org.apache.apache.resources:apache-source-release-assembly-descriptor:1.0.3.



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

Re: [VOTE] Release Maven Indexer version 3.1.0

[Jesse Glick]

Why does WagonHelper.getWagonResourceFetcher work with only http? Seems rather arbitrary, especially as there seems to be a separate role hint for https, which is by no 
means an exotic corner case. Would seem better to restore the older and more generic code that used WagonManager.getWagon.


Or is the point just to avoid the (undocumented) deprecation of 
WagonManager.getWagon? So just copy the trivial impl in DefaultWagonManager.

Not exactly a blocking issue for 3.1.0, since as a workaround I can always avoid getWagonResourceFetcher and find the right Wagon myself, but would seem preferable to not 
introduce a factory method which is broken by design.


(BTW "extends AbstractResourceFetcher implements ResourceFetcher" is redundant.)


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

[Jesse Glick]

Non-binding +1; seems to be working fine in NetBeans development builds.


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

Re: Access to the raw list of dependencies - multiple versions of an artifact included

[Jesse Glick]

On 11/19/2010 01:36 PM, Rex Hoffman wrote:

Maybe we should construct a cleaner api though.  One that could wrap
maven-dependency-tree in maven 2.2.1 and use aether in 3.0.


Alternately: release maven-dependency-tree 1.3 with an unchanged public signature that is just a proxy for Aether API, and mark m-d-p deprecated (i.e. new code should use 
Aether directly). This would allow clients such as the dependency plugin to easily and immediately fix the visible bug (inconsistency with Aether's resolution), and 
switch to the preferred API when time permits. aether-api has no dependencies so it should not be burdensome to include it as a transitive dep of m-d-t 1.3 from an 
existing client, even a plugin running in Maven 2, but perhaps aether-impl also would need to be included with runtime scope.


The question is whether you *want* something like the dependency plugin when running in M2 to mimic the graph traversal bugs in M2, or whether you want it to behave like 
the corrected version in M3. If the former, then a related possibility is to have m-d-t 1.3 behave like 1.2 did (using the same old code), unless an optional component is 
present which depends on Aether and switches the behavior to mimic M3. This would only work for plugins in case they could express a runtime dependency on a certain 
artifact iff running inside M3.


I don't pretend to understand m-d-p very deeply, but I have a bunch of old code (not written by me) which uses it, and my attempts to switch to org.sonatype.aether.graph 
were foiled by the fact that there is not a clear correspondence between the APIs when you get into the details. In particular, there is no apparent equivalent to 
DependencyNode.getState, and some of my client code has explicit handling of e.g. OMITTED_FOR_CONFLICT which is central to its function.



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

Re: Access to the raw list of dependencies - multiple versions of an artifact included

[Jesse Glick]

On 11/18/2010 07:20 PM, Rex Hoffman wrote:

it's pretty straight forward if you use some code provided by the dependencies 
library (part of the maven-dependencies-plugin)


Beware that this does _not_ produce the same results as Aether in certain 
cases, and there is no apparent plan to fix it: 
http://jira.codehaus.org/browse/MSHARED-167


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

Re: Use of standards in the Maven core

[Jesse Glick]

On 11/18/2010 03:34 AM, Kristian Rosenvold wrote:

The rant is somewhat about seeing all these internal components.


A little bit, though it is generally easy to see from the package or class name that something should be considered an implementation. My slow learning curve has had to 
do with the interfaces, probably not helped by starting from embedder code originally written against Maven 2 that was probably doing things the wrong way.


I should note that what I have seen so far of Aether interfaces has been much more clearly documented, and the code looks to do a better job of noticing invalid or 
missing parameters and throwing helpful exceptions early. So I think the issue is that older code never got fully documented or made foolproof, which is understandable 
given the focus on shipping 3.0.



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

Re: Use of standards in the Maven core

[Jesse Glick]

On 11/15/2010 04:45 AM, nicolas de loof wrote:

AFAIK most code (including some
plugins) related to POM parsing use Xpp3Reader, as we don't provide an
abstraction API for POM parsing.


Along the same lines, http://jira.codehaus.org/browse/MNG-4862 shows that org.apache.maven.model.ConfigurationContainer assumes that unspecified XML trees are represented 
as Xpp3Dom, so any code which e.g. reads/writes a plugin's  must cast to Xpp3Dom and use this interface. I doubt it would be straightforward to introduce a 
compatibility layer now, other than a supertype in the Maven namespace with a similar signature as Xpp3Dom, which would not really simplify usage.



On a tangent, I agree with Lennart's complaints about the quality of the interfaces generated by Modello, but at least I can refer back to the schema for explanation; the 
hand-written interfaces in Maven are just as bad as regards null safety, bean "pattern" abuse, and Javadoc, but in a less predictable way. My experiences embedding Maven 
3 in an IDE go something like this:


1. Look around the class index for something that sounds vaguely like what you need. If there is a ProjectLifecycleArtifactDependencyResolver interface and a 
DependencyArtifactProjectScopeResolver and a LifecycleScopeArtifactDependencyClassifier etc. etc. then just pick one. Any Javadoc would anyway be of the form "This is an 
artifact dependency resolver for the project lifecycle", which doesn't tell you anything about who uses it, when, or why. If it's @Deprecated, perhaps it came from Maven 
2; pick another one randomly, since the Javadoc never says what the intended replacement is.


2. Check source code backreferences to see if the interface you picked is ever 
actually called. If not, return to step 1.

3. Hope that there is an instance of the interface somewhere in the Plexus container. (And that no special role hint is needed, since these are unlikely to be documented 
anyway.) Check class index for DefaultEtcEtc, and read source code to see if it sounds like it is doing something you wanted.


4. Grab an instance and try calling some method on it. Usually there will be 
five overloads so just pick the one with the shortest argument list.

5. Take the first NullPointerException you encounter and inspect the code mentioned in the stack frames. Use a process of logical inference to determine what field of 
what class was expected to be non-null. This is sometimes complicated by the presence of several different SomethingRequest interfaces being passed around and 
interconverted, each of which has its own (undocumented) assumptions about nullity of certain parameters - and conversion is always of the form 
newRequest.setFrobnitz(oldRequest.getFrobnitz()) with no intermediate sanity check.


6. Call the setter corresponding to the null field in #5 and return to step 4 
until something happens.


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

Re: Auto apache version standard as an enforcer rule?

[Jesse Glick]

On 11/09/2010 07:07 PM, Rex Hoffman wrote:

I'm leaning to using the (javadoc) annotations


The trouble with Javadoc pseudo-annotations is that they are unavailable in bytecode and thus invisible to a tool like sigtest. I don't know about Clirr. I suspect this 
particular set of Javadoc tags was designed with Eclipse editor hints in mind, which probably have access to HTML Javadoc of APIs if not the original source project, and 
possibly predated JSR 175.


Furthermore, they will (ironically enough) not appear in the Javadoc HTML output by default, unlike a true @Documented annotation. The burden is on the library developer 
to remember to pass a complex argument such as -tag noimplement:t:"Do Not Implement" to the javadoc tool for each such annotation in use.


Also consider other tools which might want to analyze this information - such as FindBugs, or a hypothetical annotation processor that verified that a @NoImplement 
interface was not in fact implemented except by authorized providers.



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

Re: Auto apache version standard as an enforcer rule?

[Jesse Glick]

On 11/09/2010 02:21 PM, Rex Hoffman wrote:

http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf


Take note of the distinction made on pp. 5-6 between "interface" and "package". Without some special annotations, it is not possible for a tool to mechanically decide 
whether a given interface is intended to be used by a consumer and implemented by a provider, or vice-versa (or some more complex combination).



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

Re: Auto apache version standard as an enforcer rule?

[Jesse Glick]

On 11/09/2010 11:30 AM, Rex Hoffman wrote:

The only current problem is that it's not in the maven repo.


True. Probably not hard to fix, if that is the only obstacle; take it off list 
if interested.


I don't suppose your teams usage of it is based off on an open source ant task?


Currently we are using it via http://hg.netbeans.org/apitest/ which seems to inline the original project's code (not sure why offhand). Probably not relevant to use from 
a Maven plugin.



Though cutting a new interface is generally better programming, I don't
want this tool to force developers to do that. I want this to be easily
adopted by as many projects as possible.


Agreed, I just think the _default_ policy should be binary compatibility as defined by http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html - you should 
need to declare alternate policies somehow. (It is also safer to flag a change as incompatible, and have the developer indicate that it is OK in order to fix the build, 
than to silently claim that changes were compatible when the developer was not even aware of the possible breakage.)



Would the ability to configure the annotation and whether the plugin should
use binary or source compatibility when evaluating the interface/abstract
class meet your needs for QualifiedPublic?


No, @QualifiedPublic works differently. (Again, @QP is just an idle experiment 
at this point.)


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

Re: Auto apache version standard as an enforcer rule?

[Jesse Glick]

On 11/08/2010 02:21 AM, Rex Hoffman wrote:

project: java-version-delta


By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license & feature set suits your needs but it would make 
a potentially useful alternate impl. This is the tool used by some of Oracle's teams to check (primarily binary) compatibility of Java APIs.


My background: for netbeans.org API modules we run this tool to check for compatible & incompatible changes among packages marked public. Currently we have an 
idiosyncratic Ant build (is there any other kind?) so comparisons are done against the modules as they existed in the last product release, but of course in a Maven setup 
we would use the policy you are proposing: x.y -> x.(y+1) may have compatible but not incompatible changes, etc.



The apache portable runtime version standard does want the name of a library
to include it's major version number, so for ubuntu/debian xerces look like:
libxerces2-java_2.9.0-1_all.deb


Not sure this is applicable to most Java development. If you are using a container (such as OSGi) which supports class loader isolation, *and* this container permits 
multiple components with the same ID (but possibly different versions) to be loaded in parallel, then it is unnecessary. Containers with isolation but which enforce 
uniqueness on loaded IDs might benefit, so long as it really makes sense to load two copies of the component - true for plain old class libraries, not necessarily true 
for "active" components which might register services of some sort. Apps not using a container are unlikely to benefit since you could only use multiple versions of a 
library in case the package hierarchy was also renamed. Anyway, I agree that this is not likely something that an API compatibility plugin should address (a separate 
enforcer rule would suffice).



the default would be to
assume that a client of an artifact is not expected to implement [any 
interfaces]


This seems like a poor default - directly contradicts the longstanding Java compatibility policy. (*) If anything, I would place the burden on API designers who publish 
interfaces (or abstract classes) they expect no one else to implement, despite there being no such enforcement from the Java language. (**) An annotation for this purpose 
makes some sense, but it would have to be hosted in a very generic place quite unrelated to a Maven plugin. In the short term, plugin configuration to exclude implements 
checking on certain types or packages may be a better workaround.


(*) For binary compatibility it is permitted to add an interface method without breaking existing implementers, so long as this method is never called - but that 
condition is unlikely, since why would there be a method no one is calling? You cannot even check whether a given object implements a new method or not without using 
reflection. Better to just introduce a new interface (possibly extending the old one) when you want to change signatures.


(**) If the API designer wants, it is possible to expose an abstract class which can be implemented only within the same component. JSR 294 would be very helpful here, 
but it is possible today so long as all the implementations are in the same package, *or* the component uses a format (such as OSGi bundle) which permits restrictions on 
the exported types or packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing with a more fine-grained system but for now it requires javac from JDK 7.



-
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

[Jesse Glick]

Nonbinding +1; seems to be working well embedded in NetBeans IDE development 
builds. Nice job.


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

Re: Inflexibility of --also-make w.r.t. unusual goals

[Jesse Glick]

On 10/02/2010 07:27 AM, Brett Porter wrote:

Are there plans for a more clever make mode? The 3.0 compatibility guide 
implies that there are, but does not give any specifics.


I'm not sure what you're referring to that gave that indication?


https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-LegacystyleReactorModeusingIncludes/Excludes
 [BTW anchor link in TOC is broken]

"Future development will focus on improvements to the make-like reactor mode that 
provides similar functionality but is aware of the project hierarchy."


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

Inflexibility of --also-make w.r.t. unusual goals

[Jesse Glick]

While working on IDE support for running Maven on multi-module projects [1] I have run up against what seems to be a fundamental limitation of --also-make. This "reactor 
mode" works fine when the specified goal is standard across all lifecycles in the tree, such as 'install' or 'package'.


But frequently you would want to run some special goal which only makes sense on a particular packaging, or otherwise only for certain kinds of modules. Typically this 
would be some sort of "run" goal. As a simple example, in Hudson main sources the 'core' project (using a custom packaging akin to jar) supports just the usual goals such 
as install, while the 'war' project which depends on 'core' has war packaging and supports a hudson-dev:run goal to start Jetty for interactive testing. To test code 
changes, normally you build core, then run war.


Similarly, when developing NetBeans Platform applications, you typically have an aggregator/parent, which contains one project with nbm-application packaging supporting 
the nbm:run-platform goal to start the application in development mode, which depends on a bunch of module projects with nbm packaging supporting the usual 
package/install phase. If you make a change in a module and want to test it interactively, you must first build the module, then build & run the app; the module project 
cannot in general "know" how to start the app together with all its siblings.


These scenarios seem to call out for make mode. The problem is that 'mvn --also-make --projects  ' only permits specification of a single goal, which will be 
run in all the projects encountered; 'mvn -am -pl main something:run' dies with an error on the first dependency since it does not use the plugin with 'something' prefix. 
In these examples, what is wanted is to run 'install' (or perhaps 'package') on all the discovered dependencies, followed by something like 'run' on the "main" project.


The only workaround I can find is to run separate chained Maven commands: 'mvn -am -pl main install && mvn -pl main run'. While this works, it is slower and clumsier, and 
produces two sets of output.


I can imagine several ways Maven could support this use case:

1. Some distinguished Maven CLI argument which would run sequential commands, but within the same JVM, sharing cached plugins and project metadata, and producing a single 
summary. E.g.:


  mvn -am -pl main install -then -pl main run

A bit crude, and not very friendly to parallel builds, but at least simple. This of course could be used for other purposes, such as passing -DskipTests only to certain 
subprojects.


2. Some way of telling --also-make to use a different goal for dependencies 
than for the specified project, e.g.

  mvn --also-make-goals -pl main install run

where for each project in the reactor, only as many goals in the given sequence 
would be run as are actually available.

3. Some way of declaring in general (say, plugin.xml#//mojo/dependencyGoal) 
that a certain goal presupposes a different goal be used on reactor 
dependencies, so that plain

  mvn -am -pl main run

would automatically invoke just 'install' (or 'package') on the calculated dependencies. Note that this could be useful even with common plugins; 'install' on a jar 
project really only needs to 'package' its jar dependencies. (For compatibility reasons, a different switch than --also-make could be introduced to enable the new behavior.)


Perhaps --also-make-dependents could benefit from per-project goal selection as 
well; offhand I cannot think of a use case.

Are there plans for a more clever make mode? The 3.0 compatibility guide 
implies that there are, but does not give any specifics.


[1] https://netbeans.org/bugzilla/show_bug.cgi?id=189417


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

Is maven-archetype required/recommended for archetypes?

[Jesse Glick]

[Originally posted to d...@mojo without response. This might be the more 
appropriate list, so reposting here also with some updates.]


Recently I worked on an IDE feature [1] which enumerates archetypes available in your local repository that you might want to instantiate projects from, so you can pick 
from a list, and ran into a problem which I'm not sure I have solved satisfactorily.


If the archetype used maven-archetype then the install phase seems to insert an entry in archetype-catalog.xml, which makes it easy to find in the 
local repo. Archetypes from a remote repo are also easy to find because the Nexus indexer records the packaging for every artifact, so you can do a Lucene search on it, 
even if the remote archetype-catalog.xml was missing or not up to date. And archetype:create-from-project sets up this packaging - fine.


But it seems that many real archetypes just use jar packaging. Those in mojo-archetypes always have as far as I can tell. [2] Official ones like Quick Start sometimes use 
the custom packaging. [3] To find these in the local repository you need to add a custom index field looking for archetype-metadata.xml [4] in the JAR artifact, and there 
is no clear way to find them in a remote repository.


So should mojo-archetypes/* be converted to use maven-archetype packaging and 
new releases made?


[1] https://netbeans.org/bugzilla/show_bug.cgi?id=190401


[2] Another curious thing: though the mojo-archetypes appear to have always used jar packaging, and e.g. webapp-javaee6 in Central lists the packaging as jar when you 
download the POM for 1.0, 1.0.1, 1.0.2, and 1.1, the Central index lists the packaging as maven-archetype for 1.0, 1.0.1, and 1.0.2 - but not 1.1. Why?


Furthermore, http://repo1.maven.org/maven2/archetype-catalog.xml lists 1.0, 1.0.1, and 1.0.2, but not 1.1. Nor, now, 1.2 - as someone was just complaining on us...@mojo, 
webapp-javaee6 1.2 is not offered by m2eclipse.



[3] It seems that newer "official" archetypes use the special packaging:

http://svn.apache.org/viewvc/maven/archetype/tags/maven-archetype-quickstart-1.1/pom.xml?revision=938664&view=co

(I cannot find the "trunk" version of this code - was the source tree 
reorganized?) Older releases use jar packaging, as far as I can tell.


[4] archetype.xml seems to be an older and semideprecated format - right? Yet 
quickstart 1.1 uses it.


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

Re: [PLEASE TEST] Apache Maven 3.0-RC2

[Jesse Glick]

http://jira.codehaus.org/browse/MNG-4836 may or may not be a recent regression, but I have recently (i.e. ~ RC1) observed it making projects sporadically unloadable 
inside the NetBeans IDE, with no apparent workaround. Have been running with a patched plexus-interpolation and have not seen it recur when using this patch (while it 
does continue to happen sometimes when using an unpatched 3.0 RC2), so I believe PLXCOMP-159 is the cause.



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

Re: [PLEASE TEST] Apache Maven 3.0-RC1

[Jesse Glick]

On 09/16/2010 05:21 AM, Benjamin Bentmann wrote:

This is an attempt to collect feedback from a broad audience before we start 
the vote for 3.0, similar to what was done in the past.


I'm a bit confused over the labeling "RC1", perhaps you could clarify.

1. Nothing is published at http://maven.apache.org/download.html - only beta 3.

2. http://www.sonatype.com/people/2010/09/please-try-maven-3-0-rc1/ says "[after making fixes] we will release the final RC1", implying maybe that this is a release 
candidate of a release candidate.


3. There were votes on betas, but no apparent vote on this RC.

So is this really a "candidate" for release as 3.0 or do you expect to continue making fixes? Will you keep on publishing "RC1" over and over (distinguishing the 
different builds with timestamps??), or will there be RC2, RC3, etc. as needed?


(I am bundling M3 builds in NetBeans 6.10 development builds, and I would like 
there to be unambiguous version labels in case any problems are found.)


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

Re: [PLEASE TEST] Apache Maven 3.0-RC1

[Jesse Glick]

On 09/15/2010 04:34 PM, Benjamin Bentmann wrote:

If you encounter unexpected build issues, please fil[e] a report in JIRA


Would be good to take a look at http://jira.codehaus.org/browse/MNG-4428 (server redirect handling) and reconsider its low priority. Although it is claimed to affect 
2.2.1 and hence not be a M3 regression, my experience in http://jira.codehaus.org/browse/MNG-4816 is that some bug in M2 masks it under certain circumstances, so that M3 
effectively regresses. A patch has been available for over six months with no official comment.



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