ch to nullability is wrong, broken, and will never work
reliably from my POV.)
Cheers,
Simon
if I can do anything that helps pushing beanutils2 across the
finish line!
Thanks a lot,
Simon
Hi Gary,
I added the Automatic Module Name and sent a PR request
(https://github.com/apache/commons-beanutils/pull/4) a while ago ... is there
anything I can do to help moving this forward?
Thanks,
Simon
?
I think it might be as easy as adding to the build.xml file.
Thanks again!
Simon
if OSGI related changes are wanted.
Simon
On Feb 7, 2018 5:10 AM, "Stefan Bodewig" wrote:
> On 2018-02-07, Jochen Wiedmann wrote:
>
> > On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig
> wrote:
>
> >> I know I asked before (I really am not an OSGi gu
es (and possibly not
even all of those), it's essy to use a static map (which can be pretty much
generated from jmod/jdep).
Simon
[1] A module can only appear in the modpath once. A package can only come
from one module. If an application uses multiple third party dependencies,
which us
uction use, etc).
Simon
On Oct 9, 2017 5:21 PM, "Rob Tompkins" wrote:
Hey all,
At my day job we saw a 60% performance improvement (cpu utilization)
between 1.8.0_40 and 1.8.0_121, and I was wondering if anyone else out
there has seen anything like that before or if anyone might know what co
Camel * Camel = Camel
Let Dunhill + Dunhill = Dunhill,
Dunhill + Camel = Camel,
Camel + Dunhill = Camel,
Camel + Camel = Dunhill
Then is a Field, but of brands of cigarette.
So I vote Camel or Dunhill depending.
Simon
urrent code as almost an implementation
module, define a separate API module, and add extra interfaces and
alternate implementations to support the target use case (mutable
records, streams, reactivex, transform functions or what have you).
Simon
tes of the armistice talks.
jigsaw modules are pretty useless for most of Commons (consumers pretty
much have to shade dependencies). [ subliminal whisper about benefits of
having correct OSGI headers]
Simon
On Aug 8, 2017 11:08 AM, "Jörg Schaible"
wrote:
> Hi,
>
> Gilles wrote
pplier
function (e.g. CardinalDirection::values).
You could use a cache in the RNG, keyed by the class, but that's still
going to be a bit expensive in the middle of a tight loop.
Simon
Simon
Class file format is not treated as a breaking change under most versioning
approaches, including the JLS.
The checkers I looked at that reported on class file format changes
consider it a micro level version change (+0.0.1)
The past few major version bumps for projects I've worked happened to
remaining synchronized. Everything gets delegated to the chm.
Still full of unchecked goodness.
And a great example of how sometimes inheritance is so useless you just
compose and delegate anyway.
Simon
s could be provided to support populating a Map from an input source
containing contents formatted as specified in j.u.Properties.
So, io with a touch of codec?
Simon
On Jul 16, 2017 11:49 AM, "Matt Sicker" wrote:
C quality somewhat depends on which version of C you're trying to remain
compatible with (I'm guessing C89 due to Windows, though I could be wrong).
Valgrind and other tracing tools are typically used.
Valgrind is a default choice (though then you
Since it's an interface, I could change it to IHasACharset?
Or If you prefer I could rename it to YouGiveLove? (Lucky Millenials- you
aren't headsonged)
The name follows a pattern for interfaces of this sort, which are basically
retrofit markers for the presence of property, (with associated ge
Is this jdk 8 vs. java SDK 8? The oracle code picked up some fairly big
changes along the way that aren't present in the IBM library. (jdk 9 is
really different from both. I haven't seen what the IBM Java 9 is like
yet).
I will see if anything looks blatantly obvious.
Simon
On Jul
hide the conspiracy than in the heartblood of the conspiracy
theorists.
All hail Eris!
Simon // Ok, it could spam, but that just doesn't seem as plausible.
It was failing when I got here officer
On Jul 4, 2017 1:46 PM, "Pascal Schumacher"
wrote:
> Am 04.07.2017 um 16:17 schrieb Simon Spero:
>
>> It doesn't work. :-)
>>
>> More specifically, it doesn't work because coveralls is trying to use
>>
It doesn't work. :-)
More specifically, it doesn't work because coveralls is trying to use JAXB,
which is not available by default in JDK9. (It ships. It's just not
available without command line arguments.)
The coveralls plugin is using JAXB for a single static method, to convert a
byte[] dige
maven-compiler-plugin [4] via a
element in the plugin configuration, or by settting the property
*maven.compiler.release* .
Simon
[1] https://bugs.openjdk.java.net/browse/JDK-8011044
[2]
http://openjdk.java.net/projects/jigsaw/spec/minutes/2017-05-18#AutomaticModuleNames--ModuleNameInManifest
[3]
under plain old JDK 8; much of
the rest is subsumed by various functional and/or reactive libraries (of
which there are quite a few). AOL's Cyclops [1] bridges a bunch of these
(e.g. [2],[3].[4]). Is there anything that isn't provided for in cyclops or
one of the things it bridges?
Simon
Java 9 you can get rid of the NoPS with the spin-wait hinting.
Simon
COMPRESS-413 has some examples which include:
- Switching to the trusty container, which doesn't require installing as
many updates.
- Use only two JDKs: openjdk7 and openjdk8.
- JDK 7 is obsolete -
- Oracle EOL'ed JDK7 over two years ago; openjdk7 occasionally gets
pa
but
having all the format fixes in a single commit is a lot better than having
them mixed in with real changes.
Simon
P. S.
I prefer the builtin /google_checks.xml styleguide to the older sun_checks,
partly because it's more up to date, and partly because Google provides
native ide configur
On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig wrote:
>
> Interesting. This means OSGi only provides a way for consumers to say
> which version of an API they want, but not which implementation. This means
> as a consumer you can't say "I want version 1.19 of Compress because I know
> it contai
Hudkins is alive!
On Tue, Jun 20, 2017 at 12:49 AM, Dave Fisher wrote:
> Check with Infra weird errors are happening.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Jun 19, 2017, at 8:53 PM, Stefan Bodewig wrote:
> >
> >> On 2017-06-19, Gary Gregory wrote:
> >>
> >> Is it just me or have
On Jun 19, 2017 9:56 AM, "Stefan Bodewig" wrote:
On 2017-06-19, Simon Spero wrote:
with all parenteses properly nested, wow ;-)
No need to apologize, really.
(apply #'append '((not) (a problem)))
es to whitespace, and which
intellij and I haven't figured the pattern to.
Checkstyle as plugin is still annoying, but only when we disagree :)
Simon
On Jun 18, 2017 2:33 AM, "PascalSchumacher" wrote:
Github user PascalSchumacher commented on the issue:
https://github.com/apac
not replying to an email from him (on dev) that I'd missed because of
coveralls) .
So +1.
Also, I need to reply to that email :)
Simon
On Jun 19, 2017 6:33 AM, "Stefan Bodewig" wrote:
Hi all
apart from dev@ and user@ we've got three lists that have been created
for specific n
ations that do this.
Like, um, javac :-)
Materializing these strings as possibly transient CharSequence's is
really convenient... until some method just has to have a String
Also, wouldn't some sort of low-space-overhead string storage be a good
fit for text?
Simon
[1] Spero,S. (2015)
But BC, per initial response. I said I needed more coffee :)
On Wed, Jun 14, 2017 at 8:55 AM, Simon Spero wrote:
> Oops -I missed that the method was already generic. Need bigger
> tablet/more coffee / bigger caffeine tablet
>
>
> On Jun 14, 2017 8:46 AM, "Simon Spero&qu
Oops -I missed that the method was already generic. Need bigger tablet/more
coffee / bigger caffeine tablet
On Jun 14, 2017 8:46 AM, "Simon Spero" wrote:
On Jun 14, 2017 4:28 AM, "Benedikt Ritter" wrote:
I’d like to have feedback for CLI-277 [1], especially whether it will
On Jun 14, 2017 4:28 AM, "Benedikt Ritter" wrote:
I’d like to have feedback for CLI-277 [1], especially whether it will
affect BC. Clirr is happy with this changes, to I suppose it is fine to
merge this?
[1] https://github.com/apache/commons-cli/pull/13 <
https://github.com/apache/commons-cli/pu
tional work after a subsequent api change is
https://github.com/apache/commons-compress/pull/27/commits/82405c13bd2688817108d3f2854387b3417a764d
Some of these changes can be lifted to the parent; the initial setup of
package-info.java @Version annotations requires some code.
Simon
¹ OK, I made the change
On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker wrote:
> I'd love to have a semantic versioning plugin like that which can suggest
> what the version number is for the entire project. Elm (programming
> language) has a tool like that, and it works rather well in practice (even
> though there are so
he commons parent verify stage seems like a
sensible move regardless. This should not replace japicmp, as they have
non-overlapping features. These goals should replace CLIRR, which is
obsolete (so obsolete that won't run under jdk-9 because jdk 1.5 bytecode
is no longer supported) .
Simon
p.
have been the wrong response.
If you like, I can post a list of what the package version should have
been, assuming that every compatibility change was intentional, and
versioning was properly applied, for every bundle series under
org.apache.commons and commons-* that was on maven-central as of mid-may?
Simon
;M coming... and Jar
Hell's coming with me, you hear? **Jar Hell's coming with me!*
Simon
On Wed, Jun 7, 2017 at 5:02 PM, Gary Gregory wrote:
> On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero wrote:
>
> > As Bertrand mentioned earlier, the bundle:baseline goal is built in t
would require that the animal sniffer plugin be setup for components
> that do want to go that way. Doable if there is a sig file for the right
> Java version for that component.
>
> Gary
>
> On Jun 9, 2017 8:13 AM, "Simon Spero" wrote:
>
> > On Thu, Jun 8, 20
larly urgent, but if/when jdk9 is released, it might
be worth considering
Simon
ses@snarkive$ javac -version
*javac 1.8.0_131*
ses@snarkive$ javac -cp build/classes/main depup/src/EyeOfTheWeasel.java
*Note: depup/src/EyeOfTheWeasel.java uses or overrides a deprecated API.*
*Note: Recompile with
n inlined), but could not be re-compiled.
I don't know why anyone would be doing this...
(CLIRR pre-dates string switches)
Simon
On Thu, Jun 8, 2017 at 5:10 PM, sebb wrote:
> On 8 June 2017 at 18:09, Gary Gregory wrote:
> > On Thu, Jun 8, 2017 at 9:57 AM, sebb wrote:
> >
&g
hat the annotated item
is really really deprecated.) It's not needed in this case, but is worth
thinking about when jdk9 is eventually released (latest schedule change :
from 7/27/2017 to 9/21/2017).
Simon
[1] https://github.com/apache/commons-lang/commit/7c19a1ff4c217
f0
sion should be bumped to match the most significant change in any
package in the bundle/artifact, so that maven version-range dependencies
don't break, but that ship has sunk.
Simon
p.s.
The reason I'd been making changes to commons-compress was to support
creating and using random access t
The file called Word.xps at:
http://www.wssdemo.com/XPS/Forms/AllItems.aspx
exhibits the problem.
You are entirely correct the entry is STORED so COMPRESS-100 does the trick
for me.
Simon
On 12/03/2010 15:17, "Stefan Bodewig" wrote:
> On 2010-03-12, Simon Tyler wrot
of error occurs
but indicate the error somehow. There might be issues here (I am no zip
expert) but I would be worried about false errors being reported.
Simon
On 11/03/2010 13:11, "Stefan Bodewig" wrote:
> On 2010-03-10, Simon Tyler wrote:
>
>> Do we have a date ye
(e.g. return hasDataDescriptor).
2. Better handling when ZipArchiveInputStream is used to read such streams.
Currently it silently fails when this happens when if hits an invalid
LFH_SIG by returning null.
Cheers
Simon
would be a big job. I presume
you're aware that springframework.org includes extensive AOP support
based on the aopalliance APIs?
Regards, Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
James Carman schrieb:
> On Wed, Nov 5, 2008 at 4:04 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
>> So the rule would be:
>> * the project provides both an interface and an abstract class that
>> implements that interface.
>> * code that *uses* the API
to me; seems to ensure maximum
backward compatibility while keeping a clean interface-based API (which
allows interface-based proxies to be generated at runtime).
I would agree with Jörg here, that as long as release-notes document
expected clirr incompatibilities there is no problem. Clirr can of
cou
maven-compiler-plugin
2.0.2
1.5
1.5
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
sebb schrieb:
On 16/09/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote:
sebb wrote:
> On 16/09/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
[snip]
It's not quite clear to me why a threadlocal is being used here. I'm
>> guessing it is for
sebb schrieb:
On 16/09/2008, Simon Kitching <[EMAIL PROTECTED]> wrote:
One other concern is regarding garbage collection. From a brief look at the
code, this thread-local registry object contains a set of Integer hashcodes.
With this change, the set will now contain real hard referen
p and
IdentityHashSet classes as well, given that LANG still targets Java
1.3.
WDYT?
And do these classes need a new package, or would the top-level package be OK?
No opinion.
Cheers,
Simon
-
To unsubscribe, e-mail: [EMAIL PROT
g on, where 1.0 or 1.1 or 2.3 or whatever can be chosen
depending on transient dependencies. Instead for a parent pom the
version to use has to be explicitly specified.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Luc Maisonobe schrieb:
Maven also failed with a fatal error trying to compare with version
1.8.0-BETA which it did not found (I'm not even sure it tried to
download it). I fixed this again by downloading and installing both the
pom and jar file manually.
This is a known bug with the clirr p
r it
changed or not.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FO]
>
>
+1.
If jxpath doesn't use logging directly, but does via another optional
dependency then using dependencyManagement looks to be the right option
to set.
This isn't release critical IMO, because us
e(
org.apache.lang.math.DoubleRange range,
double val);
Now doesn't loading that bundle in an OSGi app limit the entire app to
having just one common version of lang, just like a non-OSGi app would
be?
I'd love to be wrong - it would be cool to solve that probl
. I know I don't usually put the password in there, but always
> forget about the username bit.
Yep. It defaults to your local username, which ain't good if your remote
server account is different.
Just for the record, you can also do
apach
es.
Sounds good to me. I cannot think of any problems that might cause, it
does seem likely to result in a performance improvement, and it looks
safer.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
f
days. If none of the regular beanutils maintainers respond within a week
or so, then I am sure someone (maybe me) will review and commit your patch.
Regards,
Simon
Aaron Zeckoski schrieb:
> Someone let me know if this is the wrong list or if I am going about
> this the wrong way pleas
the projects that use it, or are interested in using it.
There is a pretty low bar for committers on existing apache projects to
get commit access to commons; a major goal of commons is to centralise
code shared between apache projects exactly as you are proposing here.
But yes starting in "sandbox" is the usual path.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Wed, 2008-04-23 at 09:30 +0100, sebb wrote:
> 2008/4/23 Torsten Curdt <[EMAIL PROTECTED]>:
> >
> > > Risks are mitigated to an arguably acceptable level by wrappering the
> > > entire release process at Apache around the point to point secure
> > > transport guarantee that signing is meant to p
c version of trunk.
(e)
Update the scm link, from pointing at trunk to pointing at the tag dir.
Actually, I don't think this is very useful. Pointing at the trunk is
probably better, particularly when a release includes source jars
already.
(f)
Run all tests against the modified pom.
Well, if a "release branch" approach is used, then that happens
automatically when the release candidate code is built.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rform
>
> This has worked OK for me for releasing the poms - but I haven't tried
> it on a component. The main thing I don't like about the release
> plugin is that every time you do release:prepare, it does 3 commits -
> which is alot of noise if you have several release candidates. Also
> I'm not quite sure how we go from stage rc --> actual release. I guess
> you have to tag and version as if it were the proper release - and
> delete the tag if a RC fails.
Yeah, the release plugin is "sub-optimal". It just occurred to me
recently that it probably does this in order to be able to support CVS
etc which cannot so easily branch, fix branch, tag. Instead it does "fix
trunk", tag, "refix trunk".
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
g is possible, but what if there is
another change at some time in the future that is again so significant
that it is necessary to permit installation of old and new code in
parallel? [Well, by then Java might have a mechanism for handling this
built-in (like .Net), so it might be a moot point..]
Regards
Yeah, and maven1 is pretty much dead. Providing Ant + maven2 should make
the vast majority of users happy.
On Sat, 2008-02-16 at 22:02 +0100, Emmanuel Bourg wrote:
> I agree, it's a burden to maintain otherwise.
>
> Emmanuel Bourg
>
>
> Oliver Heger a écrit :
> > With regards to the build files
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> On Feb 6, 2008 1:44 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> > > Deprecation is useful when a method has been
> > > implemented inco
ely jspwiki's search functionality is "pluggable" so by rewriting one
jspwiki class I could make things work. But if the problem library had been
more deeply embedded into the two systems I don't know what I could possibly
have done.
Of course if the new release was org.apac
ng that? Or are you using something like
MEVENIDE?
I use eclipse and have no problem with any commons project I've worked
on so far, but only use eclipse:eclipse and not any other plugins.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
m actually +1 for releasing the AL1.1 versions too, but if people are
uncomfortable with that then in the name of harmony we can wait for an opinion
from the board.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
W..no jar hell, no project proliferation.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
new file
by copying the old one as a base, the bit is attached to the new file too..so
it spreads.
BTW, thanks for working on this..
Regards, Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
e *already* released,
and then applying a different compression method (jar, not zip).
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ems right to me that
the same license should be attached to the source jar.
So unless there is an official statement from the board, or a qualified
lawyer says this is wrong, I'm +1 on releasing these sources jars, but
suggest that people be given a few days to check that they have the
right contents first.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
email would be something like:
[beanutils] add bean merging to BeanUtils.copyProperties (patch)
Regards,
Simon
On Fri, 2008-02-01 at 13:22 -0200, Rodrigo di Lorenzo Lopes wrote:
> Hi all!
>
> I'm Rodrigo di Lorenzo Lopes and I'd like to do some contributions to
> commons ap
o do this though; we just have broken svn reports :-)
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
e real group "example.foo") could be used to avoid any confusion.
Regards,
Simon
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> I really dislike adding jars to svn - better IMO to try and get the
> project to publish the 1.2.4 version and use 1.2.1 in the meantime.
org would be an appropriate place to host the code.
Regards,
Simon
Henri Yandell <[EMAIL PROTECTED]> schrieb:
> Definitely of interest I think - if components make sense being translated.
>
> Only a few would be directly ported I think - most of the others would
> be a case of u
ry returns an instance of o.a.c.foo.Foo from v1.0 of the foo
library, and another library expects an instance of o.a.c.foo.Foo from v2.0 of
the foo library, then no "isolation" will help; the two libs are just
incompatible and there is no way AFAICT to write code that will call the fir
s my
> opinion.
Agreed.
OSGi = 10% of users (at most)
other = 90%
We cannot dump 90% of users into version-conflict hell in order to save 10% of
users some effort when upgrading to the latest version.
Yes, it would be nice if s
mespace) but implements things in an OSGi-aware manner.
As OSGi is becoming more popular, it would be nice if a link to that package
was present on the commons-logging wiki.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Luc Maisonobe <[EMAIL PROTECTED]> schrieb:
> Niall Pemberton wrote:
>
> > I'd like to release commons-sandbox-parent pom version 3 - then last
> > release used commons-parent version 4 and the only changes are to
> > upgrade to the latest version 7 of commons-parent and update the
> > plugin
[EMAIL PROTECTED] schrieb:
> - See the License for the specific mathuage governing permissions
Guess org.apache.commons.lang was the template used for this file :-)
:1,$s/lang/math/g
-
To unsubscribe, e-mail: [EMAIL PR
anyone else has time, that would be great.
Cheers, Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
be wrapped at 72 bytes, and that the rest continues
on the next line preceded by a space. No idea why it was specified that way,
but it is. So what you see here is probably correct.
See here:
http://java.sun.com/javase/6/docs/technot
Phil Steitz <[EMAIL PROTECTED]> schrieb:
> I agree here, but also with Luc's point above about logging not being
> part of the API contract. So the problem is how do you support the
> use case above and one more: configurable debug/trace information. I
> don't want to hijack this thread, but
On Sat, 2008-01-12 at 20:35 +, Niall Pemberton wrote:
> Hi,
>
> Seems like discussion has concluded so trying again...
>
> The changes since the the last release of version 6 in summary:
>
> Changes to the pom.xml:
> - Configure NOTICE.txt and LICENSE.txt resources
> - add *hack* to put N
On Sat, 2008-01-12 at 14:38 +0100, Dennis Lundberg wrote:
> simon wrote:
> > On Sat, 2008-01-12 at 00:20 +, Niall Pemberton wrote:
> >> On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> >>> Jochen Wiedmann wrote:
> >>>>
ted.
And why would we ever care that some modules use version X of a plugin,
and some use version Y? If a module declares it needs version X, and
builds correctly with version X, then it seems *bad* to me to force an
unnecessary change via inheriting new settings from a parent pom.
So in short, I
Dennis Lundberg <[EMAIL PROTECTED]> schrieb:
> simon wrote:
> > On Thu, 2008-01-10 at 21:11 +0100, Dennis Lundberg wrote:
> >> sebb wrote:
> >>> AIUI, the NOTICE file is not about dependencies, it is about the
> >>> artefacts that are actually
sues either, and it may well
be that you are right and I am wrong. But if processes are to be
*changed*, then surely we need to validate the change before applying
it. Just making changes to the legal processes without any expert
opinion seems to be askin
On Thu, 2008-01-10 at 21:20 +0100, Dennis Lundberg wrote:
> Simon Kitching wrote:
> > Jochen Wiedmann <[EMAIL PROTECTED]> schrieb:
> >> On Jan 10, 2008 9:04 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> >>
> >>> No. What I
rent
copyright holders, licensed under BSD licenses. Can the maven pom define
this information? I believe there is only one field. Or is the
fallback here to use a manual NOTICE file?
(2) If commons-bar then depends on commons-foo, what should be in the
NOTICE file?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ted email to the myfaces list saying that project
"Simple Example" failed to build. It was actually the Tobago Simple Example
project that failed, but you needed to open the email and look at the svn url
to discover that; the subject line was not sufficient.
Regards,
Simon
---
Jochen Wiedmann <[EMAIL PROTECTED]> schrieb:
> On Jan 10, 2008 9:04 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
> > No. What I am saying is that the NOTICE file should have *only* information
> > about the files in the current maven module. The NOTICE sh
Jochen Wiedmann <[EMAIL PROTECTED]> schrieb:
> On Jan 10, 2008 8:51 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
> > Sorry to repeat myself again, but I really do not think the
> > maven-remote-resources approach is
> > even legal. IANAL, but as I
acts that have
mandatory dependencies on artifacts with incompatible licenses because that
might "trap" users into making legal mistakes. But that is ASF policy, not a
legal matter.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
y.
In practice, of course, few developers *tell* the company lawyers about this,
and the ASF never sues so things tick over fine even though there is *legally*
a problem.
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
1 - 100 of 132 matches
Mail list logo
