Re: Branch with Google guice?
On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote:
Hi,
Can somebody point me to the Maven 3 branch with Google guice? I
undertsand that Google guice will replace Plexus classworlds, but the
trunk still has Plexus in it. I'd like to have a look at what Maven 3
will look like when finished (from a code perspective).
The idea is for Guice to replace the Plexus container
by using a compatibility layer to inject requirements
into components. (Plexus classworlds is more about
classloader isolation, which is orthogonal to injection
and may or may not be replaced in the near future)
The Plexus container compatibility layer is here:
http://svn.sonatype.org/spice/trunk/spice-inject
Note that because this supports Plexus components
on top of Guice/JSR330 there's actually no changes
needed to Maven 3 to run it on top of Guice - that's
all handled by the compatibility layer, you can even
mix JSR330 and Plexus components/annotations.
Below is the patch to build M3 with the replacement
container - note you'll need to build the spice-inject
project beforehand, unless you use the Sonatype
forge repository to get the latest snapshots:
https://repository.sonatype.org/content/groups/forge
Changing future plugins / Maven to use pure JSR330
annotations is a separate discussion that will happen
on the dev list - first I need to write up our experience
at Sonatype with using a JSR330 component model*
so people have something concrete to discuss.
[* apologies to the dev-list for delays in writing this up]
HTH
Index: maven-repository/pom.xml
===
--- maven-repository/pom.xml(revision 951813)
+++ maven-repository/pom.xml(working copy)
@@ -39,8 +39,8 @@
artifactIdmaven-compat/artifactId
/dependency
dependency
- groupIdorg.codehaus.plexus/groupId
- artifactIdplexus-container-default/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdspice-inject-plexus/artifactId
/dependency
dependency
groupIdorg.codehaus.plexus/groupId
Index: apache-maven/pom.xml
===
--- apache-maven/pom.xml(revision 951813)
+++ apache-maven/pom.xml(working copy)
@@ -43,8 +43,8 @@
artifactIdmaven-compat/artifactId
/dependency
dependency
- groupIdorg.codehaus.plexus/groupId
- artifactIdplexus-container-default/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdspice-inject-plexus/artifactId
/dependency
!-- CLI --
dependency
Index: maven-compat/pom.xml
===
--- maven-compat/pom.xml(revision 951813)
+++ maven-compat/pom.xml(working copy)
@@ -53,8 +53,8 @@
artifactIdplexus-interpolation/artifactId
/dependency
dependency
- groupIdorg.codehaus.plexus/groupId
- artifactIdplexus-container-default/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdspice-inject-plexus/artifactId
/dependency
dependency
groupIdorg.codehaus.plexus/groupId
Index: maven-model-builder/pom.xml
===
--- maven-model-builder/pom.xml(revision 951813)
+++ maven-model-builder/pom.xml(working copy)
@@ -41,8 +41,8 @@
artifactIdmaven-model/artifactId
/dependency
dependency
- groupIdorg.codehaus.plexus/groupId
- artifactIdplexus-container-default/artifactId
+ groupIdorg.sonatype.spice/groupId
+ artifactIdspice-inject-plexus/artifactId
scopetest/scope
/dependency
/dependencies
Index: pom.xml
===
--- pom.xml(revision 951813)
+++ pom.xml(working copy)
@@ -44,6 +44,7 @@
plexusVersion1.5.4/plexusVersion
plexusInterpolationVersion1.11/plexusInterpolationVersion
plexusUtilsVersion2.0.4/plexusUtilsVersion
+spiceInjectVersion1.2.1-SNAPSHOT/spiceInjectVersion
wagonVersion1.0-beta-6/wagonVersion
securityDispatcherVersion1.3/securityDispatcherVersion
cipherVersion1.4/cipherVersion
@@ -240,15 +241,9 @@
version${plexusUtilsVersion}/version
/dependency
dependency
-groupIdorg.codehaus.plexus/groupId
-artifactIdplexus-container-default/artifactId
-version${plexusVersion}/version
-exclusions
- exclusion
-groupIdjunit/groupId
-artifactIdjunit/artifactId
- /exclusion
-/exclusions
+groupIdorg.sonatype.spice/groupId
+artifactIdspice-inject-plexus/artifactId
+version${spiceInjectVersion}/version
/dependency
dependency
groupIdorg.codehaus.plexus/groupId
Index: maven-core/pom.xml
===
--- maven-core/pom.xml(revision 951813)
+++ maven-core/pom.xml(working copy)
Re: Branch with Google guice?
Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will look like when finished (from a code perspective). The idea is for Guice to replace the Plexus container by using a compatibility layer to inject requirements into components. (Plexus classworlds is more about classloader isolation, which is orthogonal to injection and may or may not be replaced in the near future) The Plexus container compatibility layer is here: http://svn.sonatype.org/spice/trunk/spice-inject Note that because this supports Plexus components on top of Guice/JSR330 there's actually no changes needed to Maven 3 to run it on top of Guice - that's all handled by the compatibility layer, you can even mix JSR330 and Plexus components/annotations. Below is the patch to build M3 with the replacement container - note you'll need to build the spice-inject project beforehand, unless you use the Sonatype forge repository to get the latest snapshots: https://repository.sonatype.org/content/groups/forge Changing future plugins / Maven to use pure JSR330 annotations is a separate discussion that will happen on the dev list - first I need to write up our experience at Sonatype with using a JSR330 component model* so people have something concrete to discuss. [* apologies to the dev-list for delays in writing this up] HTH Index: maven-repository/pom.xml === --- maven-repository/pom.xml(revision 951813) +++ maven-repository/pom.xml(working copy) @@ -39,8 +39,8 @@ artifactIdmaven-compat/artifactId /dependency dependency - groupIdorg.codehaus.plexus/groupId - artifactIdplexus-container-default/artifactId + groupIdorg.sonatype.spice/groupId + artifactIdspice-inject-plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId Index: apache-maven/pom.xml === --- apache-maven/pom.xml(revision 951813) +++ apache-maven/pom.xml(working copy) @@ -43,8 +43,8 @@ artifactIdmaven-compat/artifactId /dependency dependency - groupIdorg.codehaus.plexus/groupId - artifactIdplexus-container-default/artifactId + groupIdorg.sonatype.spice/groupId + artifactIdspice-inject-plexus/artifactId /dependency !-- CLI -- dependency Index: maven-compat/pom.xml === --- maven-compat/pom.xml(revision 951813) +++ maven-compat/pom.xml(working copy) @@ -53,8 +53,8 @@ artifactIdplexus-interpolation/artifactId /dependency dependency - groupIdorg.codehaus.plexus/groupId - artifactIdplexus-container-default/artifactId + groupIdorg.sonatype.spice/groupId + artifactIdspice-inject-plexus/artifactId /dependency dependency groupIdorg.codehaus.plexus/groupId Index: maven-model-builder/pom.xml === --- maven-model-builder/pom.xml(revision 951813) +++ maven-model-builder/pom.xml(working copy) @@ -41,8 +41,8 @@ artifactIdmaven-model/artifactId /dependency dependency - groupIdorg.codehaus.plexus/groupId - artifactIdplexus-container-default/artifactId + groupIdorg.sonatype.spice/groupId + artifactIdspice-inject-plexus/artifactId scopetest/scope /dependency /dependencies Index: pom.xml
[ANN] Maven JXR and Maven JXR Plugin 2.2 Released
The Maven team is pleased to announce the release of the Maven JXR and
Maven JXR Plugin, version 2.2.
The JXR Plugin produces a cross-reference of the project's sources. The
generated reports make it easier for the user to reference or find
specific lines of code. It is also handy when used with the PMD Plugin
for referencing errors found in the code.
http://maven.apache.org/jxr/
http://maven.apache.org/plugins/maven-jxr-plugin/
You should specify the version in your project's plugin configuration in
the reporting section of the POM:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.2/version
/plugin
Release Notes - Maven JXR - Version 2.2
** Bug
* [JXR-51] - Javadoc link broken for site:stage
* [JXR-52] - Dont generate xref report if project has pom packaging
and src/main exists
* [JXR-53] - Add a link to test javadoc
* [JXR-55] - Add dedicated resource bundle for English
* [JXR-57] - Change type of outputDirectory parameter to java.io.File
** Improvement
* [JXR-56] - Add german translation
* [JXR-60] - use ${project.build.sourceEncoding} as default value
for inputEncoding parameter
* [JXR-81] - Add implements to keyword filter
* [JXR-82] - Add jxr_linenumber class to generated line number anchors
** New Feature
* [JXR-67] - use ${project.reporting.outputEncoding} as default
value for outputEncoding parameter and default to UTF-8
* [JXR-77] - Add Swedish translation
** Wish
* [JXR-62] - Make file encoding default to platform encoding
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Branch with Google guice?
On 6 June 2010 17:22, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? The first URL is the umbrella project that provides the compatibility layer - it contains a patched version of Guice because we needed to tweak and experiment with certain behavior during development, and handle some corner-cases wrt. Nexus Most changes have been committed into Guice trunk. There's only one patch left needed for Maven, which is the type converter feature and this should go in soon. (diff vanilla.src vs. src to see the remaining patches) We're still keeping our patched tree around for further experimentation / point-releases because Guice 2.1 has not yet been officially released - otherwise you'd need to download and build Guice from scratch too. spice-inject also contains various modules that provide classpath scanning and Plexus-like features on top of Guice - these modules are combined into the two main distro jars: spice-inject-bean and spice-inject-plexus for convenience sake. [ these are not going back into Guice as they're external extensions ] spice-inject-bean provides a component model on top of JSR330 (component scanning, dynamic collections) - see the examples module for, well, an example ;) spice-inject-plexus adds support for Plexus to replace the Plexus container in Maven3 you need: spice-inject-bean-1.2.1-SNAPSHOT.jar spice-inject-plexus-1.2.1-SNAPSHOT.jar guice-patches-2.1.4-SNAPSHOT-noaop.jar at least until the type converter patches go into Guice If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? if you just want to download the dependencies then add that second URL (the Sonatype Forge) as a snapshot repository in your settings.xml, apply the patch from the end of my original email to Maven 3 trunk, and do a build 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. for the new container source code see 1) ... specifically guice-bean / guice-plexus which form most of the code [ it's modular so there's no single project source tree ] also look at the example to see JSR330 in practice To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. you already have it... build 1) and you have everything needed - as explained you still need the patch of Guice for now, but won't in the future or just use 2) to download the binary snapshots I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Maven 3 trunk still builds with Plexus at the moment, but if you take the patch from the bottom of my earlier email and apply it to Maven 3 then it will build with the new artifacts or just grab a snapshot build of Maven 3, remove the Plexus container jar and add the three artifacts listed above... Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will look like when finished (from a code perspective). The idea is for Guice to replace the Plexus container by using a compatibility layer to inject requirements into components. (Plexus classworlds is more about classloader isolation, which is orthogonal to injection and may or may not be replaced in the near future) The Plexus container compatibility layer is here: http://svn.sonatype.org/spice/trunk/spice-inject Note that because this supports Plexus components on top of Guice/JSR330 there's actually no changes needed to Maven 3 to run it on top of Guice - that's all handled by the compatibility layer, you can even mix JSR330 and Plexus components/annotations. Below is the patch to build M3 with the replacement container - note you'll need to build the spice-inject project beforehand, unless you use the Sonatype forge repository to get the latest snapshots: https://repository.sonatype.org/content/groups/forge Changing future plugins / Maven to use pure JSR330 annotations is a separate discussion that will happen on the
Re: Branch with Google guice?
Stuart, thank you for your email. Do you think that future emails related to the process below (mainly if I found any difficulties in building the whole thing plus observations, suggestions, etc) should be addressed to the dev mailing list? M. On Sun, 2010-06-06 at 18:11 +0800, Stuart McCulloch wrote: On 6 June 2010 17:22, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? The first URL is the umbrella project that provides the compatibility layer - it contains a patched version of Guice because we needed to tweak and experiment with certain behavior during development, and handle some corner-cases wrt. Nexus Most changes have been committed into Guice trunk. There's only one patch left needed for Maven, which is the type converter feature and this should go in soon. (diff vanilla.src vs. src to see the remaining patches) We're still keeping our patched tree around for further experimentation / point-releases because Guice 2.1 has not yet been officially released - otherwise you'd need to download and build Guice from scratch too. spice-inject also contains various modules that provide classpath scanning and Plexus-like features on top of Guice - these modules are combined into the two main distro jars: spice-inject-bean and spice-inject-plexus for convenience sake. [ these are not going back into Guice as they're external extensions ] spice-inject-bean provides a component model on top of JSR330 (component scanning, dynamic collections) - see the examples module for, well, an example ;) spice-inject-plexus adds support for Plexus to replace the Plexus container in Maven3 you need: spice-inject-bean-1.2.1-SNAPSHOT.jar spice-inject-plexus-1.2.1-SNAPSHOT.jar guice-patches-2.1.4-SNAPSHOT-noaop.jar at least until the type converter patches go into Guice If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? if you just want to download the dependencies then add that second URL (the Sonatype Forge) as a snapshot repository in your settings.xml, apply the patch from the end of my original email to Maven 3 trunk, and do a build 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. for the new container source code see 1) ... specifically guice-bean / guice-plexus which form most of the code [ it's modular so there's no single project source tree ] also look at the example to see JSR330 in practice To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. you already have it... build 1) and you have everything needed - as explained you still need the patch of Guice for now, but won't in the future or just use 2) to download the binary snapshots I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Maven 3 trunk still builds with Plexus at the moment, but if you take the patch from the bottom of my earlier email and apply it to Maven 3 then it will build with the new artifacts or just grab a snapshot build of Maven 3, remove the Plexus container jar and add the three artifacts listed above... Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will look like when finished (from a code perspective). The idea is for Guice to replace the Plexus container by using a compatibility layer to inject requirements into components. (Plexus classworlds is more about classloader isolation, which is orthogonal to injection and may or may not be replaced in the near future) The Plexus container compatibility layer is here: http://svn.sonatype.org/spice/trunk/spice-inject Note that because this supports Plexus components on top of Guice/JSR330 there's actually no changes needed to Maven 3 to run it on top of Guice - that's all handled by the compatibility layer, you can even mix
Re: Branch with Google guice?
On 6 June 2010 19:27, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, thank you for your email. Do you think that future emails related to the process below (mainly if I found any difficulties in building the whole thing plus observations, suggestions, etc) should be addressed to the dev mailing list? yep, this is more of a dev discussion M. On Sun, 2010-06-06 at 18:11 +0800, Stuart McCulloch wrote: On 6 June 2010 17:22, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? The first URL is the umbrella project that provides the compatibility layer - it contains a patched version of Guice because we needed to tweak and experiment with certain behavior during development, and handle some corner-cases wrt. Nexus Most changes have been committed into Guice trunk. There's only one patch left needed for Maven, which is the type converter feature and this should go in soon. (diff vanilla.src vs. src to see the remaining patches) We're still keeping our patched tree around for further experimentation / point-releases because Guice 2.1 has not yet been officially released - otherwise you'd need to download and build Guice from scratch too. spice-inject also contains various modules that provide classpath scanning and Plexus-like features on top of Guice - these modules are combined into the two main distro jars: spice-inject-bean and spice-inject-plexus for convenience sake. [ these are not going back into Guice as they're external extensions ] spice-inject-bean provides a component model on top of JSR330 (component scanning, dynamic collections) - see the examples module for, well, an example ;) spice-inject-plexus adds support for Plexus to replace the Plexus container in Maven3 you need: spice-inject-bean-1.2.1-SNAPSHOT.jar spice-inject-plexus-1.2.1-SNAPSHOT.jar guice-patches-2.1.4-SNAPSHOT-noaop.jar at least until the type converter patches go into Guice If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? if you just want to download the dependencies then add that second URL (the Sonatype Forge) as a snapshot repository in your settings.xml, apply the patch from the end of my original email to Maven 3 trunk, and do a build 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. for the new container source code see 1) ... specifically guice-bean / guice-plexus which form most of the code [ it's modular so there's no single project source tree ] also look at the example to see JSR330 in practice To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. you already have it... build 1) and you have everything needed - as explained you still need the patch of Guice for now, but won't in the future or just use 2) to download the binary snapshots I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Maven 3 trunk still builds with Plexus at the moment, but if you take the patch from the bottom of my earlier email and apply it to Maven 3 then it will build with the new artifacts or just grab a snapshot build of Maven 3, remove the Plexus container jar and add the three artifacts listed above... Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will look like when finished (from a code perspective). The idea is for Guice to replace the Plexus container by using a compatibility layer to inject requirements into components. (Plexus classworlds is more about classloader isolation, which is orthogonal to injection and may or may not be replaced in the near future) The Plexus container compatibility layer is here: http://svn.sonatype.org/spice/trunk/spice-inject Note
Re: Branch with Google guice?
Hi Stuart, Any objections If I create a branch in asf svn repo ? 2010/6/6 Stuart McCulloch mccu...@gmail.com: On 6 June 2010 19:27, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, thank you for your email. Do you think that future emails related to the process below (mainly if I found any difficulties in building the whole thing plus observations, suggestions, etc) should be addressed to the dev mailing list? yep, this is more of a dev discussion M. On Sun, 2010-06-06 at 18:11 +0800, Stuart McCulloch wrote: On 6 June 2010 17:22, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? The first URL is the umbrella project that provides the compatibility layer - it contains a patched version of Guice because we needed to tweak and experiment with certain behavior during development, and handle some corner-cases wrt. Nexus Most changes have been committed into Guice trunk. There's only one patch left needed for Maven, which is the type converter feature and this should go in soon. (diff vanilla.src vs. src to see the remaining patches) We're still keeping our patched tree around for further experimentation / point-releases because Guice 2.1 has not yet been officially released - otherwise you'd need to download and build Guice from scratch too. spice-inject also contains various modules that provide classpath scanning and Plexus-like features on top of Guice - these modules are combined into the two main distro jars: spice-inject-bean and spice-inject-plexus for convenience sake. [ these are not going back into Guice as they're external extensions ] spice-inject-bean provides a component model on top of JSR330 (component scanning, dynamic collections) - see the examples module for, well, an example ;) spice-inject-plexus adds support for Plexus to replace the Plexus container in Maven3 you need: spice-inject-bean-1.2.1-SNAPSHOT.jar spice-inject-plexus-1.2.1-SNAPSHOT.jar guice-patches-2.1.4-SNAPSHOT-noaop.jar at least until the type converter patches go into Guice If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? if you just want to download the dependencies then add that second URL (the Sonatype Forge) as a snapshot repository in your settings.xml, apply the patch from the end of my original email to Maven 3 trunk, and do a build 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. for the new container source code see 1) ... specifically guice-bean / guice-plexus which form most of the code [ it's modular so there's no single project source tree ] also look at the example to see JSR330 in practice To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. you already have it... build 1) and you have everything needed - as explained you still need the patch of Guice for now, but won't in the future or just use 2) to download the binary snapshots I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Maven 3 trunk still builds with Plexus at the moment, but if you take the patch from the bottom of my earlier email and apply it to Maven 3 then it will build with the new artifacts or just grab a snapshot build of Maven 3, remove the Plexus container jar and add the three artifacts listed above... Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will look like when finished (from a code perspective). The idea is for Guice to replace the Plexus container by using a compatibility layer to inject requirements into components. (Plexus classworlds is more about classloader isolation, which is orthogonal to injection and may or may not be replaced in the near future) The Plexus
Re: Branch with Google guice?
On 6 June 2010 22:16, Olivier Lamy ol...@apache.org wrote: Hi Stuart, Any objections If I create a branch in asf svn repo ? sure, fine with me 2010/6/6 Stuart McCulloch mccu...@gmail.com: On 6 June 2010 19:27, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, thank you for your email. Do you think that future emails related to the process below (mainly if I found any difficulties in building the whole thing plus observations, suggestions, etc) should be addressed to the dev mailing list? yep, this is more of a dev discussion M. On Sun, 2010-06-06 at 18:11 +0800, Stuart McCulloch wrote: On 6 June 2010 17:22, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? The first URL is the umbrella project that provides the compatibility layer - it contains a patched version of Guice because we needed to tweak and experiment with certain behavior during development, and handle some corner-cases wrt. Nexus Most changes have been committed into Guice trunk. There's only one patch left needed for Maven, which is the type converter feature and this should go in soon. (diff vanilla.src vs. src to see the remaining patches) We're still keeping our patched tree around for further experimentation / point-releases because Guice 2.1 has not yet been officially released - otherwise you'd need to download and build Guice from scratch too. spice-inject also contains various modules that provide classpath scanning and Plexus-like features on top of Guice - these modules are combined into the two main distro jars: spice-inject-bean and spice-inject-plexus for convenience sake. [ these are not going back into Guice as they're external extensions ] spice-inject-bean provides a component model on top of JSR330 (component scanning, dynamic collections) - see the examples module for, well, an example ;) spice-inject-plexus adds support for Plexus to replace the Plexus container in Maven3 you need: spice-inject-bean-1.2.1-SNAPSHOT.jar spice-inject-plexus-1.2.1-SNAPSHOT.jar guice-patches-2.1.4-SNAPSHOT-noaop.jar at least until the type converter patches go into Guice If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? if you just want to download the dependencies then add that second URL (the Sonatype Forge) as a snapshot repository in your settings.xml, apply the patch from the end of my original email to Maven 3 trunk, and do a build 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. for the new container source code see 1) ... specifically guice-bean / guice-plexus which form most of the code [ it's modular so there's no single project source tree ] also look at the example to see JSR330 in practice To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. you already have it... build 1) and you have everything needed - as explained you still need the patch of Guice for now, but won't in the future or just use 2) to download the binary snapshots I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Maven 3 trunk still builds with Plexus at the moment, but if you take the patch from the bottom of my earlier email and apply it to Maven 3 then it will build with the new artifacts or just grab a snapshot build of Maven 3, remove the Plexus container jar and add the three artifacts listed above... Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will look like when finished (from a code perspective). The idea is for Guice to replace the Plexus container by using a
Re: Custom metadata in a POM?
Nexus can utilize anything contained in the repository. Whether a piece of metadata exists alongside the artifact or within it, a Nexus plugin could be created to process the information. So you don't need to change the way Grails plugins are packaged in order to extract the metadata and make it available. We know from experience that Nexus is perfect for plugin systems :-) On Jun 4, 2010, at 4:28 PM, Les Hazlewood wrote: Is this possible? So, in addition to stuff like developers, is it possible to add additional metadata? I'm asking because the Grails development team is exploring the possibility of using a Maven repository (e.g. Nexus) to host Grails plugins. A Grails plugin is a .zip file, but the Grails environment (and the global Grails Plugin Portal http://www.grails.org/plugin/home) need to read Grails-specific metadata about that .zip without having to download the .zip first. I'm proposing that the POM could serve that purpose *if* POMs can hold additional metadata somehow. Any ideas? Thanks, Les - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: Branch with Google guice?
stuff is here : http://svn.apache.org/repos/asf/maven/maven-3/branches/guice-support/ Thanks ! 2010/6/6 Stuart McCulloch mccu...@gmail.com: On 6 June 2010 22:16, Olivier Lamy ol...@apache.org wrote: Hi Stuart, Any objections If I create a branch in asf svn repo ? sure, fine with me 2010/6/6 Stuart McCulloch mccu...@gmail.com: On 6 June 2010 19:27, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, thank you for your email. Do you think that future emails related to the process below (mainly if I found any difficulties in building the whole thing plus observations, suggestions, etc) should be addressed to the dev mailing list? yep, this is more of a dev discussion M. On Sun, 2010-06-06 at 18:11 +0800, Stuart McCulloch wrote: On 6 June 2010 17:22, Jemos Infra jemos.in...@googlemail.com wrote: Stuart, a couple of things re the below: 1) The first URL downloads spice-inject and the whole Guice. Question: was Guice extended for this compatibility layer? What actually is the compatibility layer? Is it just spice or the whole lot? The first URL is the umbrella project that provides the compatibility layer - it contains a patched version of Guice because we needed to tweak and experiment with certain behavior during development, and handle some corner-cases wrt. Nexus Most changes have been committed into Guice trunk. There's only one patch left needed for Maven, which is the type converter feature and this should go in soon. (diff vanilla.src vs. src to see the remaining patches) We're still keeping our patched tree around for further experimentation / point-releases because Guice 2.1 has not yet been officially released - otherwise you'd need to download and build Guice from scratch too. spice-inject also contains various modules that provide classpath scanning and Plexus-like features on top of Guice - these modules are combined into the two main distro jars: spice-inject-bean and spice-inject-plexus for convenience sake. [ these are not going back into Guice as they're external extensions ] spice-inject-bean provides a component model on top of JSR330 (component scanning, dynamic collections) - see the examples module for, well, an example ;) spice-inject-plexus adds support for Plexus to replace the Plexus container in Maven3 you need: spice-inject-bean-1.2.1-SNAPSHOT.jar spice-inject-plexus-1.2.1-SNAPSHOT.jar guice-patches-2.1.4-SNAPSHOT-noaop.jar at least until the type converter patches go into Guice If it's just spice, could we avoid from build the whole Guice and have the dependencies downloaded from the net? if you just want to download the dependencies then add that second URL (the Sonatype Forge) as a snapshot repository in your settings.xml, apply the patch from the end of my original email to Maven 3 trunk, and do a build 2) The second URL points to a Maven repository. You were talking of a replacement container (which I thought of as being classworlds). However I was looking for the source code. for the new container source code see 1) ... specifically guice-bean / guice-plexus which form most of the code [ it's modular so there's no single project source tree ] also look at the example to see JSR330 in practice To summarise, I'd like to have the URLs only to the source code needed to build Maven 3 with the Guice bit. you already have it... build 1) and you have everything needed - as explained you still need the patch of Guice for now, but won't in the future or just use 2) to download the binary snapshots I understand that there is a compatibility layer, and I can build that (after knowing if I have to build the whole Guice as well with it). I understand that there is a replacement container (but I don't have a precise URL to the SVN code for it); I'd like to know if the Maven 3 trunk builds already on top of the above, or if I need another URL with Guice support, and if this case I'd like a precise URL for it. Maven 3 trunk still builds with Plexus at the moment, but if you take the patch from the bottom of my earlier email and apply it to Maven 3 then it will build with the new artifacts or just grab a snapshot build of Maven 3, remove the Plexus container jar and add the three artifacts listed above... Thanks for your time. M. On Sun, 2010-06-06 at 16:40 +0800, Stuart McCulloch wrote: On 6 June 2010 02:27, Jemos Infra jemos.in...@googlemail.com wrote: Hi, Can somebody point me to the Maven 3 branch with Google guice? I undertsand that Google guice will replace Plexus classworlds, but the trunk still has Plexus in it. I'd like to have a look at what Maven 3 will
Re: Branch with Google guice?
On Sun, 2010-06-06 at 16:58 +0200, Olivier Lamy wrote: stuff is here : http://svn.apache.org/repos/asf/maven/maven-3/branches/guice-support/ Thanks ! Hi Oliver, I take it this branch contains everything that's needed, right? I mean Maven-3, the Plexus-Guice adapter and all required dependencies in the POM. Correct? Thanks. M. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Branch with Google guice?
yup. It build fine and it works for some builds I have tested since I have installed it (at least on my laptop :-) ) . 2010/6/6 Jemos Infra jemos.in...@googlemail.com: On Sun, 2010-06-06 at 16:58 +0200, Olivier Lamy wrote: stuff is here : http://svn.apache.org/repos/asf/maven/maven-3/branches/guice-support/ Thanks ! Hi Oliver, I take it this branch contains everything that's needed, right? I mean Maven-3, the Plexus-Guice adapter and all required dependencies in the POM. Correct? Thanks. M. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom metadata in a POM?
Yep, Nexus would be fantastic for this - we're basically trying to come up with the most efficient mechanism to do the following: 1. A Grails developer releases a plugin. This process first entails (ideally) Grails uploading it to a Maven repo (i.e. Nexus). 2. Grails (during its 'release-plugin' command) next 'pings' the global Grails Plugin Portal (http://www.grails.org/plugin/home) with the location of the released artifact(s). 3. The Plugin Portal downloads the plugin metadata when it can based on the location specified in #2 and updates its website pages to ensure that any searches in the Portal reflect the new release. The key here is #3 - finding the best way for the Portal to most-efficiently download and read in the plugin metadata without having to download the entire plugin release.zip. The Portal has to support this for hundreds of plugins every day - it has to be as lean as possible. Best, Les On Sun, Jun 6, 2010 at 7:38 AM, Jason van Zyl ja...@sonatype.com wrote: Nexus can utilize anything contained in the repository. Whether a piece of metadata exists alongside the artifact or within it, a Nexus plugin could be created to process the information. So you don't need to change the way Grails plugins are packaged in order to extract the metadata and make it available. We know from experience that Nexus is perfect for plugin systems :-) On Jun 4, 2010, at 4:28 PM, Les Hazlewood wrote: Is this possible? So, in addition to stuff like developers, is it possible to add additional metadata? I'm asking because the Grails development team is exploring the possibility of using a Maven repository (e.g. Nexus) to host Grails plugins. A Grails plugin is a .zip file, but the Grails environment (and the global Grails Plugin Portal http://www.grails.org/plugin/home) need to read Grails-specific metadata about that .zip without having to download the .zip first. I'm proposing that the POM could serve that purpose *if* POMs can hold additional metadata somehow. Any ideas? Thanks, Les - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Branch with Google guice?
Can we use the CI server to check how this branch supports the IT test harnesss ? It could make us more confident / help to detect incompatibilities when switching to Guive will become a concrete option. Nicolas 2010/6/6 Olivier Lamy ol...@apache.org yup. It build fine and it works for some builds I have tested since I have installed it (at least on my laptop :-) ) . 2010/6/6 Jemos Infra jemos.in...@googlemail.com: On Sun, 2010-06-06 at 16:58 +0200, Olivier Lamy wrote: stuff is here : http://svn.apache.org/repos/asf/maven/maven-3/branches/guice-support/ Thanks ! Hi Oliver, I take it this branch contains everything that's needed, right? I mean Maven-3, the Plexus-Guice adapter and all required dependencies in the POM. Correct? Thanks. M. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Branch with Google guice?
I have been running this patch on my CI (including m3 IT's) for quite some time now, and it works really well here. Obviously, the more the merrier! But then again, from a user's perspective this change really adds very little to the excitement. It's supposed to be a transparent change without any feature changes and as far as I can see that's exactly what it is. Kristian sø., 06.06.2010 kl. 21.45 +0200, skrev nicolas de loof: Can we use the CI server to check how this branch supports the IT test harnesss ? It could make us more confident / help to detect incompatibilities when switching to Guive will become a concrete option. Nicolas 2010/6/6 Olivier Lamy ol...@apache.org yup. It build fine and it works for some builds I have tested since I have installed it (at least on my laptop :-) ) . 2010/6/6 Jemos Infra jemos.in...@googlemail.com: On Sun, 2010-06-06 at 16:58 +0200, Olivier Lamy wrote: stuff is here : http://svn.apache.org/repos/asf/maven/maven-3/branches/guice-support/ Thanks ! Hi Oliver, I take it this branch contains everything that's needed, right? I mean Maven-3, the Plexus-Guice adapter and all required dependencies in the POM. Correct? Thanks. M. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Command line output when running JUnit 4 test suite
klauer wrote: The Maven Surefire plugin allows you to explicitly set a single test or set of tests using wildcard matching: I'm aware of -Dtest, but that's not what I want. klauer wrote: And as for your better command line output, why not just use the command line to output the test right there: mvn test -Dtest=MyTest; cat target/surefire-reports/com.thingMyTest.txt This will only give me feedback (plus lots of noise) once the whole suite has completed, which is exactly what I'm trying to avoid. Cheers, Peter -- View this message in context: http://old.nabble.com/Command-line-output-when-running-JUnit-4-test-suite-tp28786362p28793392.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven test cannot load cross-module resources/properties ?
I have a maven mantained project with some modules . One module contains one
XML file and one parsing class :Parser.java.
Second module depends on the first module. There is a class that extends the
parsing class in the first module , but maven seems cannot test the class in
the second module. Maven test reports :
java.lang.NullPointerException
at java.util.Properties.loadFromXML(Properties.java:851)
at foo.firstModule.Parser.init(Parser.java:92)
at foo.secondModule.Program.init(Program.java:84)
In Parser.java (in the first module) , it uses Properties and InputStream
to read/parse an XML file :
InputStream xmlStream = getClass().getResourceAsStream(Data.xml);
Properties properties = new Properties();
properties.loadFromXML(xmlStream);
The data.xml is located in first module's resources/foo/firstModule
directory , and it tests OK in the first module.
Here is my full code :
This is Parser in the first module :
package foo.firstModule;
import java.io.IOException;
import java.io.InputStream;
import java.util.InvalidPropertiesFormatException;
import java.util.Properties;
public class Parser
{
private Properties properties;
public Parser()
{
InputStream xmlStream = getClass().getResourceAsStream(Data.xml);
properties = new Properties();
try
{
properties.loadFromXML(xmlStream);
}
catch (InvalidPropertiesFormatException e)
{
e.printStackTrace();
}
catch (IOException e)
{
e.printStackTrace();
}
}
public Properties getProperties()
{
return properties;
}
}
This is Parser's test case , passed .
package foo.firstModule;
import junit.framework.TestCase;
public class ParserTest extends TestCase
{
public void testParser()
{
Parser p = new Parser();
assertEquals(64 , p.getProperties().size());
}
}
This is ParserExtend in the secondModule , which extends Parser in the
firstModule :
package foo.secondModule;
import java.util.Properties;
import foo.firstModule.Parser;
public class ParserExtend extends Parser
{
private Properties properties;
public ParserExtend()
{
this.properties = getProperties();
}
public int getSize()
{
return properties.size();
}
}
This is ParserExtend's test case :
package foo.secondModule;
import junit.framework.TestCase;
public class ParserExtendTest extends TestCase
{
public void testParserExtend()
{
ParserExtend pe = new ParserExtend();
assertEquals(64 , pe.getSize());
}
}
The above test case failed because
*Properties.loadFromXML*(Properties.java:851)
throws NPE
However , if I don't extend Parser , just new the Parser :
package foo.secondModule;
import java.util.Properties;
import foo.firstModule.Parser;
public class ParserInit
{
private Properties properties;
public ParserInit()
{
Parser p = new Parser();
this.properties = p.getProperties();
}
public int getSize()
{
return properties.size();
}
}
and this is the test case :
package foo.secondModule;
import junit.framework.TestCase;
public class ParserInitTest extends TestCase
{
public void testParserInit()
{
ParserInit pi = new ParserInit();
assertEquals(64 , pi.getSize());
}
}
The test case passes !
This is my whole test scenario. It seems it 's maven and junit's classloader
problem.
Anybody able to find how to pass the ParserExtend's test case ? Thanks in
advanced.
can't change outputDirectory for maven-surefire-report-plugin
Using the following configuration, the site reports end up
C:/opt/builds/releases/${branch}/${module}/siteReports as I expect. The
test reports, however, keep getting placed under target/surefire-reports.
I've tried with and without the reportsDirectory and I've tried reversing
the order of the maven-site-plugin and the maven-surefire-report-plugin.
Can somebody please tell me how I can make the maven-surefire-report-plugin
put the reports in a directory that I specify?
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0.1/version
configuration
outputDirectoryC:/opt/builds/releases/${branch}/$
{module}/siteReports/outputDirectory
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version2.5/version
inheritedfalse/inherited
configuration
reportsDirectoryC:/opt/builds/releases/${branch}/$
{module}/testReports/reportsDirectory
outputDirectoryC:/opt/builds/releases/${branch}/$
{module}/testReports/outputDirectory
/configuration
/plugin
/plugins
/reporting
Many thanks,
Tony
Re: maven test cannot load cross-module resources/properties ?
Could it be that it is looking for Data.xml at path
foo/secondModule/Data.xml. I'm guessing that this is a plain Java thing and
not related to Maven.
/Anders
On Mon, Jun 7, 2010 at 04:30, smallufo small...@gmail.com wrote:
I have a maven mantained project with some modules . One module contains
one
XML file and one parsing class :Parser.java.
Second module depends on the first module. There is a class that extends
the
parsing class in the first module , but maven seems cannot test the class
in
the second module. Maven test reports :
java.lang.NullPointerException
at java.util.Properties.loadFromXML(Properties.java:851)
at foo.firstModule.Parser.init(Parser.java:92)
at foo.secondModule.Program.init(Program.java:84)
In Parser.java (in the first module) , it uses Properties and InputStream
to read/parse an XML file :
InputStream xmlStream = getClass().getResourceAsStream(Data.xml);
Properties properties = new Properties();
properties.loadFromXML(xmlStream);
The data.xml is located in first module's resources/foo/firstModule
directory , and it tests OK in the first module.
Here is my full code :
This is Parser in the first module :
package foo.firstModule;
import java.io.IOException;
import java.io.InputStream;
import java.util.InvalidPropertiesFormatException;
import java.util.Properties;
public class Parser
{
private Properties properties;
public Parser()
{
InputStream xmlStream = getClass().getResourceAsStream(Data.xml);
properties = new Properties();
try
{
properties.loadFromXML(xmlStream);
}
catch (InvalidPropertiesFormatException e)
{
e.printStackTrace();
}
catch (IOException e)
{
e.printStackTrace();
}
}
public Properties getProperties()
{
return properties;
}
}
This is Parser's test case , passed .
package foo.firstModule;
import junit.framework.TestCase;
public class ParserTest extends TestCase
{
public void testParser()
{
Parser p = new Parser();
assertEquals(64 , p.getProperties().size());
}
}
This is ParserExtend in the secondModule , which extends Parser in the
firstModule :
package foo.secondModule;
import java.util.Properties;
import foo.firstModule.Parser;
public class ParserExtend extends Parser
{
private Properties properties;
public ParserExtend()
{
this.properties = getProperties();
}
public int getSize()
{
return properties.size();
}
}
This is ParserExtend's test case :
package foo.secondModule;
import junit.framework.TestCase;
public class ParserExtendTest extends TestCase
{
public void testParserExtend()
{
ParserExtend pe = new ParserExtend();
assertEquals(64 , pe.getSize());
}
}
The above test case failed because
*Properties.loadFromXML*(Properties.java:851)
throws NPE
However , if I don't extend Parser , just new the Parser :
package foo.secondModule;
import java.util.Properties;
import foo.firstModule.Parser;
public class ParserInit
{
private Properties properties;
public ParserInit()
{
Parser p = new Parser();
this.properties = p.getProperties();
}
public int getSize()
{
return properties.size();
}
}
and this is the test case :
package foo.secondModule;
import junit.framework.TestCase;
public class ParserInitTest extends TestCase
{
public void testParserInit()
{
ParserInit pi = new ParserInit();
assertEquals(64 , pi.getSize());
}
}
The test case passes !
This is my whole test scenario. It seems it 's maven and junit's
classloader
problem.
Anybody able to find how to pass the ParserExtend's test case ? Thanks in
advanced.
