You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Eric Pugh <ep...@opensourceconnections.com> on 2004/10/20 11:31:10 UTC
Please install javamail-1.3.1.jar into Gump
Hi,
Quite a few of the Jakarta Turbine Fulcrum components use the
javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3
installed. Can we have this dependency upgraded? This will remove the last
obstacle to our components compiling under Gump.
Sincerely,
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 October 2004 23:44, Stefano Mazzocchi wrote:
> What is the maven ID for the mail.jar package?
That is the entire problem; There is none.
Each project has been pushing their own for each of the non-distributables,
mostly from Sun. I have asked Brett (of Maven) to establish a recommended
list of group/artifact for all the stuff that can not be placed on the
central repositories.
As it stands, I only know of Avalon LogKit and Fulcrum, and they don't use the
same IDs. :o(
My personal opinion is that everything from Sun is thrown into a single group,
and each Jar keeps its name, but with the added version. Unfortunately, this
is not something used anywhere.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: Please install javamail-1.3.1.jar into Gump
Posted by Eric Pugh <ep...@opensourceconnections.com>.
Why yes there is a search engine: http://maven.ozacc.com/. However, that
doesn't help because mail.jar isn't a redistributable package. However,
there is a maven issue open at: http://jira.codehaus.org/browse/MAVEN-1472
that has some suggested names. I think that is as good a place as any to
look. Once we pick something it should spread from there.
While you are at it.. Can you install activation-1.0.2 as well? It also
has the same issue with no specific naming convention.
Eric
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, October 20, 2004 4:44 PM
> To: Gump code and data
> Subject: Re: Please install javamail-1.3.1.jar into Gump
>
>
> Niclas Hedhman wrote:
> > On Wednesday 20 October 2004 17:31, Eric Pugh wrote:
> >
> >>Hi,
> >>
> >>Quite a few of the Jakarta Turbine Fulcrum components use the
> >>javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3
> >>installed. Can we have this dependency upgraded? This will remove the
> >>last obstacle to our components compiling under Gump.
> >
> >
> > This is not about 1.3 vs 1.3.1, never was...
> >
> > Please proceed and change to whatever version you like.
> >
> > Now, the problem is about the 'exposure' of the Jar's from
> their names on the
> > Brutus filesystem, vs the name expected in your projects.
> > Stefano gave me heads up earlier that he is tackling this in a generic
> > fashion, since it won't scale if we go in and ask for changes in each
> > project.
> >
> > That means that we will be able to declare in the Gump
> descriptor that abc.jar
> > is used for an def-x.y.z.jar by Maven (and others), so that in
> the overrides
> > file,
> >
> > maven.jar.override = on
> > maven.jar.abc = /usr/local/...../javamail/mail.jar
> >
> > is generated. This will solve all projects with a similar situation and
> > allowing all the existing ant-wrappers for Maven projects to go away.
> >
> > So, just hang in tight, and the problem will be solved at Gump's end.
>
> I just discussed this with Adam and he suggested that rather than
> introducing further complexity in the metadata, we change the exposed
> jar ID so that they match maven's.
>
> What is the maven ID for the mail.jar package?
>
> Is there a search engine for maven artifacts?
>
> --
> Stefano.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 20 October 2004 17:31, Eric Pugh wrote:
>
>>Hi,
>>
>>Quite a few of the Jakarta Turbine Fulcrum components use the
>>javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3
>>installed. Can we have this dependency upgraded? This will remove the
>>last obstacle to our components compiling under Gump.
>
>
> This is not about 1.3 vs 1.3.1, never was...
>
> Please proceed and change to whatever version you like.
>
> Now, the problem is about the 'exposure' of the Jar's from their names on the
> Brutus filesystem, vs the name expected in your projects.
> Stefano gave me heads up earlier that he is tackling this in a generic
> fashion, since it won't scale if we go in and ask for changes in each
> project.
>
> That means that we will be able to declare in the Gump descriptor that abc.jar
> is used for an def-x.y.z.jar by Maven (and others), so that in the overrides
> file,
>
> maven.jar.override = on
> maven.jar.abc = /usr/local/...../javamail/mail.jar
>
> is generated. This will solve all projects with a similar situation and
> allowing all the existing ant-wrappers for Maven projects to go away.
>
> So, just hang in tight, and the problem will be solved at Gump's end.
I just discussed this with Adam and he suggested that rather than
introducing further complexity in the metadata, we change the exposed
jar ID so that they match maven's.
What is the maven ID for the mail.jar package?
Is there a search engine for maven artifacts?
--
Stefano.
Re: Please install javamail-1.3.1.jar into Gump
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Niclas Hedhman <ni...@hedhman.org> writes:
>On Wednesday 20 October 2004 18:07, Henning P. Schmiedehausen wrote:
>> Niclas Hedhman <ni...@hedhman.org> writes:
>> >That means that we will be able to declare in the Gump descriptor that
>> > abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in
>> > the overrides file,
>> >
>> >maven.jar.override = on
>> >maven.jar.abc = /usr/local/...../javamail/mail.jar
>>
>> Could you please explain what this means exactly for a project?
><snip content="elaboration" />
>This is probably a very interesting observation, which has to do about the
>purpose of Gump.
>Gump does not exist to make sure your system/project work. That is your own
>responsibility.
>Gump's purpose is to ensure that a source code change YOU (in anonymous sense)
>make doesn't aversely affect someone else, and if it does it should be
>captured and everyone involved should be notified about it ASAP, before any
>releases are being made.
>That means that building against the declared versions are not an option. That
>doesn't provide a solution to the purpose. We need to build against either
>the latest known sources, and for generational shifts (i.e. compatibility is
>not maintained) we have to introduce separate projects for them, and in many
>cases both generations will be maintained by those projects over a limited
>period of time, e.g. tomcat.
>I hope this clarifies why it is not in Gump's interest to use the versions
>(generations, yes, not versions) that you declare for your project, but the
>"latest/greatest" non-released stuff.
Hi,
thanks for clarification. It still makes no sense to me. This assumes
that every project is always interested to be able to build against
the latest and greatest sources of every dependency.
Or did I get your explanation wrong?
Why should building against latest and greatest sources be of any
interest to a project?
Most important IMHO is that a project builds vs. its defined set of
dependencies. If we need a method from "foo-1.0" to build "bar" which
gets deprecated in "foo-1.1" and removed in "foo-2.0"; building "bar"
in Gump will suddently no longer work. Which would for me (as a "bar"
author) not important, because we told our users that "if you want to
use bar, use "foo-1.0"". Who would you blame? The "foo" author for
doing changes in his project or the "bar" for not tracking the latest
and greatest "foo"? What if the "bar" author does not agree to changes
in "foo"?
That "build against latest and greatest" led to the -SNAPSHOT mess in
current maven.
I think that Gump sets a policy here that at least I do feel
uncomfortable with.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 October 2004 18:07, Henning P. Schmiedehausen wrote:
> Niclas Hedhman <ni...@hedhman.org> writes:
> >That means that we will be able to declare in the Gump descriptor that
> > abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in
> > the overrides file,
> >
> >maven.jar.override = on
> >maven.jar.abc = /usr/local/...../javamail/mail.jar
>
> Could you please explain what this means exactly for a project?
<snip content="elaboration" />
This is probably a very interesting observation, which has to do about the
purpose of Gump.
Gump does not exist to make sure your system/project work. That is your own
responsibility.
Gump's purpose is to ensure that a source code change YOU (in anonymous sense)
make doesn't aversely affect someone else, and if it does it should be
captured and everyone involved should be notified about it ASAP, before any
releases are being made.
That means that building against the declared versions are not an option. That
doesn't provide a solution to the purpose. We need to build against either
the latest known sources, and for generational shifts (i.e. compatibility is
not maintained) we have to introduce separate projects for them, and in many
cases both generations will be maintained by those projects over a limited
period of time, e.g. tomcat.
I hope this clarifies why it is not in Gump's interest to use the versions
(generations, yes, not versions) that you declare for your project, but the
"latest/greatest" non-released stuff.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 October 2004 18:07, Henning P. Schmiedehausen wrote:
> Niclas Hedhman <ni...@hedhman.org> writes:
> >That means that we will be able to declare in the Gump descriptor that
> > abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in
> > the overrides file,
> >
> >maven.jar.override = on
> >maven.jar.abc = /usr/local/...../javamail/mail.jar
>
> Could you please explain what this means exactly for a project?
<snip content="elaboration" />
This is probably a very interesting observation, which has to do about the
purpose of Gump.
Gump does not exist to make sure your system/project work. That is your own
responsibility.
Gump's purpose is to ensure that a source code change YOU (in anonymous sense)
make doesn't aversely affect someone else, and if it does it should be
captured and everyone involved should be notified about it ASAP, before any
releases are being made.
That means that building against the declared versions are not an option. That
doesn't provide a solution to the purpose. We need to build against either
the latest known sources, and for generational shifts (i.e. compatibility is
not maintained) we have to introduce separate projects for them, and in many
cases both generations will be maintained by those projects over a limited
period of time, e.g. tomcat.
I hope this clarifies why it is not in Gump's interest to use the versions
(generations, yes, not versions) that you declare for your project, but the
"latest/greatest" non-released stuff.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Niclas Hedhman <ni...@hedhman.org> writes:
>That means that we will be able to declare in the Gump descriptor that abc.jar
>is used for an def-x.y.z.jar by Maven (and others), so that in the overrides
>file,
>maven.jar.override = on
>maven.jar.abc = /usr/local/...../javamail/mail.jar
Could you please explain what this means exactly for a project?
Does it that mean, that I cannot rely whether the projects are run by
the Gump with the jar versions that have been specified in
project.xml?
How does that scale? Consider changes like commons-collections 3.0
vs. 3.1 or commons-lang changes? Or commons-configuration rc1 vs. rc2
What significance has a continous integration test if it does not test
the environment specified for the application?
>is generated. This will solve all projects with a similar situation and
>allowing all the existing ant-wrappers for Maven projects to go away.
This introduces just another layer of "gotchas" The whole override
shebang was a really bad idea when Jason introduced it into maven and
it hasn't improved a bit yet. Sort of "bolted on to scratch an itch".
If I want to test vs. javamail-1.3.1.jar or torque-3.1.1-rc3.jar then
I do want against this jar. Not against some dependency that Gump
decide to swap for "javamail-1.3.jar" or "torque-3.1.jar". This simply
makes no sense to me.
One of the few really good things that Jason did when building the
artifact code is, that he forced jars to have a version. It was a
really stupid idea from Sun to release "mail.jar". Even mail-1.3.1.jar
would have been better. Renaming sthese jars is IMHO a good thing that
maven has enforced.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Please install javamail-1.3.1.jar into Gump
Posted by Eric Pugh <ep...@upstate.com>.
Just to reconfirm.. This is a fix in progress.. Nothing I can do/need to
do. For now, since javamail-1.3 is installed, I can swap to that, with the
understanding that soon I can use javamail-1.3.1 and the override will work,
right?
Thanks!
Erci
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Wednesday, October 20, 2004 10:51 AM
> To: Gump code and data
> Cc: Turbine Dev
> Subject: Re: Please install javamail-1.3.1.jar into Gump
>
>
> On Wednesday 20 October 2004 17:31, Eric Pugh wrote:
> > Hi,
> >
> > Quite a few of the Jakarta Turbine Fulcrum components use the
> > javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3
> > installed. Can we have this dependency upgraded? This will remove the
> > last obstacle to our components compiling under Gump.
>
> This is not about 1.3 vs 1.3.1, never was...
>
> Please proceed and change to whatever version you like.
>
> Now, the problem is about the 'exposure' of the Jar's from their
> names on the
> Brutus filesystem, vs the name expected in your projects.
> Stefano gave me heads up earlier that he is tackling this in a generic
> fashion, since it won't scale if we go in and ask for changes in each
> project.
>
> That means that we will be able to declare in the Gump descriptor
> that abc.jar
> is used for an def-x.y.z.jar by Maven (and others), so that in
> the overrides
> file,
>
> maven.jar.override = on
> maven.jar.abc = /usr/local/...../javamail/mail.jar
>
> is generated. This will solve all projects with a similar situation and
> allowing all the existing ant-wrappers for Maven projects to go away.
>
> So, just hang in tight, and the problem will be solved at Gump's end.
>
>
> Cheers
> Niclas
> --
> +------//-------------------+
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
> +------//-------------------+
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 October 2004 17:31, Eric Pugh wrote:
> Hi,
>
> Quite a few of the Jakarta Turbine Fulcrum components use the
> javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3
> installed. Can we have this dependency upgraded? This will remove the
> last obstacle to our components compiling under Gump.
This is not about 1.3 vs 1.3.1, never was...
Please proceed and change to whatever version you like.
Now, the problem is about the 'exposure' of the Jar's from their names on the
Brutus filesystem, vs the name expected in your projects.
Stefano gave me heads up earlier that he is tackling this in a generic
fashion, since it won't scale if we go in and ask for changes in each
project.
That means that we will be able to declare in the Gump descriptor that abc.jar
is used for an def-x.y.z.jar by Maven (and others), so that in the overrides
file,
maven.jar.override = on
maven.jar.abc = /usr/local/...../javamail/mail.jar
is generated. This will solve all projects with a similar situation and
allowing all the existing ant-wrappers for Maven projects to go away.
So, just hang in tight, and the problem will be solved at Gump's end.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Please install javamail-1.3.1.jar into Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 20 October 2004 17:31, Eric Pugh wrote:
> Hi,
>
> Quite a few of the Jakarta Turbine Fulcrum components use the
> javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3
> installed. Can we have this dependency upgraded? This will remove the
> last obstacle to our components compiling under Gump.
This is not about 1.3 vs 1.3.1, never was...
Please proceed and change to whatever version you like.
Now, the problem is about the 'exposure' of the Jar's from their names on the
Brutus filesystem, vs the name expected in your projects.
Stefano gave me heads up earlier that he is tackling this in a generic
fashion, since it won't scale if we go in and ask for changes in each
project.
That means that we will be able to declare in the Gump descriptor that abc.jar
is used for an def-x.y.z.jar by Maven (and others), so that in the overrides
file,
maven.jar.override = on
maven.jar.abc = /usr/local/...../javamail/mail.jar
is generated. This will solve all projects with a similar situation and
allowing all the existing ant-wrappers for Maven projects to go away.
So, just hang in tight, and the problem will be solved at Gump's end.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org