I can't remember if this died with m1, but in the old days we used
to get a javadoc error report in maven project reports. It seems
now the only way to tell if there are javadoc errors is to examine
the command line output of the javadoc plugin. Is there a way to
get a javadoc error report genera
I've been researching ways to write tags to my images similar to how
Windows Live Photo Gallery works. I've played with several different
libraries (metadata-extractor,jhead,jheader,sanselan) but have only really
found Sanselan to accomodate writing the data back in that I need.
I followed Apache'
On 3/28/13 12:03 PM, Thomas Neidhart wrote:
> On 03/28/2013 07:46 PM, Thomas Neidhart wrote:
>> On 03/28/2013 06:33 PM, Continuum@vmbuild wrote:
>>> Group (shared) Maven 2 Build Definition (Java 1.5)
>>> MIME-Version: 1.0
>>> Content-Type: text/plain; charset=us-ascii
>>> Content-Transfer
On 03/28/2013 07:46 PM, Thomas Neidhart wrote:
> On 03/28/2013 06:33 PM, Continuum@vmbuild wrote:
>> Group (shared) Maven 2 Build Definition (Java 1.5)
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=us-ascii
>> Content-Transfer-Encoding: 7bit
>> X-Continuum-Build-Host: vmbuild
On 03/28/2013 06:33 PM, Continuum@vmbuild wrote:
> Group (shared) Maven 2 Build Definition (Java 1.5)
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Continuum-Build-Host: vmbuild
> X-Continuum-Project-Id: 97
> X-Continuum-Project-Nam
On 03/28/2013 05:24 PM, Emmanuel Bourg wrote:
But binary packages including the jars, the sources, the compiled tests,
the dependencies and the javadoc are just redundant with the other Maven
artifacts.
Agreed.
Those could/should be part of "standard" distribution method.
Some times we just o
Group (shared) Maven 2 Build Definition (Java 1.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 97
X-Continuum-Project-Name: Commons Math
Online report :
http://vmbuild.apache.org/con
Le 28/03/2013 16:20, Mladen Turk a écrit :
> Well, I find it a bit discriminating to host only java code with Maven ;)
>
> With binaries (even native like with daemon) one can easily create a pom
> that would pull everything without the need to setup gazillion of
> main/archive/mirror sites, etc.
>
>> There's only a slightly problem with that approach: the Maven central
>> repo is not under the ASF control, while the old traditional dist area
>> is, so I guess "official" releases _must_ be placed in the ASF space.
>
> I agree, our releases must go to an ASF space first. However one could
>
Le 28/03/2013 16:15, Simone Tripodi a écrit :
> There's only a slightly problem with that approach: the Maven central
> repo is not under the ASF control, while the old traditional dist area
> is, so I guess "official" releases _must_ be placed in the ASF space.
I agree, our releases must go to a
On Thu, Mar 28, 2013 at 11:20 AM, Mladen Turk wrote:
> On 03/28/2013 03:33 PM, Simone Tripodi wrote:
>
>> I don't think we can speak about "standard" practices, but Maven
>> itself[1] publishes -src and -bin artifacts on the central repo.
>>
>> +1 on NOT publishing them on central repo, but we sh
Le 28/03/2013 16:16, Phil Steitz a écrit :
> The definitive location for ASF software distributions is the apache
> mirrors. That is what we monitor, point to on the web pages, vouch
> for, etc. Downstream packagers, distributors - *including Maven
> central* - can do what they want and projects
On 03/28/2013 03:33 PM, Simone Tripodi wrote:
I don't think we can speak about "standard" practices, but Maven
itself[1] publishes -src and -bin artifacts on the central repo.
+1 on NOT publishing them on central repo, but we should find an
automated way to deploy them on SvnPubSub along the sig
On 3/28/13 7:39 AM, Emmanuel Bourg wrote:
> Le 28/03/2013 15:29, Stefan Bodewig a écrit :
>
>> Why? IMHO packagers should be using the "usual" distribution mirror
>> system.
> Sure that's what they do. But the "usual" location is different for
> every library. If it can be standardized within the
Salut Manu,
>
> Sure that's what they do. But the "usual" location is different for
> every library. If it can be standardized within the Maven infrastructure
> that would greatly simplify the downstream packaging. Any library (from
> Apache or elsewhere) could be downloaded in a buildable form di
Le 28/03/2013 15:29, Stefan Bodewig a écrit :
> Why? IMHO packagers should be using the "usual" distribution mirror
> system.
Sure that's what they do. But the "usual" location is different for
every library. If it can be standardized within the Maven infrastructure
that would greatly simplify t
On 3/28/13 3:46 AM, luc wrote:
> Hi all,
>
> Here we are. The final issues in JIRA scheduled for 3.2 have been
> either
> solved (a lot of them) or postponed (a few of them).
>
> If everybody agree, I volunteer to be the release manager for this
> version.
> I will most probably temporarily flag th
Your are welcome, Javin!
have a nice day, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Mar 28, 2013 at 1:49 PM, Javin Paul wrote:
> Thanks Simo, that's very neat.
>
> On Wed, M
I don't think we can speak about "standard" practices, but Maven
itself[1] publishes -src and -bin artifacts on the central repo.
+1 on NOT publishing them on central repo, but we should find an
automated way to deploy them on SvnPubSub along the signature and
checksums.
best,
-Simo
[1] http://r
On 2013-03-28, Emmanuel Bourg wrote:
> Hi,
> I just noticed that for the recent releases the source and binary
> packages have been published in the Maven repository. I saw that with
> fileupload 1.3 and daemon >= 1.0.11.
> Is this a "standard" practice?
I would hope it is not. When I released
This might have been unintentional. In the past, we've always made a point
of NOT putting -src and -bin zips/tars in Maven Central.
Has this policy changed with the new svnpubsub?
Gary
On Thu, Mar 28, 2013 at 10:00 AM, Emmanuel Bourg wrote:
> Hi,
>
> I just noticed that for the recent release
Why do we publish the native-src.zip/.tar.gz artifacts in the Maven
repository? That seems to be just a subset of the src.zip/.tar.gz artifacts.
Emmanuel Bourg
Le 28/03/2013 14:12, Mladen Turk a écrit :
>
> Apache Commons Daemon 1.0.15 based on RC1 is ready.
> This is bug fix release fixing bot
Hi,
I just noticed that for the recent releases the source and binary
packages have been published in the Maven repository. I saw that with
fileupload 1.3 and daemon >= 1.0.11.
Is this a "standard" practice?
I find this very interesting because the sources.jar usually shipped is
great for browsi
Apache Commons Daemon 1.0.15 based on RC1 is ready.
This is bug fix release fixing both bugs and regressions
found in previous release(s).
Binaries and sources for testing are at [1], dist layout is at [2],
generated site can be found at [3]. Tag is [4] which will be renamed to
COMMONS_DAEMON_1_
Thanks Simo, that's very neat.
On Wed, Mar 27, 2013 at 8:39 PM, Simone Tripodi wrote:
> > Is there list of changes, sort of a release notes?
> >
>
> Sure, we track resolved issues with fix version:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313525&version=12323958
>
On Thu, Mar 28, 2013 at 11:46 AM, luc wrote:
> Hi all,
>
> Here we are. The final issues in JIRA scheduled for 3.2 have been either
> solved (a lot of them) or postponed (a few of them).
>
> If everybody agree, I volunteer to be the release manager for this version.
> I will most probably tempora
On 28 March 2013 11:28, Mladen Turk wrote:
> On 03/28/2013 11:46 AM, sebb wrote:
>>
>> On 28 March 2013 07:38, Mladen Turk wrote:
>>>
>>> Hi,
>>>
>>> We have couple of regressions in 1.0.14 and few other bugs fixed
>>> like (now functional) windows JVM thread dumps, so I plan to tag
>>> and start
On 03/28/2013 11:46 AM, sebb wrote:
On 28 March 2013 07:38, Mladen Turk wrote:
Hi,
We have couple of regressions in 1.0.14 and few other bugs fixed
like (now functional) windows JVM thread dumps, so I plan to tag
and start RM later today.
Comments, objections?
OK by me.
Remember that the d
On 28 March 2013 08:53, Simone Tripodi wrote:
>>> cannot come from anywhere since it declares the fileset from ${basedir}
>>
>> I meant, the file could have been copied from anywhere and
>> accidentally left in the directory structure.
>>
>
> this is too general, it happens everywhere - like gener
On 28 March 2013 08:59, Simone Tripodi wrote:
>>>
>>> That assumes reviewers compare the tag with the releases - does anyone
>>> apart from me do that?
>>>
>>
>
> everybody HAS to do it and I assume everybody does it, otherwise we
No, that's not a requirement as far as I know (probably should be)
On 28 March 2013 07:38, Mladen Turk wrote:
> Hi,
>
> We have couple of regressions in 1.0.14 and few other bugs fixed
> like (now functional) windows JVM thread dumps, so I plan to tag
> and start RM later today.
>
> Comments, objections?
OK by me.
Remember that the dist/commons tree on people i
Hi all,
Here we are. The final issues in JIRA scheduled for 3.2 have been
either
solved (a lot of them) or postponed (a few of them).
If everybody agree, I volunteer to be the release manager for this
version.
I will most probably temporarily flag the two extremely long Bobyqa
tests as
@igno
On Thu, Mar 28, 2013 at 10:53 AM, wrote:
> Author: luc
> Date: Thu Mar 28 09:53:56 2013
> New Revision: 1462012
>
> URL: http://svn.apache.org/r1462012
> Log:
> Adding missing headers.
>
Hi Luc,
Thanks, I should enable the header check again ;-).
Thomas
>
> Modified:
>
> commons/proper/math/
>>
>> That assumes reviewers compare the tag with the releases - does anyone
>> apart from me do that?
>>
>
everybody HAS to do it and I assume everybody does it, otherwise we
have to be aware we are voting poor releases
> I do that :)
>
great! :)
-Simo
http://people.apache.org/~simonetripodi/
>> cannot come from anywhere since it declares the fileset from ${basedir}
>
> I meant, the file could have been copied from anywhere and
> accidentally left in the directory structure.
>
this is too general, it happens everywhere - like generated sources
accidentally included in bin archives, OSG
2013/3/27 sebb
> On 27 March 2013 20:33, Simone Tripodi wrote:
> >>
> >> No, sorry, it's just not as safe.
> >>
> >> I'd rather a file be missing from the release than have a release with
> >> a spurious file that could contain anything.
> >
> > The only risk we have ATM is that the RM includes
Hi,
We have couple of regressions in 1.0.14 and few other bugs fixed
like (now functional) windows JVM thread dumps, so I plan to tag
and start RM later today.
Comments, objections?
Regards
--
^TM
-
To unsubscribe, e-mail: de
37 matches
Mail list logo
