Re: Checked Exceptions

[Sandro Martini]

Hi Paul,
+1 from me for the change to unchecked exceptions, like in Scala (and others).

What do you think even on adding an annotation to better show (for
documentation purposes, etc) unchecked exceptions that could be thrown
(if useful) ?
Some info here:
http://alvinalexander.com/scala/how-to-declare-scala-methods-throws-exceptions

Bye


2016-12-05 9:47 GMT+01:00 Paul Merlin :
> Gang,
>
> We have some checked exceptions in core:
>
> - AssemblyException
> - ActivationException
> - PassivationException
> - BindingException
> - InvalidInjectionException
> - EntityFinderException
>
> They get in the way, like checked exceptions do, when writing lambdas.
> The most annoying one is AssemblyException, it prevent us from writing
> concise application assemblies.
>
> I'd be in favor of changing these to non-checked exceptions.
>
> WDYT?
>
> /Paul
>

Re: [VOTE] New name

[Sandro Martini]

> [x ] Apache Vorticity


Bye,
Sandro

Re: [VOTE] New name

[Sandro Martini]

Hi all,

> [ ] Apache Accaly
> [X] Apache Akira
> [ ] Apache Zeno
> [ ] None of the above


Bye,
Sandro

Re: Java 9 Support

[Sandro Martini]

Hi Paul,
as always you did a great job !!

Bye,
Sandro


2016-09-05 3:46 GMT+02:00 Paul Merlin :
> Gang,
>
> Good news, Zest Core just works on Java 9!
>
> Bad news, we can't just use it right now.
> Some things in the build are failing with Java 9.
>
> I created ZEST-175 to track the effort.
>
> Code wise, only one test was failing with Java 9 because it uses internal
> JDK apis.
> It's the test for virtual hosting setup in HTTP Library that failed, it
> hooks into the JVM DNS resolution to setup the test environment. I moved it
> in a separate source-set that is only used when the build is run with JDK<9.
> That's good enough.
>
> I did upgrade ./gradlew to use Gradle 3.0 along the way as it was needed to
> support Java 9.
> You'll notice that the Gradle Daemon is now enabled by default, see
> https://docs.gradle.org/3.0/release-notes.
> I explicitly disabled the daemon on CI.
>
> I also added a CI job to ensure we don't introduce anything that would
> prevent Zest to work on JDK 9:
> https://builds.apache.org/view/S-Z/view/Zest/job/Zest(JavaEdition)-develop-java9-check/
>
> Three things remain:
>
> 1/ OSGi/Bnd does not support Java 9 yet.
> 2/ The Scala compiler does not support Java 9 yet.
> 3/ Jacoco does not support Java 9 yet, their 0.7.8-SNAPSHOT version do.
>
> I'll upgrade these as soon as compatible versions are published.
>
> Cheers
>
> /Paul
>

Re: toValueList, toValueMap, toValueSet

[Sandro Martini]

Hi all,
Zinc is one library usually used by other tools/IDE for compiling Scala
code (Prince is using Scala, right) ?

A minimal sample of Prince setup could help to better understand where the
problem is ...

Hope this helps.

Bye,
Sandro

Il 03/Set/2016 17:41, "Niclas Hedhman"  ha scritto:

