How Maven works - definitions
Hello, I did not find an overview and now am trying to explain firstly myself and afterwards maybe others how Maven works (to other developers): - Maven is a declarative tool to build software, which relies mainly on conventions. - Declarations are done in a XML file called pom (project object model). - Maven consists of a small core and a plethora of plugins. - Maven builds stuff (often binaries) following paths outlined in lifecycles, predefined lifecycles are called default, clean and site. - Lifecycles are sequences of phases like e.g. compile, test or install. - Plugins provide a multitude of so called goals, which do specific stuff like e.g. compiling java source to classes or running unit tests. - The execution of goals is often bound to lifecycle phases. - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which only holds a pom, which is a XML file. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How Maven works - definitions
Hello there Mirko, I'd suggest fine-tuning the lifecycle-phase-plugin description slightly: - Maven is a tool to build software, which relies mainly on conventions. - The build is configured in an XML file called pom (project object model, or pom file). - Maven consists of a core and a plethora of plugins. Plugins can be included in the build by being configured within the pom file. - Maven builds stuff (often binaries) according to recipes outlined in lifecycles. Predefined lifecycles are called default, clean and site. - Lifecycles consist of sequences of named steps, called phases. The names of all phases are standarized, such as compile, test or install. - When Maven executes a phase, it announces the phase name to all plugins included in the build. - Plugins contain methods which perform specific actions like e.g. compiling java source to classes or running unit tests. These methods are given a symbolic name, called goal, and configured to run within a specified phase (known as binding a goal to a phase). - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which contains images but no source code, for example. 2013/7/7 Mirko Friedenhagen mfriedenha...@gmail.com Hello, I did not find an overview and now am trying to explain firstly myself and afterwards maybe others how Maven works (to other developers): - Maven is a declarative tool to build software, which relies mainly on conventions. - Declarations are done in a XML file called pom (project object model). - Maven consists of a small core and a plethora of plugins. - Maven builds stuff (often binaries) following paths outlined in lifecycles, predefined lifecycles are called default, clean and site. - Lifecycles are sequences of phases like e.g. compile, test or install. - Plugins provide a multitude of so called goals, which do specific stuff like e.g. compiling java source to classes or running unit tests. - The execution of goals is often bound to lifecycle phases. - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which only holds a pom, which is a XML file. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
Re: How Maven works - definitions
Maybe worth understanding why the current online documentation did not helped you. And maybe update it with this. Thanks. Sent from my iPhone On 07 Jul 2013, at 12:51, Lennart Jörelid lennart.jore...@gmail.com wrote: Hello there Mirko, I'd suggest fine-tuning the lifecycle-phase-plugin description slightly: - Maven is a tool to build software, which relies mainly on conventions. - The build is configured in an XML file called pom (project object model, or pom file). - Maven consists of a core and a plethora of plugins. Plugins can be included in the build by being configured within the pom file. - Maven builds stuff (often binaries) according to recipes outlined in lifecycles. Predefined lifecycles are called default, clean and site. - Lifecycles consist of sequences of named steps, called phases. The names of all phases are standarized, such as compile, test or install. - When Maven executes a phase, it announces the phase name to all plugins included in the build. - Plugins contain methods which perform specific actions like e.g. compiling java source to classes or running unit tests. These methods are given a symbolic name, called goal, and configured to run within a specified phase (known as binding a goal to a phase). - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which contains images but no source code, for example. 2013/7/7 Mirko Friedenhagen mfriedenha...@gmail.com Hello, I did not find an overview and now am trying to explain firstly myself and afterwards maybe others how Maven works (to other developers): - Maven is a declarative tool to build software, which relies mainly on conventions. - Declarations are done in a XML file called pom (project object model). - Maven consists of a small core and a plethora of plugins. - Maven builds stuff (often binaries) following paths outlined in lifecycles, predefined lifecycles are called default, clean and site. - Lifecycles are sequences of phases like e.g. compile, test or install. - Plugins provide a multitude of so called goals, which do specific stuff like e.g. compiling java source to classes or running unit tests. - The execution of goals is often bound to lifecycle phases. - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which only holds a pom, which is a XML file. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How Maven works - definitions
yes, such doc is useful IMHO, since it took myself a lot of time to get it clear in my mind (particularly lifecycle-phase-goal) for the moment, I didn't find energy to write it down since I didn't know where to put it to get us work on improvements (and even if anybody would find it useful) it's probably a good time to work on it for the moment, I imagine putting such a desdcription (=Maven as a build tool) in maven-core artifact site [1] any other idea? Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/ Le dimanche 7 juillet 2013 12:59:05 Stéphane Nicoll a écrit : Maybe worth understanding why the current online documentation did not helped you. And maybe update it with this. Thanks. Sent from my iPhone On 07 Jul 2013, at 12:51, Lennart Jörelid lennart.jore...@gmail.com wrote: Hello there Mirko, I'd suggest fine-tuning the lifecycle-phase-plugin description slightly: - Maven is a tool to build software, which relies mainly on conventions. - The build is configured in an XML file called pom (project object model, or pom file). - Maven consists of a core and a plethora of plugins. Plugins can be included in the build by being configured within the pom file. - Maven builds stuff (often binaries) according to recipes outlined in lifecycles. Predefined lifecycles are called default, clean and site. - Lifecycles consist of sequences of named steps, called phases. The names of all phases are standarized, such as compile, test or install. - When Maven executes a phase, it announces the phase name to all plugins included in the build. - Plugins contain methods which perform specific actions like e.g. compiling java source to classes or running unit tests. These methods are given a symbolic name, called goal, and configured to run within a specified phase (known as binding a goal to a phase). - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which contains images but no source code, for example. 2013/7/7 Mirko Friedenhagen mfriedenha...@gmail.com Hello, I did not find an overview and now am trying to explain firstly myself and afterwards maybe others how Maven works (to other developers): - Maven is a declarative tool to build software, which relies mainly on conventions. - Declarations are done in a XML file called pom (project object model). - Maven consists of a small core and a plethora of plugins. - Maven builds stuff (often binaries) following paths outlined in lifecycles, predefined lifecycles are called default, clean and site. - Lifecycles are sequences of phases like e.g. compile, test or install. - Plugins provide a multitude of so called goals, which do specific stuff like e.g. compiling java source to classes or running unit tests. - The execution of goals is often bound to lifecycle phases. - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which only holds a pom, which is a XML file. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Apache Maven War plugin 2.4
The vote has passed with the following result: +1 (binding): Hervé, Robert, Stéphane, Olivier +1 (non binding): Baptiste -1 (non binding): sebb I will continue the release process. Cheers, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0
On Sun, 30 Jun 2013 15:00:40 -0400 Jason van Zyl ja...@tesla.io wrote: +1, works fine for our projects. thanks, tony. Here are the release bits for 3.1.0: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-084/ Staged distribution: https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/ Staged Site: http://maven.apache.org/ref/3.1.0 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
2013/7/7 sebb seb...@gmail.com:
On 6 July 2013 19:53, John Casey jdca...@commonjava.org wrote:
Hmm, actually, from running a few builds of the source-release archive, I
can see that the unit tests appear to be creating the
${basedir}/maven-archive/ directory. I wonder if this has to do with
incomplete configuration of the test harness?
Looks like:
http://svn.apache.org/r1498096
was supposed to fix this; seems to be in the release candidate but
looks like the fix did not work.
ah yes. Strange I will have a look for next release. Grhh this file is
in svn:ignore property so svn st didn't detect that.
I noticed javadoc plugin source release has the same issue with a file
called javadoc-options-javadoc-resources.xml which must not be in
here.
In any case, I can see why the source-release assembly did the wrong thing
here; it's not in target, so not really expected to be a generated file.
Yes, that is basically the point I made early on else-thread.
I said that the release process did not guarantee that the source
archive would contain exactly the correct files - no more, no less.
The issue here is not that this particular file found its way into the
source archive.
Luckily the file looks to be harmless. It might not be next time.
The point is that the the release process is not infallible (in spite
of what people have stated).
Every so often, a vote reviewer needs to check that the source output
from the build process agrees with the source input.
If a discrepancy is found, it can be investigated and fixed.
But the important thing to take from this is that the current release
vote checking process could (and should) be improved.
On 7/6/13 1:35 PM, John Casey wrote:
On 7/6/13 11:28 AM, sebb wrote:
The curent release candidate for Apache Maven War plugin 2.4 contains
the following file in the source zip:
maven-archiver/pom.properties
The file is not in SVN or the source jar
As far as I can tell it does not belong in the source zip.
The file is unlikely to do any harm, however the fact that it somehow
has crept into the source archive points to a problem with the release
process.
The file is present in all the WAR source zips back to 2.1 (previously
there were no source archives)
AFAICT these WAR source archives were built by several different people.
It does not seem to be present in sources for the few other plugin
sources that I checked.
So why does the file end up in the WAR source archive?
What is broken?
I'd be surprised if you didn't find the same file in other
source-release archives. I'm guessing it's an exclusion that's missing
from the source-release.xml assembly descriptor that we use to construct
these archives.
I found the problem by comparing the source archive with the SVN tag.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
In this instance, these files are derived files, so does it matter?
If you re-run the build, the same files should be generated in the same way, so
you get a consistent build.
That is different issue to differences between different releases.
It is also a separate issue to whether the file should be there in the first
place, which is being looked at.
-Chris
Sent from my iPhone
On 07/07/2013, at 10:06 PM, Olivier Lamy ol...@apache.org wrote:
2013/7/7 sebb seb...@gmail.com:
On 6 July 2013 19:53, John Casey jdca...@commonjava.org wrote:
Hmm, actually, from running a few builds of the source-release archive, I
can see that the unit tests appear to be creating the
${basedir}/maven-archive/ directory. I wonder if this has to do with
incomplete configuration of the test harness?
Looks like:
http://svn.apache.org/r1498096
was supposed to fix this; seems to be in the release candidate but
looks like the fix did not work.
ah yes. Strange I will have a look for next release. Grhh this file is
in svn:ignore property so svn st didn't detect that.
I noticed javadoc plugin source release has the same issue with a file
called javadoc-options-javadoc-resources.xml which must not be in
here.
In any case, I can see why the source-release assembly did the wrong thing
here; it's not in target, so not really expected to be a generated file.
Yes, that is basically the point I made early on else-thread.
I said that the release process did not guarantee that the source
archive would contain exactly the correct files - no more, no less.
The issue here is not that this particular file found its way into the
source archive.
Luckily the file looks to be harmless. It might not be next time.
The point is that the the release process is not infallible (in spite
of what people have stated).
Every so often, a vote reviewer needs to check that the source output
from the build process agrees with the source input.
If a discrepancy is found, it can be investigated and fixed.
But the important thing to take from this is that the current release
vote checking process could (and should) be improved.
On 7/6/13 1:35 PM, John Casey wrote:
On 7/6/13 11:28 AM, sebb wrote:
The curent release candidate for Apache Maven War plugin 2.4 contains
the following file in the source zip:
maven-archiver/pom.properties
The file is not in SVN or the source jar
As far as I can tell it does not belong in the source zip.
The file is unlikely to do any harm, however the fact that it somehow
has crept into the source archive points to a problem with the release
process.
The file is present in all the WAR source zips back to 2.1 (previously
there were no source archives)
AFAICT these WAR source archives were built by several different people.
It does not seem to be present in sources for the few other plugin
sources that I checked.
So why does the file end up in the WAR source archive?
What is broken?
I'd be surprised if you didn't find the same file in other
source-release archives. I'm guessing it's an exclusion that's missing
from the source-release.xml assembly descriptor that we use to construct
these archives.
I found the problem by comparing the source archive with the SVN tag.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: How Maven works - definitions
Well ... first of all, if documentation is considered important or relevant, it should be easy to find. The first principle of design is to make the function/use of an object visible. Currently, the main maven documentation for practically everyone (except, perhaps, maven developers who digs around in the code quite a bit), is found at http://maven.apache.org/ ... and it is quite difficult to find your way from that page to the description of core concepts. For starters, one would have to know that the description of lifecycles is documented in maven-core. From a usability standpoint, I think that the start page could benefit greatly from being cleaned up. At the moment it contains a huge amount of links, and the structure of the maven site is not apparent - especially for a newcomer. Moreover, in terms of readability and usability I think we can learn from the TomEE example - refer, for example to the http://tomee.apache.org/documentation.html page for structuring and classifying information. I would argue that using twitter bootstrap mechanics for achieving readable and usable sites would be quite healthy for the Maven main site. 2013/7/7 Hervé BOUTEMY herve.bout...@free.fr yes, such doc is useful IMHO, since it took myself a lot of time to get it clear in my mind (particularly lifecycle-phase-goal) for the moment, I didn't find energy to write it down since I didn't know where to put it to get us work on improvements (and even if anybody would find it useful) it's probably a good time to work on it for the moment, I imagine putting such a desdcription (=Maven as a build tool) in maven-core artifact site [1] any other idea? Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/ Le dimanche 7 juillet 2013 12:59:05 Stéphane Nicoll a écrit : Maybe worth understanding why the current online documentation did not helped you. And maybe update it with this. Thanks. Sent from my iPhone On 07 Jul 2013, at 12:51, Lennart Jörelid lennart.jore...@gmail.com wrote: Hello there Mirko, I'd suggest fine-tuning the lifecycle-phase-plugin description slightly: - Maven is a tool to build software, which relies mainly on conventions. - The build is configured in an XML file called pom (project object model, or pom file). - Maven consists of a core and a plethora of plugins. Plugins can be included in the build by being configured within the pom file. - Maven builds stuff (often binaries) according to recipes outlined in lifecycles. Predefined lifecycles are called default, clean and site. - Lifecycles consist of sequences of named steps, called phases. The names of all phases are standarized, such as compile, test or install. - When Maven executes a phase, it announces the phase name to all plugins included in the build. - Plugins contain methods which perform specific actions like e.g. compiling java source to classes or running unit tests. These methods are given a symbolic name, called goal, and configured to run within a specified phase (known as binding a goal to a phase). - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which contains images but no source code, for example. 2013/7/7 Mirko Friedenhagen mfriedenha...@gmail.com Hello, I did not find an overview and now am trying to explain firstly myself and afterwards maybe others how Maven works (to other developers): - Maven is a declarative tool to build software, which relies mainly on conventions. - Declarations are done in a XML file called pom (project object model). - Maven consists of a small core and a plethora of plugins. - Maven builds stuff (often binaries) following paths outlined in lifecycles, predefined lifecycles are called default, clean and site. - Lifecycles are sequences of phases like e.g. compile, test or install. - Plugins provide a multitude of so called goals, which do specific stuff like e.g. compiling java source to classes or running unit tests. - The execution of goals is often bound to lifecycle phases. - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which only holds a pom, which is a XML file. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
Re: [VOTE] Apache 3.1.0
+1 (non-binding) Didn't try any of the new stuff explicitly though. /Anders On Sun, Jun 30, 2013 at 9:00 PM, Jason van Zyl ja...@tesla.io wrote: Here are the release bits for 3.1.0: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-084/ Staged distribution: https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/ Staged Site: http://maven.apache.org/ref/3.1.0 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: How Maven works - definitions
Hello, first of all, thanks for your replies. I think it would help very much if an introductory would be at the plugin development page[1] to get the big picture. Or even be repeated at the the run[2] page. Running Maven is trivial until you encounter problems or wish to extend stuff. I deal a lot with supporting our department (roughly 200 developers, 150 of whom are using Maven) and I am always reiterating explaining the basic glossary (phase, lifecycle, goal). While the Complete reference by Sonatype is great once you know the basics, it is quite extensive and not every application developer wants or needs to delve throught it :-) Regards Mirko [1] http://maven.apache.org/guides/plugin/guide-java-plugin-development.html [2] http://maven.apache.org/run-maven/index.html#Quick_Start Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Sun, Jul 7, 2013 at 4:14 PM, Lennart Jörelid lennart.jore...@gmail.com wrote: Well ... first of all, if documentation is considered important or relevant, it should be easy to find. The first principle of design is to make the function/use of an object visible. Currently, the main maven documentation for practically everyone (except, perhaps, maven developers who digs around in the code quite a bit), is found at http://maven.apache.org/ ... and it is quite difficult to find your way from that page to the description of core concepts. For starters, one would have to know that the description of lifecycles is documented in maven-core. From a usability standpoint, I think that the start page could benefit greatly from being cleaned up. At the moment it contains a huge amount of links, and the structure of the maven site is not apparent - especially for a newcomer. Moreover, in terms of readability and usability I think we can learn from the TomEE example - refer, for example to the http://tomee.apache.org/documentation.html page for structuring and classifying information. I would argue that using twitter bootstrap mechanics for achieving readable and usable sites would be quite healthy for the Maven main site. 2013/7/7 Hervé BOUTEMY herve.bout...@free.fr yes, such doc is useful IMHO, since it took myself a lot of time to get it clear in my mind (particularly lifecycle-phase-goal) for the moment, I didn't find energy to write it down since I didn't know where to put it to get us work on improvements (and even if anybody would find it useful) it's probably a good time to work on it for the moment, I imagine putting such a desdcription (=Maven as a build tool) in maven-core artifact site [1] any other idea? Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/ Le dimanche 7 juillet 2013 12:59:05 Stéphane Nicoll a écrit : Maybe worth understanding why the current online documentation did not helped you. And maybe update it with this. Thanks. Sent from my iPhone On 07 Jul 2013, at 12:51, Lennart Jörelid lennart.jore...@gmail.com wrote: Hello there Mirko, I'd suggest fine-tuning the lifecycle-phase-plugin description slightly: - Maven is a tool to build software, which relies mainly on conventions. - The build is configured in an XML file called pom (project object model, or pom file). - Maven consists of a core and a plethora of plugins. Plugins can be included in the build by being configured within the pom file. - Maven builds stuff (often binaries) according to recipes outlined in lifecycles. Predefined lifecycles are called default, clean and site. - Lifecycles consist of sequences of named steps, called phases. The names of all phases are standarized, such as compile, test or install. - When Maven executes a phase, it announces the phase name to all plugins included in the build. - Plugins contain methods which perform specific actions like e.g. compiling java source to classes or running unit tests. These methods are given a symbolic name, called goal, and configured to run within a specified phase (known as binding a goal to a phase). - There are standard definitions which goals should be run during a phase of a lifecycle and this is mostly dependent on the packaging, the type of binary produced. It makes no big sense to run the compiling goal for java sources on a project which contains images but no source code, for example. 2013/7/7 Mirko Friedenhagen mfriedenha...@gmail.com Hello, I did not find an overview and now am trying to explain firstly myself and afterwards maybe others how Maven works (to other developers): - Maven is a declarative tool to build software, which relies mainly on conventions. - Declarations are done in a XML file called pom (project object model). - Maven consists of a small core and a plethora of
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
I understand the issue but for me all that problems will never disappear if we don't find a solution to automate the process. Yes PMCs (and devs) are responsible to do various controls as you mentioned but I suppose that we aren't different to others projects and our time spent in OSS projects is often limited. About the problem of sources content I have two things in mind : * The release:perform goal is doing a checkout of the tag and then does the build/deploy of released stuffs. The problem is that the assembly which is creating the sources archive is doing it after the build instead of doing it just after the checkout. How could we change this to be sure that in the archive we just have what we just checkouted ? * We could add a control (enforcer ?) that will compare the content of an archive with an scm tag checkout Arnaud On Sun, Jul 7, 2013 at 9:31 PM, sebb seb...@gmail.com wrote: On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
On Sunday, 7 July 2013, Arnaud Héritier wrote: I understand the issue but for me all that problems will never disappear if we don't find a solution to automate the process. Yes PMCs (and devs) are responsible to do various controls as you mentioned but I suppose that we aren't different to others projects and our time spent in OSS projects is often limited. About the problem of sources content I have two things in mind : * The release:perform goal is doing a checkout of the tag and then does the build/deploy of released stuffs. The problem is that the assembly which is creating the sources archive is doing it after the build instead of doing it just after the checkout. How could we change this to be sure that in the archive we just have what we just checkouted ? If we bind the execution of the src assembly to the validate phase of the release profile, that would at least be capturing at the start... Should be possible to move the phase earlier for just the release profile. The alternative is to do a 2nd nested checkout to compare with... * We could add a control (enforcer ?) that will compare the content of an archive with an scm tag checkout Arnaud On Sun, Jul 7, 2013 at 9:31 PM, sebb seb...@gmail.com javascript:; wrote: On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com javascript:; wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier -- Sent from my phone
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
On 7 July 2013 20:39, Arnaud Héritier aherit...@gmail.com wrote: I understand the issue but for me all that problems will never disappear if we don't find a solution to automate the process. The point is that processes and people are not infallible Yes PMCs (and devs) are responsible to do various controls as you mentioned but I suppose that we aren't different to others projects and our time spent in OSS projects is often limited. It does not take long to do a comparison - assuming that the tag is provided in the vote e-mail. About the problem of sources content I have two things in mind : * The release:perform goal is doing a checkout of the tag and then does the build/deploy of released stuffs. The problem is that the assembly which is creating the sources archive is doing it after the build instead of doing it just after the checkout. How could we change this to be sure that in the archive we just have what we just checkouted ? That would reduce the window of opportunity for errors, but I'm convinced that Murphy's law can be entirely avoided. * We could add a control (enforcer ?) that will compare the content of an archive with an scm tag checkout There is already a Perl tool to compare directory structures: https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl I use that, as well as a GUI compare tool. Arnaud On Sun, Jul 7, 2013 at 9:31 PM, sebb seb...@gmail.com wrote: On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
On 7 July 2013 20:52, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Sunday, 7 July 2013, Arnaud Héritier wrote: I understand the issue but for me all that problems will never disappear if we don't find a solution to automate the process. Yes PMCs (and devs) are responsible to do various controls as you mentioned but I suppose that we aren't different to others projects and our time spent in OSS projects is often limited. About the problem of sources content I have two things in mind : * The release:perform goal is doing a checkout of the tag and then does the build/deploy of released stuffs. The problem is that the assembly which is creating the sources archive is doing it after the build instead of doing it just after the checkout. How could we change this to be sure that in the archive we just have what we just checkouted ? If we bind the execution of the src assembly to the validate phase of the release profile, that would at least be capturing at the start... Should be possible to move the phase earlier for just the release profile. This sort of takes us back to where we started, which is that people believed that the process was infallible. It's basically impossible to prove that the release process is correct. All you can do is try and design it so that it works as well as it can, and fix it when it breaks. The alternative is to do a 2nd nested checkout to compare with... That's effectively what I'm suggesting, except as an independent process which is less likely to be affected by issues in the process it is trying to check. It's really not that difficult. It's also important that independent reviewers are able to check the release candidate, should they wish to do so. * We could add a control (enforcer ?) that will compare the content of an archive with an scm tag checkout Arnaud On Sun, Jul 7, 2013 at 9:31 PM, sebb seb...@gmail.com javascript:; wrote: On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com javascript:; wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
Le dimanche 7 juillet 2013 20:53:02 sebb a écrit : On 7 July 2013 20:39, Arnaud Héritier aherit...@gmail.com wrote: I understand the issue but for me all that problems will never disappear if we don't find a solution to automate the process. The point is that processes and people are not infallible the actual *process* is not in fault: there is a bug in the implementation for this artifact, and we need to continue to improve it Yes PMCs (and devs) are responsible to do various controls as you mentioned but I suppose that we aren't different to others projects and our time spent in OSS projects is often limited. It does not take long to do a comparison - assuming that the tag is provided in the vote e-mail. the tag is in the site provided in the vote, in the mailing lists, immediately defined by convention, and so on: this info is really not difficult to find, absolutely requesting this info explicitely in the mail vote is really IMHO some form of extremism About the problem of sources content I have two things in mind : * The release:perform goal is doing a checkout of the tag and then does the build/deploy of released stuffs. The problem is that the assembly which is creating the sources archive is doing it after the build instead of doing it just after the checkout. How could we change this to be sure that in the archive we just have what we just checkouted ? That would reduce the window of opportunity for errors, but I'm convinced that Murphy's law can be entirely avoided. as far as the process is reproducible, I don't have any problem if sometimes the result isn't magically as expected: it's like every bug we find and fix * We could add a control (enforcer ?) that will compare the content of an archive with an scm tag checkout There is already a Perl tool to compare directory structures: https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs. pl I use that, as well as a GUI compare tool. no problem for people to use whatever tool they want to help them Regards, Hervé Arnaud On Sun, Jul 7, 2013 at 9:31 PM, sebb seb...@gmail.com wrote: On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. The issue is that the release process is clearly not infallible. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How Maven works - definitions
On 8 July 2013 04:01, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, first of all, thanks for your replies. I think it would help very much if an introductory would be at the plugin development page[1] to get the big picture. Or even be repeated at the the run[2] page. Running Maven is trivial until you encounter problems or wish to extend stuff. I deal a lot with supporting our department (roughly 200 developers, 150 of whom are using Maven) and I am always reiterating explaining the basic glossary (phase, lifecycle, goal). While the Complete reference by Sonatype is great once you know the basics, it is quite extensive and not every application developer wants or needs to delve throught it :-) I will agree the documentation could be improved. I've also said in the past that one of Maven's problems is that it just works for most people. Compare that to Ant where before you can build a project you must read the README, configure your project settings file and then try to build, often trouble shooting by looking at the Ant website. This means the average user of Ant has picked up more stuff because they are forced to. In Maven only the person who is modifying the poms generally acquires more in depth knowledge of Maven - including terminology. Which means when someone does need to work out what went wrong there is a steep learning curve because it was not amortized over time. Ideas on how to fix that are welcome. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
On Mon, Jul 8, 2013 at 5:31 AM, sebb seb...@gmail.com wrote: On 7 July 2013 13:45, Chris Graham chrisgw...@gmail.com wrote: In this instance, these files are derived files, so does it matter? I already said that this particular file is probably not an issue. I think that you missed my point, namely the case of derived files. The issue is that the release process is clearly not infallible. There is nothing wrong with the process. One of the core tennants of SCM is reproducability. If you were to check the tag out and rebuild it, you should achieve the same result. If you do not, then, and only then do you have a _process_ issue. And only then, if you are not able to explain any differences (timestamps in files here is a leading cause of differences). In this case we have a _configuration_ issue, not a _process_ issue. The assembly plugin does not identify every file it needs to include, so spurious files can be picked up if they happen to be in the wrong place. As happened here. Furthermore, AFAIK it does not report include failures, so a required file could be omitted. In this case, there was an issue with a test creating the spurious file. If test cases delete work files after use, it's not impossible to imagine that the wrong file is deleted. But regardless of the process used to create the release candidate, I think the way to check whether it has the correct contents is to compare it against the SCM from which it was derived. The comparison will identify missing and spurious files. Files that match the SCM also have a traceable provenance, and SCM files should already have been validated for license compatibility. I see this as basic quality control. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1500550 - /maven/archetype/trunk/pom.xml
this means archetype will be 1.6 required (http://commons.apache.org/proper/commons-io/). Is it the goal? 2013/7/8 aherit...@apache.org: Author: aheritier Date: Sun Jul 7 23:21:09 2013 New Revision: 1500550 URL: http://svn.apache.org/r1500550 Log: Update commons-io 2.2 - 2.4 Modified: maven/archetype/trunk/pom.xml Modified: maven/archetype/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/archetype/trunk/pom.xml?rev=1500550r1=1500549r2=1500550view=diff == --- maven/archetype/trunk/pom.xml (original) +++ maven/archetype/trunk/pom.xml Sun Jul 7 23:21:09 2013 @@ -146,7 +146,7 @@ under the License. dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId -version2.2/version +version2.4/version /dependency dependency groupIdorg.codehaus.plexus/groupId -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1500547 - /maven/site/trunk/content/apt/docs/history.apt
On 7 July 2013 23:36, hbout...@apache.org wrote: Author: hboutemy Date: Sun Jul 7 22:36:42 2013 New Revision: 1500547 URL: http://svn.apache.org/r1500547 Log: added releases history Added: maven/site/trunk/content/apt/docs/history.apt (with props) Added: maven/site/trunk/content/apt/docs/history.apt URL: http://svn.apache.org/viewvc/maven/site/trunk/content/apt/docs/history.apt?rev=1500547view=auto == --- maven/site/trunk/content/apt/docs/history.apt (added) +++ maven/site/trunk/content/apt/docs/history.apt Sun Jul 7 22:36:42 2013 @@ -0,0 +1,158 @@ + -- +Maven Releases History + -- +Hervé Boutemy Missing SVN property here - the mailer does not know the correct encoding. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1500550 - /maven/archetype/trunk/pom.xml
Damned no. This test commit shouldn't have land it. I will revert it. Sorry for the noise. - Arnaud Le 8 juil. 2013 à 02:33, Olivier Lamy ol...@apache.org a écrit : this means archetype will be 1.6 required (http://commons.apache.org/proper/commons-io/). Is it the goal? 2013/7/8 aherit...@apache.org: Author: aheritier Date: Sun Jul 7 23:21:09 2013 New Revision: 1500550 URL: http://svn.apache.org/r1500550 Log: Update commons-io 2.2 - 2.4 Modified: maven/archetype/trunk/pom.xml Modified: maven/archetype/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/archetype/trunk/pom.xml?rev=1500550r1=1500549r2=1500550view=diff == --- maven/archetype/trunk/pom.xml (original) +++ maven/archetype/trunk/pom.xml Sun Jul 7 23:21:09 2013 @@ -146,7 +146,7 @@ under the License. dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId -version2.2/version +version2.4/version /dependency dependency groupIdorg.codehaus.plexus/groupId -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
