installing non-maven jars before compile
Hi,
I'm trying to install some non-maven files before I compile my project.
Here's a snippet of my pom.xml:
[code]
org.apache.maven.plugins
maven-install-plugin
2.3.1
install-mallet
validate
install-file
${project.basedir}/lib/somejar.jar
mygroup
somejar
1
jar
true
true
...
[/code]
Now, this works fine if I call:
mvn validate
But if I call:
mvn compile
These jars don't get installed. I thought that if I call "mvn compile",
all phases before it will also get called (e.g. validate, initialize,
generate-sources, process-sources, generate-resources, process-resources).
Why is this not happenning?
Best Regards,
Paul
configuration plugin
Hi.
I am looking for a configuration plugin or (if it does not exist) some
brainstorming related to the maven-way of configuration. First let me
say that the configuration task is relevant for our php-maven projects
where we do not have clear conventions sou may know from java/jar or
java/war files. Please do not answer with something saying "But a java
servlet should be able to load configuration via server.xml and
server.xml is never part of the generated war". Let us assume the
config.ini is part of the file structure of our application and thus
may be part of the package we are building.
Let us look at a simple scenario of a php web application:
src/main/php/lib --> contains some useful classes
src/main/php/htdocs --> contains the index.php (and maybe other scripts)
src/main/resources/htdocs --> contains .htacces, css files etc.
src/main/resources/config/config.ini --> contains the ini file with
application configuration.
The maven way would be to activate filtering and declaring something
like this in the config.ini:
[foo]
bar = ${baz}
Typically you would add the properties to your settings.xml and
everything will be fine.
1)
But what happens now? Maven will filter the config.ini and place the
filtered content at the target/classes. Typically a developer (maybe
by using the IDE) wants to place his personal local database
information in the settings.xml. Everything he needs to test his small
web application inside a local tomcat/jetty/apache-httpd. Maybe he
wants to use a different database for unit testing. This is because he
do not want to influence the data he created by manual testing the
app.
As soon as we want to deploy he runs into trouble because normally the
maven way says: Take the target/classes and create a package. Then
deploy this package to the repository. For java projects this creates
jars/wars, for php-maven it creates phars. But all of them contain the
developers config and maybe the database credentials. This is not that
clever.
As far As I understood the maven way we are now forced to use
profiles. For example one could name profiles "development",
"testing", "deploy", "production". That is ok for me because I do not
want to reinvent the wheel and profiles are somehow magic :-). But I
did not see a way to declare something like "For goal package do use
profile deploy; for goal test do use profile testing". Must the
developers remember what profiles to activate before deploying their
module? They may use a jenkins for deploying but keep in mind that
there are enough small projects around that do not have ci servers.
2)
What about the installation phase? I do not know how to name it, I
think of installation to a productional server and not installation in
the meaning of copying it to local repository. So let me call it
"install-app". I saw some small examples to store war projects into
tomcats. Is there any convention around how the lifecycle is named for
the different application types? What I mean is something like this:
"mvn -DgroupId=org.mygroup -DartifactId=my-app -Dversion=1.5.0 install-app"
If there are no plugins around that solve this tasks what about
writing a generic one? A plugin that is able to "hack" the config.ini
by activating the correct profile depending on the use case of the
developer. All we need to know is what files represent mutable
configuration files. And as soon as we want to execute "install-app"
it means to load it from repository (containing non-filter
configuration files), to ask for the configuration parameters "baz" at
command line and to provide a filtered config.ini.
Similar to the way the archetype:generate asks for additional parameters.
What do you think about it?
Greetings
Martin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: configuration plugin
Profiles appear to be magic but it is black magic.
They should only be used by senior sorcerers who possess advanced skills
and have all of the required potions of healing and invulnerability.
They are inherently evil and can make your life a living hell.
There are a few Maven experts who can handle them with some level of
safety but for the rest of us they are to be avoided.
Configuration does not belong with software developers. It belongs to
system administrators.
If possible, structure your Maven projects to produce a single artifact.
Make a project that produces an artifact for development, another for
your test environment.
Have a look at the assembly plug-in or shade. These are safe and will
not hurt you.
They might be able to build the artifacts that you need.
Ron
On 02/04/2012 2:55 PM, martin.eisengardt wrote:
Hi.
I am looking for a configuration plugin or (if it does not exist) some
brainstorming related to the maven-way of configuration. First let me
say that the configuration task is relevant for our php-maven projects
where we do not have clear conventions you may know from java/jar or
java/war files. Please do not answer with something saying "But a java
servlet should be able to load configuration via server.xml and
server.xml is never part of the generated war". Let us assume the
config.ini is part of the file structure of our application and thus
may be part of the package we are building.
Let us look at a simple scenario of a php web application:
src/main/php/lib --> contains some useful classes
src/main/php/htdocs --> contains the index.php (and maybe other scripts)
src/main/resources/htdocs --> contains .htacces, css files etc.
src/main/resources/config/config.ini --> contains the config.
The maven way would be to activate filtering and declaring something
like this in the config.ini:
[foo]
bar = ${baz}
Typically you would add the properties to your settings.xml and
everything will be fine.
1)
But what happens now? Maven will filter the config.ini and place the
filtered content at the target/classes. Typically a developer (maybe
by using the IDE) wants to place his personal local database
information in the settings.xml. Everything he needs to test his small
web application inside a local tomcat/jetty/apache-httpd. Maybe he
wants to use a different database for unit testing. This is because he
do not want to influence the data he created by manual testing the
app.
As soon as we want to deploy he runs into trouble because normally the
maven way says: Take the target/classes and create a package. Then
deploy this package to the repository. For java projects this creates
jars/wars, for php-maven it creates phars. But all of them contain the
developers config and maybe the database credentials. This is not that
clever. You may exclude the config from build or use assemblies. But
then the configuration is gone.
As far As I understood the maven way we are now forced to use
profiles. For example one could name profiles "development",
"testing", "deploy", "production". That is ok for me because I do not
want to reinvent the wheel and profiles are somehow magic :-). But I
did not see a way to declare something like "For goal package do use
profile deploy; for goal test do use profile testing". Must the
developers remember what profiles to activate before deploying their
module? They may use a jenkins for deploying but keep in mind that
there are enough small projects around that do not have ci servers.
2)
What about the installation phase? I do not know how to name it, I
think of installation to a productional server and not installation in
the meaning of copying it to local repository. So let me call it
"install-app". I saw some small examples to store war projects into
tomcats. Is there any convention around how the lifecycle is named for
the different application types? What I mean is something like this:
"mvn -DgroupId=org.mygroup -DartifactId=my-app -Dversion=1.5.0 install-app"
If there are no plugins around that solve this tasks what about
writing a generic one? A plugin that is able to "hack" the config.ini
by activating the correct profile depending on the use case of the
developer. All we need to know is what files represent mutable
configuration files. And as soon as we want to execute "install-app"
it means to load it from repository (containing non-filter
configuration files), to ask for the configuration parameters "baz" at
command line and to provide a filtered config.ini.
Similar to the way the archetype:generate asks for additional parameters.
What do you think about it?
Greetings
Martin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Re: Using artifacts as resources in other projects.
You should probably use the maven assembly plugin Jeff Le 2 avr. 2012 17:47, "Mariusz Plucinski" a écrit : > Hello Maven users, > > I am really newbie in Maven, so I am not pretty sure if my way of thinking > is right. If it's not, do not hesitate to criticize it. > > I am developing medium-size project, which contains both Java SE and > Android sub-projects. After many troubles with Ant, I've decided to give > Maven's a try. > > To make it simple, let's say that I have three projects: > - Android application > - Swing application > - Main application (also uses Swing, but this is not important now) > > Those three applications are building pretty well with maven. I am typing > "mvn package" and - as expected - I get one *.apk file and two *.jar files. > Thanks to maven-shade-plugin, JAR files contains all required dependencies. > They are, of course, executable jars. > > Goal of Main application is to "generate" Swing and Android applications > for user's request. Those applications are prebuilt, so Main program needs > only to slightly modify it before putting onto user's disk. However, I > would like to deliver only one file - Main.jar. Two other files - > Android.apk and Swing.jar should be put as entire files inside of Main.jar > (they should stay there as full files, without unpacking or anything). This > way, when user decided to generate e.g. Swing application, Main application > gets whole file Swing.jar from itself, modifies it a little and put > somewhere to user's file system. That same is possible in case of > generating Android program. But it requires shipping Android.apk and > Swing.jar inside of Main.jar. > > Is it possible to be done using Maven? I suppose that Swing.jar and > Android.apk should be provided as resources during build of Main.jar, but I > don't know how to instruct Maven to do it this way. I have tried to set > compile in maven-jar-plugin configuration in Swing.jar. I > suppose it is wrong solution - in compile phase, Main application should > already have all required resources. Is there any way to instruct Maven to > "package" my Android and Swing projects during "prepare-resources" of Main > project? Of course, those two are dependencies, so Main project should be > informed, that resources were changed in case of modifications in those two. > > I am using Maven 3.0.3 and m2e 1.0.200. > > Thank you in advance for any help/advise/criticism :). > > Best Regards, > Mariusz Pluciński > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Different behavior when building a project as a module or "stand-alone"
> Our project depends on various corporate libraries which are not > "Mavenized". In order to use these libraries, we frequently use > deploy:deploy-file to drop them on our repository, with a fixed version > (given that new versions are duly tested and obsolete older versions). I want to be sure that I understand what you are saying here. The versions are DIFFERENT each time you run deploy-file, right? It is a basic premise of Maven and most sane build systems that that a given artifact with a particular version number must be immutable. Otherwise you have no idea if your file versioned 2.3.2 is the "right one" vs another file with version 2.3.2 that exists somewhere else. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
configuration plugin
Hi.
I am looking for a configuration plugin or (if it does not exist) some
brainstorming related to the maven-way of configuration. First let me
say that the configuration task is relevant for our php-maven projects
where we do not have clear conventions you may know from java/jar or
java/war files. Please do not answer with something saying "But a java
servlet should be able to load configuration via server.xml and
server.xml is never part of the generated war". Let us assume the
config.ini is part of the file structure of our application and thus
may be part of the package we are building.
Let us look at a simple scenario of a php web application:
src/main/php/lib --> contains some useful classes
src/main/php/htdocs --> contains the index.php (and maybe other scripts)
src/main/resources/htdocs --> contains .htacces, css files etc.
src/main/resources/config/config.ini --> contains the config.
The maven way would be to activate filtering and declaring something
like this in the config.ini:
[foo]
bar = ${baz}
Typically you would add the properties to your settings.xml and
everything will be fine.
1)
But what happens now? Maven will filter the config.ini and place the
filtered content at the target/classes. Typically a developer (maybe
by using the IDE) wants to place his personal local database
information in the settings.xml. Everything he needs to test his small
web application inside a local tomcat/jetty/apache-httpd. Maybe he
wants to use a different database for unit testing. This is because he
do not want to influence the data he created by manual testing the
app.
As soon as we want to deploy he runs into trouble because normally the
maven way says: Take the target/classes and create a package. Then
deploy this package to the repository. For java projects this creates
jars/wars, for php-maven it creates phars. But all of them contain the
developers config and maybe the database credentials. This is not that
clever. You may exclude the config from build or use assemblies. But
then the configuration is gone.
As far As I understood the maven way we are now forced to use
profiles. For example one could name profiles "development",
"testing", "deploy", "production". That is ok for me because I do not
want to reinvent the wheel and profiles are somehow magic :-). But I
did not see a way to declare something like "For goal package do use
profile deploy; for goal test do use profile testing". Must the
developers remember what profiles to activate before deploying their
module? They may use a jenkins for deploying but keep in mind that
there are enough small projects around that do not have ci servers.
2)
What about the installation phase? I do not know how to name it, I
think of installation to a productional server and not installation in
the meaning of copying it to local repository. So let me call it
"install-app". I saw some small examples to store war projects into
tomcats. Is there any convention around how the lifecycle is named for
the different application types? What I mean is something like this:
"mvn -DgroupId=org.mygroup -DartifactId=my-app -Dversion=1.5.0 install-app"
If there are no plugins around that solve this tasks what about
writing a generic one? A plugin that is able to "hack" the config.ini
by activating the correct profile depending on the use case of the
developer. All we need to know is what files represent mutable
configuration files. And as soon as we want to execute "install-app"
it means to load it from repository (containing non-filter
configuration files), to ask for the configuration parameters "baz" at
command line and to provide a filtered config.ini.
Similar to the way the archetype:generate asks for additional parameters.
What do you think about it?
Greetings
Martin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Different behavior when building a project as a module or "stand-alone"
Are you using a Maven repo such as Nexus? Can you not give your corporate libraries GAV designations that are controlled so the version numbers are monotonically increasing? Ron On 02/04/2012 11:53 AM, Philippe Lagardère wrote: Indeed, our use case for purge-local-repository is a bit dodgy and definitely sub-optimal. Our project depends on various corporate libraries which are not "Mavenized". In order to use these libraries, we frequently use deploy:deploy-file to drop them on our repository, with a fixed version (given that new versions are duly tested and obsolete older versions). Clearly, this is not the best way of doing things, but it was by far the easiest solution for us, and we expected it to be somewhat sustainable. The purge-local-repo goal (with the right set of exclusions) was used in order to ensure the latest versions of there corporate libraries were used whenever we release a new version of the project. I configured an execution as it was the first idea I had in order to have the goal run once for a multi-module build. Now, since it doesn't seem to work all that well, it probably won't be too hard finding another way around, so I suppose we can say my problem is closed. But I'm still curious as to why this problem occurred, can anyone fill me in on that ? No biggie if it's not possible, but I do wonder what I did wrong there (aside from the management of non-maven libraries ;) ) ! Anyway, thanks for your insight, Wayne ! Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5612860.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using artifacts as resources in other projects.
> However, I would like to deliver only one file - Main.jar. Two other files - > Android.apk > and Swing.jar should be put as entire files inside of Main.jar (they should > stay there > as full files, without unpacking or anything). This way, when user decided to > generate > e.g. Swing application, Main application gets whole file Swing.jar from > itself, modifies > it a little and put somewhere to user's file system. That same is possible in > case of > generating Android program. But it requires shipping Android.apk and > Swing.jar inside > of Main.jar. I don't see this as being a good way to handle your user case. Instead I think you should be using the assembly plugin to create a Zip file containing your 3 files, then provide instructions to your users about how to unzip and run the Main.jar and tell Main.jar to look in the same directory (or under a lib/ subdir) it is located in for the other 2 files. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Different behavior when building a project as a module or "stand-alone"
Indeed, our use case for purge-local-repository is a bit dodgy and definitely sub-optimal. Our project depends on various corporate libraries which are not "Mavenized". In order to use these libraries, we frequently use deploy:deploy-file to drop them on our repository, with a fixed version (given that new versions are duly tested and obsolete older versions). Clearly, this is not the best way of doing things, but it was by far the easiest solution for us, and we expected it to be somewhat sustainable. The purge-local-repo goal (with the right set of exclusions) was used in order to ensure the latest versions of there corporate libraries were used whenever we release a new version of the project. I configured an execution as it was the first idea I had in order to have the goal run once for a multi-module build. Now, since it doesn't seem to work all that well, it probably won't be too hard finding another way around, so I suppose we can say my problem is closed. But I'm still curious as to why this problem occurred, can anyone fill me in on that ? No biggie if it's not possible, but I do wonder what I did wrong there (aside from the management of non-maven libraries ;) ) ! Anyway, thanks for your insight, Wayne ! Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5612860.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Avoiding duplicate POM code: profiles, inheritance, properties
On Mon, Apr 2, 2012 at 7:55 AM, Gillet Thomas (2) < thomas.gille...@consultant.volvo.com> wrote: > Seems my first post was really not clear. Trying to make it simpler: > > Basically, my main concern is to be able to package separately parts of > the POM: > - plugin configuration and/or dependencies (previously the "type POM") > - distribution management information (previously the "deployment POM") > Yes, this is a clear and obvious thing to want to do. You are not crazy for wanting to be able to do this. But you can't do it in Maven (to the best of my knowledge). You can get close though. You can make a grandparent pom.xml with non-project but company-specific information in it (company name, maybe the location of your Nexus, various domain- and project-independent properties). Ideally this pom.xml changes rarely, if ever. Do not be tempted to load it up with plugin version specifiers and dependency information; this is really just common boilerplate, and that's it. You can then make several child poms beneath it that inherit from it that contain various plugin or pluginManagement stanzas--maybe one, for example, combines together plugins that are useful for JPA development (or whatever) and you don't want to keep specifying those plugins over and over and over again for your various JPA projects. Just an example. You can repeat this as many levels deep as you want. Finally at the end of the inheritance stack here you would have a project pom.xml that would inherit from one of these "type" poms. This would allow you to pick and choose which effective combinations of plugins and pluginManagement (and/or dependencies, etc.) you might want for that project (maybe one project needs the But there will come a time when you discover you want a mix of several of these pom.xmls. Maven has no way to import sections from another pom.xml (sure wish it did, or that it could permit this sort of thing via magic XML namespaces or xinclude or something; I'm no W3C XML wonk so I don't know fully what's possible here). Nor does it offer a way to have a project extend from several poms at once. For dependencies (and this one took me probably about a year before I fully got it), recall that dependencies are transient, so in this one case you can actually declare a dependency on an artifact of pom. Think about that for a moment. If *that* artifact (a pom file) in turn declares a pile of dependencies, then THOSE dependencies will be pulled in transitively. This is a nice hack--and it is a hack--that allows you to at *least* group dependencies into bundles that you can suck in fairly conveniently, and, to your point, maintain separately (something that I think maybe got lost in your original request). There is no equivalent hack for plugins to my knowledge. I've usually done a moderately deep inheritance stack and then pretty much just deal with the duplicate code after that. I hope this helps you out. Just another user's data point; always interested to hear better approaches. Best, Laird -- http://about.me/lairdnelson
Using artifacts as resources in other projects.
Hello Maven users, I am really newbie in Maven, so I am not pretty sure if my way of thinking is right. If it's not, do not hesitate to criticize it. I am developing medium-size project, which contains both Java SE and Android sub-projects. After many troubles with Ant, I've decided to give Maven's a try. To make it simple, let's say that I have three projects: - Android application - Swing application - Main application (also uses Swing, but this is not important now) Those three applications are building pretty well with maven. I am typing "mvn package" and - as expected - I get one *.apk file and two *.jar files. Thanks to maven-shade-plugin, JAR files contains all required dependencies. They are, of course, executable jars. Goal of Main application is to "generate" Swing and Android applications for user's request. Those applications are prebuilt, so Main program needs only to slightly modify it before putting onto user's disk. However, I would like to deliver only one file - Main.jar. Two other files - Android.apk and Swing.jar should be put as entire files inside of Main.jar (they should stay there as full files, without unpacking or anything). This way, when user decided to generate e.g. Swing application, Main application gets whole file Swing.jar from itself, modifies it a little and put somewhere to user's file system. That same is possible in case of generating Android program. But it requires shipping Android.apk and Swing.jar inside of Main.jar. Is it possible to be done using Maven? I suppose that Swing.jar and Android.apk should be provided as resources during build of Main.jar, but I don't know how to instruct Maven to do it this way. I have tried to set compile in maven-jar-plugin configuration in Swing.jar. I suppose it is wrong solution - in compile phase, Main application should already have all required resources. Is there any way to instruct Maven to "package" my Android and Swing projects during "prepare-resources" of Main project? Of course, those two are dependencies, so Main project should be informed, that resources were changed in case of modifications in those two. I am using Maven 3.0.3 and m2e 1.0.200. Thank you in advance for any help/advise/criticism :). Best Regards, Mariusz Pluciński - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Avoiding duplicate POM code: profiles, inheritance, properties
Hi Gillet, Basically, my main concern is to be able to package separately parts of the > POM: > - plugin configuration and/or dependencies (previously the "type POM") > - distribution management information (previously the "deployment POM") > To me, it sounds like you are asking for multiple inheritance in POMs—or else a non-inheritance-based include mechanism. AFAIK, Maven does not have either of those capabilities. Just like in Java, which is also single-inheritance only, it can be difficult or impossible to avoid code duplication in certain complex cases. But in my experience it is fairly rare, and often you can find an alternative design that avoids the issue. Does your project really need to "mix and match" the type and deployment POMs in many different configurations? In other words, are you sure you need a graph of POMs, rather than only a tree? As we all know, graphs can be much trickier to deal with. I suggest identifying the commonalities across most of your projects, and including those in a common parent POM. In the case of dependencies and plugins, ideally all projects will use the same versions of those anyway, so they can largely be declared at the top level. In places where 9 out of 10 projects use version A, but the 10th uses version B, declare version A in your toplevel, but override with B in the 10th project's POM. Then there is no repetition, and you are consistent with Maven's "convention over configuration" approach. Maybe some day Maven will support some form of multiple inheritance for adding in extra common configuration more efficiently. Until then, it certainly is not perfectly DRY, but you can usually do fairly well. Regards, Curtis On Mon, Apr 2, 2012 at 6:55 AM, Gillet Thomas (2) < thomas.gille...@consultant.volvo.com> wrote: > Hello Wayne, > > Seems my first post was really not clear. Trying to make it simpler: > > Basically, my main concern is to be able to package separately parts of > the POM: > - plugin configuration and/or dependencies (previously the "type POM") > - distribution management information (previously the "deployment POM") > > So I can later define one set of distribution management information per > project, and one set of configuration per bundle type. > Then each bundle will, depending on the project it is member of and > depending on its type, inherit from one set of distribution management > information, and from one set of configuration. > > Hope this is a better explanation. > > Then, about your proposals: > > > 1. Inheritance does not necessarily follow aggregation. > > That's right, I didn't think about aggregator POMs. Actually if properties > defined in an aggregator POM are accessible in the sub-modules, then it > could be a place to put shared properties for distribution management. > But I'm not sure it is the case, and anyway it would make those properties > available only when building the aggregator. I need to be able to build > each module alone. > > > 2. The maven-remote-resources-plugin can help share resources > (configuration files etc) between modules > > Didn't know that. But I need to share properties, dependencies and plugin > configurations, not only resources. > > > 3. Look into the "import" scope (but this really only helps managing > dependencies, not necessarily useful to you) > > Didn't know that either, thanks to point it out. > It actually could be used for the sets of configuration which only contain > dependencies, but when it comes to plugin configuration, again, not working. > > Not helping this particular problem I think, but that's indeed good thinks > to know. > Thanks for the pointers. > > Thomas GILLET >
Re: Different behavior when building a project as a module or "stand-alone"
> between the two builds. It happens during the execution of > dependency:purge-local-repository. As you can see in the "build" pastebins I have a lot of projects that are built with Maven, and not a single one uses purge-local-repo. Why are you using it? > below, there's only one library affected (profilage-lse). But, it's > re-downloaded once during the standalone build, and twice during the > "multi-module" build. Might seem benign, but when I comment out the > execution for that goal, the warning disappears, and the "multimodule" build > is successful. I would eliminate your usage of purge-local-repo if at all possible since it sounds like that would solve your problem. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Avoiding duplicate POM code: profiles, inheritance, properties
It sounds like you are describing the usage of a parent POM. A parent is a project specific POM that ideally carries your plug-in versions, deployment information and code versions for all of the POMs in the maven projects that makes up your application. Some of this is properties and some is full specifications. This puts these decisions under the control of the project team and reduces the concerns of the individual developers and shrinks the maven project POMs by a lot. You should read the docs on the usage of parent POMs. Remember 1) A lot of people have built whatever it is that you are doing and there are Best Practices for doing it. 2) Maven has a very particular way of doing things and until you comply, you will be in a constant losing battle. "Resistance is futile". Have a look at the list of Maven PMC members and the committers to see the quality of advice that you are getting. Ron On 02/04/2012 7:55 AM, Gillet Thomas (2) wrote: Hello Wayne, Seems my first post was really not clear. Trying to make it simpler: Basically, my main concern is to be able to package separately parts of the POM: - plugin configuration and/or dependencies (previously the "type POM") - distribution management information (previously the "deployment POM") So I can later define one set of distribution management information per project, and one set of configuration per bundle type. Then each bundle will, depending on the project it is member of and depending on its type, inherit from one set of distribution management information, and from one set of configuration. Hope this is a better explanation. Then, about your proposals: 1. Inheritance does not necessarily follow aggregation. That's right, I didn't think about aggregator POMs. Actually if properties defined in an aggregator POM are accessible in the sub-modules, then it could be a place to put shared properties for distribution management. But I'm not sure it is the case, and anyway it would make those properties available only when building the aggregator. I need to be able to build each module alone. 2. The maven-remote-resources-plugin can help share resources (configuration files etc) between modules Didn't know that. But I need to share properties, dependencies and plugin configurations, not only resources. 3. Look into the "import" scope (but this really only helps managing dependencies, not necessarily useful to you) Didn't know that either, thanks to point it out. It actually could be used for the sets of configuration which only contain dependencies, but when it comes to plugin configuration, again, not working. Not helping this particular problem I think, but that's indeed good thinks to know. Thanks for the pointers. Thomas GILLET - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Avoiding duplicate POM code: profiles, inheritance, properties
Hello Wayne, Seems my first post was really not clear. Trying to make it simpler: Basically, my main concern is to be able to package separately parts of the POM: - plugin configuration and/or dependencies (previously the "type POM") - distribution management information (previously the "deployment POM") So I can later define one set of distribution management information per project, and one set of configuration per bundle type. Then each bundle will, depending on the project it is member of and depending on its type, inherit from one set of distribution management information, and from one set of configuration. Hope this is a better explanation. Then, about your proposals: > 1. Inheritance does not necessarily follow aggregation. That's right, I didn't think about aggregator POMs. Actually if properties defined in an aggregator POM are accessible in the sub-modules, then it could be a place to put shared properties for distribution management. But I'm not sure it is the case, and anyway it would make those properties available only when building the aggregator. I need to be able to build each module alone. > 2. The maven-remote-resources-plugin can help share resources (configuration > files etc) between modules Didn't know that. But I need to share properties, dependencies and plugin configurations, not only resources. > 3. Look into the "import" scope (but this really only helps managing > dependencies, not necessarily useful to you) Didn't know that either, thanks to point it out. It actually could be used for the sets of configuration which only contain dependencies, but when it comes to plugin configuration, again, not working. Not helping this particular problem I think, but that's indeed good thinks to know. Thanks for the pointers. Thomas GILLET
Re: eclipse plugin for maven using jdk 1.3
Hi, > I checked if the JRE in the Run AS configuration was 1.3 but it was not. Why > is the maven plugin using 1.3 is beyond my understanding. http://maven.apache.org/general.html#Compiling-J2SE-5 HTH Thorsten
Re: Ear Plugin skinnyWars EJB problem
I tried this approach, / org.apache.maven.plugins maven-war-plugin 2.2 WEB-INF/lib/*.jar //this excludes all jars from being added to the WAR. true lib/ false / -- View this message in context: http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5611958.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
eclipse plugin for maven using jdk 1.3
Hello guys, I installed a maven plugin in eclipse when i ran my pavne project and tried to build it there it used jdk 1.3 to build and compile. here is the verbose out put sections related to this: / [INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @ CorpWeb --- [DEBUG] Created new class realm plugin>org.apache.maven.plugins:maven-compiler-plugin:2.0.2 [DEBUG] Populating class realm plugin>org.apache.maven.plugins:maven-compiler-plugin:2.0.2 [DEBUG] Included: org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:2.0.2 [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:1.0.4 [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:1.5.3 [DEBUG] Included: junit:junit:jar:3.8.1 [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:1.5.3 [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:1.5.3 [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0 [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0 [DEBUG] Excluded: org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 [DEBUG] Excluded: classworlds:classworlds:jar:1.1-alpha-2 [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' with basic configurator --> [DEBUG] (f) basedir = C:\RSA75Workspace\workspace\Corpweb [DEBUG] (f) buildDirectory = C:\RSA75Workspace\workspace\Corpweb\target [ [DEBUG] (f) compileSourceRoots = [C:\RSA75Workspace\workspace\Corpweb\src] [DEBUG] (f) compilerId = javac [DEBUG] (f) debug = true [DEBUG] (f) failOnError = true [DEBUG] (f) fork = false [DEBUG] (f) optimize = false [DEBUG] (f) outputDirectory = C:\RSA75Workspace\workspace\Corpweb\target\classes [DEBUG] (f) outputFileName = CorpWeb [DEBUG] (f) projectArtifact = CorpWeb:CorpWeb:war:1.0 [DEBUG] (f) showDeprecation = false [DEBUG] (f) showWarnings = false [DEBUG] (f) staleMillis = 0 [DEBUG] (f) verbose = false [DEBUG] -- end configuration –/ here it doesnt indicate to me which JDK it is using but then it fails on compile: /ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project CorpWeb: Compilation failure: Compilation failure: C:\RSA75Workspace\workspace\Corpweb\src\com\ejada\ecorp\domain\administration\GroupsUserAssignmentSummaryBO.java:[84,2] annotations are not supported in *-source 1.3* (use -source 5 or higher to enable annotations) @Override C:\RSA75Workspace\workspace\Corpweb\src\com\ejada\ecorp\domain\beneficiaries\BeneficiaryIdBO.java:[56,2] annotations are not supported in *-source 1.3* (use -source 5 or higher to enable annotations) @Override C:\RSA75Workspace\workspace\Corpweb\src\com\ejada\ecorp\domain\beneficiaries\BeneficiaryIdBO.java:[57,18] generics are not supported in *-source 1.3* (use -source 5 or higher to enable generics) public LinkedList generateSpecificDetails()/ I checked if the JRE in the Run AS configuration was 1.3 but it was not. Why is the maven plugin using 1.3 is beyond my understanding. Also: i couldnt find the settings.xml of the plugin or maven installation i had to add a new one manually. neither could i find mvn,bat any where on my harddisk . even though when i try to Run it through maven i can see that it issued a command mvn -B -Dmaven.test.skip=true -s "C:\Documents and Settings\5510041\.m2\settings.xml" clean install so everything seems to be embedded in the plugin. any help in understanding this would be appreciated. Thanks. Syed... -- View this message in context: http://maven.40175.n5.nabble.com/eclipse-plugin-for-maven-using-jdk-1-3-tp5611951p5611951.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Different behavior when building a project as a module or "stand-alone"
Thanks for your answer, Wayne. I'll refrain from using Nabble's formatting options from now on. Here are the informations from my first message, in plain text this time. === === === My project has a basic multi-module structure, like this : project |_project-core |_project-web |_project-batch The thing is, I get two different results for executing mvn clean package, whether I run it from project-core or from project. >From project-core [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ profilage-core --- [INFO] Building jar: D:\ozp6kz\Mes Documents\eclipse_workspace\ProjetProfilage\profilage-core\target\profilage-core-0.1.jar >From project [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ profilage-core --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] Building jar: D:\ozp6kz\Mes Documents\eclipse_workspace\ProjetProfilage\profilage-core\target\profilage-core-0.1.jar [INFO] Basically, as a stand-alone, the project builds perfectly well, which allows in turn the other modules to build correctly. But when built as part of the global, multi-module project, there's this one [WARNING] line which throws off the rest of the build. === === === When preparing my code for paste-bins, I (finally) noticed the difference between the two builds. It happens during the execution of dependency:purge-local-repository. As you can see in the "build" pastebins below, there's only one library affected (profilage-lse). But, it's re-downloaded once during the standalone build, and twice during the "multi-module" build. Might seem benign, but when I comment out the execution for that goal, the warning disappears, and the "multimodule" build is successful. I'm definitely at a loss as to why this happens, so any explanation would be greatly appreciated ! Here are the pastebins from poms and builds, expurged of information unrelated : pom.xml - core module : http://commitcode.com/p/r/57wI2E5ovTY.html pom.xml - project parent : http://commitcode.com/p/r/57wI4xQmdLk.html pom.xml - corporate parent : http://commitcode.com/p/r/xX96TKUHndS.html pom.xml - help:effective-pom : http://commitcode.com/p/r/57wI8D7a2eV.html build - standalone : http://commitcode.com/p/r/xX97siekqj5.html build - as a module : http://commitcode.com/p/r/57wIbt2oV2v.html Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5611840.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