> type
>   ./gradlew assemble
>
> in zest root dir
>
> On Sat, Sep 3, 2016 at 11:31 PM, Prince Arora 
> wrote:
>
> > I don't have the gradle wrapper gradlew. I am using simple gradle build
> and
> > i am using it in terminal not in IDE.
> >
> > On Sat, Sep 3, 2016 at 8:52 PM, Niclas Hedhman 
> wrote:
> >
> > > 1. Are you compiling inside IDEA or from command line with ./gradlew ??
> > >
> > > 2. I have never heard of "zincClasspath". Anyone has any idea of what
> it
> > > is?
> > >
> > > Tomorrow (it is soon midnight here) I'll do a test build on my Debian 8
> > > system, which is quite close to your Ubuntu and see what I get.
> > >
> > > On Sat, Sep 3, 2016 at 9:53 PM, Prince Arora  >
> > > wrote:
> > >
> > > > Let me know what exactly i am missing here.
> > > >
> > > > On Sat, Sep 3, 2016 at 7:22 PM, Prince Arora <
> aroraprince...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > I tried a local build but getting an error for lang-scala. Please
> > find
> > > > the
> > > > > stace trace bellow:
> > > > >
> > > > >
> > > > > Error:
> > > > > * What went wrong:
> > > > > A problem was found with the configuration of task
> > > > > ':org.apache.zest.libraries:org.apache.zest.library.lang-
> > > > > scala:compileTestScala'.
> > > > > > No value has been specified for property 'zincClasspath'.
> > > > >
> > > > >
> > > > >
> > > > > org.gradle.api.tasks.TaskValidationException: A problem was found
> > with
> > > > > the configuration of task ':org.apache.zest.libraries:
> > > > > org.apache.zest.library.lang-scala:compileTestScala'.
> > > > > at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.
> > > > execute(
> > > > > ValidatingTaskExecuter.java:55)
> > > > > at org.gradle.api.internal.tasks.execution.
> > > > SkipEmptySourceFilesTaskExecut
> > > > > er.execute(SkipEmptySourceFilesTaskExecuter.java:52)
> > > > > at org.gradle.api.internal.tasks.execution.
> > > > SkipTaskWithNoActionsExecuter.
> > > > > execute(SkipTaskWithNoActionsExecuter.java:52)
> > > > > at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.
> > > > execute(
> > > > > SkipOnlyIfTaskExecuter.java:53)
> > > > > at org.gradle.api.internal.tasks.execution.
> > > > ExecuteAtMostOnceTaskExecuter.
> > > > > execute(ExecuteAtMostOnceTaskExecuter.java:43)
> > > > > at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> > > > > EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203)
> > > > > at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> > > > > EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185)
> > > > > at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$
> > > > > TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:66)
> > > > > at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$
> > > > > TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:50)
> > > > > at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(
> > > > > DefaultTaskPlanExecutor.java:25)
> > > > > at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.
> execute(
> > > > > DefaultTaskGraphExecuter.java:110)
> > > > > at org.gradle.execution.SelectedTaskExecutionAction.execute(
> > > > > SelectedTaskExecutionAction.java:37)
> > > > > at org.gradle.execution.DefaultBuildExecuter.execute(
> > > > > DefaultBuildExecuter.java:37)
> > > > > at org.gradle.execution.DefaultBuildExecuter.access$
> > > > > 000(DefaultBuildExecuter.java:23)
> > > > > at org.gradle.execution.DefaultBuildExecuter$1.
> > > > > proceed(DefaultBuildExecuter.java:43)
> > > > > at org.gradle.execution.DryRunBuildExecutionAction.execute(
> > > > > DryRunBuildExecutionAction.java:32)
> > > > > at org.gradle.execution.DefaultBuildExecuter.execute(
> > > > > DefaultBuildExecuter.java:37)
> > > > > at org.gradle.execution.DefaultBuildExecuter.execute(
> > > > > DefaultBuildExecuter.java:30)
> > > > > at org.gradle.initialization.DefaultGradleLauncher$4.run(
> > > > > DefaultGradleLauncher.java:154)
> > > > > at org.gradle.internal.Factories$1.create(Factories.java:22)
> > > > > at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> > > > > DefaultBuildOperationExecutor.java:90)
> > > > > at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> > > > > DefaultBuildOperationExecutor.java:52)
> > > > > at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(
> > > > > DefaultGradleLauncher.java:151)
> > > > > at org.gradle.initialization.DefaultGradleLauncher.access$
> > > > > 200(DefaultGradleLauncher.java:32)
> > > > > at org.gradle.initialization.DefaultGradleLauncher$1.
> > > > > 

Re: Yeoman for scaffolding

[Sandro Martini]

Sorry, just see that you already committed some stuff in Zest-Java
under the 'ZEST-158' issue ... anyway do you need some kind of help on
this (without so much knowledge of Zest) ?

Sandro

2016-08-25 14:26 GMT+02:00 Sandro Martini <sandro.mart...@gmail.com>:
> Hi Niclas,
> like you I thing that Yeoman is an interesting tool, but up to now I
> only used it few times.
> As seen [here](http://yeoman.io/authoring/) shouldn't be too complex
> to write custom generators, so could be a good thing to try :-) ...
>
> Are templates to use in generators already present somewhere in some
> Zest repository (at least as samples) ?
>
> Last, to start write/review something, do you think a new folder
> 'generators' in 'develop' branch of Zest-Sandbox could be used (or
> other) ?
>
> Bye,
> Sandro

Re: Yeoman for scaffolding

[Sandro Martini]

Hi Niclas,
like you I thing that Yeoman is an interesting tool, but up to now I
only used it few times.
As seen [here](http://yeoman.io/authoring/) shouldn't be too complex
to write custom generators, so could be a good thing to try :-) ...

Are templates to use in generators already present somewhere in some
Zest repository (at least as samples) ?

Last, to start write/review something, do you think a new folder
'generators' in 'develop' branch of Zest-Sandbox could be used (or
other) ?

Bye,
Sandro

Re: Test Points

[Sandro Martini]

