Hi,
The vote has passed with the following result :
+1 (binding): Benjamin Bentmann, Lukas Theussl, John Casey, Hervé
Boutemy, Olivier Lamy, Kristian Rosenvold, Dennis Lundberg
+1 (non binding): Robert Scholte, Anders Hammar
I will promote the artifacts to the central repo.
On 2011-02-06 00:51,
Hi Hervé,
I followed your reference and understood the relationship between Plexus and
Maven and how Plexus is used to invoke Maven components. I got my work done
using Maven Invoker (shared component) API [0].
[0]. http://maven.apache.org/shared/maven-invoker/
Thanks and Regards,
Harshana
On 6
On Tue, Feb 8, 2011 at 9:45 PM, Benson Margulies wrote:
> I was somewhat squeamish about all of this, and now you've confirmed
> my fears. My theory was to have the doc remind inheritors to override.
>
> The good thing about the site plugin process is that there's some
> reasonable chance that any
I was somewhat squeamish about all of this, and now you've confirmed
my fears. My theory was to have the doc remind inheritors to override.
The good thing about the site plugin process is that there's some
reasonable chance that anyone modifying the pom will modify the doc.
If all the doc moves in
I see now what you've done. If you need these values for the site,
then drop them into the asf-pom profile you created, but honestly I
think we should move all of this and the site.xml out and find a place
to put the docs into the infra site, or somewhere inside of maven. I
think the asf pom projec
same comment as the url, i don't think we want to be polluting the
inheritence tree with specifics about the ASF wide pom project.
On Sat, Feb 5, 2011 at 3:47 PM, wrote:
> Author: olamy
> Date: Sat Feb 5 20:47:25 2011
> New Revision: 1067520
>
> URL: http://svn.apache.org/viewvc?rev=1067520&vie
You realize that this may cause everyone to inherit the wrong url now?
We should have the default url pointed at the apache site, not the pom
site.
On Sat, Feb 5, 2011 at 3:51 PM, wrote:
> Author: olamy
> Date: Sat Feb 5 20:51:25 2011
> New Revision: 1067521
>
> URL: http://svn.apache.org/viewv
I just have to remember to add it to the infra site.
On Tue, Feb 8, 2011 at 9:16 PM, Brian Fox wrote:
> btw, thanks for the documentation on the parent...if nothing else
> comes from this at least we got that ;-)
>
> On Tue, Feb 8, 2011 at 9:13 PM, Benson Margulies
> wrote:
>> Unfortunately for
btw, thanks for the documentation on the parent...if nothing else
comes from this at least we got that ;-)
On Tue, Feb 8, 2011 at 9:13 PM, Benson Margulies wrote:
> Unfortunately for the coherence of this discussion, it was months and
> months ago that I filed the original version of this JIRA. T
Unfortunately for the coherence of this discussion, it was months and
months ago that I filed the original version of this JIRA. The best I
can lay my mental fingers on is this: for a large project, signing and
such can take a very long time, making it very slow and frustrating to
work through a se
In my experience these problems are more often caused by bad test
infrastructure or handle leaks in production or test code. I had to
spend a lot of time for example rewriting how the maven-indexer tests
worked because it randomly failed for me on Win7. After isolating the
files into temp folder, t
On Tue, Feb 8, 2011 at 8:40 PM, Benson Margulies wrote:
> Brian,
>
> As I recall, the apparent consensus of the prior thread was to, in
> fact, turn it off by default for 'asf' and move it to 'maven'. But I'm
> not the referee of consensus here, you are :-)
>
> My argument was that the global ASF
Brian,
As I recall, the apparent consensus of the prior thread was to, in
fact, turn it off by default for 'asf' and move it to 'maven'. But I'm
not the referee of consensus here, you are :-)
My argument was that the global ASF pom should, by default, provide
the minimum collection of settings fo
Olivier, I think this still needs some discussion. What's the problem
with the activation of the release profile by default? Many Apache
projects depend up on this updated profile and if we just gank it out
to the Maven pom, it will break them all. I think perhaps we can make
it a property to make
+1 from me
On 2011-02-06 00:51, Dennis Lundberg wrote:
> Hi,
>
> We solved 6 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139&styleName=Html&version=16439
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=tr
On Feb 8, 2011, at 4:54 PM, Dennis Lundberg wrote:
> My current focus is on the Apache Maven project's plugins and
> components. I think it is up to all plugin authors out there to document
> their own plugins.
>
Same plugin could be run on the Apache Nexus instance. They have to mark the
mojo
My current focus is on the Apache Maven project's plugins and
components. I think it is up to all plugin authors out there to document
their own plugins.
On 2011-02-08 22:36, Jason van Zyl wrote:
> Write a Nexus plugin that walks a repository looking for Maven plugins, crack
> it open and pull ou
Write a Nexus plugin that walks a repository looking for Maven plugins, crack
it open and pull out the metadata and make a report.
You could take the Nexus Archetype plugin as an example. If you wanted to
create a global list this is the only real way you could accomplish this.
On Feb 8, 2011,
Right, this was added in version 2.6 of Plugin Plugin, so any site
generated with an earlier version won't have that info. See
http://jira.codehaus.org/browse/MPLUGIN-169
That however only tells you *if* the latest version is thread safe, but
it doesn't tell you *when* it was first marked as threa
I have something like 5 accepted answers on StackOverflow regarding this
issue now - all popping up with the wildest (and totally different) set
of symptoms but always the same solution. It seems like it's time to
issue a warning about this on users/mojo, since it affects all 64bit jvm
users and pr
If a plugin is marked as thread safe, it is stated on the goal detail page.
See [1] for an example.
I believe it's the plugin-plugin that creating this info and possible some
plugin sites created with an old version of plugin-plugin doesn't contain
this info even though a goal is marked as thread s
On 2011-02-07 21:21, Kristian Rosenvold wrote:
> to., 03.02.2011 kl. 21.39 +0100, skrev Dennis Lundberg:
>> MASSEMBLY-522 Thread safety
>> - It would be great if someone (Kristian?) could have a look at this
>> one.
>
> Fixed in r1068087, based on manual code inspection and version check of
> dep
I think it would be a useful service to our users to list which plugins
and components are @threadSafe, and also in which version it was first
marked as @threadSafe.
We can start writing things down on the wiki page you mentioned. I'll
add a new heading and start to accumulate the info. We can mov
Hello,
The vote has passed with the following result :
+1 (binding) : Dennis Lundberg, Lukas Theussl , Vincent Siveton, Hervé
BOUTEMY, Emmanuel Venisse, Olivier Lamy
+1 (non binding) : Evgeny Mandrikov
I will promote artifacts to central.
Thanks !
--
Olivier Lamy
http://twitter.com/olamy
http://
24 matches
Mail list logo
