Re: Preparation of Doxia 1.0-beta-1 release
Hi Paul, 2008/12/10 Paul Spencer [EMAIL PROTECTED]: Vincent, The project doxia-test-docs should contain the documents and the document should be maintained in the projects source repository so they can be release by the project, i.e. mvn release... The version of this project It is exactly what this new project does. Have a look inside the project, you could see several Doxia docs (i.e. [1] ) which will be maintained there. should change whenever the source documents change, i.e when you need to reload them from the svn copy, and their is a doxia release. The tests Maybe I confused you when I spoke of svn copy. To be more clear, all docs are initially copied from their own spaces (see [2]). The test code doesn't use SCM anymore. using doxia-test-docs may need to extract the documents from the doxia-test-doc artifact/jar, for which their are maven tools to do the unpacking. It is exactly what the tests do. See [2] Keep in mind, one of the reasons for Maven is enable any user at any time the ability to successfully rebuild the project. Sure and I think the build is now reproducible. Cheers, Vincent [1] https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-test-docs/src/main/resources/maven-ant-plugin/fml/ [2] http://svn.apache.org/viewvc?rev=725511view=rev [3] https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/xsd/AbstractXmlValidatorTest.java Paul Spencer On Dec 10, 2008, at 8:19 PM, Vincent Siveton wrote: Hi Benjamin and Paul, According your comments, I created a new module doxia-test-docs which includes svn copy on several documents. I also updated tests to fetch these changes. Any comments are welcome! Cheers, Vincent 2008/12/8 Benjamin Bentmann [EMAIL PROTECTED]: Vincent Siveton wrote: The tests are to perform XSD validations under our current documentation. Since we add new XSD files in this release, I think these tests are useful. No doubt, tests are useful but I feel we mix two different test targets here: a) correctness of the XSDs b) correctness of the currently available Maven documentation IMHO, only point a) should be a concern of Doxia, the rest is just outside world. The day we have a validating Doxia under the hood of the Site Plugin and it detects errors in our docs, we can simply fix them when be try to build the corresponding site, not when building Doxia. Instead of svn co, we could link to relative doc path, ie from doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site -1 on hard-coding inter-module or even worse inter-project paths. This introduces tight coupling where none should be. Imagine a contributor to Doxia who wants to try out patching it would end up checking out Maven plugins to test Doxia. Also, both svn co and the relative path to a local checkout make the idea of a reproducible build unreachable, as Paul already pointed out. To realize test target a), it is surely a nice idea to just grab samples of existing and presumable good docs and check whether the validator doesn't freak out. To do so, how about if we just collect all the doc files of interest from the Maven/plugin sites and copy them to a new Doxia module (doxia-test-docs or whatever). This module would mimic a svn co of a locked SVN revision and is also under Doxia control, i.e. one could also create artifical input documents to check more complex syntax structures that are currently not in use on the Maven sites. The other Doxia modules like XDoc etc. could depend on this test module and extract the input files from the test class path or from local file system after unpacking with the Dependency Plugin. Wouldn't that work? Benjamin
Re: Preparation of Doxia 1.0-beta-1 release
Vincent Siveton wrote: Any comments are welcome! Building the whole Doxia trunk takes only ~1 min for me, fine work IMHO Vincent :-) ! Benjamin
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
I'll look into it when I get back from vacation (Jan 2009). Right now it seems to be an issue with the fact that the shaded jar belongs to a project that doens't provide the source for the binaries contained. That's sort of a concept in netbeans project system, so making it work will probably involve some hacking.. Milos On Thu, Dec 11, 2008 at 4:41 AM, Lilianne E. Blaze [EMAIL PROTECTED] wrote: Hello, (I already tried on users- list) I'm trying to make a jar containing x dependencies to be used as a single dependency, using Shade with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to recognize it - code completion fails with package/class/symbol does not exist errors all over the place. Now I'm pretty much stuck. It could be a problem with Maven, could be with Netbeans, could be my (complete or partial) mistake with understanding how Maven makes / handles Shaded jars. I already submitted a report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a simple project (3 projects, 2 classes) to demonstrate it. Greetings, thanks in advance, Lilianne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
Milos Kleint wrote: I'll look into it when I get back from vacation (Jan 2009). Right now it seems to be an issue with the fact that the shaded jar belongs to a project that doens't provide the source for the binaries contained. That's sort of a concept in netbeans project system, so making it work will probably involve some hacking.. Milos I think that shouldn't matter? 1) Netbeans works correctly with 3rd party libs with no sources provided, and by default does not retrieve sources 2) createSourcesJartrue/createSourcesJar creates such jar, and from what I looked inside it, it looks just like a normal sources jar. Greetings, L On Thu, Dec 11, 2008 at 4:41 AM, Lilianne E. Blaze [EMAIL PROTECTED] wrote: Hello, (I already tried on users- list) I'm trying to make a jar containing x dependencies to be used as a single dependency, using Shade with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to recognize it - code completion fails with package/class/symbol does not exist errors all over the place. Now I'm pretty much stuck. It could be a problem with Maven, could be with Netbeans, could be my (complete or partial) mistake with understanding how Maven makes / handles Shaded jars. I already submitted a report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a simple project (3 projects, 2 classes) to demonstrate it. Greetings, thanks in advance, Lilianne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
if the project in question is opened (or otherwise known), all queries are redirected to it. That way you get the correct error badges in project B when you change classses in project A.. Milos On Thu, Dec 11, 2008 at 9:30 AM, Lilianne E. Blaze [EMAIL PROTECTED] wrote: Milos Kleint wrote: I'll look into it when I get back from vacation (Jan 2009). Right now it seems to be an issue with the fact that the shaded jar belongs to a project that doens't provide the source for the binaries contained. That's sort of a concept in netbeans project system, so making it work will probably involve some hacking.. Milos I think that shouldn't matter? 1) Netbeans works correctly with 3rd party libs with no sources provided, and by default does not retrieve sources 2) createSourcesJartrue/createSourcesJar creates such jar, and from what I looked inside it, it looks just like a normal sources jar. Greetings, L On Thu, Dec 11, 2008 at 4:41 AM, Lilianne E. Blaze [EMAIL PROTECTED] wrote: Hello, (I already tried on users- list) I'm trying to make a jar containing x dependencies to be used as a single dependency, using Shade with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to recognize it - code completion fails with package/class/symbol does not exist errors all over the place. Now I'm pretty much stuck. It could be a problem with Maven, could be with Netbeans, could be my (complete or partial) mistake with understanding how Maven makes / handles Shaded jars. I already submitted a report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a simple project (3 projects, 2 classes) to demonstrate it. Greetings, thanks in advance, Lilianne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SHA1 Checksum of org.apache.portals.bridges:portals-bridges-commons:1.0.4 are wrong
Nick, I meant that you should send this to the portal team so that they can correct: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/portals/bridges/portals-bridges-common/1.0.4/ BTW, you should check if Artifactory has an option to fix checksums on the fly for you, it might help (I know the other repo managers can do this, so Artifactory probably can too). - Brett On 11/12/2008, at 11:18 PM, Nick Stolwijk wrote: It seems that the SHA1 checksums of org.apache.portals.bridges:portals-bridges-commons:1.0.4 [1] are wrong on Central. Can this be repaired? Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '7c9e919c352f347a001885f7eb0da8df28790a65'; remote = 'fa61e182aa95c29c5f8a36223f95b15754156887' - RETRYING Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom 2K downloaded Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar 20K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'c7ee4640a35fc158cf8c4a645b8e3e21ca3b52ff'; remote = '2a74d0df0f3e4dac5f2992373a0a33d4b9fc2d92' - RETRYING Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar 20K downloaded With regards, [1] http://repo1.maven.org/maven2/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SHA1 Checksum of org.apache.portals.bridges:portals-bridges-commons:1.0.4 are wrong
It seems that the SHA1 checksums of org.apache.portals.bridges:portals-bridges-commons:1.0.4 [1] are wrong on Central. Can this be repaired? Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '7c9e919c352f347a001885f7eb0da8df28790a65'; remote = 'fa61e182aa95c29c5f8a36223f95b15754156887' - RETRYING Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom 2K downloaded Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar 20K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'c7ee4640a35fc158cf8c4a645b8e3e21ca3b52ff'; remote = '2a74d0df0f3e4dac5f2992373a0a33d4b9fc2d92' - RETRYING Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar 20K downloaded With regards, [1] http://repo1.maven.org/maven2/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r725604 - in /maven/mercury/trunk/mercury-md/mercury-md-sat/src: main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java test/java/org/apache/maven/mercury/metadata/sat/D
Hi,
2008/12/11 [EMAIL PROTECTED]:
Author: ogusakov
Date: Wed Dec 10 23:23:19 2008
New Revision: 725604
URL: http://svn.apache.org/viewvc?rev=725604view=rev
Log:
Thanks to Ben - fixed MERCURY-40
Not a big deal but could you follow our conventions about commit message [1]?
Thanks
Vincent
[1] http://maven.apache.org/developers/conventions/svn.html
Modified:
maven/mercury/trunk/mercury-md/mercury-md-sat/src/main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java
maven/mercury/trunk/mercury-md/mercury-md-sat/src/test/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolverTest.java
Modified:
maven/mercury/trunk/mercury-md/mercury-md-sat/src/main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java
URL:
http://svn.apache.org/viewvc/maven/mercury/trunk/mercury-md/mercury-md-sat/src/main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java?rev=725604r1=725603r2=725604view=diff
==
---
maven/mercury/trunk/mercury-md/mercury-md-sat/src/main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java
(original)
+++
maven/mercury/trunk/mercury-md/mercury-md-sat/src/main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java
Wed Dec 10 23:23:19 2008
@@ -24,6 +24,7 @@
import java.util.Collections;
import java.util.Comparator;
import java.util.HashMap;
+import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
@@ -143,7 +144,8 @@
throw new SatException( cannot apply policies to a null tree );
// TODO og: assumption - around 128 GA's per tree. If more - map
reallocates - slow down.
-MapString, ListMetadataTreeNode buckets = new HashMapString,
ListMetadataTreeNode(128);
+// TODO og: MERCURY-40
+MapString, ListMetadataTreeNode buckets = new LinkedHashMapString,
ListMetadataTreeNode(128);
fillBuckets( buckets, _root );
sortBuckets( buckets, comparators );
useBuckets( buckets );
@@ -419,7 +421,8 @@
if( children == null || children.size() 1 )
throw new SatException(there are queries, but not results. Queries:
+queries);
-MapArtifactBasicMetadata, ListMetadataTreeNode res = new
HashMapArtifactBasicMetadata, ListMetadataTreeNode( queries.size() );
+// TODO og: MERCURY-40
+MapArtifactBasicMetadata, ListMetadataTreeNode res = new
LinkedHashMapArtifactBasicMetadata, ListMetadataTreeNode( queries.size()
);
for( ArtifactBasicMetadata q : queries )
{
ListMetadataTreeNode bucket = new ArrayListMetadataTreeNode(4);
Modified:
maven/mercury/trunk/mercury-md/mercury-md-sat/src/test/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolverTest.java
URL:
http://svn.apache.org/viewvc/maven/mercury/trunk/mercury-md/mercury-md-sat/src/test/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolverTest.java?rev=725604r1=725603r2=725604view=diff
==
---
maven/mercury/trunk/mercury-md/mercury-md-sat/src/test/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolverTest.java
(original)
+++
maven/mercury/trunk/mercury-md/mercury-md-sat/src/test/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolverTest.java
Wed Dec 10 23:23:19 2008
@@ -342,8 +342,8 @@
assertEquals( 3, res.size() );
assertTrue( res.contains( a1 ) );
-assertTrue( res.contains( b2 ) );
-assertTrue( res.contains( c1 ) );
+assertTrue( res.contains( b1 ) );
+assertTrue( res.contains( c2 ) );
}
//--
// b:b:1 - c:c:[2,4)
@@ -419,8 +419,8 @@
assertEquals( 3, res.size() );
assertTrue( res.contains( a1 ) );
-assertTrue( res.contains( b2 ) );
-assertTrue( res.contains( c1 ) );
+assertTrue( res.contains( b1 ) );
+assertTrue( res.contains( c2 ) );
}
//--
// d:d:1 - c:c:[2,4)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM multi-level dependency resolution)
Hello, As a followup on my original mail, I also started debugging the Maven internals. I came to the conclusion that properties defined in profiles, are not injected into the Maven model of transitive dependencies, just before the interpolation is executed. Attached you can find 2 POM files that I use with Maven 2.0.9. The file a-pom.xml contains the base project depending on junit 3.8.1. In b-pom.xml, I depend on project 'a', but I want to redefine the version of junit to 3.8.2. If I override the value in the properties section, everything is OK, but if I redefine it via a profile, it is not picked up. Install project a in your local repository, and then run mvn dependency:resolve on project b. Although I redefined the junit version to 3.8.2, this is my output: [INFO] The following files have been resolved: [INFO]be.atriso.test:a:pom:1.0-SNAPSHOT:compile [INFO]junit:junit:jar:3.8.1:compile Is this a bug, or is this intended behaviour? If this is a bug, I found the reason why it fails. In the Maven 2.0.9 codebase, there are 2 callers to DefaultMavenProjectBuilder.buildInternal(...). The first, DefaultMavenProjectBuilder.buildFromSourceFileInternal(...), is used when the POM of the current project is processed. The second is DefaultMavenProjectBuilder.buildFromRepository(...) and is used when resolving the transitive dependencies during the Mojo execution. The first caller is used when Maven is bootstrapping. When we enter buildInternal(...) via this path, the config object passed in here contains a reference to the profileManager. When we enter buildInternal(...) via the second path (buildFromRepository(...) ), the config object does not have a reference to the profileManager and no profiles will be injected into the model before the interpolation is executed. Any comments? Ringo -Original Message- From: De Smet Ringo Sent: woensdag 10 december 2008 12:49 To: dev@maven.apache.org Subject: Version property in root POM multi-level dependency resolution Hello, [Repost from users list, hoping to get more in-depth answer here] I am busy creating an easy Maven2 setup for a 200+ module system, both targeted to an easier release and an easier development setup. It is a multi-level system, with common modules, service modules and presentation (web-ui) modules. I will use a simplification of this setup in this mail: pres.d - srv.a - common I also created a 'root' pom containing common build instructions and a property ver-release[9.10,9.11)/ver-release. The root POM is released as version 9.10.0. All other modules refer to this versioned root POM as their parent POM. All modules in a release 9.10 (current release) have 9.10-SNAPSHOT as their version. When I create a release, I use the properties releaseVersion and developmentVersion to make builds numbered 9.10.0, 9.10.1, ... and then fallback to 9.10-SNAPSHOT during development. The dependencies on other internal modules are specified using the ver-release property. This means that every module depends on the latest released version of its dependencies, e.g.: pres.d:9.10-SNAPSHOT - srv.a:9.10.3 srv.a:9.10-SNAPSHOT - common:9.10.2 Making releases of modules gives me a complete versioned hierarchy since I create a module release containing a release-pom.xml with all the version ranges resolved to actual version. So far so good if you look at it from a release viewpoint. The problem arises trying to get my development setup in place. Developers usually have to change code spanning multiple modules in multiple layers. Let's assume that, to implement a certain feature, a developer needs to change pres.d, srv.a and common. In such a setup, I would like pres.d:9.10-SNAPSHOT to depend on srv.a:9.10-SNAPSHOT, and srv.a:9.10-SNAPSHOT to depend on common:9.10-SNAPSHOT. Well, since the indicated version is defined as aproperty, I created an active profile in my settings.xml and redeclared the ver-release property in there. Now comes the point where I think Maven is failing. Here is the output of mvn dependency:resolve of pres.d: [INFO] The following files have been resolved: [INFO] be.telenet.test:common:jar:9.10.4:compile [INFO] be.telenet.test:srv.a:jar:9.10-SNAPSHOT:compile The dependency resolution correctly resolved the dependency from pres.d on srv.a to 9.10-SNAPSHOT, but it seems to ignore my overridden property and resolved the dependency from srv.a on common to the latest resolved version. All deployed SNAPSHOT versions of the POMs contain the version property, so I would expect this property to resolve to my overridden value for the complete dependency chain. Where in the code are properties resolved to actual values when building Artifact objects? Any other comments? Ringo * Dit e-mail bericht inclusief eventuele ingesloten bestanden
Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM multi-level dependency resolution)
On 11/12/2008, at 11:54 PM, De Smet Ringo wrote: [INFO] The following files have been resolved: [INFO]be.atriso.test:a:pom:1.0-SNAPSHOT:compile [INFO]junit:junit:jar:3.8.1:compile Is this a bug, or is this intended behaviour? It looks like the intended behaviour to me, the same as if you pulled the properties out of the profile. Properties are not transitively applied. To get what you want, you should be adding a dependency management element on junit in b-pom.xml. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SHA1 Checksum of org.apache.portals.bridges:portals-bridges-commons:1.0.4 are wrong
I hadn't read your replay before I sent the mail to the maven dev list. I will take it up with the portal developers. Thanks, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Thu, Dec 11, 2008 at 1:23 PM, Brett Porter [EMAIL PROTECTED] wrote: Nick, I meant that you should send this to the portal team so that they can correct: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/portals/bridges/portals-bridges-common/1.0.4/ BTW, you should check if Artifactory has an option to fix checksums on the fly for you, it might help (I know the other repo managers can do this, so Artifactory probably can too). - Brett On 11/12/2008, at 11:18 PM, Nick Stolwijk wrote: It seems that the SHA1 checksums of org.apache.portals.bridges:portals-bridges-commons:1.0.4 [1] are wrong on Central. Can this be repaired? Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '7c9e919c352f347a001885f7eb0da8df28790a65'; remote = 'fa61e182aa95c29c5f8a36223f95b15754156887' - RETRYING Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.pom 2K downloaded Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar 20K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'c7ee4640a35fc158cf8c4a645b8e3e21ca3b52ff'; remote = '2a74d0df0f3e4dac5f2992373a0a33d4b9fc2d92' - RETRYING Downloading: http://projectserver/artifactory/repo/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar 20K downloaded With regards, [1] http://repo1.maven.org/maven2/org/apache/portals/bridges/portals-bridges-common/1.0.4/portals-bridges-common-1.0.4.jar Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM multi-level dependency resolution)
Brett, -Original Message- From: Brett Porter It looks like the intended behaviour to me, the same as if you pulled the properties out of the profile. Properties are not transitively applied. Can you give me some more background on the why of this decision. If you re-read my original mail, I want to override the single version property that is used between the modules of our internal setup from wihtin a profile in the settings.xml. The value is overridden for the project under build, but not for the transitive dependencies. Are you surprised that I find this an inconsistent result? :-) The version in the checkedin POM files is a version range, but for a developer setup, I want to override this version to the current SNAPSHOT version without any changes to the POMs themselves. If a developer needs to make code changes over multiple modules, I want every of his checked-out modules to depend on the SNAPSHOT version of its dependencies. To get what you want, you should be adding a dependency management element on junit in b-pom.xml. I added the following to my pom.xml of project b: dependencyManagement dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.2/version typepom/type /dependency /dependencies /dependencyManagement However, mvn dependency:resolve still points to junit 3.8.1: [INFO] The following files have been resolved: [INFO]be.atriso.test:a:pom:1.0-SNAPSHOT:compile [INFO]junit:junit:jar:3.8.1:compile Was this what you suggested or did I misinterpret your suggestion? Ringo * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu. * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Maven Wiki] Update of Chinese Maven In Five Minutes by Iacob
Dear Wiki user, You have subscribed to a wiki page or wiki category on Maven Wiki for change notification. The following page has been changed by Iacob: http://wiki.apache.org/maven/Chinese_Maven_In_Five_Minutes New page: Mavenäºåéå ¥é¨ å®è£ Mavenæ¯ä¸æ¬¾Javaå·¥å ·ï¼å¦æè¦è¿è¡ä¸é¢çæ¥éª¤å¿ é¡»å®è£ Javaã é¦å ä¸è½½Maven并ä¸æç §æ¥éª¤å°å ¶å®è£ ï¼ç¶å¾ï¼å¨ç»ç«¯æå½ä»¤æ示符ä¸è¾å ¥ï¼ mvn --version å®ä¼æå°åºæå®è£ çMavenççæ¬ï¼ä¾å¦ï¼ Maven version: 2.0.8 Java version: 1.5.0_12 OS name: windows 2003 version: 5.2 arch: x86 Family: windows æ ¹æ®ç½ç»è®¾ç½®æ许ä¼éè¦ä¸äºå ¶ä»ç设置ãå¦éè¦çè¯è¯·åç Mavené ç½®æåã 建ç«ä¸ä¸ªå·¥ç¨ å¨å½ä»¤è¡ä¸ï¼è¿è¡å¦ä¸çMavenç®æ ï¼Goalï¼ï¼ mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app å¦æMavenæ¯å ¨æ°å®è£ çï¼ç¬¬ä¸æ¬¡è¿è¡æ¶ä¼è±è´¹ä¸äºæ¶é´ï¼å 为Mavenä¼ä¸è½½ææ°çå¥ä»¶ï¼æ件å åå ¶ä»æ件ï¼å°æ¬å°ï¼ä¹æå¯è½è¿è¡å 次å½ä»¤æè½æåï¼å 为è¿ç¨æå¡å¨ä¼å¨ä¸è½½å®æ¯åè¶ æ¶ãä¸è¿ï¼æ许å¤æ¹æ³æ¥è§£å³è¿ä¸ªé®é¢ã ä½ å¯è½æ³¨æå°createç®æ ï¼Goalï¼å建äºä¸ä¸ªä¸å¥ä»¶åï¼artifactIdï¼ååçç®å½ï¼ç°å¨åå ¥è¿ä¸ªç®å½ã cd my-app å¨è¿ä¸ªç®å½ä¸ä¼çå°ä¸ä¸ª æ åå·¥ç¨ç»æ my-app |-- pom.xml `-- src |-- main | `-- java | `-- com | `-- mycompany | `-- app | `-- App.java `-- test `-- java `-- com `-- mycompany `-- app `-- AppTest.java src/main/javaç®å½ä¸å å«å·¥ç¨çæºä»£ç ï¼src/test/javaç®å½ä¸å å«æµè¯ä»£ç ï¼pom.xmlæ¯é¡¹ç®ç项ç®å¯¹è±¡æ¨¡åï¼Project Object Modelï¼ï¼æç®ç§°POMã 项ç®å¯¹è±¡æ¨¡åï¼POMï¼ pom.xmlæ¯Mavenå·¥ç¨çæ ¸å¿é ç½®ï¼è¿ä¸ªæ件å å«äºæç §éè¦å»ºç«ï¼buildï¼å·¥ç¨æ¶éè¦ç大é¨åä¿¡æ¯ï¼POMæ件é常åºå¤§ä½å¯ä»¥ç®åï¼.. project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.mycompany.app/groupId artifactIdmy-app/artifactId packagingjar/packaging version1.0-SNAPSHOT/version nameMaven Quick Start Archetype/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies /project ä¸é¢æ¥éª¤åäºä»ä¹ï¼ ååæ§è¡äºMavençç®æ ï¼Goalï¼archetype:create, èä¸åè¿ä¸ªç®æ ä¼ éäºä¸äºåæ°ãåç¼``archetype''æ¯å å«æ¤ç®æ çæ件çå称ãå¦æ对Antçæï¼ä½ å¯ä»¥è®¤ä¸ºå®åAntä¸çä»»å¡ï¼taskï¼ç¸ä¼¼ãè¿ä¸ªç®æ å建äºåºäºè¿ä¸ªarchetypeçä¸ä¸ªæ®éçå·¥ç¨ã...ãä¾å¦jboss-maven-pluginçä½ç¨æ¯``å¤çä¸äºjbossçäºå¡''ã ç¼è¯è¿ä¸ªå·¥ç¨ mvn package å½ä»¤è¡ä¼æå°åºè®¸å¤å¨ä½ï¼ç»å°¾é¨åå¦ä¸ï¼ ... [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Oct 05 21:16:04 CDT 2006 [INFO] Final Memory: 3M/6M [INFO] åæ§è¡ç第ä¸ä¸ªå½ä»¤ï¼archetype:createï¼ä¸åï¼ä½ å¯è½æ³¨æå°ç¬¬äºä¸ªå½ä»¤åªå å«ä¸ä¸ªåè¯ ï¼ï¼ packageãä¸ç®æ ï¼Goalï¼ä¸åï¼è¿æ¯ä¸ä¸ª``é¶æ®µ''ï¼phaseï¼ãé¶æ®µæ¯å»ºç«è¿ç¨ççå½å¨æä¸çä¸ä¸ªæ¥éª¤ï¼å»ºç«è¿ç¨å å«ä¸ç³»åçæ¥éª¤ãå½ç»åºä¸ä¸ªé¶æ®µæ¶ï¼Mavenä¼é¡ºåºæ§è¡æ¯ä¸ªé¶æ®µç´å°å°è¾¾ç»åºçé£ä¸ªãä¾å¦ï¼å¦ææ们æ§è¡ç¼è¯ï¼compileï¼é¶æ®µï¼å®é 被æ§è¡çé¶æ®µæ¯ï¼ 1. validate 2. generate-sources 3. process-sources 4. generate-resources 5. process-resources 6. compile å¯ä»¥ä½¿ç¨ä¸é¢çå½ä»¤æµè¯ååç¼è¯å¹¶ä¸æå çJARæä»¶ï¼ java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App å®ä¼ç«å³ç»åºï¼ Hello World! è¿è¡Mavenå·¥å · Mavenå å«çå个é¶æ®µ å ¨é¨é¡¹ç®çå表ä¼å¾é¿ï¼è¿éååºçæ¯éè¦æ§è¡çæ常è§çé»è®¤çå½å¨æã * validate: æ£éªå·¥ç¨æ¯å¦æ£ç¡®ï¼æ¯å¦ç»åºäºææå¿ è¦çä¿¡æ¯ã * compile: ç¼è¯å·¥ç¨çæºä»£ç * test: 使ç¨åéçåå æµè¯æ¡æ¶æµè¯ç¼è¯è¿çæºä»£ç ãæ¤å¤çæµè¯æ¥éª¤ä¸éå°ç¼è¯å¾å°çåèç æå åé¨ç½²ã * package: å°ç¼è¯å¾å°çåèç æå æå¯ä»¥ç¨æ¥å°å ¶åå¸ï¼distributeï¼çæ ¼å¼ï¼æ¯å¦JARã * integration-test: å¦æéè¦å°è¿ä¸ªå æ¾å°ç¹å®ç¯å¢ä¸è¿è¡éææµè¯åå¤ç并é¨ç½²æ¤å ã * verify:
[Maven Wiki] Update of Chinese Maven In Five Minutes by Iacob
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Maven Wiki for change
notification.
The following page has been changed by Iacob:
http://wiki.apache.org/maven/Chinese_Maven_In_Five_Minutes
--
-
Mavenäºåéå
¥é¨
å®è£
@@ -9, +8 @@
é¦å
ä¸è½½Maven并ä¸æç
§æ¥éª¤å°å
¶å®è£
ï¼ç¶å¾ï¼å¨ç»ç«¯æå½ä»¤æ示符ä¸è¾å
¥ï¼
+ {{{
+
mvn --version
+ }}}
+
å®ä¼æå°åºæå®è£
çMavenççæ¬ï¼ä¾å¦ï¼
+
+ {{{
Maven version: 2.0.8
Java version: 1.5.0_12
OS name: windows 2003 version: 5.2 arch: x86 Family: windows
+
+ }}}
æ ¹æ®ç½ç»è®¾ç½®æ许ä¼éè¦ä¸äºå
¶ä»ç设置ãå¦éè¦çè¯è¯·åç
Mavené
ç½®æåã
@@ -23, +30 @@
å¨å½ä»¤è¡ä¸ï¼è¿è¡å¦ä¸çMavenç®æ ï¼Goalï¼ï¼
+ {{{
+
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app
+
+ }}}
å¦æMavenæ¯å
¨æ°å®è£
çï¼ç¬¬ä¸æ¬¡è¿è¡æ¶ä¼è±è´¹ä¸äºæ¶é´ï¼å 为Mavenä¼ä¸è½½ææ°çå¥ä»¶ï¼æ件å
åå
¶ä»æ件ï¼å°æ¬å°ï¼ä¹æå¯è½è¿è¡å 次å½ä»¤æè½æåï¼å 为è¿ç¨æå¡å¨ä¼å¨ä¸è½½å®æ¯åè¶
æ¶ãä¸è¿ï¼æ许å¤æ¹æ³æ¥è§£å³è¿ä¸ªé®é¢ã
@@ -32, +43 @@
cd my-app
å¨è¿ä¸ªç®å½ä¸ä¼çå°ä¸ä¸ª æ åå·¥ç¨ç»æ
+
+ {{{
my-app
|-- pom.xml
@@ -49, +62 @@
`-- app
`-- AppTest.java
+ }}}
+
src/main/javaç®å½ä¸å
å«å·¥ç¨çæºä»£ç ï¼src/test/javaç®å½ä¸å
å«æµè¯ä»£ç ï¼pom.xmlæ¯é¡¹ç®ç项ç®å¯¹è±¡æ¨¡åï¼Project
Object Modelï¼ï¼æç®ç§°POMã
项ç®å¯¹è±¡æ¨¡åï¼POMï¼
pom.xmlæ¯Mavenå·¥ç¨çæ ¸å¿é
ç½®ï¼è¿ä¸ªæ件å
å«äºæç
§éè¦å»ºç«ï¼buildï¼å·¥ç¨æ¶éè¦ç大é¨åä¿¡æ¯ï¼POMæ件é常åºå¤§ä½å¯ä»¥ç®åï¼..
+
+ {{{
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
@@ -74, +91 @@
/dependencies
/project
+ }}}
+
ä¸é¢æ¥éª¤åäºä»ä¹ï¼
ååæ§è¡äºMavençç®æ ï¼Goalï¼archetype:create,
èä¸åè¿ä¸ªç®æ ä¼ éäºä¸äºåæ°ãåç¼``archetype''æ¯å
å«æ¤ç®æ çæ件çå称ãå¦æ对Antçæï¼ä½ å¯ä»¥è®¤ä¸ºå®åAntä¸çä»»å¡ï¼taskï¼ç¸ä¼¼ãè¿ä¸ªç®æ å建äºåºäºè¿ä¸ªarchetypeçä¸ä¸ªæ®éçå·¥ç¨ã...ãä¾å¦jboss-maven-pluginçä½ç¨æ¯``å¤çä¸äºjbossçäºå¡''ã
@@ -84, +103 @@
å½ä»¤è¡ä¼æå°åºè®¸å¤å¨ä½ï¼ç»å°¾é¨åå¦ä¸ï¼
+ {{{
+
...
[INFO]
[INFO] BUILD SUCCESSFUL
@@ -92, +113 @@
[INFO] Finished at: Thu Oct 05 21:16:04 CDT 2006
[INFO] Final Memory: 3M/6M
[INFO]
+
+ }}}
åæ§è¡ç第ä¸ä¸ªå½ä»¤ï¼archetype:createï¼ä¸åï¼ä½ å¯è½æ³¨æå°ç¬¬äºä¸ªå½ä»¤åªå
å«ä¸ä¸ªåè¯
ï¼ï¼
packageãä¸ç®æ ï¼Goalï¼ä¸åï¼è¿æ¯ä¸ä¸ª``é¶æ®µ''ï¼phaseï¼ãé¶æ®µæ¯å»ºç«è¿ç¨ççå½å¨æä¸çä¸ä¸ªæ¥éª¤ï¼å»ºç«è¿ç¨å
å«ä¸ç³»åçæ¥éª¤ãå½ç»åºä¸ä¸ªé¶æ®µæ¶ï¼Mavenä¼é¡ºåºæ§è¡æ¯ä¸ªé¶æ®µç´å°å°è¾¾ç»åºçé£ä¸ªãä¾å¦ï¼å¦ææ们æ§è¡ç¼è¯ï¼compileï¼é¶æ®µï¼å®é
被æ§è¡çé¶æ®µæ¯ï¼
@@ -135, +158 @@
è®°ä½æ趣çä¸ç¹æ¯é¶æ®µåç®æ ä¼å¯ä»¥é¡ºåºæ§è¡ã
+ {{{
+
mvn clean dependency:copy-dependencies package
+
+ }}}
è¿ä¸ªå½ä»¤ä¼æ¸
çå·¥ç¨ï¼æ·è´ä¾èµçå
容ï¼å¹¶ä¸ç»è¿ä¸ªå·¥ç¨æå
ï¼ä¼æ§è¡ææçé¶æ®µç´å°å°è¾¾packageé¶æ®µï¼ã
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Maven Wiki] Update of Chinese Maven In Five Minutes by Iacob
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Maven Wiki for change
notification.
The following page has been changed by Iacob:
http://wiki.apache.org/maven/Chinese_Maven_In_Five_Minutes
--
- Mavenäºåéå
¥é¨
+ deleted
- å®è£
-
- Mavenæ¯ä¸æ¬¾Javaå·¥å
·ï¼å¦æè¦è¿è¡ä¸é¢çæ¥éª¤å¿
é¡»å®è£
Javaã
-
-
é¦å
ä¸è½½Maven并ä¸æç
§æ¥éª¤å°å
¶å®è£
ï¼ç¶å¾ï¼å¨ç»ç«¯æå½ä»¤æ示符ä¸è¾å
¥ï¼
-
- {{{
-
- mvn --version
-
- }}}
-
- å®ä¼æå°åºæå®è£
çMavenççæ¬ï¼ä¾å¦ï¼
-
- {{{
-
- Maven version: 2.0.8
- Java version: 1.5.0_12
- OS name: windows 2003 version: 5.2 arch: x86 Family: windows
-
- }}}
-
-
æ ¹æ®ç½ç»è®¾ç½®æ许ä¼éè¦ä¸äºå
¶ä»ç设置ãå¦éè¦çè¯è¯·åç
Mavené
ç½®æåã
-
- 建ç«ä¸ä¸ªå·¥ç¨
-
- å¨å½ä»¤è¡ä¸ï¼è¿è¡å¦ä¸çMavenç®æ ï¼Goalï¼ï¼
-
- {{{
-
- mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app
-
- }}}
-
-
å¦æMavenæ¯å
¨æ°å®è£
çï¼ç¬¬ä¸æ¬¡è¿è¡æ¶ä¼è±è´¹ä¸äºæ¶é´ï¼å 为Mavenä¼ä¸è½½ææ°çå¥ä»¶ï¼æ件å
åå
¶ä»æ件ï¼å°æ¬å°ï¼ä¹æå¯è½è¿è¡å 次å½ä»¤æè½æåï¼å 为è¿ç¨æå¡å¨ä¼å¨ä¸è½½å®æ¯åè¶
æ¶ãä¸è¿ï¼æ许å¤æ¹æ³æ¥è§£å³è¿ä¸ªé®é¢ã
-
-
ä½ å¯è½æ³¨æå°createç®æ ï¼Goalï¼å建äºä¸ä¸ªä¸å¥ä»¶åï¼artifactIdï¼ååçç®å½ï¼ç°å¨åå
¥è¿ä¸ªç®å½ã
-
- cd my-app
-
- å¨è¿ä¸ªç®å½ä¸ä¼çå°ä¸ä¸ª æ åå·¥ç¨ç»æ
-
- {{{
-
- my-app
- |-- pom.xml
- `-- src
- |-- main
- | `-- java
- | `-- com
- | `-- mycompany
- | `-- app
- | `-- App.java
- `-- test
- `-- java
- `-- com
- `-- mycompany
- `-- app
- `-- AppTest.java
-
- }}}
-
-
src/main/javaç®å½ä¸å
å«å·¥ç¨çæºä»£ç ï¼src/test/javaç®å½ä¸å
å«æµè¯ä»£ç ï¼pom.xmlæ¯é¡¹ç®ç项ç®å¯¹è±¡æ¨¡åï¼Project
Object Modelï¼ï¼æç®ç§°POMã
-
- 项ç®å¯¹è±¡æ¨¡åï¼POMï¼
-
-
pom.xmlæ¯Mavenå·¥ç¨çæ ¸å¿é
ç½®ï¼è¿ä¸ªæ件å
å«äºæç
§éè¦å»ºç«ï¼buildï¼å·¥ç¨æ¶éè¦ç大é¨åä¿¡æ¯ï¼POMæ件é常åºå¤§ä½å¯ä»¥ç®åï¼..
-
- {{{
-
- project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
- xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
- modelVersion4.0.0/modelVersion
- groupIdcom.mycompany.app/groupId
- artifactIdmy-app/artifactId
- packagingjar/packaging
- version1.0-SNAPSHOT/version
- nameMaven Quick Start Archetype/name
- urlhttp://maven.apache.org/url
- dependencies
- dependency
- groupIdjunit/groupId
- artifactIdjunit/artifactId
- version3.8.1/version
- scopetest/scope
- /dependency
- /dependencies
- /project
-
- }}}
-
- ä¸é¢æ¥éª¤åäºä»ä¹ï¼
-
- ååæ§è¡äºMavençç®æ ï¼Goalï¼archetype:create,
èä¸åè¿ä¸ªç®æ ä¼ éäºä¸äºåæ°ãåç¼``archetype''æ¯å
å«æ¤ç®æ çæ件çå称ãå¦æ对Antçæï¼ä½ å¯ä»¥è®¤ä¸ºå®åAntä¸çä»»å¡ï¼taskï¼ç¸ä¼¼ãè¿ä¸ªç®æ å建äºåºäºè¿ä¸ªarchetypeçä¸ä¸ªæ®éçå·¥ç¨ã...ãä¾å¦jboss-maven-pluginçä½ç¨æ¯``å¤çä¸äºjbossçäºå¡''ã
-
- ç¼è¯è¿ä¸ªå·¥ç¨
-
- mvn package
-
- å½ä»¤è¡ä¼æå°åºè®¸å¤å¨ä½ï¼ç»å°¾é¨åå¦ä¸ï¼
-
- {{{
-
- ...
- [INFO]
- [INFO] BUILD SUCCESSFUL
- [INFO]
- [INFO] Total time: 2 seconds
- [INFO] Finished at: Thu Oct 05 21:16:04 CDT 2006
- [INFO] Final Memory: 3M/6M
- [INFO]
-
- }}}
-
-
åæ§è¡ç第ä¸ä¸ªå½ä»¤ï¼archetype:createï¼ä¸åï¼ä½ å¯è½æ³¨æå°ç¬¬äºä¸ªå½ä»¤åªå
å«ä¸ä¸ªåè¯
ï¼ï¼
packageãä¸ç®æ ï¼Goalï¼ä¸åï¼è¿æ¯ä¸ä¸ª``é¶æ®µ''ï¼phaseï¼ãé¶æ®µæ¯å»ºç«è¿ç¨ççå½å¨æä¸çä¸ä¸ªæ¥éª¤ï¼å»ºç«è¿ç¨å
å«ä¸ç³»åçæ¥éª¤ãå½ç»åºä¸ä¸ªé¶æ®µæ¶ï¼Mavenä¼é¡ºåºæ§è¡æ¯ä¸ªé¶æ®µç´å°å°è¾¾ç»åºçé£ä¸ªãä¾å¦ï¼å¦ææ们æ§è¡ç¼è¯ï¼compileï¼é¶æ®µï¼å®é
被æ§è¡çé¶æ®µæ¯ï¼
-
-1. validate
-2. generate-sources
-3. process-sources
-4. generate-resources
-5. process-resources
-6. compile
-
- å¯ä»¥ä½¿ç¨ä¸é¢çå½ä»¤æµè¯ååç¼è¯å¹¶ä¸æå
çJARæ件ï¼
-
- java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
-
- å®ä¼ç«å³ç»åºï¼
-
- Hello World!
-
- è¿è¡Mavenå·¥å
·
-
- Mavenå
å«çå个é¶æ®µ
-
-
å
¨é¨é¡¹ç®çå表ä¼å¾é¿ï¼è¿éååºçæ¯éè¦æ§è¡çæ常è§çé»è®¤çå½å¨æã
-
- * validate:
æ£éªå·¥ç¨æ¯å¦æ£ç¡®ï¼æ¯å¦ç»åºäºææå¿
è¦çä¿¡æ¯ã
- * compile:
Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM multi-level dependency resolution)
On 12/12/2008, at 12:39 AM, De Smet Ringo wrote: The value is overridden for the project under build, but not for the transitive dependencies. Are you surprised that I find this an inconsistent result? :-) Ok, I see what you mean. You illustrated the property in the project which should not work. But from settings.xml and the command line it should. To get what you want, you should be adding a dependency management element on junit in b-pom.xml. I added the following to my pom.xml of project b: dependencyManagement dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.2/version typepom/type /dependency /dependencies /dependencyManagement However, mvn dependency:resolve still points to junit 3.8.1: [INFO] The following files have been resolved: [INFO]be.atriso.test:a:pom:1.0-SNAPSHOT:compile [INFO]junit:junit:jar:3.8.1:compile Was this what you suggested or did I misinterpret your suggestion? try removing the type :) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
Could you try unzipping the shaded jar and then using jar cf to create a new jar using the same contents and seeing if that helps? At one point, shade wasn't sticking directory entries into the jar properly which worked fine for java and javac and such, but it confused winzip really badly. It's possible something else or a similar issue is causing an issue with netbeans. Alos, make sure it's the latest shade plugin as well to get the fix for above. Dan On Wednesday 10 December 2008 10:41:27 pm Lilianne E. Blaze wrote: Hello, (I already tried on users- list) I'm trying to make a jar containing x dependencies to be used as a single dependency, using Shade with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to recognize it - code completion fails with package/class/symbol does not exist errors all over the place. Now I'm pretty much stuck. It could be a problem with Maven, could be with Netbeans, could be my (complete or partial) mistake with understanding how Maven makes / handles Shaded jars. I already submitted a report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a simple project (3 projects, 2 classes) to demonstrate it. Greetings, thanks in advance, Lilianne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
baerrach wrote: See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. This is an interesting problem. I don't see any way to fix this other than changing Maven itself, unfortunately, but I think Arnaud's idea about the lifecycle is a good one. What about a generate lifecycle that just does all the generation phases (ie, the ones you've listed), and ends with a generate phase. Someone could bind eclipse/idea/whatever to that, and run mvn generate from the command line. We might need to hash out the details, but I think it's worth trying it to see if it works for your use case first to see if it is worthwhile pursuing further - you could do this on the maven-2.1.x branch and add it to the maven-core components.xml file. Cheers, Brett -- View this message in context: http://www.nabble.com/MECLIPSE-37-creating-a-new-custom-lifecycle-for-m-eclipse-p-tp20846234p20958158.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What will replace the @aggregator MOJO configuration?
On 07/12/2008, at 2:06 AM, Brian E. Fox wrote: Yes it's binding the aggregator with @execute to a lifecycle that is the problem. There's nothing wrong with aggregators that are meant to perform some action from the CLI. The trouble is that everyone ends up making two goals, one @aggregator and one xxx-only goal that is without the aggregator. I know of too many instances where someone bound an aggregator executor goal to a lifecycle and ended up with n*n-1 recursive builds or other crazy behavior. What I think we need is an annotation that says execute up to this phase only if it hasn't already run essentially a minimum phase execution. There also needs to be a way to attach a plugin to execute before the lifecycle to influence things like inject dependencies and we also need a way to bind to the very end of a build for cleanup or metric collection types of things. Agreed. How do we pursue these ideas? Wiki? Not sure how they fit in with the lifecycle refactoring of 3.0 or if there's a bunch of these we could get happening sooner. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM multi-level dependency resolution)
Brett, -Original Message- From: Brett Porter Ok, I see what you mean. You illustrated the property in the project which should not work. But from settings.xml and the command line it should. Unfortunately, it doesn't, or again I'm misinterpreting you. :-) The three attached files represent a simplification of our project setup, with c - b - a I removed all usage of profiles in this example, using command line properties as you suggested. * Project a does not have any dependencies, so I installed the snapshot version in my local repository via 'mvn install' * Project b has a dependency on project a, so I installed the snapshot version in my local repository via 'mvn -Dver-modules=1.0-SNAPSHOT install' to bypass the fact that I do not have any released version of project a, matching the specified range. * Project c has a dependency on project b, and transitively on a. By overriding the property ver-modules, used in the poms of b and c, I would like to get to the setup c:1.-SNAPSHOT - b:1.0-SNAPSHOT - a:1.0-SNAPSHOT and not c:1.-SNAPSHOT - b:1.0-SNAPSHOT - a:[1.0,1.1) I tried 'mvn -Dver-modules=1.0-SNAPSHOT dependency:resolve' for project c, but I get this as output: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [INFO] [INFO] Building Project C using B [INFO]task-segment: [dependency:resolve] [INFO] [INFO] snapshot be.atriso.test:b:1.0-SNAPSHOT: checking for updates from telenet.nexus-snapshots [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Couldn't find a version in [1.0-SNAPSHOT] to match range [1.0,1.1) be.atriso.test:a:pom:null from the specified remote repositories: central (http://repo1.maven.org/maven2), telenet.nexus-snapshots (internal URL), telenet.nexus (internal URL) If I patch my local repository to simulate a released version of a:1.0, then I get this as output: [INFO] The following files have been resolved: [INFO]be.atriso.test:a:pom:1.0:compile [INFO]be.atriso.test:b:pom:1.0-SNAPSHOT:compile Still not what I want... :-) As a concluding note, I want to highlight that I'm using a patched Maven 2.0.9 distribution in which bug MNG-3092 is fixed using the patch file attached to the JIRA issue. http://jira.codehaus.org/browse/MNG-3092 try removing the type :) Good catch! :-) Ringo * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu. * project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdbe.atriso.test/groupId artifactIda/artifactId packagingpom/packaging version1.0-SNAPSHOT/version nameProject A/name /project project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdbe.atriso.test/groupId artifactIdb/artifactId
Re: BUG? Profile properties not used to resolve dependencies transitively. (was RE: Version property in root POM multi-level dependency resolution)
On 12/12/2008, at 3:10 AM, De Smet Ringo wrote: Brett, -Original Message- From: Brett Porter Ok, I see what you mean. You illustrated the property in the project which should not work. But from settings.xml and the command line it should. Unfortunately, it doesn't, or again I'm misinterpreting you. :-) No it doesn't - it should. I think that's a bug. I don't generally encourage using a property from the command line or settings, but your use case sounds valid, and I think that's being used in the hudson builds Jason was referring to as well. It should behave consistently between the POMs. I don't have time to dig into your example again now, but does the use of dependency management to centralise it in the top POM solve this for you? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r725604 - in /maven/mercury/trunk/mercury-md/mercury-md-sat/src: main/java/org/apache/maven/mercury/metadata/sat/DefaultSatSolver.java test/java/org/apache/maven/mercury/metadata/sat/D
Vincent Siveton wrote: Hi, 2008/12/11 [EMAIL PROTECTED]: Author: ogusakov Date: Wed Dec 10 23:23:19 2008 New Revision: 725604 URL: http://svn.apache.org/viewvc?rev=725604view=rev Log: Thanks to Ben - fixed MERCURY-40 Not a big deal but could you follow our conventions about commit message [1]? My bad. Thanks for pointing to the document! Oleg Thanks Vincent [1] http://maven.apache.org/developers/conventions/svn.html
RE: What will replace the @aggregator MOJO configuration?
I think most of these ideas are already covered in the lifecycle proposal out there that john wrote. -Original Message- From: Brett Porter [mailto:br...@apache.org] Sent: Thursday, December 11, 2008 11:02 AM To: Maven Developers List Subject: Re: What will replace the @aggregator MOJO configuration? On 07/12/2008, at 2:06 AM, Brian E. Fox wrote: Yes it's binding the aggregator with @execute to a lifecycle that is the problem. There's nothing wrong with aggregators that are meant to perform some action from the CLI. The trouble is that everyone ends up making two goals, one @aggregator and one xxx-only goal that is without the aggregator. I know of too many instances where someone bound an aggregator executor goal to a lifecycle and ended up with n*n-1 recursive builds or other crazy behavior. What I think we need is an annotation that says execute up to this phase only if it hasn't already run essentially a minimum phase execution. There also needs to be a way to attach a plugin to execute before the lifecycle to influence things like inject dependencies and we also need a way to bind to the very end of a build for cleanup or metric collection types of things. Agreed. How do we pursue these ideas? Wiki? Not sure how they fit in with the lifecycle refactoring of 3.0 or if there's a bunch of these we could get happening sooner. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [2.0.10 RC] please test
Brian E. Fox schrieb: Hello, This RC fixes the SCP wagon problem identified in RC2 (MNG-3717). We have reverted the 2.0.x branch back to use wagon beta-2 where it was historically for stability. Users that require fixes for wagon beta-3+ should use 2.1.0-M1 instead. Here's the list of issues fixed in 2.0.10: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112styleName =HtmlprojectId=10500Create=Create And I've staged RC-5 here: http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa che-maven/2.0.10-RC5/ Please try it out and see if we have any remaining regressions over 2.0.9. Thanks, Brian Hello, will the plugin versions in the super pom be updated for 2.0.10 or will the defaults used in 2.0.9 be kept ? -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [2.0.10 RC] please test
will the plugin versions in the super pom be updated for 2.0.10 or will the defaults used in 2.0.9 be kept ? Thanks for bringing that up. I think we adjusted them when the original 2.0.10 started but it's been a while and we should re-eval before making the final build. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Extending the Pom
I'm encountering an issue with Byldan (.NET version of Maven) and since this is a general problem, I thought I'd raise it here on the list. I need to extend the pom model to include information like the key token id of the .NET assembly. Using the modelVersion element of the pom isn't appropriate to indicate these platform type extensions. The key here is to provide enough information in the pom to allow the build tool to choose the implementation of the ModelTransformer it needs. For example, if Maven sees Maven:4.0.0, then it chooses PomClassicTransformer to read the information into the canonical data format. If Maven sees dotnet:1.0.0, then Maven could use DotnetModelTransformer, and so on. Some ideas: 1) qualify modelVersion with platform: dotnet:1.0.0, maven:4.0.0 2) new platform tag 3) use of namespaces 4) Some unique id that maps to transformer I'm leaning toward (4) as it is more future proof to changes. Thoughts? Thanks, Shane
Re: Extending the Pom
On 11-Dec-08, at 6:48 PM, Shane Isbell wrote: I'm encountering an issue with Byldan (.NET version of Maven) and since this is a general problem, I thought I'd raise it here on the list. I need to extend the pom model to include information like the key token id of the .NET assembly. Using the modelVersion element of the pom isn't appropriate to indicate these platform type extensions. The key here is to provide enough information in the pom to allow the build tool to choose the implementation of the ModelTransformer it needs. For example, if Maven sees Maven:4.0.0, then it chooses PomClassicTransformer to read the information into the canonical data format. If Maven sees dotnet:1.0.0, then Maven could use DotnetModelTransformer, and so on. Some ideas: 1) qualify modelVersion with platform: dotnet:1.0.0, maven:4.0.0 2) new platform tag 3) use of namespaces 4) Some unique id that maps to transformer I'm leaning toward (4) as it is more future proof to changes. Thoughts? But you still probably want to account for different versions of the model. I think we also need to look at Bryon Jacob's proposal again about extensibility with validation. Thanks, Shane Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Extending the Pom
The idea here is not to do away with modelVersion, but rather to add an additional parameter, similar to modelGroupId. I found a post by Bryon here talking about the extensibility: http://freedomandbeer.com/posts/extensible-xml-with-xml-namespaces-and-relaxng If it is possible to grab out extensions of the pom and hand off the nodes to appropriate ModelTransformers, that would be useful, allowing chaining of ModelTransformers for processing. Shane On Thu, Dec 11, 2008 at 10:04 AM, Jason van Zyl jvan...@sonatype.comwrote: On 11-Dec-08, at 6:48 PM, Shane Isbell wrote: I'm encountering an issue with Byldan (.NET version of Maven) and since this is a general problem, I thought I'd raise it here on the list. I need to extend the pom model to include information like the key token id of the .NET assembly. Using the modelVersion element of the pom isn't appropriate to indicate these platform type extensions. The key here is to provide enough information in the pom to allow the build tool to choose the implementation of the ModelTransformer it needs. For example, if Maven sees Maven:4.0.0, then it chooses PomClassicTransformer to read the information into the canonical data format. If Maven sees dotnet:1.0.0, then Maven could use DotnetModelTransformer, and so on. Some ideas: 1) qualify modelVersion with platform: dotnet:1.0.0, maven:4.0.0 2) new platform tag 3) use of namespaces 4) Some unique id that maps to transformer I'm leaning toward (4) as it is more future proof to changes. Thoughts? But you still probably want to account for different versions of the model. I think we also need to look at Bryon Jacob's proposal again about extensibility with validation. Thanks, Shane Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. This is an interesting problem. I don't see any way to fix this other than changing Maven itself, unfortunately, but I think Arnaud's idea about the lifecycle is a good one. What about a generate lifecycle that just does all the generation phases (ie, the ones you've listed), and ends with a generate phase. Someone could bind eclipse/idea/whatever to that, and run mvn generate from the command line. We might need to hash out the details, but I think it's worth trying it to see if it works for your use case first to see if it is worthwhile pursuing further - you could do this on the maven-2.1.x branch and add it to the maven-core components.xml file. Thats fine and I think I can see how you would create it, but the binding to this phase is done via the pom's packaging. But the eclipse plugin (or any ide plugin) should not be changing the pom's packaging, i.e it will still be jar, war, etc. The @execute lifecycle=XXX syntax doesn't allow you to specify a builtin lifecycle. It only allows you to specify the one in your lifecycle.xml file. At least that is what my limited understanding obtained by fiddling has shown. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: What will replace the @aggregator MOJO configuration?
On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox bri...@reply.infinity.nu wrote: I think most of these ideas are already covered in the lifecycle proposal out there that john wrote. Can you paste the link in please? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposed change to handling of dependency version ranges
Hi Everyone In the spirit of full-disclosure, I work with Ian at Overstock.com, but I wanted to chime in on this discussion because of issues I've had with various projects. Given this scenario: com.foo:my-artifact:jar:1.0:compile org.hibernate:hibernate:3.1.1:compile com.foo:another-artifact:2.0:compile org.hibernate:hibernate:3.1.3:compile I would like to see a way for com.foo:my-artifact to suggest hibernate 3.1.1, at the same time, indicate if there is another version of hibernate in my dependency tree (not in all of maven, just my dependencies) which has a higher version defined, use it instead (org.hibernate:hibernate:3.1.3 in this case). Currently, the closest I can get to this is the range syntax, [3.1.1,) but as we all know, this syntax will download the latest version of hibernate (today this would be version 3.3.1.ga). I agree that developers should be responsible for managing their dependencies, at the same time, Maven should make things easier not more difficult. If I have 150 dependencies, how much time should I spend determining which artifacts should be included? Perhaps as much time as needed; however, If there was a way to indicate use the highest declared version of a common dependency then Maven would be assisting me in managing my dependencies. Does it seem like a bad idea to have a syntax that lets the highest dependency version within my project dependency graph win, IFF I had a way to indicate this preference? Thanks Chris On Dec 9, 2008, at 12:25 AM, Jörg Schaible wrote: Hi Ian, Ian Robertson wrote at Montag, 8. Dezember 2008 20:35: On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: [snip] I think the short answer is, if you want repeatable builds then don't use range syntax. By defining a range you are saying that everything that fits in this range is a valid choice. Even those in the future that have yet to be release, as long as they fit in the range. Given that these future versions dont exist they haven't been tested so using a range can be dangerous. You raise a good point - open-ended version ranges leave one vulnerable to backwards-incompatible library upgrades. But the current strategy of taking the highest version introduces an additional element of instability to application that can appear from one day to the next without any change to an applications code base. Unfortunately, without a notion of version ranges, managing versions becomes prohibitive in projects with large dependency graphs. If an application has several different transitive dependencies on a particular library, the application developer is forced to traverse the entire graph, examine all the dependencies, and choose the highest of them so that she is guaranteed not to hit NoClassDefFoundErrors or NoSuchMethodErrors at runtime. For projects with hundreds of transitive dependencies, this is error-prone at best. Version ranges allow each module to declare the minimum version it needs to run properly, and let maven do the work of finding a version acceptable to all modules in the dependency graph. Nothing can really keep you save from such incompatibilities and problems anyway. You silently imply that a higher version is always compatible, but that's also not true (you know). In really worse cases it is like the incompatible ASM 1.x, 2.x and 3.x series, but even for such an innocent upgrade from JUnit 3.8.1 to 3.8.2 you might get a surprise, because the latter uses a method not available in JDK 1.3 runtime. And this does not cover cases where the groupId for the artifact changes (e.g. xstream:xstream:1.1.3 com.thoughtworks.xstream:xstream:1.2) or artifacts are splitted and/or renamed (e.g. avalon:avalon-framwork:4.1.4 to org.apache.avalon:framework-api:4.3.1 and org.apache.avalon:framework-impl:4.3.1) or two artifacts deliver the same classes (commons-logging:commons-logging:1.1.1 and org.slf4j:slf4j-jcl:1.5.6) or a jar is consumed by a different one (e.g. org.ajax4jsf:ajax4jsf:1.1.0 into org.richfaces:richfaces:3.1.0) or consumed even by the JDK (javax.activation:activation:1.0.2 in JDK 6). Therefore it is always the developers task to take care of the complete dependency tree of a product/project. [snip] - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposed change to handling of dependency version ranges
H you've just given me an idea for a mojo for the versions-maven-plugin http://jira.codehaus.org/browse/MVERSIONS-16 2008/12/11 Chris Maki chrism...@mac.com Hi Everyone In the spirit of full-disclosure, I work with Ian at Overstock.com, but I wanted to chime in on this discussion because of issues I've had with various projects. Given this scenario: com.foo:my-artifact:jar:1.0:compile org.hibernate:hibernate:3.1.1:compile com.foo:another-artifact:2.0:compile org.hibernate:hibernate:3.1.3:compile I would like to see a way for com.foo:my-artifact to suggest hibernate 3.1.1, at the same time, indicate if there is another version of hibernate in my dependency tree (not in all of maven, just my dependencies) which has a higher version defined, use it instead (org.hibernate:hibernate:3.1.3 in this case). Currently, the closest I can get to this is the range syntax, [3.1.1,) but as we all know, this syntax will download the latest version of hibernate (today this would be version 3.3.1.ga). I agree that developers should be responsible for managing their dependencies, at the same time, Maven should make things easier not more difficult. If I have 150 dependencies, how much time should I spend determining which artifacts should be included? Perhaps as much time as needed; however, If there was a way to indicate use the highest declared version of a common dependency then Maven would be assisting me in managing my dependencies. Does it seem like a bad idea to have a syntax that lets the highest dependency version within my project dependency graph win, IFF I had a way to indicate this preference? Thanks Chris On Dec 9, 2008, at 12:25 AM, Jörg Schaible wrote: Hi Ian, Ian Robertson wrote at Montag, 8. Dezember 2008 20:35: On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: [snip] I think the short answer is, if you want repeatable builds then don't use range syntax. By defining a range you are saying that everything that fits in this range is a valid choice. Even those in the future that have yet to be release, as long as they fit in the range. Given that these future versions dont exist they haven't been tested so using a range can be dangerous. You raise a good point - open-ended version ranges leave one vulnerable to backwards-incompatible library upgrades. But the current strategy of taking the highest version introduces an additional element of instability to application that can appear from one day to the next without any change to an applications code base. Unfortunately, without a notion of version ranges, managing versions becomes prohibitive in projects with large dependency graphs. If an application has several different transitive dependencies on a particular library, the application developer is forced to traverse the entire graph, examine all the dependencies, and choose the highest of them so that she is guaranteed not to hit NoClassDefFoundErrors or NoSuchMethodErrors at runtime. For projects with hundreds of transitive dependencies, this is error-prone at best. Version ranges allow each module to declare the minimum version it needs to run properly, and let maven do the work of finding a version acceptable to all modules in the dependency graph. Nothing can really keep you save from such incompatibilities and problems anyway. You silently imply that a higher version is always compatible, but that's also not true (you know). In really worse cases it is like the incompatible ASM 1.x, 2.x and 3.x series, but even for such an innocent upgrade from JUnit 3.8.1 to 3.8.2 you might get a surprise, because the latter uses a method not available in JDK 1.3 runtime. And this does not cover cases where the groupId for the artifact changes (e.g. xstream:xstream:1.1.3 com.thoughtworks.xstream:xstream:1.2) or artifacts are splitted and/or renamed (e.g. avalon:avalon-framwork:4.1.4 to org.apache.avalon:framework-api:4.3.1 and org.apache.avalon:framework-impl:4.3.1) or two artifacts deliver the same classes (commons-logging:commons-logging:1.1.1 and org.slf4j:slf4j-jcl:1.5.6) or a jar is consumed by a different one (e.g. org.ajax4jsf:ajax4jsf:1.1.0 into org.richfaces:richfaces:3.1.0) or consumed even by the JDK (javax.activation:activation:1.0.2 in JDK 6). Therefore it is always the developers task to take care of the complete dependency tree of a product/project. [snip] - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
Daniel Kulp wrote: Could you try unzipping the shaded jar and then using jar cf to create a new jar using the same contents and seeing if that helps? Thanks. It seems it doesn't help. At one point, shade wasn't sticking directory entries into the jar properly which worked fine for java and javac and such, but it confused winzip really badly. It's possible something else or a similar issue is causing an issue with netbeans. I think I remember reading about it, wasn't it fixed before 1.2? Alos, make sure it's the latest shade plugin as well to get the fix for above. 1.2? I saw references to 1.3-SNAPSHOT, but I have no idea how to declare and use it in my own .pom? Greetings, L Dan On Wednesday 10 December 2008 10:41:27 pm Lilianne E. Blaze wrote: Hello, (I already tried on users- list) I'm trying to make a jar containing x dependencies to be used as a single dependency, using Shade with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to recognize it - code completion fails with package/class/symbol does not exist errors all over the place. Now I'm pretty much stuck. It could be a problem with Maven, could be with Netbeans, could be my (complete or partial) mistake with understanding how Maven makes / handles Shaded jars. I already submitted a report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a simple project (3 projects, 2 classes) to demonstrate it. Greetings, thanks in advance, Lilianne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Shaded Jars + Netbeans = confused Netbeans?
On Thursday 11 December 2008 4:26:42 pm Lilianne E. Blaze wrote: Daniel Kulp wrote: Could you try unzipping the shaded jar and then using jar cf to create a new jar using the same contents and seeing if that helps? Thanks. It seems it doesn't help. OK. Then that's not the issue.The new jar would definitely have everything in there correctly. At one point, shade wasn't sticking directory entries into the jar properly which worked fine for java and javac and such, but it confused winzip really badly. It's possible something else or a similar issue is causing an issue with netbeans. I think I remember reading about it, wasn't it fixed before 1.2? Yea. 1.1 I think. Dan Alos, make sure it's the latest shade plugin as well to get the fix for above. 1.2? I saw references to 1.3-SNAPSHOT, but I have no idea how to declare and use it in my own .pom? Greetings, L Dan On Wednesday 10 December 2008 10:41:27 pm Lilianne E. Blaze wrote: Hello, (I already tried on users- list) I'm trying to make a jar containing x dependencies to be used as a single dependency, using Shade with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedSco pe promoteTransitiveDependenciestrue/promoteTransitiveDependencies It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to recognize it - code completion fails with package/class/symbol does not exist errors all over the place. Now I'm pretty much stuck. It could be a problem with Maven, could be with Netbeans, could be my (complete or partial) mistake with understanding how Maven makes / handles Shaded jars. I already submitted a report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a simple project (3 projects, 2 classes) to demonstrate it. Greetings, thanks in advance, Lilianne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposed change to handling of dependency version ranges
On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: H you've just given me an idea for a mojo for the versions-maven-plugin As Stephen points out in the JIRA, the correct way is to add a dependencyManagement section. Dependencies need to be MANAGED. Someone needs to take this ownership, your tech lead/architect is a good choice. Otherwise you end up in chaos. The usual way to handle this is to have all your projects inherit from a common pom and define all versions in the dependencyManagement section. Then all your children artifacts NEVER define versions. They will always select the correct version from your parent or throw an error - which indicates you need to include that artifact in the parent dependencyManagement section. Yes its a pain and the versions-maven-plugin new feature would make this work easier, but it is something that you have to actively manage to avoid testing or conflict issues. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MECLIPSE-37 creating a new custom lifecycle for m-eclipse-p
On 12/12/2008, at 6:55 AM, Barrie Treloar wrote: See http://jira.codehaus.org/browse/MECLIPSE-37 There doesn't seem to be anything on the mailing lists to help with this problem. This is an interesting problem. I don't see any way to fix this other than changing Maven itself, unfortunately, but I think Arnaud's idea about the lifecycle is a good one. What about a generate lifecycle that just does all the generation phases (ie, the ones you've listed), and ends with a generate phase. Someone could bind eclipse/idea/whatever to that, and run mvn generate from the command line. We might need to hash out the details, but I think it's worth trying it to see if it works for your use case first to see if it is worthwhile pursuing further - you could do this on the maven-2.1.x branch and add it to the maven-core components.xml file. Thats fine and I think I can see how you would create it, but the binding to this phase is done via the pom's packaging. But the eclipse plugin (or any ide plugin) should not be changing the pom's packaging, i.e it will still be jar, war, etc. Not quite what I meant... if you had a new lifecycle, each packaging would need to declare their bindings for that. So it has the upside of being more general and a lower impact change to Maven's internals, but the downside that non-core packagings would need to add a definition to support it. I was thinking along the lines that you'd then start adding this to the pom: plugin artifactIdmaven-eclipse-plugin/artifactId executions execution goals goalgenerate/goal /goals /execution /executions /plugin then run mvn generate instead of eclipse:eclipse (though that would still work). This let's the one eclipse plugin work across both versions of maven. This is a lifecycle the IDE integration could later use much more happily I think as well. Still thinking it through - but it seems worth prototyping to try. The @execute lifecycle=XXX syntax doesn't allow you to specify a builtin lifecycle. It only allows you to specify the one in your lifecycle.xml file. At least that is what my limited understanding obtained by fiddling has shown. Yep, but phase= will use a built-in lifecycle. The problem is that to add a built-in lifecycle, you need to incr. the version of Maven, and the Eclipse plugin then won't work on older ones. Hope this is making some sense. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposed change to handling of dependency version ranges
I agree with this. But even with managed dependencies there are still problems. Even though you have dictated the version you really have no idea if it is compatible with the version needed by the artifact trying to use it. I have been advocating for some time that 3.0 support requires and provides. Jason has assured me that it will make it into one of the 3.0 milestone releases. When used by artifacts this would allow Maven to pick the latest version from a range that provides all the required attributes. When used with a managed dependency it could report an error if the artifact being overridden has incompatible requirements with the managed dependency. With 2.0.x no one should expect any real improvement in this as it would break too many things. Ralph On Dec 11, 2008, at 3:25 PM, Barrie Treloar wrote: On Fri, Dec 12, 2008 at 7:45 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: H you've just given me an idea for a mojo for the versions-maven-plugin As Stephen points out in the JIRA, the correct way is to add a dependencyManagement section. Dependencies need to be MANAGED. Someone needs to take this ownership, your tech lead/architect is a good choice. Otherwise you end up in chaos. The usual way to handle this is to have all your projects inherit from a common pom and define all versions in the dependencyManagement section. Then all your children artifacts NEVER define versions. They will always select the correct version from your parent or throw an error - which indicates you need to include that artifact in the parent dependencyManagement section. Yes its a pain and the versions-maven-plugin new feature would make this work easier, but it is something that you have to actively manage to avoid testing or conflict issues. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (28 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 You may edit this subscription at: http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
opinions on MSHADE-42
Hi, I was looking at applying the patch for this one, but wasn't happy with it and looked for a better solution, which I'm also not happy with :) Basically, in the reactor target/classes is always used as the classpath for projects referring to dependencies inside the reactor because of the way it is set in MavenProject. I think it would be worth us reversing the logic in MavenProject (if the artifact file is not null, use that, if it is, use the active project) - any thoughts why that would be a bad idea? As for shade, to make it work in the reactor, there's 3 options: - unpack the final JAR into the classesDirectory (the original patch) - replace the outputDirectory with the JAR (cleaner and more concise, but effectively makes the output directory read-only from the package phase, might have unexpected side effects if someone modifies the output afterwards, though that would seem unwise anyway) - don't fix it, require people to use shadedArtifactAttachedtrue/ shadedArtifactAttached instead and depend on the one with the classifier. Opinions? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
{VOTE] Release Mercury 1.0.0-alpha-2 results
6 votes casted [+1] 6: 4 binding, 2 non-binding [-1] [0] I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury Thanks, Oleg Oleg Gusakov wrote: Dear All, This is the first release of Mercury with all major [mercury] functionality enabled: repository access + dependency resolution. You can try using it for resolving artifacts and then writing them into a local repo in a standalone application, event system helps to understand what is going on inside (and for how long it does that). Example of using Mercury is available in mercury-plexus unit test. More detailed discussion - http://docs.codehaus.org/display/MAVEN/Mercury Special thanks to Herve Bouteme and Benjamin Bentmann for helping to make this happen! We solved 20 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11816styleName=Htmlversion=14629 Staging repo: http://people.apache.org/~ogusakov/repos/staging Staging site: http://maven.apache.org/mercury/staging Vote open for 72 hours. Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Mercury ant tasks - can try them now
I made a first working snapshot of the Mercury ant tasks available at http://people.apache.org/~ogusakov/repos/test/org/apache/maven/mercury/mercury-ant-tasks/1.0-alpha-1-SNAPSHOT/mercury-ant-tasks-1.0-alpha-1-20081211-all.jar Just put this jar into ~/.ant/lib and use http://people.apache.org/~ogusakov/repos/test/org/apache/maven/mercury/mercury-ant-tasks/1.0-alpha-1-SNAPSHOT/build.xml as a reference Available functionality: * configure repositories in named (id attribute) merc:config ../ sets * list dependencies in named (id attribute) merc:dep ../ sets * create named classpaths or add to existing ones with merc:resolve ../ task. pathid means create new path, refpathid - add to existing path. This task also used a previously defined merc:config / and merc:dep / sets. You can use OSGi compatible ranges in the dependency declarations, like ant:ant:(1.6.4, 1.7.1) or ant:ant:[1.6.5,) * deploy/install files to local/remote repos with merc:write ../ task I am working on adding stream verification configuration for reading and writing: OpenPGP, SHA1, MD5, which will be in the next snapshot sometime next week Of cause - all the names, syntax, could be changed - I tried to make them short yet explanatory. Main drive - create something simple yet usable. Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: opinions on MSHADE-42
Sent from my iPhone On Dec 12, 2008, at 7:02 AM, Brett Porter br...@apache.org wrote: Hi, I was looking at applying the patch for this one, but wasn't happy with it and looked for a better solution, which I'm also not happy with :) Basically, in the reactor target/classes is always used as the classpath for projects referring to dependencies inside the reactor because of the way it is set in MavenProject. I think it would be worth us reversing the logic in MavenProject (if the artifact file is not null, use that, if it is, use the active project) - any thoughts why that would be a bad idea? The reactor, if only defined by what it has always been, means resolving from the stated build output directory. You can't change that fundamental contract at this point. How people work from the reactor and/or walk into directories will yield a random mixture of artifact and build output directories which I can only see causing problems. As for shade, to make it work in the reactor, there's 3 options: Trying to use the shade plugin from the reactor is a misuse of the plugin. I specifically made it to work with JARs and it reads entries from JARs. I would suggest treating the über JAR like an assembly where you have a separate project. - unpack the final JAR into the classesDirectory (the original patch) - replace the outputDirectory with the JAR (cleaner and more concise, but effectively makes the output directory read-only from the package phase, might have unexpected side effects if someone modifies the output afterwards, though that would seem unwise anyway) - don't fix it, require people to use shadedArtifactAttachedtrue/ shadedArtifactAttached instead and depend on the one with the classifier. Opinions? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Extending the Pom
On Dec 11, 2008, at 7:48 PM, Shane Isbell shane.isb...@gmail.com wrote: The idea here is not to do away with modelVersion, but rather to add an additional parameter, similar to modelGroupId. Something that I think would be useful is a language/platform element. Then it's purely additions to the POM. If you could identify the language/platform and it's version would that be enough for you? I found a post by Bryon here talking about the extensibility: http://freedomandbeer.com/posts/extensible-xml-with-xml-namespaces-and-relaxng If it is possible to grab out extensions of the pom and hand off the nodes to appropriate ModelTransformers, that would be useful, allowing chaining of ModelTransformers for processing. That would be pretty powerful. I would prefer to use Bryon's method and avoid XSD validation and tooling like the plague. Only downside is IDE support I suppose. Could probably internally generate the XSD for the XML editors in the current IDEs. Shane On Thu, Dec 11, 2008 at 10:04 AM, Jason van Zyl jvan...@sonatype.comwrote: On 11-Dec-08, at 6:48 PM, Shane Isbell wrote: I'm encountering an issue with Byldan (.NET version of Maven) and since this is a general problem, I thought I'd raise it here on the list. I need to extend the pom model to include information like the key token id of the .NET assembly. Using the modelVersion element of the pom isn't appropriate to indicate these platform type extensions. The key here is to provide enough information in the pom to allow the build tool to choose the implementation of the ModelTransformer it needs. For example, if Maven sees Maven:4.0.0, then it chooses PomClassicTransformer to read the information into the canonical data format. If Maven sees dotnet:1.0.0, then Maven could use DotnetModelTransformer, and so on. Some ideas: 1) qualify modelVersion with platform: dotnet:1.0.0, maven:4.0.0 2) new platform tag 3) use of namespaces 4) Some unique id that maps to transformer I'm leaning toward (4) as it is more future proof to changes. Thoughts? But you still probably want to account for different versions of the model. I think we also need to look at Bryon Jacob's proposal again about extensibility with validation. Thanks, Shane Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: {VOTE] Release Mercury 1.0.0-alpha-2 results
Cool, I'll flip trunk to use it so we're another step closer to the alpha-1. Sent from my iPhone On Dec 12, 2008, at 7:02 AM, Oleg Gusakov oleg.subscripti...@gmail.com wrote: 6 votes casted [+1] 6: 4 binding, 2 non-binding [-1] [0] I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury Thanks, Oleg Oleg Gusakov wrote: Dear All, This is the first release of Mercury with all major [mercury] functionality enabled: repository access + dependency resolution. You can try using it for resolving artifacts and then writing them into a local repo in a standalone application, event system helps to understand what is going on inside (and for how long it does that). Example of using Mercury is available in mercury-plexus unit test. More detailed discussion - http://docs.codehaus.org/display/MAVEN/Mercury Special thanks to Herve Bouteme and Benjamin Bentmann for helping to make this happen! We solved 20 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11816styleName=Htmlversion=14629 Staging repo: http://people.apache.org/~ogusakov/repos/staging Staging site: http://maven.apache.org/mercury/staging Vote open for 72 hours. Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