Hi all,
just for info I see some libraries like the great
[Akka](http://akka.io) that has an instrumented version too, so
if/when needed it's possible to use that version to gather more info
at runtime (via JMX, etc) have more asserts, and if needed even to set
some action ...
Maybe something like this could be applied here, with a variant in
published artifacts, but for sure it's not trivial to setup and keep
aligned with "normal" (not instrumented) version ...

What do you think ?

Bye,
Sandro

2016-06-14 2:26 GMT+02:00 Niclas Hedhman :
> Hi,
> I just had a revelation, watching Uncle Bob about TDD, combined with my
> knowledge about electronics design which uses Test Points (both at board
> level as well as silicon level)
>
> Since Zest "owns" the call chain, we could rather easily design a feature
> that is the equivalent to Test Points in electronics. Places where values
> are checked against an expectations.
>
> Isn't that what "assert" keyword is all about?
>
> Yes and no.
>
> Assert keyword can only tell if the value is within an expected range. It
> is rather difficult to communicate to assert what values are expected right
> now.
>
> What is the purpose of this?
>
> Well, I think that unit tests are a little bit "weak" since it is difficult
> to test that sequencing is correct, that interdependent computations are
> accurate and many other "functional" and "acceptance" test level issues. I
> think we can solve this rather neatly, by assembling the "real" application
> with additional Test Points (well the annotations are there all the time),
> Memory Es and feed actually data through and validate the results.
>
> So how is this going to work?
>
> Well, I don't know yet. But I imagine that One test consists of S setup
> steps, N steps of execution, and M results from T test points. Details not
> clear yet.
>
> I imagine that the Test Point is a combo of a SideEffect, an annotation and
> Reporting service. I imagine that the side effect has some way to know what
> is expected to happen at each test point.
>
> This is GutFeeling(tm) innovation at the moment, but I think there is
> strong values in here.
>
> As usual, feedback is most welcome...
>
> Cheers
> Niclas

Re: Generic composite types in Zest

[Sandro Martini]

Hi all,
in Scala there is a workaround for erasure, take a look here:

http://docs.scala-lang.org/overviews/reflection/typetags-manifests.html

but probably that info is accessible only in/from Scala code.
But in the implementation they use some trick available in Java, maybe
something like this could be implemented/reimplemented even here.
Some info on the trick used here (in comments):

http://blogs.atlassian.com/2012/12/scala-and-erasure/

hope you can find useful ...


In Groovy I'm not sure there is something similar, but with the
ability to have metadata for any class probably something could be
done. Some info on available AST Transformations here:

http://www.groovy-lang.org/metaprogramming.html#_compile_time_metaprogramming


Anyway note that reified generics could have a runtime overhead, so
I'm not sure it will be a good solution for all cases (in many
probably it is :-) ). Anyway it seems that Java 10 could implement
something better on generics ... who can say ?

http://literatejava.com/java-language/value-types-list-int-coming-java-10/


Bye,
Sandro


2015-12-18 2:40 GMT+01:00 Niclas Hedhman :
> In Zest Java, there is limited support for generic types. For instance,
>
> @Service
> Foo longFoo;
>
> @Service
> Foo stringFoo;
>
> is handled as expected.
>
> To sort out what Java can and can not do;
> As you mention, Java's generics support is not complete, but it is (and
> always been) incorrect (despite everyone saying so) that the generics are
> compile-time only.
>
> The "declaration" of something (method return type, method parameters,
> fields,...) all has the generics information in them, even the TypeVariable
> name ("K" and "V" in Map). But the object doesn't reference the
> ParameterizedType (only the Class) instance, so that bit is missing (still,
> and probably not going to be fixed).
>
> This has some consequences,
>
> {
> Object list = new ArrayList();   // local variable = No generics
> information
> abc( list );   // Requires cast, but only for compiler. No runtime
> check possible
> def( list );// Requires cast, but only for compiler. No runtime
> check possible
> }
>
> public void abc( List list ) {}
> public void def( List list ) {}
>
> So, from there it is possible to fill the List with any type you want. So,
> there is no possibility to equal()=false for
>
> new ArrayList().equals( new ArrayList() )
>
> the information isn't there.
>
>
> Now, this also means that;
>
> ValueBuilderFactory vbf;
>
> MyValueComposite v =
> (MyValueComposite) vbf.newValue( MyComposite.class);
>
> will "work" just as well as the java.util.List shown above.
>
> So beyond these basic two cases, I am not sure what else can be done to
> support Generic Types in Zest Java.
>
> I am uncertain whether nested generics works for Services;
>
> @Service
> Foo>> foo;
>
> But that would be the only thing that I could imagine to be improved.
>
> Other concrete ideas are welcome.
>
> Niclas
>
> On Thu, Dec 17, 2015 at 10:33 PM, Stanislav Muhametsin <
> stanislav.muhamet...@zest.mail.kapsi.fi> wrote:
>
>> This thing came to my mind when writing previous mail about Assemblies,
>> Models, and Instances.
>> Is it true that Zest still has limitation/restriction not to support
>> generic composites (i.e. MyComposite -interfaces as composite types)?
>> IMO you might want to remove that limitation.
>> I am not sure if that is possible, since generics in Java exist only at
>> compile-time (is this so with newest Java?).
>> But I am certain that many people are most likely to give up on Zest when
>> they encounter that limitation (I know it was a tough slap-in-the-face for
>> me, when I encountered it).
>>
>> If you decide to remove this limitation, I could give some pointers as to
>> which pitfalls to avoid, and what to keep in mind, when dealing with
>> generic composite types.
>> I encountered a lot of trouble when I implemented generic composites in
>> Qi4CS, but the type system in CLR preserves generic argument information at
>> runtime (so, in Java terms, that List.class will return *false*
>> when doing equality comparison with List.class), so it was possible
>> to implement support for generic composite types.
>> In Zest, it might make code generation more complex, and it might make the
>> method intercepting code in Zest more complex, but I think it is worth the
>> hassle.
>>
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java

