For the record, I just want the specs issue resolved... be it my way
or not... I just want it fixed.
* * *
I apologize to those who think I was ignoring them... this issue was
getting me way to worked up and I had to basically delete the thread
to clear my head.
--jason
On Oct 3, 2006, at 11:47 AM, Jason Dillon wrote:
On Oct 3, 2006, at 11:39 AM, David Blevins wrote:
Ok, now it's me whose not reading emails :) You mentioned the
site changes. Is that it? Are we really talking about re-
releasing completely stable specs because of website changes?
This
On Oct 3, 2006, at 11:39 AM, David Blevins wrote:
Ok, now it's me whose not reading emails :) You mentioned the site
changes. Is that it? Are we really talking about re-releasing
completely stable specs because of website changes?
This was a reason why the spec module might change, not w
On Oct 3, 2006, at 11:25 AM, David Blevins wrote:
On Oct 3, 2006, at 11:12 AM, Jason Dillon wrote:
On Oct 3, 2006, at 11:03 AM, David Blevins wrote:
Dude, you never read my emails.
I read it... but the mail you just sent said they have not changed:
Can you give some examples on what ki
For the two classes of users that I mentioned earlier, the work will
not be significant. I'm not certain that the post-it note spectre
applies to this narrow domain.
Regards,
Alan
On Oct 3, 2006, at 11:14 AM, Jason Dillon wrote:
It does not matter how often it happens. The fact that the
On Oct 3, 2006, at 11:12 AM, Jason Dillon wrote:
On Oct 3, 2006, at 11:03 AM, David Blevins wrote:
Dude, you never read my emails.
I read it... but the mail you just sent said they have not changed:
Can you give some examples on what kind of pom changes that would
happen to these that w
It does not matter how often it happens. The fact that they can be
changed, and most *will* have some change made to them, increases the
work to manage them significantly.
--jason
On Oct 3, 2006, at 11:09 AM, Alan D. Cabrera wrote:
These don't change all that often, IIRC.
Regards,
Alan
On Oct 3, 2006, at 11:03 AM, David Blevins wrote:
Dude, you never read my emails.
I read it... but the mail you just sent said they have not changed:
On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
Yank these from trunk as they haven't changed in 2+ years?
--jason
These don't change all that often, IIRC.
Regards,
Alan
On Oct 2, 2006, at 2:56 PM, Jason Dillon wrote:
About 1/3 of the specs depend on other specs (not including the
uber 1.4 spec):
ejb 2.1 -> jta 1.0.1b
ejb3 -> jta 1.1, interceptor, annotation
conector 1.5 -> jta 1.0.1b
jacc -> servlet 2
On Oct 2, 2006, at 12:38 PM, Jason Dillon wrote:
IMO there is no "best" way to handle this problem. There is only
good and bad for each solution, but there is no smoking gun to
solve everyones issues.
I already sent out that itty bitty note about the release being jar
+ pom(s) but I wan
On Oct 3, 2006, at 10:50 AM, Jason Dillon wrote:
On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
Thoughts?
Yank these from trunk as they haven't changed in 2+ years?
ejb
servlet
jms
transaction
connector
qname
Not true... remember the pom. Once all of this is settled we need
to update
On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote:
As a user, it is a convenience to be able to have a single version
number to track across all the spec releases. So there's only one
variable to track.
There are two classes of specs users. One is Geroninmo users and
they will just use wh
On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote:
How about we split them into j2ee 1.4, j2ee 1.5 and independent
modules for the non j2ee specs? This will prevent the flux from
the 1.5 development from causing lots of new versions for the 1.4
specs.
Just another middle ground idea. T
r now A release is jar + pom configuration.
--jason
-Original Message-
From: "Alan D. Cabrera" <[EMAIL PROTECTED]>
Date: Mon, 2 Oct 2006 06:51:20
To:dev@geronimo.apache.org
Subject: Re: One version for specs
I don't think that this is a good idea. Versions shou
On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
Thoughts?
Yank these from trunk as they haven't changed in 2+ years?
ejb
servlet
jms
transaction
connector
qname
Not true... remember the pom. Once all of this is settled we need to
update the site deployments too. So it is not safe to ass
Can we think carefully about complexity for a second and agree that
the two models under discussion are
trunk/
branches//
tags//
and
/[trunk, branches/, tags/]
(in the 2nd choice each spec must be built and released individually
by itself, there is no "build all the specs" pom)
and that
On Oct 2, 2006, at 1:35 PM, David Blevins wrote:
On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:
The main problem with compromise in this case... (not that I am
unwilling to do so), is that it appears that _any_ compromise
results in the same problem which I am trying to lead us away
fr
The maintenance simplicity problem does not differentiate between
less changing specs or not... as soon as something changes, you will
see the increased burden of knowledge and tasks to make a complete
release.
My point is that we do not need to spend time worry about this with
one versio
This is good info. Out of this list of dependencies activation is
the only one that changes often; the rest of the jars are just
interfaces (or annotations which are just interfaces). That leaves
us with the following problematic specifications:
javamail 1.3.1 -> activation
javamail 1.4 -
About 1/3 of the specs depend on other specs (not including the uber
1.4 spec):
ejb 2.1 -> jta 1.0.1b
ejb3 -> jta 1.1, interceptor, annotation
conector 1.5 -> jta 1.0.1b
jacc -> servlet 2.4
j2ee mgmt -> ejb 2.1
javamail 1.3.1 -> activation
javamail 1.4 -> activation
jaxr -> activation
jaxrpc ->
You may be right... but I still believe one version is going to be
easier for us. And I am willing to make the changes to get one
version working as it is simple and easy (with a decent network
connection it can all be done in under an hour).
Almost anything else is going to take much long
I hear you, but underlying your case is the assumption that a lot of
specs depend on each other. I'm not convinced that's true.
Certainly, no J2EE 1.4 specs should rely on any J2EE 1.5 or non-J2EE
specs. I guess underlying the compromise proposal is the assumtion
that at this point J2EE 1.4 is f
On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:
The main problem with compromise in this case... (not that I am
unwilling to do so), is that it appears that _any_ compromise
results in the same problem which I am trying to lead us away
from. That problem being a complicated build and rele
The main problem with compromise in this case... (not that I am
unwilling to do so), is that it appears that _any_ compromise results
in the same problem which I am trying to lead us away from. That
problem being a complicated build and release process due to needing
deep insight into the
On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote:
However, I still don't think this is a very good approach. Our specs
tree will continue to expand with new JSRs and J2EE releases,
especially if we go with the earlier intent of making it a home for
all Apache Java spec packages. I don't like the
IMO there is no "best" way to handle this problem. There is only
good and bad for each solution, but there is no smoking gun to solve
everyones issues.
I already sent out that itty bitty note about the release being jar +
pom(s) but I wanted to clarify that even more...
If you take the c
On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote:
How about we split them into j2ee 1.4, j2ee 1.5 and independent
modules for the non j2ee specs? This will prevent the flux from
the 1.5 development from causing lots of new versions for the 1.4
specs.
Just another middle ground idea. T
I don't think that 1.5 development will result in new releases...
those will all be SNAPSHOT artifacts anyways.
Just some questions about this strategy...
Which modules go where? Will each of these trees have a single
version? How will the overlap between J2EE 1.5 and 1.4 fit? Where
wil
A good compromise. Also, good for a start. Let's do this.
Cheers
Prasad
On 10/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
How about we split them into j2ee 1.4, j2ee 1.5 and independent
modules for the non j2ee specs? This will prevent the flux from the
1.5 development from causing lots of
On 10/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
How about we split them into j2ee 1.4, j2ee 1.5 and independent
modules for the non j2ee specs? This will prevent the flux from the
1.5 development from causing lots of new versions for the 1.4 specs.
Sounds promising to me...
Thanks,
A
How about we split them into j2ee 1.4, j2ee 1.5 and independent
modules for the non j2ee specs? This will prevent the flux from the
1.5 development from causing lots of new versions for the 1.4 specs.
Just another middle ground idea. Thoughts?
-dain
On Oct 2, 2006, at 11:16 AM, David Blev
On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
In any case PLEASE think about this and make your opinion known soon.
If we could at least make a compromise that'd be very great, all or
nothing is not the only way.
Maybe we could just remove these core specs from trunk or something
(we
Remeber now A release is jar + pom configuration.
--jason
-Original Message-
From: "Alan D. Cabrera" <[EMAIL PROTECTED]>
Date: Mon, 2 Oct 2006 06:51:20
To:dev@geronimo.apache.org
Subject: Re: One version for specs
I don't think that this is a good i
As a user, it is a convenience to be able to have a single version
number to track across all the spec releases. So there's only one
variable to track.
However, I still don't think this is a very good approach. Our specs
tree will continue to expand with new JSRs and J2EE releases,
especially i
On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
I now think we should at least try the one-version approach. What
we've been doing has resulted IMO in total confusion and many many
problems releasing specs.
We did try that, seven times. M1 -> 1.0.1 had all specs released all
at the same
On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
After a long time thinking that separately versioned specs were
better I started thinking about how much work it would be if I was
trying to release separately versioned specs. I now think we
should at least try the one-version approach. Wh
I don't think that this is a good idea. Versions should reflect the
contents of the jar not the fact that an unrelated spec was released/
patched/updated.
Regards,
Alan
On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:
Hi, me again... and the specs topic again too.
I have been thinking abo
On Oct 1, 2006, at 7:31 PM, David Jencks wrote:
After a long time thinking that separately versioned specs were
better I started thinking about how much work it would be if I was
trying to release separately versioned specs. I now think we
should at least try the one-version approach. Wh
After a long time thinking that separately versioned specs were
better I started thinking about how much work it would be if I was
trying to release separately versioned specs. I now think we should
at least try the one-version approach. What we've been doing has
resulted IMO in total con
Hi, me again... and the specs topic again too.
I have been thinking about this for quite a while and I believe that
it would be in the best interest of the project to treat our specs as
a project and use one version to release the spec modules under.
Doing so will greatly reduce the complex
40 matches
Mail list logo
