Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Brian,
Did you have any suggested changes to the forks section wording to clear up
my intent for that section?
I'd like to start wrapping this up and move towards making it official
Everyone else,
Time to shout out if you have any issues / suggested improvements on the
content
- Stephen
On Friday, 2 August 2013, Stephen Connolly wrote:
On 2 August 2013 16:07, Brian Fox bri...@infinity.nu javascript:_e({},
'cvml', 'bri...@infinity.nu'); wrote:
I think the bulk of this is pretty good. On the fork section,
specifically:
As soon as changes in that
fork are identified which should be brought back to the project those
changes should be introduced into at least a branch hosted on the Apache
Maven
source control in order to facilitate the easier review by the community.
The PMC should encourage by example the early committing of changes from a
fork back to Apache Maven source control.
This seems to want to compel code to be brought back as a
responsibility, I don't think we need to spell that out.
This is why I say as soon as ... are identified
The wording could be clearer... if somebody can figure out a better way to
say it.
Basically, as soon as you say something like... Oh commit 1a2b3d4e, we
really need to get that into Maven itself, it's too good to be in our
fork... you should be trying to hasten getting that commit into Maven
itself and if you are on the PMC and one of your commits is one that
you say this of... you should just commit it back.
Until you realise that a commit is one that you want to push to Maven, hey
it's your work... whatever... but as soon as you identify the change as
being one that should be at Maven, as a PMC member you are expected to try
and get it into Maven quickly so that others working on the fork see that
this is the example by which the PMC leads.
If you can think of a clearer way to express that than my wording (which
since you are not getting my intended meaning must therefore be lacking)
please update.
The section
about the downsides to not doing so and attempting to do it later is
really the core of the concerns... the extra diligence required to
consume large bodies of work is bigger. That doesn't mean that code
contributions are inherently bad just because they were developed
elsewhere, it's just harder to pull in.
Correct.
On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I have updated the project-roles with my thoughts resulting from the
healthy debate on the list and some debates elsewhere.
If anyone wants to look at the resulting Work In Progress document as a
whole:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup
Thoughts?
-Stephen
-- Forwarded message --
From: steph...@apache.org
Date: 2 August 2013 10:52
Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
project-roles.md
To: comm...@maven.apache.org
Author: stephenc
Date: Fri Aug 2 09:52:11 2013
New Revision: 1509594
URL: http://svn.apache.org/r1509594
Log:
After a lengthy discussion on the users@maven list and some
side discussions on members@apache, I think the following changes
are more in line with what we should be seeking as responsibilities
of the PMC.
* Forks are not bad... letting changes stack up in the fork is bad
but more from a 'it will be hard to review' point of view...
similarly using a fork to get external contributions complicates
the tracablity
* We are not obligated to promote other ASF projects... but there
should be a symmetry in how that lack of obligation plays out
* I identified some
--
Sent from my phone
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Some small formating or typos.
Added commas in a long sentence around line 280 and another one around
l298. I generally find it hard to concentrate on a whole sentence without
commas (or even periods separating ideas).
See https://gist.github.com/Batmat/6155302 for proposed patch.
If you need any other attachment format, just let me know.
Cheers
2013/8/5 Stephen Connolly stephen.alan.conno...@gmail.com
Brian,
Did you have any suggested changes to the forks section wording to clear up
my intent for that section?
I'd like to start wrapping this up and move towards making it official
Everyone else,
Time to shout out if you have any issues / suggested improvements on the
content
- Stephen
On Friday, 2 August 2013, Stephen Connolly wrote:
On 2 August 2013 16:07, Brian Fox bri...@infinity.nu javascript:_e({},
'cvml', 'bri...@infinity.nu'); wrote:
I think the bulk of this is pretty good. On the fork section,
specifically:
As soon as changes in that
fork are identified which should be brought back to the project those
changes should be introduced into at least a branch hosted on the Apache
Maven
source control in order to facilitate the easier review by the
community.
The PMC should encourage by example the early committing of changes
from a
fork back to Apache Maven source control.
This seems to want to compel code to be brought back as a
responsibility, I don't think we need to spell that out.
This is why I say as soon as ... are identified
The wording could be clearer... if somebody can figure out a better way
to
say it.
Basically, as soon as you say something like... Oh commit 1a2b3d4e, we
really need to get that into Maven itself, it's too good to be in our
fork... you should be trying to hasten getting that commit into Maven
itself and if you are on the PMC and one of your commits is one that
you say this of... you should just commit it back.
Until you realise that a commit is one that you want to push to Maven,
hey
it's your work... whatever... but as soon as you identify the change as
being one that should be at Maven, as a PMC member you are expected to
try
and get it into Maven quickly so that others working on the fork see that
this is the example by which the PMC leads.
If you can think of a clearer way to express that than my wording (which
since you are not getting my intended meaning must therefore be lacking)
please update.
The section
about the downsides to not doing so and attempting to do it later is
really the core of the concerns... the extra diligence required to
consume large bodies of work is bigger. That doesn't mean that code
contributions are inherently bad just because they were developed
elsewhere, it's just harder to pull in.
Correct.
On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I have updated the project-roles with my thoughts resulting from the
healthy debate on the list and some debates elsewhere.
If anyone wants to look at the resulting Work In Progress document as a
whole:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup
Thoughts?
-Stephen
-- Forwarded message --
From: steph...@apache.org
Date: 2 August 2013 10:52
Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
project-roles.md
To: comm...@maven.apache.org
Author: stephenc
Date: Fri Aug 2 09:52:11 2013
New Revision: 1509594
URL: http://svn.apache.org/r1509594
Log:
After a lengthy discussion on the users@maven list and some
side discussions on members@apache, I think the following changes
are more in line with what we should be seeking as responsibilities
of the PMC.
* Forks are not bad... letting changes stack up in the fork is bad
but more from a 'it will be hard to review' point of view...
similarly using a fork to get external contributions complicates
the tracablity
* We are not obligated to promote other ASF projects... but there
should be a symmetry in how that lack of obligation plays out
* I identified some
--
Sent from my phone
--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
PDF Plugin filtering
Hi folks,I am fairly new to maven and I am currently playing with Maven PDF
Plugin trying to generate a document. It works fine but when I need to use
some POM defined properties I hit the wall. For instance if I use .apt.vm
file I enable the filtering, but the properties I have defined are not being
substituted.If I use an apt system property as ${project.name} it works
fine, but if I use ${myProperty} it just don't substitute it.in pom.xml I do
haveMy other value and it also
works fine if I use
it in pdf.xml, but not if I do it in a content file.Any idea on that issue?
What am I missing?Thanks,Nikola
--
View this message in context:
http://maven.40175.n5.nabble.com/PDF-Plugin-filtering-tp5766783.html
Sent from the Maven - Users mailing list archive at Nabble.com.
PDF Plugin custom properties do not appear
Hi all,
I am trying to generate a PDF, but I face the following issue.
Although I do have properties defined in my pom.xml they are not properly
filtered in any type of content I use.
e.g. I have the property defined in pom.xml
properties
myPropertyMy other value/myProperty
/properties
If I use this property in pdf.xml it appears in the generated PDF, but if I
set it in an .apt.vm file as ${myProperty} it doesn't.
The apt file is also with .vm extension as documented on the site.
On the other hand properties as ${project.name} work fine.
Do you have an idea what am I missing?
Thanks,
Nikola
how to make the SVN release process more robust
Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to make the SVN release process more robust
Hi Nathan, No one should ever be committing to an SVN tag that already exists. Unless the team has malicious committers? Or very clueless ones? In which case you have much bigger problems... In other words: isn't this more of a social issue? -Curtis On Aug 5, 2013 9:51 AM, Nathan Coast nathan.co...@db.com wrote: Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to make the SVN release process more robust
Hi, Well, as this is actually something that the SCM itself allows, I would consider just forbidding on my svn server. This might be an interesting evolution though to be able to enforce this at the maven-release-plugin (though unlikely to happen often since the three usual commits actually happen very close to each others). Cheers 2013/8/5 Nathan Coast nathan.co...@db.com Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Yes, I will take a pass tonight.
On Mon, Aug 5, 2013 at 6:55 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Brian,
Did you have any suggested changes to the forks section wording to clear up
my intent for that section?
I'd like to start wrapping this up and move towards making it official
Everyone else,
Time to shout out if you have any issues / suggested improvements on the
content
- Stephen
On Friday, 2 August 2013, Stephen Connolly wrote:
On 2 August 2013 16:07, Brian Fox bri...@infinity.nu javascript:_e({},
'cvml', 'bri...@infinity.nu'); wrote:
I think the bulk of this is pretty good. On the fork section,
specifically:
As soon as changes in that
fork are identified which should be brought back to the project those
changes should be introduced into at least a branch hosted on the Apache
Maven
source control in order to facilitate the easier review by the community.
The PMC should encourage by example the early committing of changes from a
fork back to Apache Maven source control.
This seems to want to compel code to be brought back as a
responsibility, I don't think we need to spell that out.
This is why I say as soon as ... are identified
The wording could be clearer... if somebody can figure out a better way to
say it.
Basically, as soon as you say something like... Oh commit 1a2b3d4e, we
really need to get that into Maven itself, it's too good to be in our
fork... you should be trying to hasten getting that commit into Maven
itself and if you are on the PMC and one of your commits is one that
you say this of... you should just commit it back.
Until you realise that a commit is one that you want to push to Maven, hey
it's your work... whatever... but as soon as you identify the change as
being one that should be at Maven, as a PMC member you are expected to try
and get it into Maven quickly so that others working on the fork see that
this is the example by which the PMC leads.
If you can think of a clearer way to express that than my wording (which
since you are not getting my intended meaning must therefore be lacking)
please update.
The section
about the downsides to not doing so and attempting to do it later is
really the core of the concerns... the extra diligence required to
consume large bodies of work is bigger. That doesn't mean that code
contributions are inherently bad just because they were developed
elsewhere, it's just harder to pull in.
Correct.
On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I have updated the project-roles with my thoughts resulting from the
healthy debate on the list and some debates elsewhere.
If anyone wants to look at the resulting Work In Progress document as a
whole:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup
Thoughts?
-Stephen
-- Forwarded message --
From: steph...@apache.org
Date: 2 August 2013 10:52
Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
project-roles.md
To: comm...@maven.apache.org
Author: stephenc
Date: Fri Aug 2 09:52:11 2013
New Revision: 1509594
URL: http://svn.apache.org/r1509594
Log:
After a lengthy discussion on the users@maven list and some
side discussions on members@apache, I think the following changes
are more in line with what we should be seeking as responsibilities
of the PMC.
* Forks are not bad... letting changes stack up in the fork is bad
but more from a 'it will be hard to review' point of view...
similarly using a fork to get external contributions complicates
the tracablity
* We are not obligated to promote other ASF projects... but there
should be a symmetry in how that lack of obligation plays out
* I identified some
--
Sent from my phone
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Hi,,,I have a problem with the PMD plugin for maven. For our project I have,defined a custom rulest for PMD in an XML file [1]. This ruleset defines,properties for some of the standard PMD rules using
Hi, I have a problem with the PMD plugin for maven. For our project I have defined a custom ruleset for PMD in an XML file [1]. This ruleset defines properties for some of the standard PMD rules using this syntax: rule ref=rulesets/java/naming.xml/LongVariable properties property name=minimum value=25/ /properties /rule When I execute PMD using a parallel ant file we maintain, these custom properties are respected correctly. However, when executing PMD through maven, the properties are completely ignored. And idea what could cause this? Thanks for any help, Johannes The pom.xml we are using is available at [2]. [1] https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml [2] https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml signature.asc Description: OpenPGP digital signature
Unmaving a project
Hello, English is not my native language; please excuse typing errors. I need to unmave a project because in the place I work Maven is not used. The problem is that I downloaded a lot of source-code from a book and all it´s content are Maven Projects. I found easy to make the projects work as Maven Projects... just import a Maven Project, configure my application server - I am using Jboss 7.0, and run them. I could easily configure this projects after testing it and change them to my needs. But since we don´t use Maven here, I started trying to disable the Maven nature of a project and I couldn´t get the project to work. I deleted the pom.xml file and added the libs that were necessary to the project classpath - after clicking in the Eclipse IDE to disable Maven nature. Is there any other configuration needed? When I want to unmaven project, in addition to the libs, what should I pay attention? Thanks for your attention. -- View this message in context: http://maven.40175.n5.nabble.com/Unmaving-a-project-tp5766830.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: how to make the SVN release process more robust
The original behaviour was to tag the local working copy not the remote tree, so that you could release at any time without having to for e a quiet period on trunk. Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot recall which) made tagging from working copies for https based repositories difficult for users. Now that serf is the default transport, perhaps we can switch back to the old behaviour? On Monday, 5 August 2013, Baptiste MATHUS wrote: Hi, Well, as this is actually something that the SCM itself allows, I would consider just forbidding on my svn server. This might be an interesting evolution though to be able to enforce this at the maven-release-plugin (though unlikely to happen often since the three usual commits actually happen very close to each others). Cheers 2013/8/5 Nathan Coast nathan.co...@db.com javascript:; Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org javascript:; -- Sent from my phone
Re: how to make the SVN release process more robust
Classification: Public Absolutely agree that people should not commit to tags, however we need to take a more defensive position to guarantee that there is no route for malicious code to sneak into the release process. As release prepare and release perform are not atomic, we need a process which guarantees what is being built, is exactly the same as tagged code. From: Curtis Rueden ctrue...@wisc.edu To: Maven Users List users@maven.apache.org, Date: 05/08/2013 15:59 Subject: Re: how to make the SVN release process more robust Hi Nathan, No one should ever be committing to an SVN tag that already exists. Unless the team has malicious committers? Or very clueless ones? In which case you have much bigger problems... In other words: isn't this more of a social issue? -Curtis On Aug 5, 2013 9:51 AM, Nathan Coast nathan.co...@db.com wrote: Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to make the SVN release process more robust
Classification: Public We have considered that route, and unfortunately that option is not possible for us. From: Baptiste MATHUS m...@batmat.net To: Maven Users List users@maven.apache.org, Date: 05/08/2013 16:01 Subject: Re: how to make the SVN release process more robust Hi, Well, as this is actually something that the SCM itself allows, I would consider just forbidding on my svn server. This might be an interesting evolution though to be able to enforce this at the maven-release-plugin (though unlikely to happen often since the three usual commits actually happen very close to each others). Cheers 2013/8/5 Nathan Coast nathan.co...@db.com Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to make the SVN release process more robust
Classification: Public I'm not sure that will help our problem as tags remain mutable. The tag checked out for release perform could still be corrupted. From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 05/08/2013 18:00 Subject: Re: how to make the SVN release process more robust The original behaviour was to tag the local working copy not the remote tree, so that you could release at any time without having to for e a quiet period on trunk. Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot recall which) made tagging from working copies for https based repositories difficult for users. Now that serf is the default transport, perhaps we can switch back to the old behaviour? On Monday, 5 August 2013, Baptiste MATHUS wrote: Hi, Well, as this is actually something that the SCM itself allows, I would consider just forbidding on my svn server. This might be an interesting evolution though to be able to enforce this at the maven-release-plugin (though unlikely to happen often since the three usual commits actually happen very close to each others). Cheers 2013/8/5 Nathan Coast nathan.co...@db.com javascript:; Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript: ; For additional commands, e-mail: users-h...@maven.apache.org javascript:; -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org javascript:; -- Sent from my phone --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Unmaving a project
You probably need to start by finding out how everyone at your organization builds projects. For example, do they use a set of Ant scripts? Maven gives you a standard way to do things but if your organization is not using Maven, it probably has a standard way that all of the projects are built. You may also need to restructure your source tree to match the organization's way of organizing a project. I can not think of any reason why it would be necessary to remove the pom.xml or tell Eclipse anything after you have removed the Maven nature. No one here can tell you how your organization builds its applications and that is what you need to find out. Ron On 05/08/2013 12:17 PM, flmaven wrote: Hello, English is not my native language; please excuse typing errors. I need to unmave a project because in the place I work Maven is not used. The problem is that I downloaded a lot of source-code from a book and all it´s content are Maven Projects. I found easy to make the projects work as Maven Projects... just import a Maven Project, configure my application server - I am using Jboss 7.0, and run them. I could easily configure this projects after testing it and change them to my needs. But since we don´t use Maven here, I started trying to disable the Maven nature of a project and I couldn´t get the project to work. I deleted the pom.xml file and added the libs that were necessary to the project classpath - after clicking in the Eclipse IDE to disable Maven nature. Is there any other configuration needed? When I want to unmaven project, in addition to the libs, what should I pay attention? Thanks for your attention. -- View this message in context: http://maven.40175.n5.nabble.com/Unmaving-a-project-tp5766830.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: how to make the SVN release process more robust
Hi Nathan, I'm not sure that will help our problem as tags remain mutable. The tag checked out for release perform could still be corrupted. As I asked before: who is doing this corruption? If you have committers capable of doing that, they could absolutely hose your repository in all sorts of ways. It's a much bigger problem than just the maven-release-plugin. That's not to say your proposed changes wouldn't make maven-release-plugin more robust -- it just seems like an unwinnable battle. Better to go Baptiste's very sensible route of locking down the server on the server-side. -Curtis P.S. SVN is certainly not unique in having mutable tags. Git's tags are mutable too: just force push over top the old one. And any VCS having immutable tags would be a real PITA, IMO. On Mon, Aug 5, 2013 at 12:14 PM, Nathan Coast nathan.co...@db.com wrote: Classification: Public I'm not sure that will help our problem as tags remain mutable. The tag checked out for release perform could still be corrupted. From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 05/08/2013 18:00 Subject: Re: how to make the SVN release process more robust The original behaviour was to tag the local working copy not the remote tree, so that you could release at any time without having to for e a quiet period on trunk. Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot recall which) made tagging from working copies for https based repositories difficult for users. Now that serf is the default transport, perhaps we can switch back to the old behaviour? On Monday, 5 August 2013, Baptiste MATHUS wrote: Hi, Well, as this is actually something that the SCM itself allows, I would consider just forbidding on my svn server. This might be an interesting evolution though to be able to enforce this at the maven-release-plugin (though unlikely to happen often since the three usual commits actually happen very close to each others). Cheers 2013/8/5 Nathan Coast nathan.co...@db.com javascript:; Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript: ; For additional commands, e-mail: users-h...@maven.apache.org javascript:; -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org javascript:; -- Sent from my phone --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to make the SVN release process more robust
typically you go $ mvn release:prepare release:perform -B So there is maybe a 1 second window when somebody can mutate the tag between the create and the checkout... Now if you are doing release:perform a while after the release:prepare (the tag is created only as the second last operation at end of the prepare step - the final being checking in the development of next version poms) then it could be a concern... But that will always be an issue because you could have the case where the machine with the release.properties has a hard disk failure before you can run release:perform and as a result you loose the revision detail. TL;DR for every safeguard you put in place (that is not a rule enforced on the Subversion server) we can find a scenario that can work around your safeguard... the solution is a rule enforced by the Subversion server that only permits creation and deletion of tags and no modification to the tags themselves (you need delete if you ever want to respin a release... if you don't want to respin [your name could be sebb or fred :-P ] then don't put a rule that permits deleting borked tags. On 5 August 2013 18:14, Nathan Coast nathan.co...@db.com wrote: Classification: Public I'm not sure that will help our problem as tags remain mutable. The tag checked out for release perform could still be corrupted. From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Users List users@maven.apache.org, Date: 05/08/2013 18:00 Subject: Re: how to make the SVN release process more robust The original behaviour was to tag the local working copy not the remote tree, so that you could release at any time without having to for e a quiet period on trunk. Then a bug in the neon transport for Subversion 1.5 or 1.6 (I cannot recall which) made tagging from working copies for https based repositories difficult for users. Now that serf is the default transport, perhaps we can switch back to the old behaviour? On Monday, 5 August 2013, Baptiste MATHUS wrote: Hi, Well, as this is actually something that the SCM itself allows, I would consider just forbidding on my svn server. This might be an interesting evolution though to be able to enforce this at the maven-release-plugin (though unlikely to happen often since the three usual commits actually happen very close to each others). Cheers 2013/8/5 Nathan Coast nathan.co...@db.com javascript:; Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript: ; For additional commands, e-mail: users-h...@maven.apache.org javascript:; -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! users-h...@maven.apache.org javascript:; -- Sent from my phone --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
PMD plugin ignores rue properties in custom ruleset
Hi, I have a problem with the PMD plugin for maven. For our project I have defined a custom rulest for PMD in an XML file [1]. This ruleset defines properties for some of the standard PMD rules using this syntax: rule ref=rulesets/java/naming.xml/LongVariable properties property name=minimum value=25/ /properties /rule When I execute PMD using a parallel ant file we maintain, these custom properties are respected correctly. However, when executing PMD through maven, the properties are completely ignored. And idea what could cause this? Thanks for any help, Johannes The pom.xml we are using is available at [2]. [1] https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/7e71d4d3e6d57c8529111a7f7143edeb48ddec59/entry/codecheck/pmd-rules.xml [2] https://code.cor-lab.org/projects/rsb/repository/rsb-java/revisions/ff17c0dd008697f70dad27bd0319f4475ab87712/entry/pom.xml signature.asc Description: OpenPGP digital signature
Re: how to make the SVN release process more robust
Isn't it possible to handle this in a technical manner` For example, a rigger script that's invoked upon commit and checks whether the path contains a tags directory? On Mon, Aug 5, 2013 at 4:51 PM, Nathan Coast nathan.co...@db.com wrote: Classification: Public Hi all, As SVN tags are simply a convention overlayed on top of SVN directories, SVN tags are therefore mutable. This opens the possibility that someone could inject code to a tag between the release:prepare and the release:perform phases. This would mean that the code checked out during release perform phase could be different from the code which was originally tagged. To close this potential loophole, I'm considering this solution: 1) Modify the behaviour within org.apache.maven.scm.provider.svn.svnjava.command.tag.SvnTagCommand to return the tag revision number via TagScmResult 2) Write the result to release.properties 3) Utilise the revision number within the checkout command (tag plus revision#) Does anyone have any alternate suggestion for how to solve this? Regards, Nathan --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