Re: Commit signing?

[Sandro Martini]

Hi Niclas,
after reading so many emails on Git and code provenance (and maybe
lost some email ...) I fear to introduce only a small complexity
without too much gain ... anyway I think that we could try something,
if not in main repository in zest-sandbox.

I have a Code Signing PGP key with my Apache ID that's still valid; to
begin we could exchange our public key between us :-) . And then add
to KEYS file in Zest source repository.
My Key ID is: F9EDAF10 , note that's published at MIT Key Server
(should be valid, please tell me if not because it's not clear); you
can find it even here (two asc files but it's the same key):
http://people.apache.org/~smartini/
I put here in attach here just for convenience.

Niclas, your ?
Paul and others ?

Stay well.

Bye,
Sandro

2015-10-28 2:32 GMT+01:00 Niclas Hedhman :
> Hi,
> There are some internal debate about how to ensure provenance in a Git and
> GitHub world. I can't say how that discussion is going, but one idea that
> surfaced, which we (the projects) can do regardless of the total outcome,
> to improve code provenance is to sign our commits.
>
> I first note that IntelliJ doesn't support for commit signing directly.
>
> Secondly, http://mikegerwitz.com/papers/git-horror-story (I hope I typed
> that correctly) is a must read.
>
> In that paper, I am specifically talking about Option #3 (as I doubt that
> we (Zest) will get too many pull requests that are many commits long)
>
> This seems to be something that can be introduced incrementally and at slow
> pace, which is something we like at Apache. Trust enforcement and all of
> that can be done later, and perhaps other projects will lead the way...
>
> I would like to hear what people think about this...
>
> Cheers
> Niclas
>
> P.S. I am now settled in, in Shanghai and just started to work on a new
> Zest based app on my spare time, so activity should start to pick up again.
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v2.0.17 (MingW32)

mQENBE5ScxYBCAC8B9CIHxb7rouKnmTJbJOzWCsjYAx9CTHxNYGYI4bbM7M/tyTh
73Rex5Af8UkBeZsFPRY0yXLtgWKFmqhtPaM9gAgvFZu/Fi/c30HsMW6SyuoMzXRF
sYfe6ra+uanqf0STfMDjojNCDELbjfC+y4z1MFU/IyQUke6jnup6PFfAj9olsD8f
bHNy/BU/J7iicOcqY+oWiCi71kNGAMx1Oh/iU5l0HPw3qDDz4dE9PO4k8dA0sPIH
0xcZuPzAAEhVxn5J+Z8uvZ1FoxceKviv5lXWm+5YejmyUdrWpGdWo+lKMgojznPB
dV3YKazEuZLpDiPPDnEgg9C7EIrSJ1e+1WghABEBAAG0LVNhbmRybyBNYXJ0aW5p
IC0gQXBhY2hlIDxzbWFydGluaUBhcGFjaGUub3JnPokBOAQTAQIAIgIbDwYLCQgH
AwIGFQgCCQoLBBYCAwECHgECF4AFAk5lThsACgkQZF/YhvntrxD6fQf/XD21fimN
UH95RumWDjeugmH86GdAYqYSkWneQbDnnEeFiigZjRxx5QeHMkbHt/QDnlgi2iG8
mrESq1cHpTIrFXQlyPa6pAoBsK78tPVKYI8fwY4nI3HkLWpdGY9KP66Ihl4WDt4V
hGBBzv9XSBczHfJ5cKQp7Vxl6qZltBFk8qbKx4Lnf/WS936PLN6al6bi0h0CCCqM
Znqc/la+nwnXcBa6reIYZi+6L3QQBBESWCMMYr7YkIQ5yFncmPsWsal+CZiqOQ29
UcH4B6gWVOqjfXsceF5mAvfdqVS7cgq/ltvW8UKMZHpFMuYIgtLMyIdi7dEAbpF3
DQQU6OVfDXFY9w==
=PlP9
-END PGP PUBLIC KEY BLOCK-

