Re: Reorganizing javamai (revisited)
Alan D. Cabrera wrote:
Rick McGuire wrote:
Alan D. Cabrera wrote:
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached
a consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that
the javamail code needed to be reorganized so that the
javamail-transport jar (which is currently part of the Geronimo
build) is separated from Geronimo and available with the
geronimo-javamail-spec jar. The consensus seemed to lean toward
the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the
tck signature tests. It looks like the best approach here would be
to rename the existing javamail spec module to
"geronimo-javamail-spec-1.3" and introduce a new
"geronimo-javamail-spec-1.4" module to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it
doesn't really fit). This will have two modules for the 1.3 and
1.4 versions of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
So, in light of the other conversation going on with the 1.3.1 spec
jar version, can I assume the version number for the 1.4 spec jar
should be 1.2-SNAPSHOT also, and the provider jars (and the uber
jars), because they're in a new repo should start out at 1.0-SNAPSHOT?
I'm not sure why we would tie the spec jars and the provider jar
versions together. I just reread your proposal w/ a more careful
attention to the version macros. We might want to restate the proposal:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamail13Version} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamail14Version} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4 versions
of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamail13Version}
and
geronimo-javamail_1.4_provider-${geronimoProviderJavamail14Version}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamail13Version} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamail14Version}
geronimoSpecsJavamail13Version=1.2-SNAPSHOT
geronimoSpecsJavamail14Version=1.0-SNAPSHOT
geronimoProviderJavamail13Version=1.0-SNAPSHOT
geronimoProviderJavamail14Version=1.0-SNAPSHOT
Thoughts?
I'm pretty much in agreement, except possibly for the value of
geronimoSpecsJavamail14Version. I thought the reason why you wanted my
recent changes labeled 1.2-SNAPSHOT was to tie it to the repos version.
That would sort of suggest that geronimoSpecsJavamail14Version should
start out with 1.2 to tie to
Re: Reorganizing javamai (revisited)
Rick McGuire wrote:
Alan D. Cabrera wrote:
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached a
consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that the
javamail code needed to be reorganized so that the
javamail-transport jar (which is currently part of the Geronimo
build) is separated from Geronimo and available with the
geronimo-javamail-spec jar. The consensus seemed to lean toward the
following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the tck
signature tests. It looks like the best approach here would be to
rename the existing javamail spec module to
"geronimo-javamail-spec-1.3" and introduce a new
"geronimo-javamail-spec-1.4" module to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4
versions of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
So, in light of the other conversation going on with the 1.3.1 spec
jar version, can I assume the version number for the 1.4 spec jar
should be 1.2-SNAPSHOT also, and the provider jars (and the uber
jars), because they're in a new repo should start out at 1.0-SNAPSHOT?
I'm not sure why we would tie the spec jars and the provider jar
versions together. I just reread your proposal w/ a more careful
attention to the version macros. We might want to restate the proposal:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamail13Version} jar file,
which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamail14Version} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only contained
smtp, but now that it also has Store providers, it doesn't really fit).
This will have two modules for the 1.3 and 1.4 versions of the
providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamail13Version}
and geronimo-javamail_1.4_provider-${geronimoProviderJavamail14Version}
jar files.
4) Additionally, the javamail-provider build will create two uber-jars
containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamail13Version} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamail14Version}
geronimoSpecsJavamail13Version=1.2-SNAPSHOT
geronimoSpecsJavamail14Version=1.0-SNAPSHOT
geronimoProviderJavamail13Version=1.0-SNAPSHOT
geronimoProviderJavamail14Version=1.0-SNAPSHOT
Thoughts?
Regards,
Alan
Re: Reorganizing javamai (revisited)
Alan D. Cabrera wrote:
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached a
consensus on what should be done but the work was put off until after
1.1 shipped. Since then, I have a new factor to introduce into this
discussion, so I want to make sure we've got good agreement on what
needs to be done. To refresh, I proposed that the javamail code
needed to be reorganized so that the javamail-transport jar (which is
currently part of the Geronimo build) is separated from Geronimo and
available with the geronimo-javamail-spec jar. The consensus seemed
to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is going
to need to be kept around, since it's required to pass the tck. The
javamail 1.4 jar can't be used, since it will fail the tck signature
tests. It looks like the best approach here would be to rename the
existing javamail spec module to "geronimo-javamail-spec-1.3" and
introduce a new "geronimo-javamail-spec-1.4" module to create the
other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4 versions
of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
So, in light of the other conversation going on with the 1.3.1 spec jar
version, can I assume the version number for the 1.4 spec jar should be
1.2-SNAPSHOT also, and the provider jars (and the uber jars), because
they're in a new repo should start out at 1.0-SNAPSHOT?
Rick
Regards,
Alan
Re: Reorganizing javamai (revisited)
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached a
consensus on what should be done but the work was put off until after
1.1 shipped. Since then, I have a new factor to introduce into this
discussion, so I want to make sure we've got good agreement on what
needs to be done. To refresh, I proposed that the javamail code
needed to be reorganized so that the javamail-transport jar (which is
currently part of the Geronimo build) is separated from Geronimo and
available with the geronimo-javamail-spec jar. The consensus seemed
to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module and
continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is going
to need to be kept around, since it's required to pass the tck. The
javamail 1.4 jar can't be used, since it will fail the tck signature
tests. It looks like the best approach here would be to rename the
existing javamail spec module to "geronimo-javamail-spec-1.3" and
introduce a new "geronimo-javamail-spec-1.4" module to create the
other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar file,
which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4 versions
of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
Regards,
Alan
Re: Reorganizing javamai (revisited)
+1
Great idea.
-dain
On Jun 7, 2006, at 5:46 AM, Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached
a consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that
the javamail code needed to be reorganized so that the javamail-
transport jar (which is currently part of the Geronimo build) is
separated from Geronimo and available with the geronimo-javamail-
spec jar. The consensus seemed to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the
tck signature tests. It looks like the best approach here would be
to rename the existing javamail spec module to "geronimo-javamail-
spec-1.3" and introduce a new "geronimo-javamail-spec-1.4" module
to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to geronimo-spec-
javamail-1.3. This already builds a geronimo-javamail_1.3.1_spec-$
{geronimoSpecsJavamailVersion} jar file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it
doesn't really fit). This will have two modules for the 1.3 and
1.4 versions of the providers, and will build geronimo-
javamail_1.3.1_provider-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two uber-
jars containing the specs and providers combined: geronimo-
javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and geronimo-
javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
Re: Reorganizing javamai (revisited)
Looks good.
+1
thanks
david jencks
On Jun 7, 2006, at 5:46 AM, Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached
a consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that
the javamail code needed to be reorganized so that the javamail-
transport jar (which is currently part of the Geronimo build) is
separated from Geronimo and available with the geronimo-javamail-
spec jar. The consensus seemed to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the
tck signature tests. It looks like the best approach here would be
to rename the existing javamail spec module to "geronimo-javamail-
spec-1.3" and introduce a new "geronimo-javamail-spec-1.4" module
to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to geronimo-spec-
javamail-1.3. This already builds a geronimo-javamail_1.3.1_spec-$
{geronimoSpecsJavamailVersion} jar file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it
doesn't really fit). This will have two modules for the 1.3 and
1.4 versions of the providers, and will build geronimo-
javamail_1.3.1_provider-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two uber-
jars containing the specs and providers combined: geronimo-
javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and geronimo-
javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
Re: Reorganizing javamai (revisited)
+1 from me.
On 6/7/06, Rick McGuire <[EMAIL PROTECTED]> wrote:
I brought this up a couple of months ago, and I believe we reached a
consensus on what should be done but the work was put off until after
1.1 shipped. Since then, I have a new factor to introduce into this
discussion, so I want to make sure we've got good agreement on what
needs to be done. To refresh, I proposed that the javamail code needed
to be reorganized so that the javamail-transport jar (which is currently
part of the Geronimo build) is separated from Geronimo and available
with the geronimo-javamail-spec jar. The consensus seemed to lean
toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module and
continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar that
combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be made
an optional plugin. However, the javamail 1.3 spec jar is going to need
to be kept around, since it's required to pass the tck. The javamail
1.4 jar can't be used, since it will fail the tck signature tests. It
looks like the best approach here would be to rename the existing
javamail spec module to "geronimo-javamail-spec-1.3" and introduce a new
"geronimo-javamail-spec-1.4" module to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the transport
repository will also need modules to build the matching provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar file,
which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only contained
smtp, but now that it also has Store providers, it doesn't really fit).
This will have two modules for the 1.3 and 1.4 versions of the
providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion} jar files.
4) Additionally, the javamail-provider build will create two uber-jars
containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
--
Davanum Srinivas : http://wso2.com/blogs/
