11:34 p.m.
Agenda
- Logging
- Testing
These are in the context of Seam 3.1 which we are working on releasing and
have noticed a few issues and concerns
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
4:27 a.m.
Another thing to add to the agenda which we need to discuss is
dependency scopes. In particular, we need to review our previous
decision to make the implementation component of a module
runtime-scoped, in light of the fact that we now no longer have combined
jars.
On 17/08/11 07:34, Jason Porter wrote:
Agenda
* Logging
* Testing
These are in the context of Seam 3.1 which we are working on releasing
and have noticed a few issues and concerns
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net <http://keyserver.net>;,
pgp.mit.edu <http://pgp.mit.edu>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
4:48 a.m.
On Tue, Aug 16, 2011 at 22:27, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Another thing to add to the agenda which we need to discuss is
dependency
scopes. In particular, we need to review our previous decision to make the
implementation component of a module runtime-scoped, in light of the fact
that we now no longer have combined jars.
Isn't the idea of having an API and implementation split is that you should
not be compiling against anything in the implementation? Of course, an end
user can choose to override that convention to make the implementation a
compile-time scope, but we don't want to encourage that, do we?
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
4:56 a.m.
On Tue, Aug 16, 2011 at 22:48, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Aug 16, 2011 at 22:27, Shane Bryzak
<sbryzak(a)redhat.com> wrote:
> Another thing to add to the agenda which we need to discuss is dependency
> scopes. In particular, we need to review our previous decision to make the
> implementation component of a module runtime-scoped, in light of the fact
> that we now no longer have combined jars.
>
Isn't the idea of having an API and implementation split is that you should
not be compiling against anything in the implementation? Of course, an end
user can choose to override that convention to make the implementation a
compile-time scope, but we don't want to encourage that, do we?
I'll add to that that I really, really don't think that having a single
dependency declaration is a holy grail. We have gone to great lengths to
have an API for Seam 3 and I think we should advocating the use of it (as
separate from the implementation). It's a minor inconvenience to add to the
POM (a complexity that Forge can tare), but far less convenient than
slipping into a dependency on an implementation class.
I do agree that we need to revisit it how it all works, but the goal should
be so that the API can be honored and that adding a dependency is consistent
from module to module.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
4:56 a.m.
On Aug 16, 2011, at 20:48, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Aug 16, 2011 at 22:27, Shane Bryzak
<sbryzak(a)redhat.com> wrote:
Another thing to add to the agenda which we need to discuss is dependency scopes. In
particular, we need to review our previous decision to make the implementation component
of a module runtime-scoped, in light of the fact that we now no longer have combined
jars.
Isn't the idea of having an API and implementation split is that you should not be
compiling against anything in the implementation? Of course, an end user can choose to
override that convention to make the implementation a compile-time scope, but we don't
want to encourage that, do we?
-Dan
I'm with Dan on this one. That's the whole point of impl and api.
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
4:57 a.m.
Of course, but we break that rule. Solder is one example, there's
multiple utility classes in the implementation that are required to
compile other modules. Also, by making the implementation runtime-only,
the user is forced to declare two dependencies for their project, one
for the API and one for the implementation. If the implementation was
compile-scoped, they could just declare the implementation dependency
and the API would then be pulled in automatically. This is the kind of
stuff we need to discuss and come to a resolution on.
On 17/08/11 12:48, Dan Allen wrote:
On Tue, Aug 16, 2011 at 22:27, Shane Bryzak <sbryzak(a)redhat.com
<mailto:sbryzak@redhat.com>> wrote:
Another thing to add to the agenda which we need to discuss is
dependency scopes. In particular, we need to review our previous
decision to make the implementation component of a module
runtime-scoped, in light of the fact that we now no longer have
combined jars.
Isn't the idea of having an API and implementation split is that you
should not be compiling against anything in the implementation? Of
course, an end user can choose to override that convention to make the
implementation a compile-time scope, but we don't want to encourage
that, do we?
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:05 a.m.
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Of course, but we break that rule. Solder is one example,
there's
multiple utility classes in the implementation that are required to compile
other modules.
I consider that a bug (or a work in progress, depending on how you look at
it).
Also, by making the implementation runtime-only, the user is forced
to
declare two dependencies for their project, one for the API and one for the
implementation. If the implementation was compile-scoped, they could just
declare the implementation dependency and the API would then be pulled in
automatically. This is the kind of stuff we need to discuss and come to a
resolution on.
Again, I don't think one dependency is a holy grail. We are making an
optimization that I don't find necessary. Making an implementation
compile-scoped could be classified as careless programming (by some strict
architects, let's say).
If it's setup correctly, depending on seam-faces (the impl) should make it a
runtime dep, make the api compile time, make any dependent api compile time
and make any dependency impl runtime. If Maven can't accommodate that, then
it's just a pita (even then, the worse thing that happens is that the user
has two dependencies).
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:06 a.m.
On Tue, Aug 16, 2011 at 23:05, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak
<sbryzak(a)redhat.com> wrote:
> Of course, but we break that rule. Solder is one example, there's
> multiple utility classes in the implementation that are required to compile
> other modules.
>
I consider that a bug (or a work in progress, depending on how you look at
it).
An API is an API. If it's an "internal API", then perhaps it should be an
SPI. Under no circumstances should we be depending on implementation classes
between modules. Otherwise, we are changing the definition of an
implementation.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:10 a.m.
As I have spoken with Shane in IRC, why not merge Solder API and Impl
into one module only ?
I mean, is there a strong reason for them to exist ? It will make it
easier for end users (and seam modules also)
2011/8/17 Dan Allen <dan.j.allen(a)gmail.com>:
On Tue, Aug 16, 2011 at 23:05, Dan Allen
<dan.j.allen(a)gmail.com> wrote:
>
> On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>>
>> Of course, but we break that rule. Solder is one example, there's
>> multiple utility classes in the implementation that are required to compile
>> other modules.
>
> I consider that a bug (or a work in progress, depending on how you look at
> it).
An API is an API. If it's an "internal API", then perhaps it should be an
SPI. Under no circumstances should we be depending on implementation classes
between modules. Otherwise, we are changing the definition of an
implementation.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
5:12 a.m.
On 17/08/11 13:05, Dan Allen wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com
<mailto:sbryzak@redhat.com>> wrote:
Of course, but we break that rule. Solder is one example, there's
multiple utility classes in the implementation that are required
to compile other modules.
I consider that a bug (or a work in progress, depending on how you
look at it).
George suggested that we make solder a single jar, and to me it makes
sense considering it's a set of utility features, and it would solve
this problem.
Also, by making the implementation runtime-only, the user is
forced to declare two dependencies for their project, one for the
API and one for the implementation. If the implementation was
compile-scoped, they could just declare the implementation
dependency and the API would then be pulled in automatically.
This is the kind of stuff we need to discuss and come to a
resolution on.
Again, I don't think one dependency is a holy grail. We are making an
optimization that I don't find necessary. Making an implementation
compile-scoped could be classified as careless programming (by some
strict architects, let's say).
That's fine as long as we're consistent with it.
If it's setup correctly, depending on seam-faces (the impl) should
make it a runtime dep, make the api compile time, make any dependent
api compile time and make any dependency impl runtime. If Maven
can't accommodate that, then it's just a pita (even then, the worse
thing that happens is that the user has two dependencies).
Maven won't allow this. If the dependency is runtime, it will be
totally ignored during the compile phase.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:12 a.m.
What if every module had a bom that was imported, or if this were handled in
the seam-bom?
John
On Aug 16, 2011 11:06 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak
<sbryzak(a)redhat.com> wrote:
> Of course, but we break that rule. Solder is one example, there's
> multiple utility classes in the implementation that are required to
compile
> other modules.
>
I consider that a bug (or a work in progress, depending on how you look at
it).
> Also, by making the implementation runtime-only, the user is forced to
> declare two dependencies for their project, one for the API and one for
the
> implementation. If the implementation was compile-scoped, they
could just
> declare the implementation dependency and the API would then be pulled in
> automatically. This is the kind of stuff we need to discuss and come to a
> resolution on.
>
Again, I don't think one dependency is a holy grail. We are making an
optimization that I don't find necessary. Making an implementation
compile-scoped could be classified as careless programming (by some strict
architects, let's say).
If it's setup correctly, depending on seam-faces (the impl) should make it
a
runtime dep, make the api compile time, make any dependent api
compile
time
and make any dependency impl runtime. If Maven can't accommodate
that,
then
it's just a pita (even then, the worse thing that happens is that
the user
has two dependencies).
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:13 a.m.
On Aug 16, 2011, at 21:06, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Aug 16, 2011 at 23:05, Dan Allen
<dan.j.allen(a)gmail.com> wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Of course, but we break that rule. Solder is one example, there's multiple utility
classes in the implementation that are required to compile other modules.
I consider that a bug (or a work in progress, depending on how you look at it).
An API is an API. If it's an "internal API", then perhaps it should be an
SPI. Under no circumstances should we be depending on implementation classes between
modules. Otherwise, we are changing the definition of an implementation.
+1
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:13 a.m.
On 17/08/11 13:06, Dan Allen wrote:
On Tue, Aug 16, 2011 at 23:05, Dan Allen <dan.j.allen(a)gmail.com
<mailto:dan.j.allen@gmail.com>> wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com
<mailto:sbryzak@redhat.com>> wrote:
Of course, but we break that rule. Solder is one example,
there's multiple utility classes in the implementation that
are required to compile other modules.
I consider that a bug (or a work in progress, depending on how you
look at it).
An API is an API. If it's an "internal API", then perhaps it should be
an SPI. Under no circumstances should we be depending on
implementation classes between modules. Otherwise, we are changing the
definition of an implementation.
We agree on this, and as far as I know (besides Solder) we conform to
this throughout all the modules.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5:15 a.m.
I think this would over-complicate things. I've got no problem with
telling our users that they must declare a dependency for a module's
API, and a dependency for the IMPL they want to use, if that's what we
decide.
On 17/08/11 13:12, John D. Ament wrote:
What if every module had a bom that was imported, or if this were
handled in the seam-bom?
John
On Aug 16, 2011 11:06 PM, "Dan Allen" <dan.j.allen(a)gmail.com
<mailto:dan.j.allen@gmail.com>> wrote:
> On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com
<mailto:sbryzak@redhat.com>> wrote:
>
>> Of course, but we break that rule. Solder is one example, there's
>> multiple utility classes in the implementation that are required to
compile
>> other modules.
>>
>
> I consider that a bug (or a work in progress, depending on how you
look at
> it).
>
>
>> Also, by making the implementation runtime-only, the user is forced to
>> declare two dependencies for their project, one for the API and one
for the
>> implementation. If the implementation was compile-scoped, they
could just
>> declare the implementation dependency and the API would then be
pulled in
>> automatically. This is the kind of stuff we need to discuss and
come to a
>> resolution on.
>>
>
> Again, I don't think one dependency is a holy grail. We are making an
> optimization that I don't find necessary. Making an implementation
> compile-scoped could be classified as careless programming (by some
strict
> architects, let's say).
>
> If it's setup correctly, depending on seam-faces (the impl) should
make it a
> runtime dep, make the api compile time, make any dependent api
compile time
> and make any dependency impl runtime. If Maven can't accommodate
that, then
> it's just a pita (even then, the worse thing that happens is that
the user
> has two dependencies).
>
> -Dan
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
5:35 a.m.
For my $0.02, I wish more people would split their runtime and compile time deps. Too
often people add the runtime which pulls in the compile time and the user builds against
the runtime classes. Part of this problem, imo, comes from maven resolving compile
transitively. If you depend on it to compile, state it, and don't bleed your runtime
into mine if it's swappable. I think Sonatype would probably agree.
Sent from my iPhone
On Aug 16, 2011, at 21:15, Shane Bryzak <sbryzak(a)redhat.com> wrote:
I think this would over-complicate things. I've got no problem
with telling our users that they must declare a dependency for a module's API, and
a dependency for the IMPL they want to use, if that's what we decide.
On 17/08/11 13:12, John D. Ament wrote:
>
> What if every module had a bom that was imported, or if this were handled in the
seam-bom?
>
> John
>
> On Aug 16, 2011 11:06 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
> > On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> >
> >> Of course, but we break that rule. Solder is one example, there's
> >> multiple utility classes in the implementation that are required to compile
> >> other modules.
> >>
> >
> > I consider that a bug (or a work in progress, depending on how you look at
> > it).
> >
> >
> >> Also, by making the implementation runtime-only, the user is forced to
> >> declare two dependencies for their project, one for the API and one for the
> >> implementation. If the implementation was compile-scoped, they could just
> >> declare the implementation dependency and the API would then be pulled in
> >> automatically. This is the kind of stuff we need to discuss and come to a
> >> resolution on.
> >>
> >
> > Again, I don't think one dependency is a holy grail. We are making an
> > optimization that I don't find necessary. Making an implementation
> > compile-scoped could be classified as careless programming (by some strict
> > architects, let's say).
> >
> > If it's setup correctly, depending on seam-faces (the impl) should make it
a
> > runtime dep, make the api compile time, make any dependent api compile time
> > and make any dependency impl runtime. If Maven can't accommodate that, then
> > it's just a pita (even then, the worse thing that happens is that the user
> > has two dependencies).
> >
> > -Dan
> >
> > --
> > Dan Allen
> > Principal Software Engineer, Red Hat | Author of Seam in Action
> > Registered Linux User #231597
> >
> > http://www.google.com/profiles/dan.j.allen#about
> > http://mojavelinux.com
> > http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
9:39 p.m.
On Tue, Aug 16, 2011 at 23:35, Jason Porter <lightguard.jp(a)gmail.com> wrote:
For my $0.02, I wish more people would split their runtime and
compile time
deps. Too often people add the runtime which pulls in the compile time and
the user builds against the runtime classes. Part of this problem, imo,
comes from maven resolving compile transitively. If you depend on it to
compile, state it, and don't bleed your runtime into mine if it's swappable.
I think Sonatype would probably agree.
I agree that we want to promote best practices. I have yet to hear anyone
say "two dependencies, that's so many!" They just copy and paste what we
give them. So let's just give them the right thing to copy paste (or let
forge do it).
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
9:41 p.m.
On Tue, Aug 16, 2011 at 23:12, Shane Bryzak <sbryzak(a)redhat.com> wrote:
On 17/08/11 13:05, Dan Allen wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> Of course, but we break that rule. Solder is one example, there's
> multiple utility classes in the implementation that are required to compile
> other modules.
>
I consider that a bug (or a work in progress, depending on how you look
at it).
George suggested that we make solder a single jar, and to me it makes sense
considering it's a set of utility features, and it would solve this problem.
I don't agree. Solder is not just utility classes. It has very clear APIs
and implementations in some places. There is quite a lot of implementation
detail, in fact, to implement things like the service handler and the
generic beans.
I am okay with moving more of the utility classes into the API, if they
truly are utility APIs.
Combining it all is just giving up on good design, IMO.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
12:03 a.m.
=================
#seam-dev Meeting
=================
Meeting started by lightguard_jp at 21:00:55 UTC. The full logs are
available
athttp://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/sea...
.
Meeting summary
---------------
* Logging (lightguard_jp, 21:02:46)
* logging will be pulled out of solder, and into it's own module.
(lightguard_jp, 21:15:09)
* Testing (lightguard_jp, 21:18:04)
* LINK: https://github.com/seam/international/tree/develop/testsuite
(sbryzak, 21:23:09)
* weld parent will be removed (lightguard_jp, 21:36:23)
* we'll be focusing on testing and getting modules up to date
(lightguard_jp, 21:36:35)
* we need some documentation about testing in seam (lightguard_jp,
21:36:45)
* dependency discussion from the mailing list (lightguard_jp, 21:37:08)
* Beta2 tasks: testing update / restructure, maven dep / rename change
and logging change (lightguard_jp, 21:47:20)
* wicket discussion (lightguard_jp, 21:47:40)
Meeting ended at 22:01:54 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* sbryzak (129)
* lightguard_jp (51)
* kenfinnigan (43)
* mojavelinux (23)
* jose_freitas (14)
* oranheim (11)
* johnament (3)
* stuartdouglas (3)
* jbott (3)
* clerum (2)
* maschmid (1)
* jbossbot (1)
* hannelita (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
On Tue, Aug 16, 2011 at 15:34, Jason Porter <lightguard.jp(a)gmail.com> wrote:
Agenda
- Logging
- Testing
These are in the context of Seam 3.1 which we are working on releasing and
have noticed a few issues and concerns
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
4:56 p.m.
On 17 Aug 2011, at 20:41, Dan Allen wrote:
On Tue, Aug 16, 2011 at 23:12, Shane Bryzak
<sbryzak(a)redhat.com> wrote:
On 17/08/11 13:05, Dan Allen wrote:
> On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> Of course, but we break that rule. Solder is one example, there's multiple
utility classes in the implementation that are required to compile other modules.
>
> I consider that a bug (or a work in progress, depending on how you look at it).
George suggested that we make solder a single jar, and to me it makes sense considering
it's a set of utility features, and it would solve this problem.
I don't agree. Solder is not just utility classes. It has very clear APIs and
implementations in some places. There is quite a lot of implementation detail, in fact, to
implement things like the service handler and the generic beans.
I am okay with moving more of the utility classes into the API, if they truly are utility
APIs.
Combining it all is just giving up on good design, IMO.
I assume these are utility methods? In which case just make them non-static and injectable
beans?
4631
days inactive
4637
days old
18 comments
6 participants
participants (6)
-
Dan Allen -
George Gastaldi -
Jason Porter -
John D. Ament -
Pete Muir -
Shane Bryzak