Re: Release...

[Sandro Martini]

Hi all,
what do you think on keep the vote period long this time ?
Two weeks are too much ?
Otherwise I'll do my vote next release, sorry ...

Bye
 Il 24/Lug/2015 17:35, Paul Merlin p...@nosphere.org ha scritto:

 Niclas Hedhman a écrit :
  Oh... Let me do that.
 Ok we're now good to go.
 I'll probably start the release on monday, or earlier if I find time to
 do so.

 Cheers

 /Paul


  On Fri, Jul 24, 2015 at 9:28 PM, Paul Merlin p...@nosphere.org wrote:
 
  Niclas Hedhman a écrit :
  Paul,
 
  I think we are totally ok to start a release. I have nothing I want to
  add
  at this point. And we have more things verified than ever before when
  starting releases, where minor adjustments had to be made in the
 release
  branch.
 
  So, go ahead if/when you have time.
  Yes, things are in a pretty good shape now.
 
  Did you happen to request the zest-java git repository from INFRA?
 
  I'd really like this to be done before releasing (before people start to
  clone etc..).
 
 
 
 

Re: Rename git repository from zest-qi4j to zest-java?

[Sandro Martini]

Hi all,
just for info, currently I'm using the Zest repository from this url
(not the usual git-us) and all works good the same ...

git://git.apache.org/zest-qi4j.git

I found some reference to the original host git-wip-us.apache.org in
maven-compat.gradle, and in this page
http://zest.apache.org/community/codebase.html;, if you are doing a
rename maybe even this could be updated :-) .

Bye


2015-07-19 20:59 GMT+02:00 Paul Merlin p...@nosphere.org:
 Hey Niclas,

 Niclas Hedhman a écrit :
 Actually; Isn't it a matter of asking for a new one? We should be able to
 migrate the content ourselves, as in a few minutes.

 Or?
 I see no issue doing it either way.

Re: Rename git repository from zest-qi4j to zest-java?

[Sandro Martini]

ok, good to know :-) .

Paul, thanks for your tests.
Bye

2015-07-20 14:24 GMT+02:00 Paul Merlin p...@nosphere.org:
 I just tried to push some commits to:

 - https://git.apache.org/zest-qi4j.git - not supported
 - g...@git.apache.org:zest-qi4j.git - support only ssh pub keys, which I
 don't have, don't know if it support pushing


 Sandro Martini a écrit :
 Sorry I don't know, maybe a check with Infra could give us right answers ...

 2015-07-20 12:06 GMT+02:00 Niclas Hedhman nic...@hedhman.org:
 I am in transit at the moment and can't double-check, isn't one URL a
 read-only and the other the ACL controlled one?

 // Niclas
 On Jul 20, 2015 10:25, Sandro Martini sandro.mart...@gmail.com wrote:

 Hi all,
 just for info, currently I'm using the Zest repository from this url
 (not the usual git-us) and all works good the same ...

 git://git.apache.org/zest-qi4j.git

 I found some reference to the original host git-wip-us.apache.org in
 maven-compat.gradle, and in this page
 http://zest.apache.org/community/codebase.html;, if you are doing a
 rename maybe even this could be updated :-) .

 Bye


 2015-07-19 20:59 GMT+02:00 Paul Merlin p...@nosphere.org:
 Hey Niclas,

 Niclas Hedhman a écrit :
 Actually; Isn't it a matter of asking for a new one? We should be able
 to
 migrate the content ourselves, as in a few minutes.

 Or?
 I see no issue doing it either way.

Re: Rename git repository from zest-qi4j to zest-java?

[Sandro Martini]

Hi Paul,
I think a rename now would be better now, but maybe the same rename
should be done in many other places (docs, etc) to reduce possible
confusion even there.

Bye

Re: Admin access to Jira

[Sandro Martini]

Hi all and sorry for the delay ...

I see that Niclas has already been able to fix the permissions stuff,
very good (I forgot to do this step).

