[mojo-dev] [jira] (MVERSIONS-259) Website is missing the update-property goal in the index
Title: Message Title Baptiste Mathus created an issue Mojo's Versions Maven Plugin / MVERSIONS-259 Website is missing the update-property goal in the index Issue Type: Bug Affects Versions: 2.1 Assignee: Unassigned Created: 30/Jun/14 9:00 AM Priority: Trivial Reporter: Baptiste Mathus The page is actually generated and present: http://mojo.codehaus.org/versions-maven-plugin/update-property-mojo.html, but missing from the main page http://mojo.codehaus.org/versions-maven-plugin/ Add Comment This message was sent by
[mojo-dev] [jira] (MVERSIONS-259) Website is missing the update-property goal in the index
Title: Message Title Baptiste Mathus closed an issue as Fixed Fixed in r19840. Mojo's Versions Maven Plugin / MVERSIONS-259 Website is missing the update-property goal in the index Change By: Baptiste Mathus Resolution: Fixed Assignee: Baptiste Mathus Status: Open Closed Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MVERSIONS-259) Website is missing the update-property goal in the index
Title: Message Title Baptiste Mathus edited a comment on an issue Re: Website is missing the update-property goal in the index Fixed in r19840. Merci Sylvain Monteillet ! Add Comment Mojo's Versions Maven Plugin / MVERSIONS-259 Website is missing the update-property goal in the index The page is actually generated and present: http://mojo.codehaus.org/versions-maven-plugin/update-property-mojo.html, but missing from the main page http://mojo.codehaus.org/versions-maven-plugin/ This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MVERSIONS-259) Website is missing the update-property goal in the index
Title: Message Title Baptiste Mathus edited a comment on an issue Re: Website is missing the update-property goal in the index Fixed in r19840. Merci Sylvain! Add Comment Mojo's Versions Maven Plugin / MVERSIONS-259 Website is missing the update-property goal in the index The page is actually generated and present: http://mojo.codehaus.org/versions-maven-plugin/update-property-mojo.html, but missing from the main page http://mojo.codehaus.org/versions-maven-plugin/ This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MSONAR-81) On "war" modules the directory containing the web resources ("src/main/webapp" by default) should be automatically added to "sonar.sources"
Title: Message Title
Julien HENRY updated an issue
Mojo's Sonar Maven Plugin / MSONAR-81
On "war" modules the directory containing the web resources ("src/main/webapp" by default) should be automatically added to "sonar.sources"
Change By:
Julien HENRY
Summary:
On "war" modules the directory (ies) containing the web resources ("src/main/webapp" by default) should be automatically added to "sonar.sources"
Add Comment
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MSONAR-75) Remove unexisting entries from "sonar.sources" and "sonar.tests" on projects with packaging=pom
Title: Message Title Julien HENRY updated an issue Mojo's Sonar Maven Plugin / MSONAR-75 Remove unexisting entries from "sonar.sources" and "sonar.tests" on projects with packaging=pom Change By: Julien HENRY Summary: Ignore Remove unexisting entries from "sonar.sources" and "sonar.tests" on projects with packaging=pom Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MSONAR-81) On "war" modules the directory containing the web resources ("src/main/webapp" by default) should be automatically added to "sonar.sources"
Title: Message Title
Julien HENRY commented on an issue
Re: On "war" modules the directory containing the web resources ("src/main/webapp" by default) should be automatically added to "sonar.sources"
Done
Add Comment
Mojo's Sonar Maven Plugin / MSONAR-81
On "war" modules the directory containing the web resources ("src/main/webapp" by default) should be automatically added to "sonar.sources"
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MOJO-1945) tidy check goal
Title: Message Title Stefan Birkner commented on an issue Re: tidy check goal Fixed in r19842. Add Comment Mojo / MOJO-1945 tidy check goal a tidy:check goal bound to the verify phase would be really handy to ensure that the pom is always valid. e.g. fail the build if the pom is not in the correct order. This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MOJO-1945) tidy check goal
Title: Message Title Stefan Birkner closed an issue as Fixed Mojo / MOJO-1945 tidy check goal Change By: Stefan Birkner Resolution: Fixed Fix Version/s: tidy-maven-plugin-1.0-beta-1 Status: In Progress Closed Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
Re: [mojo-dev] [VOTE] Release MOJODEV Maven Plugin - Release 1.0-beta-1 (take 2)
Hi Dan, I start to wonder if its worth such a plugin. the prepare-eclipse is called once per workspace per user (a workspace can have multiple projects) if you're talking about setting the code format. the prepare-project is done only once per project, the ignore files are checked in, so other users have the same set of ignorable files. the import-codehaus-certificate is called once per environment. The amount of work to call a maven plugin and to do it by hand is about the same I guess. And by doing it by hand users are probably more aware of what they are doing. Sure it can be done by Maven, but IMHO a batch-file seems just as simple in this case. If others think differently they should say so, I'd prefer to have plugins for the right reason. thanks, Robert Op Mon, 30 Jun 2014 01:57:46 +0200 schreef Dan Tran : I must admin i am rushing to push it to Central since there is another project at workshop.perforce.com that I like to use prepare-eclipse officially ( available at central). But that can be delay to get a conscientious agreement at MOJO. Historically, I started out with this plugin due to the need to configure my eclipse workspace to load Maven core, its plugins and plugins at MOJO. And then codehaus certificates automated. And therefor its become very specific for MOJO development at codehaus. However It does not mean other ppl can not use it. This is where plugindev does not make sense to me. So I would propose that to rename 'prepare-environment' back to 'import-codehaus-certificate' ( rather then removing it) and call it alpha, to let ppl know it it very specify MOJO at codehaus development. Thanks -Dan On Sun, Jun 29, 2014 at 12:25 PM, Robert Scholte wrote: This is exactly the reason why there is a separate phase for getting plugins out of the sandbox. I often hear people complaining about backwards compatibility, so we should at least try to have a clear vision on this plugin. For now I'd say: - remove the prepare-environment goal, since environments are too hard to configure for a specific project. - rename the plugin to plugindev-maven-plugin, so it is much more clear it's about plugin development, not a specific mojo-team plugin. - and yes, start at least with an alpha. Personally I find it hard to understand there a sudden need to push a brand new plugin into central within such a small amount of time. Instead I'd prefer to refer to use the SNAPSHOT-repository of Codehaus if that's possible. Robert Op Sun, 29 Jun 2014 20:35:56 +0200 schreef Dan Tran : I advocate to push it to maven central since other project can use it as well including my internal plugin development. BTW, I have a really need for this. What would it take todo so? should we push it as alpha while waiting for more concrete decision? -D On Sun, Jun 29, 2014 at 2:33 AM, Robert Scholte < codeh...@sourcegrounds.com> wrote: Hi Dan, I see some comparison with one of my old plugins. About 2,5 years ago I started the setup-maven-plugin[1] Main reasons were: - the maven-install-plugin doesn't install Maven. - there are a lot of unknown configuration files for Maven. By bundling these into 1 plugin I hoped it could help the community. However, the plugin only works if: - it is in Maven central - the user can or is allowed to connect to Maven Central (users with a Repository Manager are kind of doomed) Otherwise the user still has to define its own settings.xml. So here we have our chicken-egg problem, though I still think that the base is good. So the "mojo" part of the name of your plugin means actually Mojo as in Maven-Plugin instead of the Codehaus Mojo team. I still think that "prepare-environment" is correct, but you should be able to add an argument for which certificates should be installed. So " codehaus.org" should map to the already specified URL's. The prepare-eclipse is actually also Codehaus Mojo specific. The only general thing is prepare-project, which could be enriched with other scm types. IMHO we should make a decision: either make it for the mojo-team only and don't push it to Maven Central or make it for maven-plugin development in general and make it more configurable, e.g. by URL. Robert [1] http://mojo.codehaus.org/setup/setup-maven-plugin/index.html Op Sun, 29 Jun 2014 01:20:57 +0200 schreef Dan Tran : Hi Robert, I think this plugin is helpful for those using Maven code style. Apache Maven and MOJO dev team can use it.. I also has the another Maven SCM Provider for Perforce using P4Java hosted at workshop.perforce.com That is why it is needed at Maven Central. The only unrelated goal is prepare-environment, perhaps I should change it back to 'import-codehaus-certificates. Thoughts? Thanks -Dan On Sat, Jun 28, 2014 at 3:08 AM, Robert Scholte < codeh...@sourcegrounds.com> wrote: I agree with Baptiste here. I'm also wondering if this project should be pushed to Maven central, since
Re: [mojo-dev] [VOTE] Release MOJODEV Maven Plugin - Release 1.0-beta-1 (take 2)
Hi Robert, I am very often wipe out my workspace and redo it with confident I can recreated quickly. Here is list of thing prepare-eclipse automated - Push Maven java code formatter into the workspace - Configure all XML related files use 2 spaces indent and 120 spaces, quite a few steps - Configure m2e to pickup my Maven Must agree prepare-project is hardly needed specially with SVN since it also commit for you at MOJO project. It only good for new plugin. but I uses it for other projects at work as well ( we adopt maven code style and svn). import-codehaus-certificate is very helpful, try to read the instructions from Codehaus and import manually is a pain IMO Thanks -Dan On Mon, Jun 30, 2014 at 2:32 PM, Robert Scholte wrote: > Hi Dan, > > I start to wonder if its worth such a plugin. > > the prepare-eclipse is called once per workspace per user (a workspace can > have multiple projects) if you're talking about setting the code format. > the prepare-project is done only once per project, the ignore files are > checked in, so other users have the same set of ignorable files. > the import-codehaus-certificate is called once per environment. > > The amount of work to call a maven plugin and to do it by hand is about > the same I guess. And by doing it by hand users are probably more aware of > what they are doing. > Sure it can be done by Maven, but IMHO a batch-file seems just as simple > in this case. > > If others think differently they should say so, I'd prefer to have plugins > for the right reason. > > thanks, > Robert > > Op Mon, 30 Jun 2014 01:57:46 +0200 schreef Dan Tran : > > > I must admin i am rushing to push it to Central since there is another >> project at workshop.perforce.com that I like to use prepare-eclipse >> officially ( available at central). But that can be delay to get a >> conscientious agreement at MOJO. >> >> Historically, I started out with this plugin due to the need to configure >> my eclipse workspace to load Maven core, its plugins and plugins at MOJO. >> And then codehaus certificates automated. And therefor its become very >> specific for MOJO development at codehaus. However It does not mean other >> ppl can not use it. This is where plugindev does not make sense to me. >> >> So I would propose that to rename 'prepare-environment' back to >> 'import-codehaus-certificate' ( rather then removing it) and call it >> alpha, >> to let ppl know it it very specify MOJO at codehaus development. >> >> Thanks >> >> -Dan >> >> >> >> On Sun, Jun 29, 2014 at 12:25 PM, Robert Scholte < >> codeh...@sourcegrounds.com >> >>> wrote: >>> >> >> This is exactly the reason why there is a separate phase for getting >>> plugins out of the sandbox. >>> I often hear people complaining about backwards compatibility, so we >>> should at least try to have a clear vision on this plugin. >>> For now I'd say: >>> - remove the prepare-environment goal, since environments are too hard to >>> configure for a specific project. >>> - rename the plugin to plugindev-maven-plugin, so it is much more clear >>> it's about plugin development, not a specific mojo-team plugin. >>> - and yes, start at least with an alpha. Personally I find it hard to >>> understand there a sudden need to push a brand new plugin into central >>> within such a small amount of time. Instead I'd prefer to refer to use >>> the >>> SNAPSHOT-repository of Codehaus if that's possible. >>> >>> Robert >>> >>> Op Sun, 29 Jun 2014 20:35:56 +0200 schreef Dan Tran : >>> >>> >>> I advocate to push it to maven central since other project can use it as >>> well including my internal plugin development. BTW, I have a really need for this. What would it take todo so? should we push it as alpha while waiting for more concrete decision? -D On Sun, Jun 29, 2014 at 2:33 AM, Robert Scholte < codeh...@sourcegrounds.com> wrote: Hi Dan, > > I see some comparison with one of my old plugins. > About 2,5 years ago I started the setup-maven-plugin[1] > Main reasons were: > - the maven-install-plugin doesn't install Maven. > - there are a lot of unknown configuration files for Maven. > By bundling these into 1 plugin I hoped it could help the community. > However, the plugin only works if: > - it is in Maven central > - the user can or is allowed to connect to Maven Central (users with a > Repository Manager are kind of doomed) > Otherwise the user still has to define its own settings.xml. > So here we have our chicken-egg problem, though I still think that the > base is good. > > So the "mojo" part of the name of your plugin means actually Mojo as in > Maven-Plugin instead of the Codehaus Mojo team. > I still think that "prepare-environment" is correct, but you should be > able to add an argument for which certificates should be installed. So > " > codehaus.org" shoul
Re: [mojo-dev] [VOTE] Release MOJODEV Maven Plugin - Release 1.0-beta-1 (take 2)
Look like garvin.leclaire is using it. -D On Mon, Jun 30, 2014 at 3:21 PM, Dan Tran wrote: > Hi Robert, > > I am very often wipe out my workspace and redo it with confident I can > recreated quickly. Here is list of thing prepare-eclipse automated > > - Push Maven java code formatter into the workspace > - Configure all XML related files use 2 spaces indent and 120 spaces, > quite a few steps > - Configure m2e to pickup my Maven > > Must agree prepare-project is hardly needed specially with SVN since it > also commit for you at MOJO project. It only good for new plugin. but I > uses it for other projects at work as well ( we adopt maven code style and > svn). > > import-codehaus-certificate is very helpful, try to read the instructions > from Codehaus and import manually is a pain IMO > > > Thanks > > -Dan > > > On Mon, Jun 30, 2014 at 2:32 PM, Robert Scholte < > codeh...@sourcegrounds.com> wrote: > >> Hi Dan, >> >> I start to wonder if its worth such a plugin. >> >> the prepare-eclipse is called once per workspace per user (a workspace >> can have multiple projects) if you're talking about setting the code format. >> the prepare-project is done only once per project, the ignore files are >> checked in, so other users have the same set of ignorable files. >> the import-codehaus-certificate is called once per environment. >> >> The amount of work to call a maven plugin and to do it by hand is about >> the same I guess. And by doing it by hand users are probably more aware of >> what they are doing. >> Sure it can be done by Maven, but IMHO a batch-file seems just as simple >> in this case. >> >> If others think differently they should say so, I'd prefer to have >> plugins for the right reason. >> >> thanks, >> Robert >> >> Op Mon, 30 Jun 2014 01:57:46 +0200 schreef Dan Tran : >> >> >> I must admin i am rushing to push it to Central since there is another >>> project at workshop.perforce.com that I like to use prepare-eclipse >>> officially ( available at central). But that can be delay to get a >>> conscientious agreement at MOJO. >>> >>> Historically, I started out with this plugin due to the need to >>> configure >>> my eclipse workspace to load Maven core, its plugins and plugins at MOJO. >>> And then codehaus certificates automated. And therefor its become very >>> specific for MOJO development at codehaus. However It does not mean other >>> ppl can not use it. This is where plugindev does not make sense to me. >>> >>> So I would propose that to rename 'prepare-environment' back to >>> 'import-codehaus-certificate' ( rather then removing it) and call it >>> alpha, >>> to let ppl know it it very specify MOJO at codehaus development. >>> >>> Thanks >>> >>> -Dan >>> >>> >>> >>> On Sun, Jun 29, 2014 at 12:25 PM, Robert Scholte < >>> codeh...@sourcegrounds.com >>> wrote: >>> >>> This is exactly the reason why there is a separate phase for getting plugins out of the sandbox. I often hear people complaining about backwards compatibility, so we should at least try to have a clear vision on this plugin. For now I'd say: - remove the prepare-environment goal, since environments are too hard to configure for a specific project. - rename the plugin to plugindev-maven-plugin, so it is much more clear it's about plugin development, not a specific mojo-team plugin. - and yes, start at least with an alpha. Personally I find it hard to understand there a sudden need to push a brand new plugin into central within such a small amount of time. Instead I'd prefer to refer to use the SNAPSHOT-repository of Codehaus if that's possible. Robert Op Sun, 29 Jun 2014 20:35:56 +0200 schreef Dan Tran >>> >: I advocate to push it to maven central since other project can use it as > well including my internal plugin development. BTW, I have a really > need > for this. > > What would it take todo so? should we push it as alpha while waiting > for > more concrete decision? > > -D > > > > > > > On Sun, Jun 29, 2014 at 2:33 AM, Robert Scholte < > codeh...@sourcegrounds.com> > wrote: > > Hi Dan, > >> >> I see some comparison with one of my old plugins. >> About 2,5 years ago I started the setup-maven-plugin[1] >> Main reasons were: >> - the maven-install-plugin doesn't install Maven. >> - there are a lot of unknown configuration files for Maven. >> By bundling these into 1 plugin I hoped it could help the community. >> However, the plugin only works if: >> - it is in Maven central >> - the user can or is allowed to connect to Maven Central (users with a >> Repository Manager are kind of doomed) >> Otherwise the user still has to define its own settings.xml. >> So here we have our chicken-egg problem, though I still think that the >> base is good. >> >> So
