[maven2 build - FAILED] Tue Apr 19 02:07:00 EDT 2005
Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050419.020700.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED] Tue Apr 19 01:07:01 EDT 2005
Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050419.010701.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-33) Plugin development guide
[ http://jira.codehaus.org/browse/MNG-33?page=comments#action_34710 ] Brett Porter commented on MNG-33: - I say we make Dan do it since he was first to complain (I'm testing that comment mails work after JIRA upgrade) > Plugin development guide > > > Key: MNG-33 > URL: http://jira.codehaus.org/browse/MNG-33 > Project: m2 > Type: Task > Components: documentation > Reporter: Jason van Zyl > Priority: Blocker > Fix For: 2.0-alpha-2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED] Tue Apr 19 00:07:00 EDT 2005
Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050419.000700.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED] Mon Apr 18 23:07:00 EDT 2005
Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050418.230700.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-components/maven-artifact/src/main/java/org/apache/maven/artifact/manager DefaultWagonManager.java
brett 2005/04/18 19:46:08
Modified:maven-artifact/src/main/java/org/apache/maven/artifact/manager
DefaultWagonManager.java
Log:
start some wagon clean up
Revision ChangesPath
1.26 +10 -2
maven-components/maven-artifact/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java
Index: DefaultWagonManager.java
===
RCS file:
/home/cvs/maven-components/maven-artifact/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- DefaultWagonManager.java 13 Apr 2005 00:05:41 - 1.25
+++ DefaultWagonManager.java 19 Apr 2005 02:46:08 - 1.26
@@ -46,6 +46,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.Map;
+import java.security.NoSuchAlgorithmException;
public class DefaultWagonManager
extends AbstractLogEnabled
@@ -131,8 +132,15 @@
//}
// TODO: configure these
-wagon.addTransferListener( new ChecksumObserver( "MD5" ) );
-wagon.addTransferListener( new ChecksumObserver( "SHA-1" ) );
+try
+{
+wagon.addTransferListener( new ChecksumObserver( "MD5" ) );
+wagon.addTransferListener( new ChecksumObserver( "SHA-1" ) );
+}
+catch ( NoSuchAlgorithmException e )
+{
+throw new TransferFailedException( "Unable to add checksum
methods", e );
+}
try
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
payload
http://www.osjava.org/payload/index.html This seems very much related to what we were talking about with respect to filtering - applying deployment profiles to previously built artfiacts. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS] Mon Apr 18 20:07:00 EDT 2005
Distribution: http://www.codehaus.org/~maven/m2/m2-20050418.200700.tar.gz Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050418.200700.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-components/maven-core/src/site/apt offline-mode.apt
jdcasey 2005/04/18 16:15:25 Modified:maven-core/src/site/apt offline-mode.apt Log: posting an update that represents changes in the design for offline mode, back to being more similar to m1's concept of it. Revision ChangesPath 1.5 +15 -0 maven-components/maven-core/src/site/apt/offline-mode.apt Index: offline-mode.apt === RCS file: /home/cvs/maven-components/maven-core/src/site/apt/offline-mode.apt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- offline-mode.apt 18 Apr 2005 21:50:55 - 1.4 +++ offline-mode.apt 18 Apr 2005 23:15:25 - 1.5 @@ -8,6 +8,21 @@ Offline Mode Design +* UPDATE: 18-April-2005 + + We cannot take the approach outlined below of detecting which remote + repositories are "really" offline, since offline mode is more of a behavior, + and this will lead to counter-intuitive results. A different feature may exist + unimplemented, which is to detect when the network is down and provide better + feedback for that case. However, when offline mode is declared, nothing + earmarked as remote should be accessed, regardless of whether it is actually + a physically local resource. + + NOTE: One side-effect of this design change is that all offline-mode code can + be isolated to maven-core, maven-plugin-descriptor, and [possibly] + maven-artifact. Usage of maven-wagon will be determined by an offline-aware + manager. + * Assumptions: What is Offline? For the purposes of determining the areas sensitive to offline status, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS] Mon Apr 18 18:07:00 EDT 2005
Distribution: http://www.codehaus.org/~maven/m2/m2-20050418.180700.tar.gz Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050418.180700.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-components/maven-core/src/main/java/org/apache/maven DefaultMaven.java
jdcasey 2005/04/18 14:50:55
Modified:maven-core/src/main/java/org/apache/maven/project
DefaultMavenProjectBuilder.java
maven-core/src/test/java/org/apache/maven/plugin
PluginParameterExpressionEvaluatorTest.java
maven-settings settings.mdo
maven-core-it/it0015 pom.xml
maven-core/src/main/java/org/apache/maven/cli MavenCli.java
maven-core/src/main/java/org/apache/maven/settings
MavenSettingsBuilder.java
DefaultMavenSettingsBuilder.java
maven-core/src/main/java/org/apache/maven/execution
MavenExecutionRequest.java MavenSession.java
DefaultMavenExecutionRequest.java
maven-core/src/site/apt offline-mode.apt
maven-core/src/main/java/org/apache/maven/plugin
DefaultPluginManager.java
maven-core-it/it0015/src/main/scripts/org/apache/maven/it0015
it0015.mmld
maven-core/src/test/java/org/apache/maven MavenTestCase.java
maven-core/src/test/java/org/apache/maven/project
ProjectClasspathTest.java
maven-core/src/main/java/org/apache/maven/artifact/repository
ArtifactRepositoryFactory.java
DefaultArtifactRepositoryFactory.java
maven-core/src/main/java/org/apache/maven/lifecycle
DefaultLifecycleExecutor.java
maven-plugin-descriptor/src/main/java/org/apache/maven/plugin/descriptor
MojoDescriptor.java
maven-core/src/main/java/org/apache/maven DefaultMaven.java
Added: maven-core/src/test/resources/local-repo marker.txt
Removed: maven-core/src/main/java/org/apache/maven/settings
MavenSettings.java
Log:
o Refactored the MavenSettings code into the settings.mdo/Settings class.
o Added code to cache the active proxy and profile inside the Settings
instance for quicker lookup.
o Added a method to initialize a new active profile for a Settings instance
in the event one didn't exist.
o Started adding offline mode. So far, I've implemented:
- Warning when a mojo declares a requirement for connectivity, but we're
offline.
- INFO message stating when maven is running in offline mode.
- Addition to the Profile class in o.a.m.settings package to allow
specification of offline mode by declaring: true
Revision ChangesPath
1.66 +38 -4
maven-components/maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java
Index: DefaultMavenProjectBuilder.java
===
RCS file:
/home/cvs/maven-components/maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- DefaultMavenProjectBuilder.java 8 Apr 2005 05:13:10 - 1.65
+++ DefaultMavenProjectBuilder.java 18 Apr 2005 21:50:54 - 1.66
@@ -39,8 +39,8 @@
import org.apache.maven.project.path.PathTranslator;
import org.apache.maven.project.validation.ModelValidationResult;
import org.apache.maven.project.validation.ModelValidator;
-import org.apache.maven.settings.MavenSettings;
import org.apache.maven.settings.MavenSettingsBuilder;
+import org.apache.maven.settings.Settings;
import org.codehaus.plexus.PlexusConstants;
import org.codehaus.plexus.PlexusContainer;
import
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
@@ -125,6 +125,19 @@
// Always cache files in the source tree over those in the repository
modelCache.put( createCacheKey( model.getGroupId(),
model.getArtifactId(), model.getVersion() ), model );
+
+Settings settings = null;
+
+try
+{
+settings = mavenSettingsBuilder.buildSettings();
+}
+catch ( Exception e )
+{
+throw new ProjectBuildingException( "Cannot read settings.", e );
+}
+
+boolean systemOnline = !settings.getActiveProfile().isOffline();
MavenProject project = build( model, localRepository,
resolveDependencies );
@@ -146,6 +159,17 @@
ArtifactRepository
localRepository )
throws ProjectBuildingException
{
+Settings settings = null;
+
+try
+{
+settings = mavenSettingsBuilder.buildSettings();
+}
+catch ( Exception e )
+{
+throw new ProjectBuildingException( "Cannot read settings.", e );
+}
+
M
Re: commit privs for dan diephouse
+1 Jason van Zyl wrote: >Howdy, > >Dan is working on the SOAP interface for Continuum and I'd like to just >grant him access to work on this stuff. > >+1 > > >
Re: [M2] filter definition
Maczka Michal wrote: >I a not 100% sure if I understand you. >What do you mean by deployment process here? Is it going to be >supported/executed in m2? > > Yes, what we were talking about covers your use case, you'd just need to run your deployment profiles over the artifacts and store them wherever is suitable to later retrieve them and distribute them. Maybe a layered repository approach would be helpful here, where you copy the relevant artifacts to change and build a small repository of them that they can use, and for the standard stuff the base repository is used. Just thinking out loud, but it all fits together with what we were thinking. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commit privs for dan diephouse
Howdy, Dan is working on the SOAP interface for Continuum and I'd like to just grant him access to work on this stuff. +1 -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
RE: [M2] filter definition
I've done something similar to Vincent's approach but extended it with distributed configuration files. A project can publish its configuration as a jar file that contains a properties file per environment. The configuration jar gets downloaded like any other dependency. When "filter.file=true" is found within a dependency's properties, the jar is extracted and the appropriate configuration is loaded for filtering. I have found this to be useful in large project settings where one project's configuration (e.g a Web service end-point) is used by multiple projects. It avoids ensuring that a trivial modification is propagated across all teams. I've installed a blog so you can take a look at the Jelly script. http://lacesco.com/blog/ Best regards, Thomas -Original Message- From: Maczka Michal [mailto:[EMAIL PROTECTED] Sent: lundi 18 avril 2005 16:02 To: 'Maven Developers List' Subject: RE: [M2] filter definition > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Monday, April 18, 2005 1:53 AM > To: Maven Developers List > Subject: Re: [M2] filter definition > > > Jason van Zyl wrote: > > >>Here's the full URL: http://www.jconfig.org/ConfigurationServer.html > >> > >> > > > >Cool! I'll take a look and try to integrate it into what I'm making. > > > > > Yeah, I think we are all on the same page now. > almost :) > - Build a single archive > - swizzle J2EE files that need to be changed for deployment, > as part of > the deployment process, not the build process > I a not 100% sure if I understand you. What do you mean by deployment process here? Is it going to be supported/executed in m2? In a place where I am working we often follow the following scenario: There is one person resposible to prepare deployment artifacts. Some other person is verifing if everything is OK and is transfering those artifacts to CDs which are later taken to the customer. Alternativly they are transferd to the customer via ftp/ssh. Third person is responsible of physical deployment of those artifacts at the customer site. And this may happen weeks or even months after the artifacts were prepared (built). It may also happen in the place where there is not a chance that they will let you use any extra tool (so maven ant and such tools are excluded). So as you can see in my case really build process is completly seperated from deployment process but during the deployment process we are not allowed to change any artifacts. As we try to deploy more and more artifacts for each customer to our artifact repository - it makes it possible to do some cool things and for example we are exeprimenting with incremental updates and hoping to soon have a possibility of transfering to the clients just very small archives which contains the files, which have changed since the last deployment. This is possible as we know what we have deployed (historical version are stored in the repoitory) and what we have to deploy. So from my experince the communication via artifact repositories (e.g. maven repositories) and the requirment that build process on output must deploy ready (or almost ready to use) artifacts to repositoriy(ies) realy is a key and works quite well. This also requires that each artifact must have unique name - so the rule one project - one artifact has to be followed. So for example Vincent's solution: --- project1 |_ src/resources |_ env1 |_ [files or env1] |_ envN |_ [files or envN] |_ shared |_ [files shared by all envs] |_ [...] And then having the logic to choose the resource files based on a env.name=env1|envN property. -- is not something which we can use as artifacts for different environments will replace each other in local/remote repository. I don't think that my scenario is the only valid one it is one and most likely some other case (simpler or more complex) may require completely different solutions (e.g. the one described by Jason and Vincent). But I don't think that there is too many such cases. And I am sure there is a lot of "private" existing m1 plugins which were never published, which support those use cases. So it is not like we are exploring new lands - just nothing was shared and standarized in that domain :). best regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPECLIPSE-90) Backslash in generated .classpath
Backslash in generated .classpath - Key: MPECLIPSE-90 URL: http://jira.codehaus.org/browse/MPECLIPSE-90 Project: maven-eclipse-plugin Type: Bug Versions: 1.9 Environment: Windows Reporter: Per Ejeklint If maven-eclipse is run on Windows, and there are src or output paths that have more than one folder level, the generated .classpath file will contain backslashes in classpathentries kind="src" and "output". This .classpath file will not work on non-Windows systems. A solution could be to tokenise the read src and output paths with "\" as separator and put them together properly again. But maybe there is another place to do this so ALL jelly scripts get proper slashes... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-226) need to be able to dynamically register providers for wagon, scm, scripting
[ http://jira.codehaus.org/browse/MNG-226?page=comments#action_32130 ] John Casey commented on MNG-226: Came back around to this issue again, to see what the specific problem is. I looked in the code, and it's already doing a lookup on the container per-call to the getWagon() method, so it should be able to use dynamically-added wagons. What is the specific problem WRT DefaultWagonManager and wagon lookup? > need to be able to dynamically register providers for wagon, scm, scripting > --- > > Key: MNG-226 > URL: http://jira.codehaus.org/browse/MNG-226 > Project: m2 > Type: Bug > Components: design > Reporter: Brett Porter > Assignee: John Casey > Fix For: 2.0-alpha-2 > > > currently, only what is a dependency on the using plugin, or in maven2/lib is > used. Need to be able to add these on the fly - perhaps this is a plexus > artifact container thing that can register certain roles with > groupID/artifactId patterns so a hint of "file" can always go and get > wagon-file? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-226) need to be able to dynamically register providers for wagon, scm, scripting
[ http://jira.codehaus.org/browse/MNG-226?page=comments#action_32126 ] John Casey commented on MNG-226: This issue is blocked by the same problem which caused problems with the assembly plugin, namely that class realms are getting mixed up. One plugin loads a component, and that component stays in the container even after that plugin is finished executing. Then, a second plugin comes along with a requirement on the same (pre-loaded this time) component. This time, the container uses the component defined from the last plugin's execution, which means that the current plugin and the component which has been wired to it have incompatible class realms. The specific case for scripting language support means that the component factory doesn't have access to the scripts, taglibs, etc. which are defined in this current plugin, since it cannot use the classloader to discover scripting parts inside the plugin (the plugin and component-factory have sibling, and isolated, class realms). Until we have a better way of really sharing components inside of plexus, including shared classloading, etc. for loaded components, this will remain a problem. > need to be able to dynamically register providers for wagon, scm, scripting > --- > > Key: MNG-226 > URL: http://jira.codehaus.org/browse/MNG-226 > Project: m2 > Type: Bug > Components: design > Reporter: Brett Porter > Assignee: John Casey > Fix For: 2.0-alpha-2 > > > currently, only what is a dependency on the using plugin, or in maven2/lib is > used. Need to be able to add these on the fly - perhaps this is a plexus > artifact container thing that can register certain roles with > groupID/artifactId patterns so a hint of "file" can always go and get > wagon-file? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] filter definition
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Monday, April 18, 2005 1:53 AM > To: Maven Developers List > Subject: Re: [M2] filter definition > > > Jason van Zyl wrote: > > >>Here's the full URL: http://www.jconfig.org/ConfigurationServer.html > >> > >> > > > >Cool! I'll take a look and try to integrate it into what I'm making. > > > > > Yeah, I think we are all on the same page now. > almost :) > - Build a single archive > - swizzle J2EE files that need to be changed for deployment, > as part of > the deployment process, not the build process > I a not 100% sure if I understand you. What do you mean by deployment process here? Is it going to be supported/executed in m2? In a place where I am working we often follow the following scenario: There is one person resposible to prepare deployment artifacts. Some other person is verifing if everything is OK and is transfering those artifacts to CDs which are later taken to the customer. Alternativly they are transferd to the customer via ftp/ssh. Third person is responsible of physical deployment of those artifacts at the customer site. And this may happen weeks or even months after the artifacts were prepared (built). It may also happen in the place where there is not a chance that they will let you use any extra tool (so maven ant and such tools are excluded). So as you can see in my case really build process is completly seperated from deployment process but during the deployment process we are not allowed to change any artifacts. As we try to deploy more and more artifacts for each customer to our artifact repository - it makes it possible to do some cool things and for example we are exeprimenting with incremental updates and hoping to soon have a possibility of transfering to the clients just very small archives which contains the files, which have changed since the last deployment. This is possible as we know what we have deployed (historical version are stored in the repoitory) and what we have to deploy. So from my experince the communication via artifact repositories (e.g. maven repositories) and the requirment that build process on output must deploy ready (or almost ready to use) artifacts to repositoriy(ies) realy is a key and works quite well. This also requires that each artifact must have unique name - so the rule one project - one artifact has to be followed. So for example Vincent's solution: --- project1 |_ src/resources |_ env1 |_ [files or env1] |_ envN |_ [files or envN] |_ shared |_ [files shared by all envs] |_ [...] And then having the logic to choose the resource files based on a env.name=env1|envN property. -- is not something which we can use as artifacts for different environments will replace each other in local/remote repository. I don't think that my scenario is the only valid one it is one and most likely some other case (simpler or more complex) may require completely different solutions (e.g. the one described by Jason and Vincent). But I don't think that there is too many such cases. And I am sure there is a lot of "private" existing m1 plugins which were never published, which support those use cases. So it is not like we are exploring new lands - just nothing was shared and standarized in that domain :). best regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant tasks to wrap maven-artifact
Hi, I've written some Ant tasks to wrap maven-artifact, so we can provide transitive dependencies, snapshots and installation/deployment to Maven 1.0 and Ant users, while still utilising Maven2 metadata and practices. Here is a sample usage, any comments? Thoughts or ideas? http://cvs.apache.org/viewcvs.cgi/maven-components/maven-artifact-ant/sample.build.xml?rev=1.1&view=markup You can test it out by running this on maven-artifact-ant: m2 package assembly:assembly cp target/*-dep.jar $ANT_HOME/lib ant -f sample.build.xml It is currently based off 2.0-alpha-1, and I'd like to make it available and documented later this week if possible. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-364) Please upload cewolf, no url available
Please upload cewolf, no url available -- Key: MAVENUPLOAD-364 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-364 Project: maven-upload-requests Type: Task Reporter: Rafael Borges Attachments: cewolf-0.10.3-bundle.jar Please upload cewolf to ibiblio. It is a JSP tag library for jfreechart. I can not follow your steps as I am not part of the development team of cewolf. Ive contact them to include uploading to ibiblio as part of their release. Attached is the required bundle for version 0.10.3 Project sites: http://sourceforge.net/projects/cewolf http://cewolf.sourceforge.net Many thanks for this -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Jar aggregation use case (was RE: cvs commit: maven-components/maven-plugins/maven-assembly-plugin/src/main/resources/assemblies jar-with-dependencies.xml)
Vincent Massol wrote on Monday, April 18, 2005 10:14 AM: > Hi Brett, > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: lundi 18 avril 2005 09:08 >> To: [EMAIL PROTECTED] >> Subject: cvs commit: maven-components/maven-plugins/maven-assembly- >> plugin/src/main/resources/assemblies jar-with-dependencies.xml > > [snip] > >> add ability to build a JAR with its dependencies unpacked inside. > > Cool. Just a question: In the cargo's build I have the following > structure: > > cargo/ > |_ core/ > |_ util/ > |_ module/ > |_ container/ > |_ ant/ > |_ samples/ > |_ ant/ > |_ java/ > > Ideally I would like that the core's pom.xml produces an > aggregated jar from util/, module/ and container/ and that > the ant/, samples/ant/ and samples/java project have a single > dependency on this aggregated jar. > > How would that work? If I type "m2 install" it will not > produce the aggregated jar as I believe it'll be done during > the assembly stage only, right? > > Of course, I could still have the other projects depend on > the individual jars but then it's not as good as they won't exercise > the generated jar. > > Any idea how this UC could be supported? javaapp ? Seriously, this is the job of the javaapp in M1. With this possibility a port of javaapp to M2 is a little hollow if it just reuses the functionality of the jar plugin, but with the aggregated jar as main artifact. OTOH I currently don't know enough about the different artifact type support of M2, but I believe you can specify a dependency. All that is left to support this is, that the aggregated jar has a different artifact type. One question to Brett though: How does the aggregation work, if two dependent artifacts come with the same classes? The aggregation must ensure, that the same classes are available as it would have been using a normal classpath i.e. the aggragation may not overwrite classes already provided by another artifact in the dependency list. A use case is my current app, that is a standalone java app running in a server environment managed with JMX. Additionally it has to access EJBs provided by an app server. In my case I have to use jboss-client-3.2.3.jar as dependency for accessing the EJBs and mx4j--2.1.1.jar for the JMX functionality. Unfortunately jboss-client-3.2.3.jar contains also a subset (!) of the classes defined by JSR3 and the app breaks if this dependency is in the classpath before the mx4j jars. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (CONTINUUM-90) Store the SCM results
[ http://jira.codehaus.org/browse/CONTINUUM-90?page=history ] Trygve Laugstol reassigned CONTINUUM-90: Assign To: Trygve Laugstol > Store the SCM results > - > > Key: CONTINUUM-90 > URL: http://jira.codehaus.org/browse/CONTINUUM-90 > Project: Continuum > Type: Improvement > Components: continuum-core > Reporter: Trygve Laugstol > Assignee: Trygve Laugstol > Fix For: 1.0-alpha-2 > > > When checking out and updating the code for a project store the result so it > can be displayed to the user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-90) Store the SCM results
Store the SCM results - Key: CONTINUUM-90 URL: http://jira.codehaus.org/browse/CONTINUUM-90 Project: Continuum Type: Improvement Components: continuum-core Reporter: Trygve Laugstol Fix For: 1.0-alpha-2 When checking out and updating the code for a project store the result so it can be displayed to the user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[maven2 build - SUCCESS] Mon Apr 18 04:07:00 EDT 2005
Distribution: http://www.codehaus.org/~maven/m2/m2-20050418.040700.tar.gz Log: http://www.codehaus.org/~maven/m2-build-logs/m2-build-log-20050418.040700.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Jar aggregation use case (was RE: cvs commit: maven-components/maven-plugins/maven-assembly-plugin/src/main/resources/assemblies jar-with-dependencies.xml)
Hi Brett, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: lundi 18 avril 2005 09:08 > To: [EMAIL PROTECTED] > Subject: cvs commit: maven-components/maven-plugins/maven-assembly- > plugin/src/main/resources/assemblies jar-with-dependencies.xml [snip] > add ability to build a JAR with its dependencies unpacked inside. Cool. Just a question: In the cargo's build I have the following structure: cargo/ |_ core/ |_ util/ |_ module/ |_ container/ |_ ant/ |_ samples/ |_ ant/ |_ java/ Ideally I would like that the core's pom.xml produces an aggregated jar from util/, module/ and container/ and that the ant/, samples/ant/ and samples/java project have a single dependency on this aggregated jar. How would that work? If I type "m2 install" it will not produce the aggregated jar as I believe it'll be done during the assembly stage only, right? Of course, I could still have the other projects depend on the individual jars but then it's not as good as they won't exercise the generated jar. Any idea how this UC could be supported? [snip] Thanks -Vincent _ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 directory structure for Multiple Modules configurable?
Hi Joachim, Joachim Schreiber wrote on Saturday, April 16, 2005 6:28 PM: [snip] > When I now check out the complete trunk in the new Maven 2 > layout I have all ejbs (sub projects/modules) in one > directory and when I start the multi-project build all ejbs > are generated with e.g. xdoclet. This takes a long time and > no advantage of the binary dependency build is available any longer. > The solution is now to delete all ejbs I do not need to > develop only for example a few modules. But this is not a > fine solution to tell your developers please check out the > trunk and after this you're allowed to delete this and this > and. It's nicer to say check out this core projects and > then the module you want to work with. > > After a checkout from a project I use in Maven 1 the > maven-eclipse-plugin to generate .classpath and .project. Is > this working with the new directory structure too? > > I hope my bad English can explain my prob clear enough?! You may tell your developers to work with a local build.properties file in the multiproject root, that contains the maven.multiproject.include (or maven.multiproject.include) property, e.g. maven.multiproject.include=\ ejb1/project.xml, \ ejb2/project.xml, \ webapp1\project.xml ... you get the idea. The value just overrides the one found in project.properties. If they check out individual subprojects only, you might even generate that entry for all locally available subprojects with a script. This way everyone can have an individual multiproject builds. Just ensure, that build.properties is excluded in the .cvsignore (this file should never be checked in anyway). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-components/maven-artifact-ant pom.xml sample.build.xml
brett 2005/04/18 00:09:16
Modified:maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant
AbstractArtifactTask.java DeployTask.java
RemoteRepository.java
maven-artifact-ant/src/main/resources/org/apache/maven/artifact/ant
antlib.xml
maven-artifact-ant pom.xml sample.build.xml
Added: maven-artifact-ant/src/main/assembly dep.xml
maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant
Authentication.java
maven-artifact-ant/src/main/resources/META-INF/plexus
components.xml
Log:
build an assembly that includes dependencies
Revision ChangesPath
1.1
maven-components/maven-artifact-ant/src/main/assembly/dep.xml
Index: dep.xml
===
dep
jar
false
target/classes
/
/
true
runtime
junit:junit
ant:ant
marmalade:marmalade-core
plexus:plexus-marmalade-factory
commons-cli:commons-cli
plexus:plexus-container-artifact
plexus:plexus-i18n
org.apache.maven:maven-script-marmalade
org.apache.maven:maven-plugin
org.apache.maven:maven-monitor
1.2 +6 -9
maven-components/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/AbstractArtifactTask.java
Index: AbstractArtifactTask.java
===
RCS file:
/home/cvs/maven-components/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/AbstractArtifactTask.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractArtifactTask.java 18 Apr 2005 04:12:35 - 1.1
+++ AbstractArtifactTask.java 18 Apr 2005 07:09:16 - 1.2
@@ -36,19 +36,16 @@
protected ArtifactRepository createArtifactRepository( LocalRepository
repository )
{
-return createArtifactRepository( "local", "file://" +
repository.getLocation(), repository.getLayout() );
+ArtifactRepositoryLayout repositoryLayout =
(ArtifactRepositoryLayout) lookup( ArtifactRepositoryLayout.ROLE,
+
repository.getLayout() );
+return new ArtifactRepository( "local", "file://" +
repository.getLocation(), repositoryLayout );
}
protected ArtifactRepository createArtifactRepository( RemoteRepository
repository )
{
-return createArtifactRepository( "remote", repository.getUrl(),
repository.getLayout() );
-}
-
-private ArtifactRepository createArtifactRepository( String id, String
url, String layout )
-{
ArtifactRepositoryLayout repositoryLayout =
(ArtifactRepositoryLayout) lookup( ArtifactRepositoryLayout.ROLE,
-
layout );
-return new ArtifactRepository( id, url, repositoryLayout );
+
repository.getLayout() );
+return new ArtifactRepository( "remote", repository.getUrl(),
repository.getAuthentication(), repositoryLayout );
}
protected Object lookup( String role )
1.2 +4 -4
maven-components/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/DeployTask.java
Index: DeployTask.java
===
RCS file:
/home/cvs/maven-components/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/DeployTask.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DeployTask.java 18 Apr 2005 04:12:35 - 1.1
+++ DeployTask.java 18 Apr 2005 07:09:16 - 1.2
@@ -18,12 +18,11 @@
import org.apache.maven.artifact.Artifact;
import org.apache.maven.artifact.DefaultArtifact;
-import org.apache.maven.artifact.installer.ArtifactInstaller;
-import org.apache.maven.artifact.repository.ArtifactRepository;
-import org.apache.maven.artifact.deployer.ArtifactDeploymentException;
import org.apache.maven.artifact.deployer.ArtifactDeployer;
+import org.apache.maven.artifact.deployer.ArtifactDeploymentException;
import org.apache.maven.artifact.metadata.ArtifactMetadata;
import org.apache.maven.artifact.metadata.MavenMetadata;
+import org.apache.maven.artifact.repository.ArtifactRepository;
import org.apache.maven.project.MavenProjectBuilder;
import org.apache.tools.ant.BuildException;
@@ -63,6 +62,7 @@
artifact.addMetadata( metadata );
cvs commit: maven-components/maven-core/src/main/resources/META-INF/plexus components.xml
brett 2005/04/18 00:08:22 Modified:maven-core/src/main/resources/META-INF/plexus components.xml Log: remove half-done declaration Revision ChangesPath 1.28 +0 -5 maven-components/maven-core/src/main/resources/META-INF/plexus/components.xml Index: components.xml === RCS file: /home/cvs/maven-components/maven-core/src/main/resources/META-INF/plexus/components.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- components.xml15 Apr 2005 04:52:30 - 1.27 +++ components.xml18 Apr 2005 07:08:21 - 1.28 @@ -233,11 +233,6 @@ - - org.codehaus.plexus.component.configurator.expression.ExpressionEvaluator - org.apache.maven. - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven-components/maven-plugins/maven-assembly-plugin/src/main/resources/assemblies jar-with-dependencies.xml
brett 2005/04/18 00:07:58
Modified:
maven-plugins/maven-assembly-plugin/src/main/java/org/apache/maven/plugin/assembly
AssemblyMojo.java
maven-plugins/maven-assembly-plugin/src/main/mdo
descriptor.mdo
Added: maven-plugins/maven-assembly-plugin/src/main/resources/assemblies
jar-with-dependencies.xml
Log:
add ability to build a JAR with its dependencies unpacked inside.
Currently ignores META-INF in dependencies, though should probably merge
things like components.xml
Revision ChangesPath
1.4 +91 -18
maven-components/maven-plugins/maven-assembly-plugin/src/main/java/org/apache/maven/plugin/assembly/AssemblyMojo.java
Index: AssemblyMojo.java
===
RCS file:
/home/cvs/maven-components/maven-plugins/maven-assembly-plugin/src/main/java/org/apache/maven/plugin/assembly/AssemblyMojo.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AssemblyMojo.java 13 Apr 2005 04:29:25 - 1.3
+++ AssemblyMojo.java 18 Apr 2005 07:07:57 - 1.4
@@ -35,14 +35,19 @@
import org.codehaus.plexus.util.IOUtil;
import java.io.File;
+import java.io.FileOutputStream;
import java.io.FileReader;
+import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.Reader;
import java.util.ArrayList;
+import java.util.Enumeration;
import java.util.Iterator;
import java.util.List;
import java.util.Set;
+import java.util.jar.JarEntry;
+import java.util.jar.JarFile;
/**
* @author mailto:[EMAIL PROTECTED]">Brett Porter
@@ -52,6 +57,7 @@
* @description assemble an application bundle or distribution
* @parameter name="basedir" type="String" required="true" validator=""
expression="#basedir" description=""
* @parameter name="outputDirectory" type="java.io.File" required="true"
validator="" expression="#project.build.directory" description=""
+ * @parameter name="workDirectory" type="java.io.File" required="true"
validator="" expression="#project.build.directory/assembly/work"
description="Directory to unpack JARs into if needed"
* @parameter name="descriptor" type="java.io.File" required="false"
validator="" expression="#maven.assembly.descriptor" description=""
* @parameter name="finalName" type="String" required="true" validator=""
expression="#project.build.finalName" description=""
* @parameter name="descriptorId" type="String" required="false"
validator="" expression="#maven.assembly.descriptorId" description=""
@@ -64,10 +70,7 @@
private String basedir;
-/**
- * @todo use java.io.File
- */
-private String outputDirectory;
+private File outputDirectory;
private File descriptor;
@@ -77,6 +80,8 @@
private Set dependencies;
+private File workDirectory;
+
public void execute()
throws PluginExecutionException
{
@@ -136,8 +141,8 @@
// TODO: use component roles? Can we do that in a mojo?
Archiver archiver = createArchiver( format );
-processFileSets( archiver, assembly.getFileSets() );
-processDependencySets( archiver,
assembly.getDependencySets() );
+processFileSets( archiver, assembly.getFileSets(),
assembly.isIncludeBaseDirectory() );
+processDependencySets( archiver,
assembly.getDependencySets(), assembly.isIncludeBaseDirectory() );
archiver.setDestFile( new File( outputDirectory, filename )
);
archiver.createArchive();
@@ -149,14 +154,14 @@
}
}
-private void processDependencySets( Archiver archiver, List
dependencySets )
-throws ArchiverException
+private void processDependencySets( Archiver archiver, List
dependencySets, boolean includeBaseDirectory )
+throws ArchiverException, IOException
{
for ( Iterator i = dependencySets.iterator(); i.hasNext(); )
{
DependencySet depedencySet = (DependencySet) i.next();
String output = depedencySet.getOutputDirectory();
-output = getOutputDirectory( output );
+output = getOutputDirectory( output, includeBaseDirectory );
AndArtifactFilter filter = new AndArtifactFilter();
filter.add( new ScopeArtifactFilter( depedencySet.getScope() ) );
@@ -176,13 +181,68 @@
if ( filter.include( artifact ) )
{
-archiver.addFile( artifact.getFile(), output +
artifact.getFile().getName() );
+String name = artifact.getFile().getName();
+if ( depedencySet.isUnpack() )
+{