Paul, if you want to reassign the related issue (
https://issues.apache.org/jira/browse/ZEST-28 ) be free, don't worry.
And if it's no more useful, mark it as resolved :-) .

Stay well.
Bye


2015-06-14 11:53 GMT+02:00 Paul Merlin p...@nosphere.org:
 Niclas Hedhman a écrit :
 Gang,
 I was asking Sandro to add me and Paul to Jenkins for administration. Well,
 turns out that *I* am supposed to do that via a Perl script on
 people.apache.org, similarly to how I add committers to the project.

 So, although I wasn't allowed to administer the Jenkins instance, I have
 been allowed to add
   * niclas
   * paulmerlin
   * jiri
   * soelvsten

 to the Jenkins job admin group (ironically called 'hudson-jobadmin' for
 historical reasons).

 Notifications have been sent to root@ which probably takes a short while to
 make it happen.

 Sandro, thanks for starting this.
 Paul, we (you, since I don't recall I had creds to do that) should take
 down the build and resources on Cloudbees.
 Thanks Niclas.
 I just changed the build from `clean build` to `clean check` for quick
 feedback.

 I'll take cloudbees builds down.

 Cheers

 /Paul

Re: Build failed in Jenkins: Zest-qi4j develop on Java7 (Oracle JDK) #5

[Sandro Martini]

Hi,
should be enough to have an account at builds,  but maybe I forgot to
configure something ... I'll check asap.

On the throttle I'll remove, but for add a limit to email don't know, but
will do other checks soon.

I'll post some update.
Sorry for the current behavior.

Bye
 Il 13/Giu/2015 05:14, Niclas Hedhman nic...@hedhman.org ha scritto:

 Also, who can enable more Karma for committers at Zest on this build? I
 don't seem to be allowed to view nor change the config.

 Niclas

 On Sat, Jun 13, 2015 at 11:08 AM, Niclas Hedhman nic...@hedhman.org
 wrote:

 
  IIRC, instead of limiting the builds, one can limit the number of emails
  to a given destination. Or do I remember completely wrongly?
 
  On Sat, Jun 13, 2015 at 5:57 AM, Sandro Martini 
 sandro.mart...@gmail.com
  wrote:
 
  Hi all,
  sorry for the noise emails at any failed build ... tell me if it's too
  much and I can temporarily disable or reduce to 1 build per day for
  now ...
 
  Bye
 
 
  2015-06-12 22:47 GMT+02:00 Apache Jenkins Server 
  jenk...@builds.apache.org:
   See 
 
 https://builds.apache.org/job/Zest-qi4j%20develop%20on%20Java7%20(Oracle%20JDK)/5/
  
  
 
 
 
 
  --
  Niclas Hedhman, Software Developer
  http://zest.apache.org - New Energy for Java
 



 --
 Niclas Hedhman, Software Developer
 http://zest.apache.org - New Energy for Java

Re: Releasing 2.1

[Sandro Martini]

Hi all,
to help with builds (or better to ensure code is buildable, at least
one time per day), what do you think to add a new issue for Jenkins
builds of Zest branches (master, and maybe others) ?

https://builds.apache.org/


Bye,
Sandro


2015-06-12 2:51 GMT+02:00 Niclas Hedhman nic...@hedhman.org:
 Gang,

 as I mentioned else-thread, I would like to push a 2.1 release out the
 door.


 For this to be achievable, there are quite a lot of small tasks to be made,
 and I have started to collect those on
 https://issues.apache.org/jira/browse/ZEST-24

 Please help add tasks, and if possible assist any way you can to make this
 happen.


 Cheers
 --
 Niclas Hedhman, Software Developer
 http://zest.apache.org - New Energy for Java

[jira] [Created] (ZEST-28) Create Jenkins Builds for Zest sources

[Sandro Martini (JIRA)]

Sandro Martini created ZEST-28:
--

 Summary: Create Jenkins Builds for Zest sources
 Key: ZEST-28
 URL: https://issues.apache.org/jira/browse/ZEST-28
 Project: Zest
  Issue Type: Sub-task
Reporter: Sandro Martini
Assignee: Sandro Martini


To ensure sources are buildable, add one job for any desired branch with 
default configuration (JDK, etc), and maybe others with different 
configurations.

For now, schedule only required (with defaults) daily, and maybe keep others 
not enabled and execute them only by hand.

builds.apache.org

One time created, post here job URLs so it's simple to reference them (note 
that any build has an RSS feed that could be useful to get by browsers).

If possible, before doing this, update Zest build to use latest Gradle (2.4).

Note: be free to update this description and/or reassign to another Zest member.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Releasing 2.1

[Sandro Martini]

Yes, I did a setup some time ago for Pivot (one build per branch with
default JDK, and another with a more recent JDK, so in total 4 or more
daily builds).

Zest uses Gradle so all should be doable.
At the moment Zest is using Gradle-2.2.1, but latest (2.4) is faster,
what do you think to update (if all builds the same of course :-) ) ?

I think we can start with default branch and default configuration.


I can try to take a look, or help someone who wants to do it ... tell me.


This is the issue:
https://issues.apache.org/jira/browse/ZEST-28
be free to update/reassign, or move outside the 2.1 umbrella , don't worry.


Bye


