Re: Inflexibility of --also-make w.r.t. unusual goals
On 05/04/2011, at 1:16 AM, Jesse Glick wrote: > 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? It makes sense. Of the solutions, 2 seems clearest, though the test-compile should sit with the --also-make-goals parameter. However, I'm not sure how many people would use this - it's quite some entry complexity to gain a little more runtime efficiency. 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). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Suggestion: split the user list
Writing plugins is for most a function of using Maven. I think the users@ list is the right place to ask. If you're not getting answers, that's a different problem :) A split would only make sense if there were a number of people talking about plugin development already that was hindering less advanced users from getting answers. Creating a list without a group of people to go there is probably not going to make your situation any better, as you'll shrink the audience. - Brett On 05/04/2011, at 11:59 AM, Benson Margulies wrote: > My perception is that there's still a lot of room for improvement in > the documentation of the various interfaces that a mojo developer > needs to talk to. So a would-be plugin developer is prone to have > questions. > > On a day when the user list is swamped with some the latest flame-fest > about the supposed conflict between maven and continuous-hibachi, or > the whatever buzzword is in play, I think that there's a lot of room > for questions to go missing. > > Of course, I suppose that this is also true of legitimate user > questions drowned out. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Parent-to-child inheritance of dynamic properties
On Sun, Dec 12, 2010 at 10:45 AM, Benson Margulies
wrote:
> On Sat, Dec 11, 2010 at 7:05 PM, Benjamin Bentmann
> wrote:
>> Benson Margulies wrote:
>>
>>> Say that, in a parent pom, there is an execution of a plugin that sets
>>> a property. (e.g. the build helper plugin's port reserver).
>>>
>>> Will those properties inherit down to the children?
>>
>> No, the runtime data of project instances is separated.
>
> Let me explain what I had in mind, perhaps there's a better way to
> accomplish it.
>
> I was about to walk over a hierarchy of about 20 poms adding, to each,
> a property like:
>
> ../../..
>
> where the number of ..'s would be different depending on the hierarchy
> location of the POM. So, I had this inspiration: make a plugin that
> could be stuck at the very top that would set a property to the
> absolute path of the top, and let it trickle down. Then individual
> projects could reference some large, slow-to-copy items up there with
> ${globalRoot}/refrigerator.
>
> Of course, my plugin doesn't work due to what you just told me. So, I
> wonder -- is there some other way to do this?
Have you considered the case where someone only has a single module of
your build checked out?
In that case globalRoot will be pointing to something that does not exist.
The way you are trying to solve the problem doesn't feel right.
Can you explain what you are trying to do?
I vaguely remember someone else talking about large resource sets and
exploding them inside your ~/.m2/repository.
I'm not sure this is similar to your problem, but we do Eclipse RCP
development and use maven-dependency-plugin:unpack to extract the
eclipse RCP (+delta packs) where we have manually added the zips to
our internal repository.
So as long as we don't "clean" that project out, we have the large
target platform exploded for use by the development team.
But this isn't referenceable by other maven modules.
There may be some guidance on the war/ear plugin since merging this
stuff may be relevant there.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Suggestion: split the user list
My perception is that there's still a lot of room for improvement in the documentation of the various interfaces that a mojo developer needs to talk to. So a would-be plugin developer is prone to have questions. On a day when the user list is swamped with some the latest flame-fest about the supposed conflict between maven and continuous-hibachi, or the whatever buzzword is in play, I think that there's a lot of room for questions to go missing. Of course, I suppose that this is also true of legitimate user questions drowned out. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Suggestion: split the user list
On Mon, Apr 4, 2011 at 7:11 AM, Benson Margulies wrote: > Oh Maven PMC, > > Have you ever considered splitting the user list into one for people > who type 'mvn' and another for people developing plugins? The > audiences are fairly distinct, and I think that it would improve the > Signal to Noise ratio, and facilitate more communications, if they > were split. Hm. If I were developing a plugin I'd probably ask on mojo-dev, not on the Maven users list. The dev list should be for discussion about developing Maven itself, but I suppose questions around how your plugin should interact with the Maven code would be appropriate. So, I sort of agree, there doesn't seem to be a good place for general plugin dev questions without going outside of Apache. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Suggestion: split the user list
On Mon, Apr 4, 2011 at 8:41 PM, Benson Margulies wrote: > Oh Maven PMC, > > Have you ever considered splitting the user list into one for people > who type 'mvn' and another for people developing plugins? The > audiences are fairly distinct, and I think that it would improve the > Signal to Noise ratio, and facilitate more communications, if they > were split. If you are developing a plugin, you can use the developers list? See http://maven.apache.org/mail-lists.html I can't find anything that explicitly states that plugin development is not allowed on the dev list, but that is where I would expect people to post. - 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
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
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: Repository Security Improvement
I'd be interested in talking about it again, if you have time/new thoughts to share. On 4/2/11 8:34 AM, Chad La Joie wrote: Quite some time ago I was asking[1] about PGP support in Maven. And in February Brett noted[2][3] some initial thinking he had done around increasing certain security aspects of Maven repositories. I've come back to this topic again and have been doing some thinking on it. Is this still a topic people are interested in? Is there a willingness to make changes to APIs in order to support this kind of work? I can write up my current thoughts on the topic if there is some interest. [1] http://www.mail-archive.com/dev@maven.apache.org/msg75604.html [2] http://www.mail-archive.com/dev@maven.apache.org/msg87327.html [3] https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Security -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Suggestion: split the user list
Oh Maven PMC, Have you ever considered splitting the user list into one for people who type 'mvn' and another for people developing plugins? The audiences are fairly distinct, and I think that it would improve the Signal to Noise ratio, and facilitate more communications, if they were split. - 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
Hi Hervé, issues created MINDEXER-23 MINDEXER-24 Thanks for spotting these! ~t~ On Sun, Apr 3, 2011 at 10:35 AM, Hervé BOUTEMY wrote: > but I have a few (non-blocking) remarks: > - a description should be defined in each pom.xml (actually description is > inherited from Maven parent pom) > - the site should be published: [1]? > > tell me if I can help > > Regards, > > Hervé > > [1] http://maven.apache.org/maven-indexer > >
