[GitHub] maven-plugins pull request: Move logs from java.lang.System.out to...
Github user velo closed the pull request at: https://github.com/apache/maven-plugins/pull/49 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-plugins pull request: Move logs from java.lang.System.out to...
GitHub user velo opened a pull request: https://github.com/apache/maven-plugins/pull/49 Move logs from java.lang.System.out to org.apache.maven.plugin.logging.Log You can merge this pull request into a Git repository by running: $ git pull https://github.com/velo/maven-plugins antrun/logs Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/49.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #49 commit 8753a9ece2273a4cdee9c35a06e8feb901279301 Author: Marvin Froeder velo...@gmail.com Date: 2015-03-13T19:20:08Z Move logs from java.lang.System.out to org.apache.maven.plugin.logging.Log --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-enforcer pull request: New enforcer for environment variables
Github user velo closed the pull request at: https://github.com/apache/maven-enforcer/pull/3 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-enforcer pull request: New enforcer for environment variables
GitHub user velo opened a pull request: https://github.com/apache/maven-enforcer/pull/3 New enforcer for environment variables http://jira.codehaus.org/browse/MENFORCER-136 You can merge this pull request into a Git repository by running: $ git pull https://github.com/velo/maven-enforcer 317a3ddf826727fbed4ceb87b87e6a72acf67781 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-enforcer/pull/3.patch commit 317a3ddf826727fbed4ceb87b87e6a72acf67781 Author: Marvin Froeder mar...@marvinformatics.com Date: 2012-08-29T05:15:27-07:00 Created environment variable enforcer - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Call one plugin from another
Hi folks, I wrote one plugin, who take one java project and generate some flex sources. Is there any way to call another plugin (in this case flex-compiler-mojo) from this generator-plugin? Any ideas? VELO
Re: [proposal] eclipse plugin extensibility
Question: The extensions, will auto-actived according with installed eclipse (don't like this idea) or I will declared on pom.xml my extensions? VELO On Wed, Apr 30, 2008 at 10:45 AM, nicolas de loof [EMAIL PROTECTED] wrote: I've created an inital proposal for this on wiki : http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility 2008/4/24 VELO [EMAIL PROTECTED]: Flex / Flex builder I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin If this goes on, I can create flexbuilder extension. VELO On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni [EMAIL PROTECTED] wrote: Hi Nicolas, yes, many Maven plugins have an Eclipse counterpart, and having the eclipse plugin discover this plugins and delegate to them the generation of eclipse specific configurations is a great idea. I don't know the internals of the Eclipse plugin well enough to understand the details of your proposal, but it sounds very interesting. Any comment from the Maven community? Just to name a few, these are the technologies that i use extensively and have both maven and eclipse support that could be harmonized: - Obviously the java compiler itself :) - The Maven eclipse plugin - AspectJ - Hibernate - Spring - Jetty (would it be possible to make some generation of configurations for Eclipse WST?) - Emma, Clover - FindBugs Which else? Simone nicolas de loof wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/version /dependency /dependencies /plugin Beeing added to the plugin classpath, the plugin-extension could add it's EclipseWriters, and maybe other optional components (to setup ProjectNatures ?). Many other extensions could be added this way to the eclipse plugin : generate SpringIDE configuration, setup Checkstyle in sync with the maven-checkstyle configuration, etc. Another benefict is that the extension could benefict from the forked generate-source execution that the eclipse-plugin runs, to access the list of multi-project modules. Any suggestion is welcome. Nicolas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
Great, Count on me for flexbuilder support. VELO On Wed, Apr 30, 2008 at 10:58 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote: both of them. If you specify your workspace location, the plugin will try to auto-detect your features plugins and if it find contributors compatible with them it will generate appropriate settings. If not, you'll have to specify them (like is actually with properties like wtpversion or custom goals like rad6, myeclipse, ...) Arnaud On Wed, Apr 30, 2008 at 3:52 PM, VELO [EMAIL PROTECTED] wrote: Question: The extensions, will auto-actived according with installed eclipse (don't like this idea) or I will declared on pom.xml my extensions? VELO On Wed, Apr 30, 2008 at 10:45 AM, nicolas de loof [EMAIL PROTECTED] wrote: I've created an inital proposal for this on wiki : http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility 2008/4/24 VELO [EMAIL PROTECTED]: Flex / Flex builder I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin If this goes on, I can create flexbuilder extension. VELO On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni [EMAIL PROTECTED] wrote: Hi Nicolas, yes, many Maven plugins have an Eclipse counterpart, and having the eclipse plugin discover this plugins and delegate to them the generation of eclipse specific configurations is a great idea. I don't know the internals of the Eclipse plugin well enough to understand the details of your proposal, but it sounds very interesting. Any comment from the Maven community? Just to name a few, these are the technologies that i use extensively and have both maven and eclipse support that could be harmonized: - Obviously the java compiler itself :) - The Maven eclipse plugin - AspectJ - Hibernate - Spring - Jetty (would it be possible to make some generation of configurations for Eclipse WST?) - Emma, Clover - FindBugs Which else? Simone nicolas de loof wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/version /dependency /dependencies /plugin Beeing added to the plugin classpath, the plugin-extension could add it's EclipseWriters, and maybe other optional components (to setup ProjectNatures ?). Many other extensions could be added this way to the eclipse plugin : generate SpringIDE configuration, setup Checkstyle in sync with the maven-checkstyle configuration, etc. Another benefict is that the extension could benefict from the forked generate-source execution that the eclipse-plugin runs, to access the list of multi-project modules. Any suggestion is welcome. Nicolas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can plugins be extended?
I use it, works!
VELO
On Tue, Apr 29, 2008 at 11:45 AM, Benoit Decherf [EMAIL PROTECTED]
wrote:
Here is the plugin:
http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/
Benoit
Brian E. Fox wrote:
Plugins can't really be extended. What is most likely happening is that
the metadata that tells plexus what to inject is not included in your
plugin. There is a plugin/tool out there that supposedly allows you to
extend plugins by merging the metadata, but I forget the name.
-Original Message-
From: walid joseph Gedeon [mailto:[EMAIL PROTECTED] Sent: Tuesday,
April 29, 2008 10:37 AM
To: Maven Developers List
Subject: Can plugins be extended?
Hello all,
After failing to customize the compiler pluging (by passing
compileSourceRoots / in the maven-compiler-plugin configuration /);
I've
went onto trying to extend the maven-compiler-plugin CompileMojo to just
set
that variable.
It looks like I've missed something: the injected parameters of the
super
classes are not being set (e.g. the parameter compilerId, or the
component
compilerManager in AbstractCompilerMojo are null).
Is there a flag that enables injection of parameters in super classes?
Or is
the issue something else?
Thanks :-)
Walid.
Note: a component definition maps the custom-compile goal to the
compile /
phase.
ox maven-customcompile-plugin Mojo: xo
/**
* @goal custom-compile
* @phase compile
* @requiresDependencyResolution runtime
*/
public class CustomCompilerMojo extends CompilerMojo {
// ...
/**
* @parameter
*/
private ListString compileSourceRoots;
protected ListString getCompileSourceRoots()
{
return compileSourceRoots;
}
public void execute() throws MojoExecutionException,
CompilationFailureException
{
super.execute();
}
}
ox Project POM: xo
!-- ... --
build
plugins
plugin
groupIdfr.gedeon/groupId
artifactIdmaven-customcompile-plugin/artifactId
extensionstrue/extensions
configuration
compileSourceRoots
directoryDev/src/java/directory
/compileSourceRoots
/configuration
/plugin
/plugins
/build
ox Partial Trace: xo
[DEBUG] Configuring mojo
'fr.gedeon:maven-customcompile-plugin:1.0-SNAPSHOT:custom-compile' --
[DEBUG] (f) compileSourceRoots = [Dev/src/java]
[DEBUG] (f) project = [EMAIL PROTECTED]
[DEBUG] -- end configuration --
[INFO] [bem:custom-compile]
[DEBUG] Using compiler 'null'.
^ this is from getLog().debug( Using compiler ' + compilerId +
'. );
in AbstractCompilerMojo
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[DEBUG] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:267)
^ I suppose this is compiler = compilerManager.getCompiler(
compilerId );
with compilerManager = null
at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114)
at
org.apache.maven.plugin.CompileBemMojo.execute(CompileBemMojo.java:37)
...
Re: Can plugins be extended?
Try add type to dependency:
typemaven-plugin/type
VELO
On Tue, Apr 29, 2008 at 1:46 PM, walid joseph Gedeon [EMAIL PROTECTED]
wrote:
It seems to want to do what I need... but I can't seem to get rid of this
error:
[ERROR] BUILD ERROR
[INFO]
[INFO] maven-compiler-plugin plugin is not a dependency
eventhough I do have it in my pom...
dependency
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0.2/version
/dependency
Looking at the code, it seems to also want to allow compiler, but tried
that too with no luck...
Still digging, but if anyone has an idea, all hints are appreciated :-)
W
On Tue, Apr 29, 2008 at 6:39 PM, VELO [EMAIL PROTECTED] wrote:
I use it, works!
VELO
On Tue, Apr 29, 2008 at 11:45 AM, Benoit Decherf [EMAIL PROTECTED]
wrote:
Here is the plugin:
http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/
Benoit
Brian E. Fox wrote:
Plugins can't really be extended. What is most likely happening is
that
the metadata that tells plexus what to inject is not included in
your
plugin. There is a plugin/tool out there that supposedly allows you
to
extend plugins by merging the metadata, but I forget the name.
-Original Message-
From: walid joseph Gedeon [mailto:[EMAIL PROTECTED] Sent: Tuesday,
April 29, 2008 10:37 AM
To: Maven Developers List
Subject: Can plugins be extended?
Hello all,
After failing to customize the compiler pluging (by passing
compileSourceRoots / in the maven-compiler-plugin configuration
/);
I've
went onto trying to extend the maven-compiler-plugin CompileMojo to
just
set
that variable.
It looks like I've missed something: the injected parameters of the
super
classes are not being set (e.g. the parameter compilerId, or the
component
compilerManager in AbstractCompilerMojo are null).
Is there a flag that enables injection of parameters in super
classes?
Or is
the issue something else?
Thanks :-)
Walid.
Note: a component definition maps the custom-compile goal to the
compile /
phase.
ox maven-customcompile-plugin Mojo: xo
/**
* @goal custom-compile
* @phase compile
* @requiresDependencyResolution runtime
*/
public class CustomCompilerMojo extends CompilerMojo {
// ...
/**
* @parameter
*/
private ListString compileSourceRoots;
protected ListString getCompileSourceRoots()
{
return compileSourceRoots;
}
public void execute() throws MojoExecutionException,
CompilationFailureException
{
super.execute();
}
}
ox Project POM: xo
!-- ... --
build
plugins
plugin
groupIdfr.gedeon/groupId
artifactIdmaven-customcompile-plugin/artifactId
extensionstrue/extensions
configuration
compileSourceRoots
directoryDev/src/java/directory
/compileSourceRoots
/configuration
/plugin
/plugins
/build
ox Partial Trace: xo
[DEBUG] Configuring mojo
'fr.gedeon:maven-customcompile-plugin:1.0-SNAPSHOT:custom-compile'
--
[DEBUG] (f) compileSourceRoots = [Dev/src/java]
[DEBUG] (f) project =
[EMAIL PROTECTED]
[DEBUG] -- end configuration --
[INFO] [bem:custom-compile]
[DEBUG] Using compiler 'null'.
^ this is from getLog().debug( Using compiler ' +
compilerId +
'. );
in AbstractCompilerMojo
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[DEBUG] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:267)
^ I suppose this is compiler =
compilerManager.getCompiler(
compilerId );
with compilerManager = null
at
org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114)
at
org.apache.maven.plugin.CompileBemMojo.execute(CompileBemMojo.java:37)
...
Re: [proposal] eclipse plugin extensibility
Flex / Flex builder I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin If this goes on, I can create flexbuilder extension. VELO On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni [EMAIL PROTECTED] wrote: Hi Nicolas, yes, many Maven plugins have an Eclipse counterpart, and having the eclipse plugin discover this plugins and delegate to them the generation of eclipse specific configurations is a great idea. I don't know the internals of the Eclipse plugin well enough to understand the details of your proposal, but it sounds very interesting. Any comment from the Maven community? Just to name a few, these are the technologies that i use extensively and have both maven and eclipse support that could be harmonized: - Obviously the java compiler itself :) - The Maven eclipse plugin - AspectJ - Hibernate - Spring - Jetty (would it be possible to make some generation of configurations for Eclipse WST?) - Emma, Clover - FindBugs Which else? Simone nicolas de loof wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/version /dependency /dependencies /plugin Beeing added to the plugin classpath, the plugin-extension could add it's EclipseWriters, and maybe other optional components (to setup ProjectNatures ?). Many other extensions could be added this way to the eclipse plugin : generate SpringIDE configuration, setup Checkstyle in sync with the maven-checkstyle configuration, etc. Another benefict is that the extension could benefict from the forked generate-source execution that the eclipse-plugin runs, to access the list of multi-project modules. Any suggestion is welcome. Nicolas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting resources
Thinking MavenProject has the list of resources, right? http://maven.apache.org/ref/2.0.4/maven-project/apidocs/org/apache/maven/project/MavenProject.html#getResources() So, exists any kind of dependency/plugin/whatever who allow me to define the dependency A must be maped into resources list? VELO On Thu, Apr 17, 2008 at 4:51 PM, Sebastien ARBOGAST [EMAIL PROTECTED] wrote: But how can I choose specifically this one and not unpack all the other dependencies in the same place. I didn't find any configuration showing that level of granularity. 2008/4/17, Brian E. Fox [EMAIL PROTECTED]: You can use dependency:unpack/unpack-dependencies to retrieve them and put 'em were you need 'em -Original Message- From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 3:40 PM To: Maven Developers List; [EMAIL PROTECTED] Subject: Re: Inheriting resources I've been trying to make it work with assembly plugin but configuration is quite heavy. I manage to archive my configuration files in a zip file, but then how do I configure the other modules to unpack the archive (just this one) to the right directory? Far too much hassle. I'm starting to think that duplicating those configuration files is like the least bad solution. 2008/4/14, VELO [EMAIL PROTECTED]: At current stage flex-compiler-plugin look at all resources folder (project.getBuild().getResources()) for configuration files. Is possible too specify some relative path, such as .../.../anotherProject/src/main/resources/config.xml But this has a lot of problems,.. VELO On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I think there could be some value to making resource sharing a little easier out of the box. Naturally it won't fit all instances but those other instances can already be solved with assembly and or remote-resources We currently package up the site descriptor for a parent and that gets inherited by the children. I think we could leverage the remote-resources and do something similar. If you put files in the src/main/resources of a pom, we could automatically pick those up and deploy them as a resource bundle. Then in the children we could augment the resources model to specify to inherit the resources from the parents and the plugin could be smart enough to find them on the disk or from the repo. -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Sunday, April 13, 2008 6:06 AM To: Maven Developers List Subject: Re: Inheriting resources Sebastien ARBOGAST wrote: I would like to find a natural solution to share confirguration files between two modules. [...] For now, the only solution I've found is to duplicate those files in src/main/resources for each module. Brian suggested that I could put those files in a third module to package them up using assembly, and then retrieve these in both modules that need it. But it doesn't seem very natural to me. As a matter of fact, I don't think that this use case is very rare. I mean, there are situatiosn where you want to reuse icon graphics or configuration files in several modules. And it would be great if we could place those resources in the parent module and have the submodules inherit resources from their parent. What do you think? Would it be feasible? Would it be okay with best practices promoted by Maven? I'm used to think of projects as independent build units. More precisely, I expect the following to work: - checkout an arbitrary project/module, i.e. not necessarily a whole trunk - run any build command on this checkout, it should succeed Now, if I checked out one of your sub-modules how should it inherit its resources from the parent which is not on my local disk? Maven can retrieve the POM and the site descriptor from the remote repo but anything else (like resources) from the parent project is not shared via the repo. For the above reason, you would need to package the resources up into a JAR that can be deployed to the repos. Maybe your resources need filtering before their packaging and now you're quite there what is known as a jar packaging. That is just as Brian suggested, a separate module. And I believe this is right because sharing POM configuration and sharing resources seem two different aspects, hence separation of concerns. Finally note that project inheritance suffers from the same drawback as class inheritance in ordinary programming: What if you ever needed your resources in projects that do not inherit from a common parent? Shift it up the parent
Re: Inheriting resources
At current stage flex-compiler-plugin look at all resources folder (project.getBuild().getResources()) for configuration files. Is possible too specify some relative path, such as .../.../anotherProject/src/main/resources/config.xml But this has a lot of problems,.. VELO On Mon, Apr 14, 2008 at 12:09 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I think there could be some value to making resource sharing a little easier out of the box. Naturally it won't fit all instances but those other instances can already be solved with assembly and or remote-resources We currently package up the site descriptor for a parent and that gets inherited by the children. I think we could leverage the remote-resources and do something similar. If you put files in the src/main/resources of a pom, we could automatically pick those up and deploy them as a resource bundle. Then in the children we could augment the resources model to specify to inherit the resources from the parents and the plugin could be smart enough to find them on the disk or from the repo. -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Sunday, April 13, 2008 6:06 AM To: Maven Developers List Subject: Re: Inheriting resources Sebastien ARBOGAST wrote: I would like to find a natural solution to share confirguration files between two modules. [...] For now, the only solution I've found is to duplicate those files in src/main/resources for each module. Brian suggested that I could put those files in a third module to package them up using assembly, and then retrieve these in both modules that need it. But it doesn't seem very natural to me. As a matter of fact, I don't think that this use case is very rare. I mean, there are situatiosn where you want to reuse icon graphics or configuration files in several modules. And it would be great if we could place those resources in the parent module and have the submodules inherit resources from their parent. What do you think? Would it be feasible? Would it be okay with best practices promoted by Maven? I'm used to think of projects as independent build units. More precisely, I expect the following to work: - checkout an arbitrary project/module, i.e. not necessarily a whole trunk - run any build command on this checkout, it should succeed Now, if I checked out one of your sub-modules how should it inherit its resources from the parent which is not on my local disk? Maven can retrieve the POM and the site descriptor from the remote repo but anything else (like resources) from the parent project is not shared via the repo. For the above reason, you would need to package the resources up into a JAR that can be deployed to the repos. Maybe your resources need filtering before their packaging and now you're quite there what is known as a jar packaging. That is just as Brian suggested, a separate module. And I believe this is right because sharing POM configuration and sharing resources seem two different aspects, hence separation of concerns. Finally note that project inheritance suffers from the same drawback as class inheritance in ordinary programming: What if you ever needed your resources in projects that do not inherit from a common parent? Shift it up the parent chain until you reach a common ancestor and pollute the resources for all children below? I would rather take the composition approach and package your resources into an independent project/JAR that other projects can put on their class path if needed. Just my two cents, Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support for Adobe Flex
Hi guys, Talking with Shane Isbell some day ago, about NMaven. How it starts, how get involved with maven on apache and so go on. Well, I wanna know if exists any interest from Maven Project/Apache Foundation to provide any official support for Adobe Flex. And, if I can submit flex-mojos as an implementation for this official support. I'm not sure how to start this conversation. But I'm putting this idea on the table. Well, I will wait for some feedback. VELO
Re: Inheriting resources
I like this Idea
Some resources packaging.
If its not possible, we can create a simple mojo on flex-mojos, only to
handle configurations. What you think?
VELO
On Sun, Apr 13, 2008 at 3:49 PM, Sebastien ARBOGAST
[EMAIL PROTECTED] wrote:
Now I think I understand what you mean by something similar. The main
problem I see with using the assembly plugin is the amount of
configuration
needed for packaging and depackaging of resources to work. Indeed, if it
was
possible to specify an dependency as overlaid instead of included, this
would simplify depackaging resources. But then you could not just package
those resources in a mere JAR, otherwise how could you differentiate
included JARs and overlaid JARs. The maven war plugin automatically
overlays
WAR dependencies and includes JAR dependencies.
So here's my proposition:
- modules containing only resources have their packaging set to resource
- such modules are automatically packaged in a zip format
- when specifying a zip dependency in any module (jar or war packaging),
it's overlaid instead of being included
Is it already possible AND simple to configure?
If not is it a better practice?
Does it require new development? (in which case this discussion is good
for
the development list)
2008/4/13, Tim O'Brien [EMAIL PROTECTED]:
Even though we happen to all be developers, this discussion may be more
appropriate on the users list.
Sebastien, have you looked at the overlay feature of the WAR plugin?
http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html
Are you proposing that a similar idea be generalized for other projects?
I know this still might no fit your definition of reasonable, but it
might
just be what you were looking for.
Tim
On Apr 13, 2008, at 11:56 AM, Sejal Patel wrote:
Hi Sebastien, you are right that this is a common problem and has no
clean
solution. Partly because of this limitation, at my job I've instituted
some
rules as part of the project standards. Any resources instead of
being
placed in the src/main/resources are now placed in src/main/packages
and
I've written a custom plugin that goes through and does a few things
actually but one thing is to create the same artifact jar with a
different
classifier called ${artifactId}-${version}-external-${envName}.jar
in
our
case for externalized resources.
The custom plugin also allows you to do either a -Denv=foo to
automatically
filter the src/main/package with a filter located in the
src/main/filters.
For instance -Denv=prod would filter using
src/main/filters/prod.properties.
This would produce a classifier called
${artifactId}-${version}-external-prod.jar
It also supports doing a -Dfilter=~/myfilters/custom.properties to
allow
filtering of the src/main/package contents with individual filterings.
This
would produce a classifier called
${artifactId}-${version}-external-${user.name}.jar
In both cases filtering values default to
src/main/filters/default.properties
What this does is allow you to treat resources as external
configurations of
sorts and still allows you to filter them on an environment level
(test,
dev, qa, ref, prod, etc ) which are stored in the repository as
well
as
local developer filtering which sits only on the developers machine
and
doesn't clutter the filters with 30 different custom filters that are
only
meaningful to a single person.
And as a general rule of thumb, we mark that resource in the pom.xml
as
a
scope of provided in order to prevent the wrong configurations from
being
pushed out to the wrong environments and such. And the pom.xml
contains
the
test filtered in the test scope for use with unit tests.
So our base project will contain the shared resources and the
modules
will
include the base projects external-test classified resource within
them
for
use with testing and such. Modules which produce applications (stand
alone
or web) include the external-default as a provided and/or rely on
assembly
to pull in the correct one to be used.
On Sun, Apr 13, 2008 at 5:31 AM, Sebastien ARBOGAST
[EMAIL PROTECTED] wrote:
Hi guys,
I've had a comment exchange on my blog with Brian Fox (
http://sebastien-arbogast.com/index.php/2008/04/11/flex-spring-and-blazeds-the-full-stack-part-2/#comment-126
)
because I would like to find a natural solution to share
confirguration
files between two modules. In this case, I'm building a
Flex+BlazeDS+Spring
applications with two modules, one for the flex part, and the other
one
for
the web application. And both of those modules need the same
configuration
files.
For now, the only solution I've found is to duplicate those files in
src/main/resources for each module.
Brian
Re: [VOTE] POM Element for Source File Encoding
+1 On Sat, Apr 5, 2008 at 2:20 PM, Hervé BOUTEMY [EMAIL PROTECTED] wrote: Hi, Since the discussion on the list about Maven and encoding 2 weeks ago, Benjamin and I worked on a proposal to have: 1. a central point of configuration of sources encoding, to be used by each and every plugin, 2. a default value set to ISO-8859-1 (instead of platform encoding) to have build reproducibility by default The full proposal is here: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding As you'll see, we've already found 8 Apache plugins to change, and 4 Codehaus ones. Before starting the code modifications, we need everybody to agree on the proposal (and complete it if you know other places to change). The vote will be open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Custom scopes
Hi guys, I'm developing a maven compiler mojo to another language (not Java, but I prefer don't reveal, at least not now). That language have more scopes (total 6). One (COMPILE) is Java like. But the others have different naming: RUNTIME on Java there is called EXTERNAL PROVIDED on Java looks like to RUNTIME on this language SYSTEM doesn't exist I wanna the same Java Scopes, but I wanna to use another name convention. How can I create my custom scope and insert they into the maven dependency mechanism? I need to do that because I have 2 types of transitive dependencies and 3 non transitive. Any one can help me? VELO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom scopes
And there is any where to say: Hey maven, I wanna change your scopes, I wanna this scopes? VELO On Fri, Mar 14, 2008 at 10:13 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: System scope doesn't exist in Java either. It's not a Java thing, but a Maven thing, and it just means that the dependency is provided at compile time by a local direct path, and that the ultimate runtime will provide the dependency. Christian. On 14-Mar-08, at 07:25 , VELO wrote: Hi guys, I'm developing a maven compiler mojo to another language (not Java, but I prefer don't reveal, at least not now). That language have more scopes (total 6). One (COMPILE) is Java like. But the others have different naming: RUNTIME on Java there is called EXTERNAL PROVIDED on Java looks like to RUNTIME on this language SYSTEM doesn't exist I wanna the same Java Scopes, but I wanna to use another name convention. How can I create my custom scope and insert they into the maven dependency mechanism? I need to do that because I have 2 types of transitive dependencies and 3 non transitive. Any one can help me? VELO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom scopes
In Flex, we have 5 scopes Merged (Like compile) External (Like provided) Include (Do compile + copy all class from this dependency into my output file) Runtime (Like provided) Caching (Like provided) I use different names to allow me call the right parameter on the compiler. I can't use all as provided because the compilation parameter not is the same. I don't know if you know Adobe Flex, is a little hard to explain without a big intro. VELO On Fri, Mar 14, 2008 at 4:50 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Why would you actually need other scopes? Don't think of scope, think of use-cases: 1. Need for both compile and in the deployed system 2. Need only for compile. 3. Need only in the deployed system 4. Provided locally for compile 5. Need only during testing What other scenarios would your other language have need for? These are the scenarios that are handled by the maven dependency scopes. Christian. On 14-Mar-08, at 10:45 , Brian E. Fox wrote: Nope, the scopes are coded into the core and most of the plugins since it's a core concept. -Original Message- From: VELO [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 9:42 AM To: Maven Developers List Subject: Re: Custom scopes And there is any where to say: Hey maven, I wanna change your scopes, I wanna this scopes? VELO On Fri, Mar 14, 2008 at 10:13 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: System scope doesn't exist in Java either. It's not a Java thing, but a Maven thing, and it just means that the dependency is provided at compile time by a local direct path, and that the ultimate runtime will provide the dependency. Christian. On 14-Mar-08, at 07:25 , VELO wrote: Hi guys, I'm developing a maven compiler mojo to another language (not Java, but I prefer don't reveal, at least not now). That language have more scopes (total 6). One (COMPILE) is Java like. But the others have different naming: RUNTIME on Java there is called EXTERNAL PROVIDED on Java looks like to RUNTIME on this language SYSTEM doesn't exist I wanna the same Java Scopes, but I wanna to use another name convention. How can I create my custom scope and insert they into the maven dependency mechanism? I need to do that because I have 2 types of transitive dependencies and 3 non transitive. Any one can help me? VELO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom scopes
But to compile, you need the SWC. Your dependency is the SWC, or am I wrong? The artifiact doesn't change. I can use the same SWC as external or as runtime or as merged So, I don't believe changing type is the right decision. VELO On Fri, Mar 14, 2008 at 5:17 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Yeah - I may do that too with the flex thing because a .swf is the normal web-deployable, but a particular dynamic linking approach (called Remote Shared Libraries) uses .swf files as libraries. I may force it by using a swf-rsl packaging type, but I haven't completely figured that out. Christian. On 14-Mar-08, at 16:14 , Shane Isbell wrote: I'm not sure the specifics of VELOs problem but I have run into some issues with NMaven for .NET support. There may be cases (like netmodules, or linking of assemblies) where you don't want transitive dependencies, they need to be direct. So it is up to the plugins to decide if artifactType[x]:compile is transtive or not. It is the same scope but the behavior is different depending on artifact type. There are also issues such as the Global Assembly Cache. In this case, I use a provided scope but when the plugins see an artifact dependency with dotnet:gac_msil type, they know to treat it differently. So the key is not to change scopes but to change the artifact type of the dependency to handle different behavior of the scope. Shane On Fri, Mar 14, 2008 at 12:50 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Why would you actually need other scopes? Don't think of scope, think of use-cases: 1. Need for both compile and in the deployed system 2. Need only for compile. 3. Need only in the deployed system 4. Provided locally for compile 5. Need only during testing What other scenarios would your other language have need for? These are the scenarios that are handled by the maven dependency scopes. Christian. On 14-Mar-08, at 10:45 , Brian E. Fox wrote: Nope, the scopes are coded into the core and most of the plugins since it's a core concept. -Original Message- From: VELO [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 9:42 AM To: Maven Developers List Subject: Re: Custom scopes And there is any where to say: Hey maven, I wanna change your scopes, I wanna this scopes? VELO On Fri, Mar 14, 2008 at 10:13 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: System scope doesn't exist in Java either. It's not a Java thing, but a Maven thing, and it just means that the dependency is provided at compile time by a local direct path, and that the ultimate runtime will provide the dependency. Christian. On 14-Mar-08, at 07:25 , VELO wrote: Hi guys, I'm developing a maven compiler mojo to another language (not Java, but I prefer don't reveal, at least not now). That language have more scopes (total 6). One (COMPILE) is Java like. But the others have different naming: RUNTIME on Java there is called EXTERNAL PROVIDED on Java looks like to RUNTIME on this language SYSTEM doesn't exist I wanna the same Java Scopes, but I wanna to use another name convention. How can I create my custom scope and insert they into the maven dependency mechanism? I need to do that because I have 2 types of transitive dependencies and 3 non transitive. Any one can help me? VELO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom scopes
Just a clarification, For now, deployment isn't my first concern. Now I'm 100% focused on build the SWF (I know, I need to think in future) I think Shane has a good point. If exists any planning to maven supports another languages, some changes are need. Some scope doesn't make sense on Java, but do on Flex, .Net, Ruby, MyHouseLanguage... How can I keep in touch for these generalizations? VELO On Fri, Mar 14, 2008 at 5:46 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: I agree, I just hadn't yet thought through how to handle deployment. Especially since a .swc is a .swf with a manifest file in a zip file, it doesn't entirely map to the maven artifact concept of one-artifact- per-project. Maybe as a classifier... Hmmm. Anyway, we should take this flex-specific stuff off the maven dev list unless there's actual questions about maven mechanics. Christian. On 14-Mar-08, at 16:42 , VELO wrote: But to compile, you need the SWC. Your dependency is the SWC, or am I wrong? The artifiact doesn't change. I can use the same SWC as external or as runtime or as merged So, I don't believe changing type is the right decision. VELO On Fri, Mar 14, 2008 at 5:17 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Yeah - I may do that too with the flex thing because a .swf is the normal web-deployable, but a particular dynamic linking approach (called Remote Shared Libraries) uses .swf files as libraries. I may force it by using a swf-rsl packaging type, but I haven't completely figured that out. Christian. On 14-Mar-08, at 16:14 , Shane Isbell wrote: I'm not sure the specifics of VELOs problem but I have run into some issues with NMaven for .NET support. There may be cases (like netmodules, or linking of assemblies) where you don't want transitive dependencies, they need to be direct. So it is up to the plugins to decide if artifactType[x]:compile is transtive or not. It is the same scope but the behavior is different depending on artifact type. There are also issues such as the Global Assembly Cache. In this case, I use a provided scope but when the plugins see an artifact dependency with dotnet:gac_msil type, they know to treat it differently. So the key is not to change scopes but to change the artifact type of the dependency to handle different behavior of the scope. Shane On Fri, Mar 14, 2008 at 12:50 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Why would you actually need other scopes? Don't think of scope, think of use-cases: 1. Need for both compile and in the deployed system 2. Need only for compile. 3. Need only in the deployed system 4. Provided locally for compile 5. Need only during testing What other scenarios would your other language have need for? These are the scenarios that are handled by the maven dependency scopes. Christian. On 14-Mar-08, at 10:45 , Brian E. Fox wrote: Nope, the scopes are coded into the core and most of the plugins since it's a core concept. -Original Message- From: VELO [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 9:42 AM To: Maven Developers List Subject: Re: Custom scopes And there is any where to say: Hey maven, I wanna change your scopes, I wanna this scopes? VELO On Fri, Mar 14, 2008 at 10:13 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: System scope doesn't exist in Java either. It's not a Java thing, but a Maven thing, and it just means that the dependency is provided at compile time by a local direct path, and that the ultimate runtime will provide the dependency. Christian. On 14-Mar-08, at 07:25 , VELO wrote: Hi guys, I'm developing a maven compiler mojo to another language (not Java, but I prefer don't reveal, at least not now). That language have more scopes (total 6). One (COMPILE) is Java like. But the others have different naming: RUNTIME on Java there is called EXTERNAL PROVIDED on Java looks like to RUNTIME on this language SYSTEM doesn't exist I wanna the same Java Scopes, but I wanna to use another name convention. How can I create my custom scope and insert they into the maven dependency mechanism? I need to do that because I have 2 types of transitive dependencies and 3 non transitive. Any one can help me? VELO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Custom scopes
So, is possible =D Let me do a question. I can't do configurations like this to scopes, right?! Well, a dependency has 2 attributes. Scope and type. In my original thought is: type is related to dependency's type; scope is related to dependency's usage. Are this thought wrong? What mean the type? When I say typeswc/type: I say this dependency kind is a SWC? Or I say this dependency is used like a SWC? I always think on the type related to kind and the scope related to usage. Can anyone give some light on this? VELO On Fri, Mar 14, 2008 at 6:03 PM, Shane Isbell [EMAIL PROTECTED] wrote: That's the default behavior of Maven: extension = type. You can the mapping through an entry in a components.xml file. For example, component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintdotnet:gac/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration extensiondll/extension typedotnet:gac/type addedToClasspathtrue/addedToClasspath /configuration /component On Fri, Mar 14, 2008 at 2:00 PM, VELO [EMAIL PROTECTED] wrote: Just a question from a noobie. If I change the type, I'm pointing to a different file or to the same? I always think in the type as the extension. typeswc/type means aFile.swc Right? Wrong? +-? VELO On Fri, Mar 14, 2008 at 5:55 PM, Shane Isbell [EMAIL PROTECTED] wrote: Multiple artifact types can all match to the same artifact. By using the dependency/type you can change behavior, like whether it is transitive or if it should be linked or compiled, etc. There is no need to muck around with scopes. Shane On Fri, Mar 14, 2008 at 1:46 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: I agree, I just hadn't yet thought through how to handle deployment. Especially since a .swc is a .swf with a manifest file in a zip file, it doesn't entirely map to the maven artifact concept of one-artifact- per-project. Maybe as a classifier... Hmmm. Anyway, we should take this flex-specific stuff off the maven dev list unless there's actual questions about maven mechanics. Christian. On 14-Mar-08, at 16:42 , VELO wrote: But to compile, you need the SWC. Your dependency is the SWC, or am I wrong? The artifiact doesn't change. I can use the same SWC as external or as runtime or as merged So, I don't believe changing type is the right decision. VELO On Fri, Mar 14, 2008 at 5:17 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Yeah - I may do that too with the flex thing because a .swf is the normal web-deployable, but a particular dynamic linking approach (called Remote Shared Libraries) uses .swf files as libraries. I may force it by using a swf-rsl packaging type, but I haven't completely figured that out. Christian. On 14-Mar-08, at 16:14 , Shane Isbell wrote: I'm not sure the specifics of VELOs problem but I have run into some issues with NMaven for .NET support. There may be cases (like netmodules, or linking of assemblies) where you don't want transitive dependencies, they need to be direct. So it is up to the plugins to decide if artifactType[x]:compile is transtive or not. It is the same scope but the behavior is different depending on artifact type. There are also issues such as the Global Assembly Cache. In this case, I use a provided scope but when the plugins see an artifact dependency with dotnet:gac_msil type, they know to treat it differently. So the key is not to change scopes but to change the artifact type of the dependency to handle different behavior of the scope. Shane On Fri, Mar 14, 2008 at 12:50 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Why would you actually need other scopes? Don't think of scope, think of use-cases: 1. Need for both compile and in the deployed system 2. Need only for compile. 3. Need only in the deployed system 4. Provided locally for compile 5. Need only during testing What other scenarios would your other language have need for? These are the scenarios that are handled by the maven dependency scopes. Christian. On 14-Mar-08, at 10:45 , Brian E. Fox wrote: Nope, the scopes are coded into the core and most of the plugins since it's a core concept. -Original Message- From: VELO [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 9:42 AM To: Maven Developers List Subject: Re: Custom scopes And there is any where to say: Hey maven, I wanna change your