2015-06-12 10:10 GMT+02:00 Jiri Jetmar juergen.jet...@gmail.com:
 Hi Sandro,

 at least for me this is a good idea ! I guess it will be possible to
 measure aspects like
 failing tests, coverage, .. in a automated way.

 Cheers,
 jj

 2015-06-12 9:51 GMT+02:00 Sandro Martini sandro.mart...@gmail.com:

 Hi all,
 to help with builds (or better to ensure code is buildable, at least
 one time per day), what do you think to add a new issue for Jenkins
 builds of Zest branches (master, and maybe others) ?

 https://builds.apache.org/


 Bye,
 Sandro


 2015-06-12 2:51 GMT+02:00 Niclas Hedhman nic...@hedhman.org:
  Gang,
 
  as I mentioned else-thread, I would like to push a 2.1 release out the
  door.
 
 
  For this to be achievable, there are quite a lot of small tasks to be
 made,
  and I have started to collect those on
  https://issues.apache.org/jira/browse/ZEST-24
 
  Please help add tasks, and if possible assist any way you can to make
 this
  happen.
 
 
  Cheers
  --
  Niclas Hedhman, Software Developer
  http://zest.apache.org - New Energy for Java

Re: Releasing 2.1

[Sandro Martini]

Hi Paul,

 And for information we have our old CI server at
 https://qi4j.ci.cloudbees.com/

 It already points to Apache git service.

great, I haven't an account there, but I'll try to take a look

 The uploadArchive weekly job push SNAPSHOTS maven artifacts to our old
 repository hosted at Cloudbees too. There is ZEST-20 to setup maven
 repository @apache for the Zest project.

 If the `version` is a -SNAPSHOT, the build system do not sign the
 artifacts so PGP setup is unneeded.

even better :-) , so I'd skip the signing of artifacts


 For updating Gradle to latest, I'll check it later (unless someone
 will do it before me) ...
 I have the needed changes locally, will push them asap.

very well

 We need also to add our PGP signing keys to KEYS file, you remember ?
 And then maybe add keys from other Zest PMC Members (at least Release 
 managers).
 We already have a KEYS file in the source tree root.
 Only mine and Niclas's are in for now.

ok, I'll do some check on mine and maybe add there ...


Paul, you know that in my someone other I was thinking to you as
Release Manager, right ? :-) ...

Thanks for now.

Bye

Re: Releasing 2.1

[Sandro Martini]

Hi,

 Perhaps you and others haven't seen our codebase guideline;
 http://zest.apache.org/community/codebase.html, which contains a nice
 diagram on the Git forking model we use.

Note that in that page, references aren't to ASF Git Zest repository
... and probably something (later) should be written on how to
conrtibute via push request (with GitHUB mirror, or directly at Apache
Git ?).

git://git.apache.org/zest-qi4j.git
and its mirror:
https://github.com/apache/zest-qi4j

maybe that page has to be updated (and maybe even write that read-only
users can use normal http, not https).

Note:
I'm using this but not sure if it's good the same (generally speaking):
https://git-wip-us.apache.org/repos/asf/zest-qi4j.git



Maybe even this page should be updated (soon or later):
http://zest.apache.org/community/contributors.html
PMC Members and more info related on an ASF Project structure ...


Bye

2015-06-12 12:31 GMT+02:00 Sandro Martini sandro.mart...@gmail.com:
 Hi Paul,

 And for information we have our old CI server at
 https://qi4j.ci.cloudbees.com/

 It already points to Apache git service.

 great, I haven't an account there, but I'll try to take a look

 The uploadArchive weekly job push SNAPSHOTS maven artifacts to our old
 repository hosted at Cloudbees too. There is ZEST-20 to setup maven
 repository @apache for the Zest project.

 If the `version` is a -SNAPSHOT, the build system do not sign the
 artifacts so PGP setup is unneeded.

 even better :-) , so I'd skip the signing of artifacts


 For updating Gradle to latest, I'll check it later (unless someone
 will do it before me) ...
 I have the needed changes locally, will push them asap.

 very well

 We need also to add our PGP signing keys to KEYS file, you remember ?
 And then maybe add keys from other Zest PMC Members (at least Release 
 managers).
 We already have a KEYS file in the source tree root.
 Only mine and Niclas's are in for now.

 ok, I'll do some check on mine and maybe add there ...


 Paul, you know that in my someone other I was thinking to you as
 Release Manager, right ? :-) ...

 Thanks for now.

 Bye

Re: Build failed in Jenkins: Zest-qi4j develop on Java7 (Oracle JDK) #5

[Sandro Martini]

Hi all,
sorry for the noise emails at any failed build ... tell me if it's too
much and I can temporarily disable or reduce to 1 build per day for
now ...

Bye


