Re: svn commit: r775789 - in /maven/resources/trunk/apache-source-release-assembly-descriptor: ./ pom.xml src/ src/main/ src/main/resources/ src/main/resources/assemblies/ src/main/resources/assemblie
Hi Brian,
Author: brianf
Date: Mon May 18 01:15:18 2009
New Revision: 775789
URL: http://svn.apache.org/viewvc?rev=775789&view=rev
Log:
add new component to hold the asf specific source descriptor
+
+ source-release
+
+tar.gz
+zip
+
+
+
+ ${project.basedir}
+ true
+
+**/${project.build.directory}/**
+
Is this working reliably? AFAIK, include/exclude patterns are
usually relative to the fileset's base directory but
${project.build.directory} could resolve to an absolute path, couldn't it?
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Programatically loading jars from the local maven repository
I need to programatically load jars from the local maven repository. While the format of the repository is pretty simple I would like to be relieved of the tedium of discovering where this local repository is and, as an added bonus, I would love to have jars automatically downloaded to my local repository if it is not there already. Can someone point me to the code bits that will help me do this? Regards, Alan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Gathering Artifact repository discovery requirements
On Sun, May 17, 2009 at 3:15 PM, Brian Fox wrote: > Bump. Maybe it would be better to post the info and discuss here? I don't think people are going to keep going back to a wiki page to follow the comments, and it would be good to have it all in the list archives anyway. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: maven-assembly-plugin 2.2-beta-4-SNAPSHOT single validate true source-release org.apache apache-source-release-assembly-descriptor 1.0-SNAPSHOT Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? [1] https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4 [2] https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor On Mon, May 4, 2009 at 9:01 PM, Brian Fox wrote: > There have been a few threads spawned on various ASF lists lately about the > release process at the ASF and Maven projects and other Apache projects that > use Maven being compliant. > > A documentation patch for the release page at > http://www.apache.org/dev/release.html is pending, but it's close enough > that I can summarize it here. The ASF produces Open _Source_ releases. The > primary artifact that is to be released and voted upon is a source archive > that is sufficient for others to use to produce the product. Binaries that > are also released have additional requirements such as NOTICE and LICENSE > files, but these are not considered to be the primary release -- the source > archive is. > > Part of the default release profile in Maven is to generate sources jars. > These sources jars contain the java packages only and not the pom.xml or any > resources or test resources actually used to build the project. In short, > they aren't really close at all to what you might find in an svn tag for the > same release. The primary use of these jars is by IDEs for debugging > purposes. The Maven Core releases do produce source archives using the > assembly plugin. Plugins, Shared, and other smaller releases do not. This > part is not in compliance with the ASF release process and needs to be fixed > before the next release. > > A simple solution to this problem is to bind the assembly plugin using a > src descriptor to the pom. This will work in the short term for releases > ready to go like the archetype plugin. However, it won't be very > maintainable since we have over 60 modules (i stopped counting after plugins > and shared) that are individually released. If we bind the plugin in the > Maven pom, it would produce source archives for every single module > recursively, which is not what we want here. > > To solve this, I've added a new flag to the Assembly plugin that will tell > the plugin to only run in the Execution Root folder and skip everything > else. The enforcer plugin tree is a good example of how this will work. The > plugin binding would be defined in the Maven pom and thus inherited down to > the Enforcer. The Enforcer tree looks like this: > > \ > +---enforcer-api > +---enforcer-rules > +---maven-enforcer-plugin > \---pom.xml > > Normally I would do a release of the enforcer from the top and release the > parent, the api, rules and plugin all at once. In this case I want the > source archive to zip up the entire tree. However, I may do a release of the > plugin only. In this case I would run from the > \enforcer\maven-enforcer-plugin subfolder. In this case, I want the just > maven-enforcer-plugin source archive because that's what I'm releasing. > > The new flag in the assembly plugin would allow both cases to work without > changing the poms, because the goal would skip in any project that doesn't > match where Maven was executed > (!session.getExecutionRootDir().equals(basedir)) > > Eventually if we get this perfected, it would be appropriate to bump up to > the Apach
Re: 5 minute guide - Incorrect documentation/documentation improvement?
On Mon, May 18, 2009 at 2:49 AM, Martijn Verburg wrote: > Hi Benjamin, > >>> http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html >>> [...] >>> 1.) I was unable to find in SVN where this file lives, any pointers? >> >> http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/getting-started/maven-in-five-minutes.apt > > Ah thanks, I'd checked out the maven-components, didn't think to check > site . > >>> 2.) I was unable to assign the JIRA to myself, I assume there are >>> some restrictions in place there? >> >> Right, JIRAs are assigned by committers. But this doesn't prevent you from >> attaching patches to the JIRA, so happy patching ;-) > > Cool, will do! Whats the JIRA ticket number? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Gathering Artifact repository discovery requirements
Bump. On Sun, May 10, 2009 at 9:12 PM, Brian Fox wrote: > It's time to start looking at the problems with the current 2.x resolution > scheme as it specifically relates to repository declaration and discovery. > I've created the start of a document at [1]. This should be the place to > gather feedback and use cases that will help drive towards a more complete > benefit and drawback list as well as a list of requirements for a final > solution. Please leave comments on the page with things that should be added > or changed. > Please note, at this point I think it's better to stay away from specific > proposals on implementation details. This tends to pollute peoples thoughts > on the current problems and requirements, so lets stick to just improving > the first 4 sections of the page. > > [1] > http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery >
Re: 5 minute guide - Incorrect documentation/documentation improvement?
Hi Benjamin, >> http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html >> [...] >> 1.) I was unable to find in SVN where this file lives, any pointers? > > http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/getting-started/maven-in-five-minutes.apt Ah thanks, I'd checked out the maven-components, didn't think to check site . >> 2.) I was unable to assign the JIRA to myself, I assume there are >> some restrictions in place there? > > Right, JIRAs are assigned by committers. But this doesn't prevent you from > attaching patches to the JIRA, so happy patching ;-) Cool, will do! Thanks again, Martijn - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 5 minute guide - Incorrect documentation/documentation improvement?
Martijn Verburg wrote: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html [...] 1.) I was unable to find in SVN where this file lives, any pointers? http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/getting-started/maven-in-five-minutes.apt 2.) I was unable to assign the JIRA to myself, I assume there are some restrictions in place there? Right, JIRAs are assigned by committers. But this doesn't prevent you from attaching patches to the JIRA, so happy patching ;-) Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 5 minute guide - Incorrect documentation/documentation improvement?
Hi all, Hopefully this isn't too much of a stupid question :). I'm attempting to make a documentation patch for the document located at: http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html I've created the JIRA etc, but I have a couple of questions: 1.) I was unable to find in SVN where this file lives, any pointers? 2.) I was unable to assign the JIRA to myself, I assume there are some restrictions in place there? Cheers, Martijn - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Java 5 and Maven Plugins
+1 for [B]. This is what I had to do for the Findbugs plugin since Findbugs relies on Java 5 since . We are still able to use it against Java 1.3 or 1.4 generated code. Regards, Garvin LeClaire garvin.lecla...@gmail.com Dennis Lundberg wrote: Hi Recent discussions about the Checkstyle Plugin has raised the question of requiring Java 5 in Maven Plugins. We will IIUC require Java 5 for Maven 2.2. So when do we start using it in our plugins? [A] We start using it across the board for the next release of every plugin that wants to use Java 5 features or needs a dependency that requires Java 5. [B] The plugins can start using Java 5 features and/or dependencies. It is required that the current trunk of the plugin is released first, targeting Java 1.4. In the announcement for that last Java 1.4 version of the plugin, we inform the users that this is the last version that will be able to run on Java 1.4. [C] The plugins should not use Java 5 features. We can use retrotranslator, or something similar, to handle dependencies that require Java 5. [D] The plugins should not use Java 5 features. We will not update dependencies unless a "-java14" classified artifact is readily available from the developers of any dependencies. If you feel that there are other options we can take, please feel free to put them into the mix. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
On Sat, May 16, 2009 at 5:17 AM, Joerg Hohwiller wrote: >> Off topic. >> >> Actually I believe this isn't true anymore. >> >> See http://jira.codehaus.org/browse/MECLIPSE-344 [del] >> mvn eclipse:eclipse will make sure my module pA references the eclipse >> project for module cA (and not the jar of cA in the repo) > > Thanks for the hint! > But only works if eclipse-plugin knows where my workspace is. > The location may be different for each developer so I can NOT > truly automate. Anyhow I will start using this. > At least better solution than what I had before. With 2.6 (http://maven.apache.org/plugins/maven-eclipse-plugin-2.6/eclipse-mojo.html#workspace) if the workspace variable is not defined then m-e-p will walk up the directory hierarchy attempting to locate your workspace. As a general rule people checkout their projects underneath an eclipse workspace so it will find it automatically. Otherwise you will need to specify it manually. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