2015-06-12 22:47 GMT+02:00 Apache Jenkins Server jenk...@builds.apache.org:
 See 
 https://builds.apache.org/job/Zest-qi4j%20develop%20on%20Java7%20(Oracle%20JDK)/5/

[jira] [Commented] (ZEST-28) Create Jenkins Builds for Zest sources

[Sandro Martini (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZEST-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583403#comment-14583403
 ] 

Sandro Martini commented on ZEST-28:


Here you can find the build for the develop branch, with Oracle JDK 7 and all 
other defaults:
https://builds.apache.org/user/smartini/my-views/view/Zest/job/Zest-qi4j%20develop%20on%20Java7%20%28Oracle%20JDK%29/

Gradle tasks assemble dist has been removed (in executes tasks) because they 
need to sign artifacts, so no useful here at the moment. I scheduled one build 
at 13 PM and another at 20 PM every day, with a timeout of 60 minutes (or a 
build will be aborted), but not enabled the email sending if a build fails 
(until we fix the develop branch it's better).
But anyone can login and trigger a manual build.

For other jobs I suggest to update this (or a copy of it), and then copy to use 
as a starting point.

Other Zest developers should be able to login at Builds and change/add other 
jobs, if not tell me.


Pauls, than you very much for the update, I'll try to check if it's updated too.
Be free to update the current job (or update a copy and put this in disabled 
status if not sure :-) ).

To resolve the current issue I'd wait to have a more complete build of sources.


 Create Jenkins Builds for Zest sources
 --

 Key: ZEST-28
 URL: https://issues.apache.org/jira/browse/ZEST-28
 Project: Zest
  Issue Type: Sub-task
Reporter: Sandro Martini
Assignee: Sandro Martini
  Labels: continuous_integration, jenkins, quality

 To ensure sources are buildable, add one job for any desired branch with 
 default configuration (JDK, etc), and maybe others with different 
 configurations.
 For now, schedule only required (with defaults) daily, and maybe keep others 
 not enabled and execute them only by hand.
 builds.apache.org
 One time created, post here job URLs so it's simple to reference them (note 
 that any build has an RSS feed that could be useful to get by browsers).
 If possible, before doing this, update Zest build to use latest Gradle (2.4).
 Note: be free to update this description and/or reassign to another Zest 
 member.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Site

[Sandro Martini]

Hi all,

 No trunk/tags/branches for svn is needed, since the code is residing on Git, 
 and only a very small section of source documentation for the landing pages 
 are in SVN. The main documentation is in src/docs folders in the Git 
 repository.
ok, my question was just to be sure it wasn't needed ...

 As for your issue with SVN, I don't know what it could be.
yes, it's very strange ...
 But I also know that unless you plan to write docs, generate site or release 
 the SDK, then you don't really need the SVN part. Because setting up a 
 working AsciiDoc (currently required) might be troublesome on Windows.
anyway it's not a problem, and I have some vm with Linux if needed :-)


 Yep I've seen that other projects have t/t/b folders under site/
 Some other projects don't.
 Some do not have a content/ folder either.
yes, I see it too, it depends even on tools used in any project

 I did put the files where they get served at zest.apache.org/.
 Tried zest/site/trunk/content but it did not work, only
 zest/site/content worked.
ok, don't worry
 This may be related to some infra configuration but wanted to put the site 
 online asap.
ok, don't worry


 For the record, it took me like 5/6 hours to commit  svn FTW.
:-)

 I just did a fresh svn checkout without any issue here (Mac  Linux).
I'll make other tests, but yes, could be something with Windows ...
because others could have the same problem.

Stay well.
Bye

Re: JIRA

[Sandro Martini]

Hi Paul :-) ,
no I think could be something related to permissions/visibility for
zest committers / developers that aren't asf members (so already
defined even in other groups) ... maybe Niclas have some idea on
fixing it.

Note that here: http://people.apache.org/committers-by-project.html#zest
I find your apache id that seems to be another, maybe even this can
lead to some confusion ...

Bye

[jira] [Created] (ZEST-18) QuickCheck instead of JUnit

[Sandro Martini (JIRA)]

Sandro Martini created ZEST-18:
--

 Summary: QuickCheck instead of JUnit
 Key: ZEST-18
 URL: https://issues.apache.org/jira/browse/ZEST-18
 Project: Zest
  Issue Type: Improvement
 Environment: Java 8
Reporter: Sandro Martini


To better fix/identify problems in multi-thread execution contexts, verify if 
write (additional) Unit Tests but with dedicated libraries (more specific than 
JUnit), like QuickCheck or one of others similar (for example see even 
ScalaCheck).
Note that usually many libraries for this require Java 8.

As repository use Zest-sandbox (maybe in a feature branch), so it would be 
simpler to evolve/integrate/remove later in Zest code base.

For more info, see related thread in our dev mailing list.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)