You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2005/06/21 23:35:23 UTC
Proposal: Elimiante jar files from SVN
First off, thanks to James Mitchell (of the Struts team) who has been
teaching me the wonders of svn:externals. I hope my SVN reorg will
make him proud. :-)
While James and I were discussing the Struts layout he also mentioned
something interesting. They no longer keep any jar files in their
repository. He has figured out a way to deal with the jar file
dependencies that does *not* require Maven (ie. can be done from Ant.)
I'm planning on doing something similar as part of the reorg. Check
out the following steps that allow you to build struts 1.2 without
specifying a single jar file in your properties ...
$svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
struts-1.2
$cd struts-1.2
$ant download-dependencies release
Nice! I see no reason to deprive ourselves of the same cool build
process ;-) Also, its possible to build using local jar files if that
is your cup of tea (just don't run the download-dependencies target
and specify the jar file locations in your local props file.)
sean
Re: Proposal: Elimiante jar files from SVN
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
I submitted a maven POM patch for this 2 or 3 weeks ago. Works at least
to get the project to compile, after <kbd>maven eclipse</kbd> in
eclipse.
On 22 Jun 2005, at 12:03, Manfred Geiler wrote:
> yes, looks good
> +1 for automatic download of jars
>
> -Manfred
>
>
>
> 2005/6/21, Sean Schofield <se...@gmail.com>:
>> First off, thanks to James Mitchell (of the Struts team) who has been
>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>> make him proud. :-)
>>
>> While James and I were discussing the Struts layout he also mentioned
>> something interesting. They no longer keep any jar files in their
>> repository. He has figured out a way to deal with the jar file
>> dependencies that does *not* require Maven (ie. can be done from Ant.)
>>
>> I'm planning on doing something similar as part of the reorg. Check
>> out the following steps that allow you to build struts 1.2 without
>> specifying a single jar file in your properties ...
>>
>> $svn co
>> https://svn.apache.org/repos/asf/struts/core/branches/
>> STRUTS_1_2_BRANCH/
>> struts-1.2
>> $cd struts-1.2
>> $ant download-dependencies release
>>
>> Nice! I see no reason to deprive ourselves of the same cool build
>> process ;-) Also, its possible to build using local jar files if that
>> is your cup of tea (just don't run the download-dependencies target
>> and specify the jar file locations in your local props file.)
>>
>> sean
>>
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Sean Schofield wrote:
>Oliver,
>
>Have you examined the Struts build process as I have suggested? It is
>pretty simple. What is so complicated about typing 'ant
>download-dependencies release' instead of 'ant release'?
>
>Keep in mind that the 'download-dependencies' target need only be
>called once. Actually, it need never be called if you want to get the
>jars through your own methods. As you will see in the Struts build
>process, you can set up your properties file to use your local copy of
>the jar files at any point you wish. So you won't be prevented from
>building if there is a problem with the Maven repository.
>
>
That's exactly my point. Of course I can resolve problems with the
automatic download manually. But that's me or you or anybody else from
the MyFaces team as we all know how our build works. But what about
users who checked out MyFaces from the svn repository the first time and
then automatic download fails. What should they do? Start an adventure
and collect all the required jars from their respective project's
download pages? I don't think so.
>Its bad practice to keep the jar files in SVN if you have a reasonable
>alternative. A spot check of existing Apache projects reveals that
>none of them store jar files in SVN. This includes Struts and Jakarta
>Commons. IMO its time for MyFaces to adopt this practice as well.
>The download-dependencies target is just an elegant solution used by
>Struts to help the user get those jars.
>
>
Who is saying that keeping the jar files in SVN is bad practice? I'm
open to adopt best practices from other projects. But removing the
required libs from the repository is no best practice to me, it's the
opposite. You tell me that other projects deleted the libs from their
repository so we should do the same. But I can show you hundreds and
thousands of projects not going that road and I tell you we shouldn't do
it either. So how are we going to resolve this? Fact is: I don't care
about how struts, commons or any other project in the world handles
their source repository. If one project starts to check in tarballs of
their source files instead of single source files and if ten other
projects are stupid enough to follow, will we do the same because it's
the latest trend and there are 11 others doing it?
It's fine to collect ideas and inspiration from other projects but it's
the best solution for the MyFaces build that matters! And so far I have
not seen any argument it this discussion that convinces me eliminating
the jars from the repository is a good thing.
Oliver
>sean
>
>On 6/22/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
>
>
>>-1 on that. Please don't make the build more complex than needed. Not
>>any stuff that seems to be cool to implement should be implemented.
>>
>>What's your problem with having the required libs in the repository? For
>>me there are advantages only:
>>
>>- one source fits it all: you check out the svn module and have
>>everything you need to build
>>- the libs are versioned with the code which depends on the libs
>>- you have everything maintained in one place, the svn repository; no
>>need for external jar repositories or stuff like that
>>- no build is blocked because the download of a required lib is not
>>working for whatever reason (firewalls, network failures, ...)
>>
>>If you ever had the html of a http 500 page as the contents of a jar
>>file in your maven repository instead of the required jar itself you
>>know what I'm talking about. So do not try to imitate maven just by
>>other means but follow the KISS principle and keep it simple, please.
>>
>>Oliver
>>
>>
>>Manfred Geiler wrote:
>>
>>
>>
>>>yes, looks good
>>>+1 for automatic download of jars
>>>
>>>-Manfred
>>>
>>>
>>>
>>>2005/6/21, Sean Schofield <se...@gmail.com>:
>>>
>>>
>>>
>>>
>>>>First off, thanks to James Mitchell (of the Struts team) who has been
>>>>teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>>make him proud. :-)
>>>>
>>>>While James and I were discussing the Struts layout he also mentioned
>>>>something interesting. They no longer keep any jar files in their
>>>>repository. He has figured out a way to deal with the jar file
>>>>dependencies that does *not* require Maven (ie. can be done from Ant.)
>>>>
>>>>I'm planning on doing something similar as part of the reorg. Check
>>>>out the following steps that allow you to build struts 1.2 without
>>>>specifying a single jar file in your properties ...
>>>>
>>>>$svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>struts-1.2
>>>>$cd struts-1.2
>>>>$ant download-dependencies release
>>>>
>>>>Nice! I see no reason to deprive ourselves of the same cool build
>>>>process ;-) Also, its possible to build using local jar files if that
>>>>is your cup of tea (just don't run the download-dependencies target
>>>>and specify the jar file locations in your local props file.)
>>>>
>>>>sean
>>>>
>>>>
>>>>
>>>>
>>>>
>>--
>>Oliver Rossmueller
>>Software Engineer and IT-Consultant
>>Hamburg, Germany
>>http://www.rossmueller.com
>>
>>
>>
>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
Oliver,
Have you examined the Struts build process as I have suggested? It is
pretty simple. What is so complicated about typing 'ant
download-dependencies release' instead of 'ant release'?
Keep in mind that the 'download-dependencies' target need only be
called once. Actually, it need never be called if you want to get the
jars through your own methods. As you will see in the Struts build
process, you can set up your properties file to use your local copy of
the jar files at any point you wish. So you won't be prevented from
building if there is a problem with the Maven repository.
Its bad practice to keep the jar files in SVN if you have a reasonable
alternative. A spot check of existing Apache projects reveals that
none of them store jar files in SVN. This includes Struts and Jakarta
Commons. IMO its time for MyFaces to adopt this practice as well.
The download-dependencies target is just an elegant solution used by
Struts to help the user get those jars.
sean
On 6/22/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
> -1 on that. Please don't make the build more complex than needed. Not
> any stuff that seems to be cool to implement should be implemented.
>
> What's your problem with having the required libs in the repository? For
> me there are advantages only:
>
> - one source fits it all: you check out the svn module and have
> everything you need to build
> - the libs are versioned with the code which depends on the libs
> - you have everything maintained in one place, the svn repository; no
> need for external jar repositories or stuff like that
> - no build is blocked because the download of a required lib is not
> working for whatever reason (firewalls, network failures, ...)
>
> If you ever had the html of a http 500 page as the contents of a jar
> file in your maven repository instead of the required jar itself you
> know what I'm talking about. So do not try to imitate maven just by
> other means but follow the KISS principle and keep it simple, please.
>
> Oliver
>
>
> Manfred Geiler wrote:
>
> >yes, looks good
> >+1 for automatic download of jars
> >
> >-Manfred
> >
> >
> >
> >2005/6/21, Sean Schofield <se...@gmail.com>:
> >
> >
> >>First off, thanks to James Mitchell (of the Struts team) who has been
> >>teaching me the wonders of svn:externals. I hope my SVN reorg will
> >>make him proud. :-)
> >>
> >>While James and I were discussing the Struts layout he also mentioned
> >>something interesting. They no longer keep any jar files in their
> >>repository. He has figured out a way to deal with the jar file
> >>dependencies that does *not* require Maven (ie. can be done from Ant.)
> >>
> >>I'm planning on doing something similar as part of the reorg. Check
> >>out the following steps that allow you to build struts 1.2 without
> >>specifying a single jar file in your properties ...
> >>
> >>$svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
> >>struts-1.2
> >>$cd struts-1.2
> >>$ant download-dependencies release
> >>
> >>Nice! I see no reason to deprive ourselves of the same cool build
> >>process ;-) Also, its possible to build using local jar files if that
> >>is your cup of tea (just don't run the download-dependencies target
> >>and specify the jar file locations in your local props file.)
> >>
> >>sean
> >>
> >>
> >>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by John Fallows <jo...@gmail.com>.
On 6/23/05, Sean Schofield <se...@gmail.com> wrote:
> Right. I remember this was an issue with commons-chain. No
> refactoring of Struts to use commons-chain could start until that was
> released. Makes sense to me.
It would seem reasonable to be allowed get a jump start on uptaking
new, unreleased dependencies from the safety of an isolated feature
branch, as long as there is no impact on the branch being used to
stablize the release.
This can be beneficial if there is a significant amount of work
required to consume the new dependency.
Once the new dependency is officially released, the private branch can
be updated to reference it and then the changes can be safely merged
back to trunk, ready for the next release train.
Kind Regards,
John Fallows.
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
Right. I remember this was an issue with commons-chain. No
refactoring of Struts to use commons-chain could start until that was
released. Makes sense to me.
sean
On 6/23/05, Martin Cooper <ma...@apache.org> wrote:
>
>
> On Thu, 23 Jun 2005, Sean Schofield wrote:
>
> >> 1) Digester has removed the RSS classes from their standard build, so
> >> we either have to do a custom build of Digester or we have to have
> >> version 1.5 (which is what was in the lib dir)
> >
> > This is a known problem.
> > (http://issues.apache.org/jira/browse/MYFACES-134) I accidentally
> > introduced the problem into the build by using a newer version of
> > Digester. We should resolve this problem regardless of where the jars
> > are stored.
> >
> > Matthias was talking about taking it out and moving it into the
> > sandbox. Perhaps we should just take it out and reintroduce it to the
> > sandbox *after* its been refactored. We can discuss that on another
> > thread.
> >
> >> 2) Validator does not have the ISBN validator in its current release
> >> build (1.1.4), this class is in the 1.2 branch (which might be head,
> >> I did not dig into it). So we have to have the latest nightly (which
> >> is currently hosed on the apache servers at 45 bytes) or build it
> >> ourselves from their repo.
> >
> > Apparently the ISBN validator is relying on a dev version of commons
> > validator. IMO that's a bad thing. The dev version of some jars is
> > available in the Maven repository. We could ask the commons-validator
> > team to update the repository with a snapshot dev version. (Also we
> > can check the ASF repository Martin Cooper is referencing in his
> > post.)
> >
> >> So this points to the simplicity factor that Oliver argues. In order
> >> for us to have an auto download from ibiblio we will have to make our
> >> code depended on one of the released versions of these libraries. If
> >> we have the jar files in a repo (probably linked in with
> >> svn:externals?) then we have the ability to put in a dev version of
> >> some dependency jar.
> >
> > I don't think a milestone release of MyFaces should have dependencies
> > on beta versions of third party libraries. So this particular
> > drawback to ibiblio, etc. doesn't matter much to me.
>
> Absolutely. In earlier days, Struts dependended on unreleased versions of
> some of its dependencies, and this turned out to be a nightmare. Before we
> could release Struts itself, we had to make sure, one way or another, that
> all of its dependencies got released. That can cause unpredictable (and
> lengthy) delays in the release cycle. Since then, we've been determined to
> depend only on relesed versions of our dependencies, so that any delays in
> getting Struts released are purely our own fault. ;-)
>
> --
> Martin Cooper
>
>
> > [snip]
> >
> >> -bd-
> >
> > sean
> >
>
Re: Proposal: Elimiante jar files from SVN
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 23 Jun 2005, Sean Schofield wrote:
>> 1) Digester has removed the RSS classes from their standard build, so
>> we either have to do a custom build of Digester or we have to have
>> version 1.5 (which is what was in the lib dir)
>
> This is a known problem.
> (http://issues.apache.org/jira/browse/MYFACES-134) I accidentally
> introduced the problem into the build by using a newer version of
> Digester. We should resolve this problem regardless of where the jars
> are stored.
>
> Matthias was talking about taking it out and moving it into the
> sandbox. Perhaps we should just take it out and reintroduce it to the
> sandbox *after* its been refactored. We can discuss that on another
> thread.
>
>> 2) Validator does not have the ISBN validator in its current release
>> build (1.1.4), this class is in the 1.2 branch (which might be head,
>> I did not dig into it). So we have to have the latest nightly (which
>> is currently hosed on the apache servers at 45 bytes) or build it
>> ourselves from their repo.
>
> Apparently the ISBN validator is relying on a dev version of commons
> validator. IMO that's a bad thing. The dev version of some jars is
> available in the Maven repository. We could ask the commons-validator
> team to update the repository with a snapshot dev version. (Also we
> can check the ASF repository Martin Cooper is referencing in his
> post.)
>
>> So this points to the simplicity factor that Oliver argues. In order
>> for us to have an auto download from ibiblio we will have to make our
>> code depended on one of the released versions of these libraries. If
>> we have the jar files in a repo (probably linked in with
>> svn:externals?) then we have the ability to put in a dev version of
>> some dependency jar.
>
> I don't think a milestone release of MyFaces should have dependencies
> on beta versions of third party libraries. So this particular
> drawback to ibiblio, etc. doesn't matter much to me.
Absolutely. In earlier days, Struts dependended on unreleased versions of
some of its dependencies, and this turned out to be a nightmare. Before we
could release Struts itself, we had to make sure, one way or another, that
all of its dependencies got released. That can cause unpredictable (and
lengthy) delays in the release cycle. Since then, we've been determined to
depend only on relesed versions of our dependencies, so that any delays in
getting Struts released are purely our own fault. ;-)
--
Martin Cooper
> [snip]
>
>> -bd-
>
> sean
>
Re: Proposal: Elimiante jar files from SVN
Posted by Manfred Geiler <ma...@gmail.com>.
I agree with Sean and Martin in all points.
-Manfred
2005/6/23, Sean Schofield <se...@gmail.com>:
> > 1) Digester has removed the RSS classes from their standard build, so
> > we either have to do a custom build of Digester or we have to have
> > version 1.5 (which is what was in the lib dir)
>
> This is a known problem.
> (http://issues.apache.org/jira/browse/MYFACES-134) I accidentally
> introduced the problem into the build by using a newer version of
> Digester. We should resolve this problem regardless of where the jars
> are stored.
>
> Matthias was talking about taking it out and moving it into the
> sandbox. Perhaps we should just take it out and reintroduce it to the
> sandbox *after* its been refactored. We can discuss that on another
> thread.
>
> > 2) Validator does not have the ISBN validator in its current release
> > build (1.1.4), this class is in the 1.2 branch (which might be head,
> > I did not dig into it). So we have to have the latest nightly (which
> > is currently hosed on the apache servers at 45 bytes) or build it
> > ourselves from their repo.
>
> Apparently the ISBN validator is relying on a dev version of commons
> validator. IMO that's a bad thing. The dev version of some jars is
> available in the Maven repository. We could ask the commons-validator
> team to update the repository with a snapshot dev version. (Also we
> can check the ASF repository Martin Cooper is referencing in his
> post.)
>
> > So this points to the simplicity factor that Oliver argues. In order
> > for us to have an auto download from ibiblio we will have to make our
> > code depended on one of the released versions of these libraries. If
> > we have the jar files in a repo (probably linked in with
> > svn:externals?) then we have the ability to put in a dev version of
> > some dependency jar.
>
> I don't think a milestone release of MyFaces should have dependencies
> on beta versions of third party libraries. So this particular
> drawback to ibiblio, etc. doesn't matter much to me.
>
> [snip]
>
> > -bd-
>
> sean
>
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
> 1) Digester has removed the RSS classes from their standard build, so
> we either have to do a custom build of Digester or we have to have
> version 1.5 (which is what was in the lib dir)
This is a known problem.
(http://issues.apache.org/jira/browse/MYFACES-134) I accidentally
introduced the problem into the build by using a newer version of
Digester. We should resolve this problem regardless of where the jars
are stored.
Matthias was talking about taking it out and moving it into the
sandbox. Perhaps we should just take it out and reintroduce it to the
sandbox *after* its been refactored. We can discuss that on another
thread.
> 2) Validator does not have the ISBN validator in its current release
> build (1.1.4), this class is in the 1.2 branch (which might be head,
> I did not dig into it). So we have to have the latest nightly (which
> is currently hosed on the apache servers at 45 bytes) or build it
> ourselves from their repo.
Apparently the ISBN validator is relying on a dev version of commons
validator. IMO that's a bad thing. The dev version of some jars is
available in the Maven repository. We could ask the commons-validator
team to update the repository with a snapshot dev version. (Also we
can check the ASF repository Martin Cooper is referencing in his
post.)
> So this points to the simplicity factor that Oliver argues. In order
> for us to have an auto download from ibiblio we will have to make our
> code depended on one of the released versions of these libraries. If
> we have the jar files in a repo (probably linked in with
> svn:externals?) then we have the ability to put in a dev version of
> some dependency jar.
I don't think a milestone release of MyFaces should have dependencies
on beta versions of third party libraries. So this particular
drawback to ibiblio, etc. doesn't matter much to me.
[snip]
> -bd-
sean
Re: Proposal: Elimiante jar files from SVN
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
On 23 Jun 2005, at 14:14, Bill Dudney wrote:
> I like simple, so I'm inclined to vote with Oliver.
>
> I really like the new structure BTW, thanks again Sean for all the
> work you have put into making this happen!
>
> I've grabbed the new layout and started to make it work in Eclipse and
> here is what I've found.
>
> 1) Digester has removed the RSS classes from their standard build, so
> we either have to do a custom build of Digester or we have to have
> version 1.5 (which is what was in the lib dir)
> 2) Validator does not have the ISBN validator in its current release
> build (1.1.4), this class is in the 1.2 branch (which might be head, I
> did not dig into it). So we have to have the latest nightly (which is
> currently hosed on the apache servers at 45 bytes) or build it
> ourselves from their repo.
>
> So this points to the simplicity factor that Oliver argues. In order
> for us to have an auto download from ibiblio we will have to make our
> code depended on one of the released versions of these libraries. If
> we have the jar files in a repo (probably linked in with
> svn:externals?) then we have the ability to put in a dev version of
> some dependency jar.
I disagree, as a user (for what it's worth). Do you have any idea of
the hoops we have to jump through, to get things working if you don't
use the released versions? Our code uses those versions, and if we use
the same commons lib MyFaces uses (as in, always), in an unofficial
version, we get a version conflict that is extremely hard to fix, to
say the least.
Please use only officially released binaries of external projects. And
I do suggest that you use maven. KISS, indeed.
>
> In addition, we should probably have a way to ensure that these
> dependencies on non-released versions of libraries are more explicitly
> called out and I guess going to ibibilo would help us in that regard.
>
> Regardless of which way we go we should probably have some way of
> quickly distinguishing 'dev' versions of what we are using. If we do
> go back to a lib directory in subversion we should name the validator
> jar with a version so that its obvious its not a released version.
>
> Are there further benefits to having the lib not be part of the repo
> besides download/update times that I'm missing?
>
> Thanks again Sean!
>
> -bd-
>
> On Jun 22, 2005, at 6:18 PM, Oliver Rossmueller wrote:
>
>> -1 on that. Please don't make the build more complex than needed. Not
>> any stuff that seems to be cool to implement should be implemented.
>>
>> What's your problem with having the required libs in the repository?
>> For
>> me there are advantages only:
>>
>> - one source fits it all: you check out the svn module and have
>> everything you need to build
>> - the libs are versioned with the code which depends on the libs
>> - you have everything maintained in one place, the svn repository; no
>> need for external jar repositories or stuff like that
>> - no build is blocked because the download of a required lib is not
>> working for whatever reason (firewalls, network failures, ...)
>>
>> If you ever had the html of a http 500 page as the contents of a jar
>> file in your maven repository instead of the required jar itself you
>> know what I'm talking about. So do not try to imitate maven just by
>> other means but follow the KISS principle and keep it simple, please.
>>
>> Oliver
>>
>>
>> Manfred Geiler wrote:
>>
>>
>>> yes, looks good
>>> +1 for automatic download of jars
>>>
>>> -Manfred
>>>
>>>
>>>
>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>
>>>
>>>
>>>> First off, thanks to James Mitchell (of the Struts team) who has
>>>> been
>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>> make him proud. :-)
>>>>
>>>> While James and I were discussing the Struts layout he also
>>>> mentioned
>>>> something interesting. They no longer keep any jar files in their
>>>> repository. He has figured out a way to deal with the jar file
>>>> dependencies that does *not* require Maven (ie. can be done from
>>>> Ant.)
>>>>
>>>> I'm planning on doing something similar as part of the reorg. Check
>>>> out the following steps that allow you to build struts 1.2 without
>>>> specifying a single jar file in your properties ...
>>>>
>>>> $svn co
>>>> https://svn.apache.org/repos/asf/struts/core/branches/
>>>> STRUTS_1_2_BRANCH/
>>>> struts-1.2
>>>> $cd struts-1.2
>>>> $ant download-dependencies release
>>>>
>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>> process ;-) Also, its possible to build using local jar files if
>>>> that
>>>> is your cup of tea (just don't run the download-dependencies target
>>>> and specify the jar file locations in your local props file.)
>>>>
>>>> sean
>>>>
>>>>
>>>>
>>>>
>>
>>
>> --
>> Oliver Rossmueller
>> Software Engineer and IT-Consultant
>> Hamburg, Germany
>> http://www.rossmueller.com
>>
>>
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Proposal: Elimiante jar files from SVN
Posted by Bill Dudney <bd...@mac.com>.
Hi Sean,
I wish I'd checked and seen your response before sending... I started
my email last night and finished this morning without checking the
mail box...
On Jun 23, 2005, at 6:09 AM, Sean Schofield wrote:
>
> Keep in mind that the 'download-dependencies' target need only be
> called once. Actually, it need never be called if you want to get the
> jars through your own methods. As you will see in the Struts build
> process, you can set up your properties file to use your local copy of
> the jar files at any point you wish. So you won't be prevented from
> building if there is a problem with the Maven repository.
>
Only having to do it once (download-dependencies) is a good thing but
has the potential of issues with custom build jars such as the two
outlined in my previous email below.
I also really like having each dependency being a property in the
build process so that we can all point to our own local copies of the
jar files. However that requires greater discipline on our part to
not use 'unreleased' stuff like IDBNValidator and the RSSDigester.
Which IMO would be a good thing, but it keeps us from offering
features, which many will see as a bad thing.
> Its bad practice to keep the jar files in SVN if you have a reasonable
> alternative. A spot check of existing Apache projects reveals that
> none of them store jar files in SVN. This includes Struts and Jakarta
> Commons. IMO its time for MyFaces to adopt this practice as well.
> The download-dependencies target is just an elegant solution used by
> Struts to help the user get those jars.
Well, I partially agree. In most of my 'real job' work we keep open
source code and jars in a repo so that we can always have a 'working'
copy of the project in case one of the dependent OSS projects goes
off on a path the 'real job' project can't follow. In fact the svn
folks have a really cool tool to help you keep your dependent code up
to date (svn_load_dirs.pl). I'm not suggesting that we (MyFaces) be
so stringent in our approach but keeping the jars (esp the custom
built ones) in our repo is not all together bad.
In an ideal world though I'd buy into what you are suggesting if we
could keep from using any unreleased code and we had as part of our
auto build a way to build against the nightlies of the other projects
we depended on. That would allow us early warning that we are no
longer compatible with a 'soon' to be released version of something
(like in the case of digester).
Anyway, thanks again for all your hard work.
TTFN,
-bd-
On Jun 23, 2005, at 6:14 AM, Bill Dudney wrote:
> I like simple, so I'm inclined to vote with Oliver.
>
> I really like the new structure BTW, thanks again Sean for all the
> work you have put into making this happen!
>
> I've grabbed the new layout and started to make it work in Eclipse
> and here is what I've found.
>
> 1) Digester has removed the RSS classes from their standard build,
> so we either have to do a custom build of Digester or we have to
> have version 1.5 (which is what was in the lib dir)
> 2) Validator does not have the ISBN validator in its current
> release build (1.1.4), this class is in the 1.2 branch (which might
> be head, I did not dig into it). So we have to have the latest
> nightly (which is currently hosed on the apache servers at 45
> bytes) or build it ourselves from their repo.
>
> So this points to the simplicity factor that Oliver argues. In
> order for us to have an auto download from ibiblio we will have to
> make our code depended on one of the released versions of these
> libraries. If we have the jar files in a repo (probably linked in
> with svn:externals?) then we have the ability to put in a dev
> version of some dependency jar.
>
> In addition, we should probably have a way to ensure that these
> dependencies on non-released versions of libraries are more
> explicitly called out and I guess going to ibibilo would help us in
> that regard.
>
> Regardless of which way we go we should probably have some way of
> quickly distinguishing 'dev' versions of what we are using. If we
> do go back to a lib directory in subversion we should name the
> validator jar with a version so that its obvious its not a released
> version.
>
> Are there further benefits to having the lib not be part of the
> repo besides download/update times that I'm missing?
>
> Thanks again Sean!
>
> -bd-
>
> On Jun 22, 2005, at 6:18 PM, Oliver Rossmueller wrote:
>
>
>> -1 on that. Please don't make the build more complex than needed. Not
>> any stuff that seems to be cool to implement should be implemented.
>>
>> What's your problem with having the required libs in the
>> repository? For
>> me there are advantages only:
>>
>> - one source fits it all: you check out the svn module and have
>> everything you need to build
>> - the libs are versioned with the code which depends on the libs
>> - you have everything maintained in one place, the svn repository; no
>> need for external jar repositories or stuff like that
>> - no build is blocked because the download of a required lib is not
>> working for whatever reason (firewalls, network failures, ...)
>>
>> If you ever had the html of a http 500 page as the contents of a jar
>> file in your maven repository instead of the required jar itself you
>> know what I'm talking about. So do not try to imitate maven just by
>> other means but follow the KISS principle and keep it simple, please.
>>
>> Oliver
>>
>>
>> Manfred Geiler wrote:
>>
>>
>>
>>> yes, looks good
>>> +1 for automatic download of jars
>>>
>>> -Manfred
>>>
>>>
>>>
>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>
>>>
>>>
>>>
>>>> First off, thanks to James Mitchell (of the Struts team) who has
>>>> been
>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>> make him proud. :-)
>>>>
>>>> While James and I were discussing the Struts layout he also
>>>> mentioned
>>>> something interesting. They no longer keep any jar files in their
>>>> repository. He has figured out a way to deal with the jar file
>>>> dependencies that does *not* require Maven (ie. can be done from
>>>> Ant.)
>>>>
>>>> I'm planning on doing something similar as part of the reorg.
>>>> Check
>>>> out the following steps that allow you to build struts 1.2 without
>>>> specifying a single jar file in your properties ...
>>>>
>>>> $svn co https://svn.apache.org/repos/asf/struts/core/branches/
>>>> STRUTS_1_2_BRANCH/
>>>> struts-1.2
>>>> $cd struts-1.2
>>>> $ant download-dependencies release
>>>>
>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>> process ;-) Also, its possible to build using local jar files
>>>> if that
>>>> is your cup of tea (just don't run the download-dependencies target
>>>> and specify the jar file locations in your local props file.)
>>>>
>>>> sean
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>> --
>> Oliver Rossmueller
>> Software Engineer and IT-Consultant
>> Hamburg, Germany
>> http://www.rossmueller.com
>>
>>
>>
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by Bill Dudney <bd...@mac.com>.
I like simple, so I'm inclined to vote with Oliver.
I really like the new structure BTW, thanks again Sean for all the
work you have put into making this happen!
I've grabbed the new layout and started to make it work in Eclipse
and here is what I've found.
1) Digester has removed the RSS classes from their standard build, so
we either have to do a custom build of Digester or we have to have
version 1.5 (which is what was in the lib dir)
2) Validator does not have the ISBN validator in its current release
build (1.1.4), this class is in the 1.2 branch (which might be head,
I did not dig into it). So we have to have the latest nightly (which
is currently hosed on the apache servers at 45 bytes) or build it
ourselves from their repo.
So this points to the simplicity factor that Oliver argues. In order
for us to have an auto download from ibiblio we will have to make our
code depended on one of the released versions of these libraries. If
we have the jar files in a repo (probably linked in with
svn:externals?) then we have the ability to put in a dev version of
some dependency jar.
In addition, we should probably have a way to ensure that these
dependencies on non-released versions of libraries are more
explicitly called out and I guess going to ibibilo would help us in
that regard.
Regardless of which way we go we should probably have some way of
quickly distinguishing 'dev' versions of what we are using. If we do
go back to a lib directory in subversion we should name the validator
jar with a version so that its obvious its not a released version.
Are there further benefits to having the lib not be part of the repo
besides download/update times that I'm missing?
Thanks again Sean!
-bd-
On Jun 22, 2005, at 6:18 PM, Oliver Rossmueller wrote:
> -1 on that. Please don't make the build more complex than needed. Not
> any stuff that seems to be cool to implement should be implemented.
>
> What's your problem with having the required libs in the
> repository? For
> me there are advantages only:
>
> - one source fits it all: you check out the svn module and have
> everything you need to build
> - the libs are versioned with the code which depends on the libs
> - you have everything maintained in one place, the svn repository; no
> need for external jar repositories or stuff like that
> - no build is blocked because the download of a required lib is not
> working for whatever reason (firewalls, network failures, ...)
>
> If you ever had the html of a http 500 page as the contents of a jar
> file in your maven repository instead of the required jar itself you
> know what I'm talking about. So do not try to imitate maven just by
> other means but follow the KISS principle and keep it simple, please.
>
> Oliver
>
>
> Manfred Geiler wrote:
>
>
>> yes, looks good
>> +1 for automatic download of jars
>>
>> -Manfred
>>
>>
>>
>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>
>>
>>
>>> First off, thanks to James Mitchell (of the Struts team) who has
>>> been
>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>> make him proud. :-)
>>>
>>> While James and I were discussing the Struts layout he also
>>> mentioned
>>> something interesting. They no longer keep any jar files in their
>>> repository. He has figured out a way to deal with the jar file
>>> dependencies that does *not* require Maven (ie. can be done from
>>> Ant.)
>>>
>>> I'm planning on doing something similar as part of the reorg. Check
>>> out the following steps that allow you to build struts 1.2 without
>>> specifying a single jar file in your properties ...
>>>
>>> $svn co https://svn.apache.org/repos/asf/struts/core/branches/
>>> STRUTS_1_2_BRANCH/
>>> struts-1.2
>>> $cd struts-1.2
>>> $ant download-dependencies release
>>>
>>> Nice! I see no reason to deprive ourselves of the same cool build
>>> process ;-) Also, its possible to build using local jar files if
>>> that
>>> is your cup of tea (just don't run the download-dependencies target
>>> and specify the jar file locations in your local props file.)
>>>
>>> sean
>>>
>>>
>>>
>>>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by John Fallows <jo...@gmail.com>.
I strongly agree with Martin and Sean.
Eliminating binary dependencies from versioned source control is a Good Thing.
Kind Regards,
John Fallows.
On 6/23/05, Martin Cooper <ma...@apache.org> wrote:
> I would strongly recommend that you not store your dependencies in the SVN
> repo. Consider the consequences if every ASF project did the same thing.
> There would be many dozens of copies of the exact same libraries taking up
> space in the repo, one (or more) per project. The repo would end up being
> clogged with binaries, many of them duplicates.
>
> This is one reason that the ASF Java repo was created - so that there is
> one place that libraries can be placed, so that they are available to any
> project that needs them. This is a parallel to the Maven repository at
> ibiblio, but neither of these require that Maven be used for the builds.
>
> Also, as Sean points out, if you prefer not to make use of automatic
> downloads, you are free to configure your system that way. But for many,
> if not most, people, the automatic downloads give them a way to get up and
> running much more quickly than a manual configuration.
>
> --
> Martin Cooper
>
>
> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>
> > -1 on that. Please don't make the build more complex than needed. Not
> > any stuff that seems to be cool to implement should be implemented.
> >
> > What's your problem with having the required libs in the repository? For
> > me there are advantages only:
> >
> > - one source fits it all: you check out the svn module and have
> > everything you need to build
> > - the libs are versioned with the code which depends on the libs
> > - you have everything maintained in one place, the svn repository; no
> > need for external jar repositories or stuff like that
> > - no build is blocked because the download of a required lib is not
> > working for whatever reason (firewalls, network failures, ...)
> >
> > If you ever had the html of a http 500 page as the contents of a jar
> > file in your maven repository instead of the required jar itself you
> > know what I'm talking about. So do not try to imitate maven just by
> > other means but follow the KISS principle and keep it simple, please.
> >
> > Oliver
> >
> >
> > Manfred Geiler wrote:
> >
> >> yes, looks good
> >> +1 for automatic download of jars
> >>
> >> -Manfred
> >>
> >>
> >>
> >> 2005/6/21, Sean Schofield <se...@gmail.com>:
> >>
> >>
> >>> First off, thanks to James Mitchell (of the Struts team) who has been
> >>> teaching me the wonders of svn:externals. I hope my SVN reorg will
> >>> make him proud. :-)
> >>>
> >>> While James and I were discussing the Struts layout he also mentioned
> >>> something interesting. They no longer keep any jar files in their
> >>> repository. He has figured out a way to deal with the jar file
> >>> dependencies that does *not* require Maven (ie. can be done from Ant.)
> >>>
> >>> I'm planning on doing something similar as part of the reorg. Check
> >>> out the following steps that allow you to build struts 1.2 without
> >>> specifying a single jar file in your properties ...
> >>>
> >>> $svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
> >>> struts-1.2
> >>> $cd struts-1.2
> >>> $ant download-dependencies release
> >>>
> >>> Nice! I see no reason to deprive ourselves of the same cool build
> >>> process ;-) Also, its possible to build using local jar files if that
> >>> is your cup of tea (just don't run the download-dependencies target
> >>> and specify the jar file locations in your local props file.)
> >>>
> >>> sean
> >>>
> >>>
> >>>
> >
> >
> > --
> > Oliver Rossmueller
> > Software Engineer and IT-Consultant
> > Hamburg, Germany
> > http://www.rossmueller.com
> >
> >
>
Re: Proposal: Elimiante jar files from SVN
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 25 Jun 2005, Oliver Rossmueller wrote:
> Martin Cooper wrote:
>
>>
>>
>> On Fri, 24 Jun 2005, Oliver Rossmueller wrote:
>>
>>> Martin Cooper wrote:
>>>
>>>> I would strongly recommend that you not store your dependencies in the
>>>> SVN repo. Consider the consequences if every ASF project did the same
>>>> thing. There would be many dozens of copies of the exact same
>>>> libraries taking up space in the repo, one (or more) per project. The
>>>> repo would end up being clogged with binaries, many of them duplicates.
>>>
>>>
>>> Martin,
>>>
>>> if saving hard disk space is the main argument, than it's -1 again. Of
>>> course you end up with duplicates of the same jar in different projects
>>> in the repository, but that's not the point. The point is simplicity of
>>> the build process so it can be handled by any developer and not only the
>>> MyFaces core team.
>>>
>>>>
>>>> This is one reason that the ASF Java repo was created - so that there
>>>> is one place that libraries can be placed, so that they are available
>>>> to any project that needs them. This is a parallel to the Maven
>>>> repository at ibiblio, but neither of these require that Maven be used
>>>> for the builds.
>>>>
>>>> Also, as Sean points out, if you prefer not to make use of automatic
>>>> downloads, you are free to configure your system that way. But for
>>>> many, if not most, people, the automatic downloads give them a way to
>>>> get up and running much more quickly than a manual configuration.
>>>
>>>
>>> Of course I can configure anything manually, and I am also able to deal
>>> with problems caused by failed automatic downloads. But that's because I
>>> know how the build works. Consider somebody who just got the sources
>>> from svn. The first step then would be to check for the existence of
>>> build.xml and to run 'ant'. Now that first and straightforward attempt
>>> fails because the default ant target does not download required jars or
>>> the default target does download the jars but download fails for
>>> whatever reason. From the POV of named user what would you do? I would
>>> throw MyFaces to the trash can and don't have a look at it for at least
>>> half a year as those MyFaces guys seem to be not able to handle their
>>> build process so how good and stable can their software be?
>>
>>
>> You don't have much patience, do you? ;-) Personally, I would look for
>> an answer before just throwing it in the trash, and I suspect most
>> people would do the same.
>
> Well, there is the JSF RI I can get from Sun without any problems, so
> why would I care for fixing a broken MyFaces build if I just want to
> give it a try? If the first impression you get from an open-source
> product is a broken build what will you think? To provide convidence
> does look different.
If all I cared about was *using* JSF, why would I be trying to *build*
MyFaces at all? If I'm trying to build MyFaces, it's probably because I'm
interested in helping develop it. If I'm interested enough to grab the
source, I honestly don't think I'm going to give up the very first time
something doesn't go as smoothly as silk. I think you need to give
potential developers a bit more credit that you seem prepared to give
them.
>>> That's my point: ease of build for anybody. It should not be necessary
>>> to be an ant and subversion guru to handle the build.
>>
>>
>> Come on, Oliver, nobody has said anything about needing to be an Ant
>> or SVN guru. Unless you count typing 'ant' as being an Ant guru. ;-)
>>
>> OK, so what do you do when not all your dependencies have licenses
>> that allow you to store them in the SVN repo? All it takes is one.
>> That will immediately and permanently break your nice clean "pull
>> everything from the repo and go" model.
>
> That's the first argument so far that makes kind of sense. But do we
> have this problem the moment? As far as I know that's not the case. So
> why are we trying to fix a problem that does not exist?
I haven't looked at the dependencies to see if you have the problem right
now. However, I would emphasise that it is *very* easy to get into this
type of scenario. So basing your build system on the hope that you're
never going to hit this is building on very shaky ground, at best.
--
Martin Cooper
> Oliver
>
>
>>
>> --
>> Martin Cooper
>>
>>
>>> Oliver
>>>
>>>>
>>>> --
>>>> Martin Cooper
>>>>
>>>>
>>>> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>>>>
>>>>> -1 on that. Please don't make the build more complex than needed. Not
>>>>> any stuff that seems to be cool to implement should be implemented.
>>>>>
>>>>> What's your problem with having the required libs in the
>>>>> repository? For
>>>>> me there are advantages only:
>>>>>
>>>>> - one source fits it all: you check out the svn module and have
>>>>> everything you need to build
>>>>> - the libs are versioned with the code which depends on the libs
>>>>> - you have everything maintained in one place, the svn repository; no
>>>>> need for external jar repositories or stuff like that
>>>>> - no build is blocked because the download of a required lib is not
>>>>> working for whatever reason (firewalls, network failures, ...)
>>>>>
>>>>> If you ever had the html of a http 500 page as the contents of a jar
>>>>> file in your maven repository instead of the required jar itself you
>>>>> know what I'm talking about. So do not try to imitate maven just by
>>>>> other means but follow the KISS principle and keep it simple, please.
>>>>>
>>>>> Oliver
>>>>>
>>>>>
>>>>> Manfred Geiler wrote:
>>>>>
>>>>>> yes, looks good
>>>>>> +1 for automatic download of jars
>>>>>>
>>>>>> -Manfred
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>>>>
>>>>>>
>>>>>>> First off, thanks to James Mitchell (of the Struts team) who has
>>>>>>> been
>>>>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>>>>> make him proud. :-)
>>>>>>>
>>>>>>> While James and I were discussing the Struts layout he also
>>>>>>> mentioned
>>>>>>> something interesting. They no longer keep any jar files in their
>>>>>>> repository. He has figured out a way to deal with the jar file
>>>>>>> dependencies that does *not* require Maven (ie. can be done from
>>>>>>> Ant.)
>>>>>>>
>>>>>>> I'm planning on doing something similar as part of the reorg. Check
>>>>>>> out the following steps that allow you to build struts 1.2 without
>>>>>>> specifying a single jar file in your properties ...
>>>>>>>
>>>>>>> $svn co
>>>>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>>>>
>>>>>>>
>>>>>>> struts-1.2
>>>>>>> $cd struts-1.2
>>>>>>> $ant download-dependencies release
>>>>>>>
>>>>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>>>>> process ;-) Also, its possible to build using local jar files if
>>>>>>> that
>>>>>>> is your cup of tea (just don't run the download-dependencies target
>>>>>>> and specify the jar file locations in your local props file.)
>>>>>>>
>>>>>>> sean
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Oliver Rossmueller
>>>>> Software Engineer and IT-Consultant
>>>>> Hamburg, Germany
>>>>> http://www.rossmueller.com
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Oliver Rossmueller
>>> Software Engineer and IT-Consultant
>>> Hamburg, Germany
>>> http://www.rossmueller.com
>>>
>>>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Martin Cooper wrote:
>
>
> On Fri, 24 Jun 2005, Oliver Rossmueller wrote:
>
>> Martin Cooper wrote:
>>
>>> I would strongly recommend that you not store your dependencies in the
>>> SVN repo. Consider the consequences if every ASF project did the same
>>> thing. There would be many dozens of copies of the exact same
>>> libraries taking up space in the repo, one (or more) per project. The
>>> repo would end up being clogged with binaries, many of them duplicates.
>>
>>
>> Martin,
>>
>> if saving hard disk space is the main argument, than it's -1 again. Of
>> course you end up with duplicates of the same jar in different projects
>> in the repository, but that's not the point. The point is simplicity of
>> the build process so it can be handled by any developer and not only the
>> MyFaces core team.
>>
>>>
>>> This is one reason that the ASF Java repo was created - so that there
>>> is one place that libraries can be placed, so that they are available
>>> to any project that needs them. This is a parallel to the Maven
>>> repository at ibiblio, but neither of these require that Maven be used
>>> for the builds.
>>>
>>> Also, as Sean points out, if you prefer not to make use of automatic
>>> downloads, you are free to configure your system that way. But for
>>> many, if not most, people, the automatic downloads give them a way to
>>> get up and running much more quickly than a manual configuration.
>>
>>
>> Of course I can configure anything manually, and I am also able to deal
>> with problems caused by failed automatic downloads. But that's because I
>> know how the build works. Consider somebody who just got the sources
>> from svn. The first step then would be to check for the existence of
>> build.xml and to run 'ant'. Now that first and straightforward attempt
>> fails because the default ant target does not download required jars or
>> the default target does download the jars but download fails for
>> whatever reason. From the POV of named user what would you do? I would
>> throw MyFaces to the trash can and don't have a look at it for at least
>> half a year as those MyFaces guys seem to be not able to handle their
>> build process so how good and stable can their software be?
>
>
> You don't have much patience, do you? ;-) Personally, I would look for
> an answer before just throwing it in the trash, and I suspect most
> people would do the same.
Well, there is the JSF RI I can get from Sun without any problems, so
why would I care for fixing a broken MyFaces build if I just want to
give it a try? If the first impression you get from an open-source
product is a broken build what will you think? To provide convidence
does look different.
>
>
>> That's my point: ease of build for anybody. It should not be necessary
>> to be an ant and subversion guru to handle the build.
>
>
> Come on, Oliver, nobody has said anything about needing to be an Ant
> or SVN guru. Unless you count typing 'ant' as being an Ant guru. ;-)
>
> OK, so what do you do when not all your dependencies have licenses
> that allow you to store them in the SVN repo? All it takes is one.
> That will immediately and permanently break your nice clean "pull
> everything from the repo and go" model.
That's the first argument so far that makes kind of sense. But do we
have this problem the moment? As far as I know that's not the case. So
why are we trying to fix a problem that does not exist?
Oliver
>
> --
> Martin Cooper
>
>
>> Oliver
>>
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>>> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>>>
>>>> -1 on that. Please don't make the build more complex than needed. Not
>>>> any stuff that seems to be cool to implement should be implemented.
>>>>
>>>> What's your problem with having the required libs in the
>>>> repository? For
>>>> me there are advantages only:
>>>>
>>>> - one source fits it all: you check out the svn module and have
>>>> everything you need to build
>>>> - the libs are versioned with the code which depends on the libs
>>>> - you have everything maintained in one place, the svn repository; no
>>>> need for external jar repositories or stuff like that
>>>> - no build is blocked because the download of a required lib is not
>>>> working for whatever reason (firewalls, network failures, ...)
>>>>
>>>> If you ever had the html of a http 500 page as the contents of a jar
>>>> file in your maven repository instead of the required jar itself you
>>>> know what I'm talking about. So do not try to imitate maven just by
>>>> other means but follow the KISS principle and keep it simple, please.
>>>>
>>>> Oliver
>>>>
>>>>
>>>> Manfred Geiler wrote:
>>>>
>>>>> yes, looks good
>>>>> +1 for automatic download of jars
>>>>>
>>>>> -Manfred
>>>>>
>>>>>
>>>>>
>>>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>>>
>>>>>
>>>>>> First off, thanks to James Mitchell (of the Struts team) who has
>>>>>> been
>>>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>>>> make him proud. :-)
>>>>>>
>>>>>> While James and I were discussing the Struts layout he also
>>>>>> mentioned
>>>>>> something interesting. They no longer keep any jar files in their
>>>>>> repository. He has figured out a way to deal with the jar file
>>>>>> dependencies that does *not* require Maven (ie. can be done from
>>>>>> Ant.)
>>>>>>
>>>>>> I'm planning on doing something similar as part of the reorg. Check
>>>>>> out the following steps that allow you to build struts 1.2 without
>>>>>> specifying a single jar file in your properties ...
>>>>>>
>>>>>> $svn co
>>>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>>>
>>>>>>
>>>>>> struts-1.2
>>>>>> $cd struts-1.2
>>>>>> $ant download-dependencies release
>>>>>>
>>>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>>>> process ;-) Also, its possible to build using local jar files if
>>>>>> that
>>>>>> is your cup of tea (just don't run the download-dependencies target
>>>>>> and specify the jar file locations in your local props file.)
>>>>>>
>>>>>> sean
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Oliver Rossmueller
>>>> Software Engineer and IT-Consultant
>>>> Hamburg, Germany
>>>> http://www.rossmueller.com
>>>>
>>>>
>>
>>
>> --
>> Oliver Rossmueller
>> Software Engineer and IT-Consultant
>> Hamburg, Germany
>> http://www.rossmueller.com
>>
>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 24 Jun 2005, Oliver Rossmueller wrote:
> Martin Cooper wrote:
>
>> I would strongly recommend that you not store your dependencies in the
>> SVN repo. Consider the consequences if every ASF project did the same
>> thing. There would be many dozens of copies of the exact same
>> libraries taking up space in the repo, one (or more) per project. The
>> repo would end up being clogged with binaries, many of them duplicates.
>
> Martin,
>
> if saving hard disk space is the main argument, than it's -1 again. Of
> course you end up with duplicates of the same jar in different projects
> in the repository, but that's not the point. The point is simplicity of
> the build process so it can be handled by any developer and not only the
> MyFaces core team.
>
>>
>> This is one reason that the ASF Java repo was created - so that there
>> is one place that libraries can be placed, so that they are available
>> to any project that needs them. This is a parallel to the Maven
>> repository at ibiblio, but neither of these require that Maven be used
>> for the builds.
>>
>> Also, as Sean points out, if you prefer not to make use of automatic
>> downloads, you are free to configure your system that way. But for
>> many, if not most, people, the automatic downloads give them a way to
>> get up and running much more quickly than a manual configuration.
>
> Of course I can configure anything manually, and I am also able to deal
> with problems caused by failed automatic downloads. But that's because I
> know how the build works. Consider somebody who just got the sources
> from svn. The first step then would be to check for the existence of
> build.xml and to run 'ant'. Now that first and straightforward attempt
> fails because the default ant target does not download required jars or
> the default target does download the jars but download fails for
> whatever reason. From the POV of named user what would you do? I would
> throw MyFaces to the trash can and don't have a look at it for at least
> half a year as those MyFaces guys seem to be not able to handle their
> build process so how good and stable can their software be?
You don't have much patience, do you? ;-) Personally, I would look for an
answer before just throwing it in the trash, and I suspect most people
would do the same.
> That's my point: ease of build for anybody. It should not be necessary
> to be an ant and subversion guru to handle the build.
Come on, Oliver, nobody has said anything about needing to be an Ant or
SVN guru. Unless you count typing 'ant' as being an Ant guru. ;-)
OK, so what do you do when not all your dependencies have licenses that
allow you to store them in the SVN repo? All it takes is one. That will
immediately and permanently break your nice clean "pull everything from
the repo and go" model.
--
Martin Cooper
> Oliver
>
>>
>> --
>> Martin Cooper
>>
>>
>> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>>
>>> -1 on that. Please don't make the build more complex than needed. Not
>>> any stuff that seems to be cool to implement should be implemented.
>>>
>>> What's your problem with having the required libs in the repository? For
>>> me there are advantages only:
>>>
>>> - one source fits it all: you check out the svn module and have
>>> everything you need to build
>>> - the libs are versioned with the code which depends on the libs
>>> - you have everything maintained in one place, the svn repository; no
>>> need for external jar repositories or stuff like that
>>> - no build is blocked because the download of a required lib is not
>>> working for whatever reason (firewalls, network failures, ...)
>>>
>>> If you ever had the html of a http 500 page as the contents of a jar
>>> file in your maven repository instead of the required jar itself you
>>> know what I'm talking about. So do not try to imitate maven just by
>>> other means but follow the KISS principle and keep it simple, please.
>>>
>>> Oliver
>>>
>>>
>>> Manfred Geiler wrote:
>>>
>>>> yes, looks good
>>>> +1 for automatic download of jars
>>>>
>>>> -Manfred
>>>>
>>>>
>>>>
>>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>>
>>>>
>>>>> First off, thanks to James Mitchell (of the Struts team) who has been
>>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>>> make him proud. :-)
>>>>>
>>>>> While James and I were discussing the Struts layout he also mentioned
>>>>> something interesting. They no longer keep any jar files in their
>>>>> repository. He has figured out a way to deal with the jar file
>>>>> dependencies that does *not* require Maven (ie. can be done from Ant.)
>>>>>
>>>>> I'm planning on doing something similar as part of the reorg. Check
>>>>> out the following steps that allow you to build struts 1.2 without
>>>>> specifying a single jar file in your properties ...
>>>>>
>>>>> $svn co
>>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>>
>>>>> struts-1.2
>>>>> $cd struts-1.2
>>>>> $ant download-dependencies release
>>>>>
>>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>>> process ;-) Also, its possible to build using local jar files if that
>>>>> is your cup of tea (just don't run the download-dependencies target
>>>>> and specify the jar file locations in your local props file.)
>>>>>
>>>>> sean
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Oliver Rossmueller
>>> Software Engineer and IT-Consultant
>>> Hamburg, Germany
>>> http://www.rossmueller.com
>>>
>>>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by James Mitchell <jm...@apache.org>.
Not sure why my text got garbled. (unless it's just my mail client)
Here's what I posted:
http://www.edgetechservices.net/ant-get.htm
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: "James Mitchell" <jm...@apache.org>
To: "MyFaces Development" <de...@myfaces.apache.org>
Sent: Saturday, June 25, 2005 12:52 AM
Subject: Re: Proposal: Elimiante jar files from SVN
> ----- Original Message -----
> From: "Oliver Rossmueller" <ol...@tuxerra.com>
> To: "MyFaces Development" <de...@myfaces.apache.org>
> Sent: Friday, June 24, 2005 10:08 PM
> Subject: Re: Proposal: Elimiante jar files from SVN
>
>
>> James Mitchell wrote:
>>
>>> Unless I missed it somewhere, no one has mentioned the extra bloat in
>>> your source distributions (if you include the binary dependencies).
>>
>> James,
>>
>> you need the binary dependencies anyway to build the project, so what is
>> your point? You download the source distribution with libs included or
>> you download the source distribution without libs and ant does the lib
>> download afterwards. The sum of required network traffic is the same.
>>
>
> That's true for the developer. But I was also considering ASF hardware
> and bandwidth. Again, that's a drop in the bucket if only MyFaces were
> doing it. But you are not. I have had this same conversation (beating
> the same dead horse) with developers on other projects, both here, sf.net,
> and many, MANY closed source projects.
>
>>>
>>> Oliver, I'm having a hard time understanding your point.
>>>
>>> I can see how one wouldn't care about disk space and bandwidth,
>>> because you (nor I) currently pay for neither. But how much more
>>> "simple" can building a project be then calling "ant". That's all you
>>> should have to do to build the project.
>>>
>>> Please explain to me what makes it "not simple" if the ant script
>>> automatically goes out and gets the dependencies the first time you
>>> run the script (and never has to do it again unless a dependency is
>>> added or changed) ??
>>
>> It get's "not simple" as soon as the automatic download fails for
>> whatever reason. I had problems in the past with maven-based builds
>> because the attempt to download required libs ended up in corrupt jars
>> in the local repository because ibiblio was not available and all the
>> downloaded jars actually were http 404/500 error pages. The result is a
>> long list of strange error messages talking about corrupt zip files and
>> stuff like that. What you plan to do with ant is just another way to the
>> same potential problem.
>
> I'm not sure why you keep talking about corrupt binaries. This is not
> even a valid case. At least not with any of the last 5 versions of Ant
> that I have used.
>
> Let me explain:
>
> <?xml version="1.0"?>
>
> <project name="Test build" default="test">
>
> <target name="test">
> <echo>Getting the correct JAR </echo>
> <get dest="commons-beanutils.jar"
> usetimestamp="true" ignoreerrors="true"
> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0.jar"/>
> <echo>Attempt to get an invalid JAR (with ignoreerrors=true)</echo> <get
> dest="commons-beanutils-8.jar" usetimestamp="true" ignoreerrors="true"
> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar"/>
> <echo>Attempt to get an invalid JAR (with ignoreerrors=false)</echo> <get
> dest="commons-beanutils-9.jar" usetimestamp="true" ignoreerrors="false"
> src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar"/>
> </target></project>Ok, so here's what I get when I run
> this...---------------------------------------------------------jmitchell@compaq
> ~/test$ lsbuild.xmljmitchell@compaq ~/test$ antBuildfile: build.xmltest:
> [echo] Getting the correct JAR [get]
> Getting:http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0.jar
> [get] To: C:\cygwin\home\jmitchell\test
> \commons-beanutils.jar [echo] Attempt to get an invalid JAR (with
> ignoreerrors=true) [get]
> Getting:http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar
> [get] To: C:\cygwin\home\jmitchell\test\commons-beanutils-8.jar [get]
> Error opening connection java.io.IOException [get] Error opening
> connection java.io.IOException [get] Error opening connection
> java.io.IOException [get] Can't
> gethttp://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar
> toC:\cygwin\home\jmitchell\test\commons-beanutils-8.jar [echo] Attempt
> to get an invalid JAR (with ignoreerrors=false) [get]
> Getting:http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar
> [get] To: C:\cygwin\home\jmitchell\test\commons-beanutils-9.jar [get]
> Error opening connection java.io.IOException [get] Error opening
> connection java.io.IOException [get]
> Error opening connection java.io.IOException [get] Can't
> gethttp://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar
> toC:\cygwin\home\jmitchell\test\commons-beanutils-9.jarBUILD
> FAILEDC:\cygwin\home\jmitchell\test\build.xml:19: Can't
> gethttp://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar
> toC:\cygwin\home\jmitchell\test\commons-beanutils-9.jarTotal time: 4
> secondsjmitchell@compaq ~/test$ lsbuild.xml
> commons-beanutils.jar--------------------------------------------------------Notice
> there are no corrupted JARs, just a nice clean message as to what Antwas
> trying to do, but couldn't.>> I'm sure you are able to deal with problems
> like that. If you know the> build mechanism it won't be a big deal. But
> there will always be users> who checkout the MyFaces sources for the first
> time. Consider they want> to get a fix before the next release is out. If
> automatic download does> not work for them - I don't say this will happen
> every day, but it's a> possible scenario - they are stuck. They just
> called ant, they don't> know and don't want to know what's going on behind
> the scenes. What they> want is a working MyFaces built from sources.Why do
> you continue to make this assumption that someone is smart enough tobe
> able to download and configure both SVN and Ant, and checkout theproject,
> yet so dumb that they would "throw it in the trash" on the firsterror.
> That's not making a lot of sense to me. That's why we have a userslist,
> and forums, and books, and many articles and blogs about the same.--James
> MitchellSoftware Engineer / Open Source EvangelistConsulting / Mentoring /
> FreelanceEdgeTech, Inc.http://www.edgetechservices.net/678.910.8017AIM:
> jmitchtxYahoo: jmitchtxMSN: jmitchell@apache.orgSkype: jmitchtx
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
There may be a misunderstanding here about "end-user". Just to clean up
the point:
Distributions of libraries (both source and binary) should never
contain binary dependencies. The users of libraries are developers
themselves. They need an extensive list of dependencies, with lots of
information, and potential automatic download. The maven POM and maven
process provides this. Yes, this means developers should install maven.
Distributions of full applications, for end-users, i.e., complete
webapplications or desktop applications, should contain all
dependecies. The users of full applications are non-developers, i.e.,
real end-uers or administrators.
On 27 Jun 2005, at 9:44, Craig McClanahan wrote:
> On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>>
>> On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>>
>>>
>>> For the record, I am absolutely and totally -1 on including JAR files
>>> in the source code repository of any Apache project that I work on.
>>> Including them in a binary distribution, of course, is a totally
>>> different animal.
>>>
>>> Craig
>>>
>>>
>>
>> Even then. (see previous post). In my opinion (for as much as that of
>> a
>> user counts), only end-user products should contain all dependencies.
>> Libraries should never, but instead list the dependencies with all
>> needed information, including what each dependency is needed for.
>>
>
> Totally agreed on end user products (i.e binary releases) -- they
> should, licenses permitting, include all the relevant dependencies.
> That is a totally separate question from whether the binary artifacts
> should be included in the CVS or SVN source repositories of the
> software package you are interested in. That's a question of how a
> product is *built*, not of how it is *packaged*.
>
> Craig
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Proposal: Elimiante jar files from SVN
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>
> On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>
> >
> > For the record, I am absolutely and totally -1 on including JAR files
> > in the source code repository of any Apache project that I work on.
> > Including them in a binary distribution, of course, is a totally
> > different animal.
> >
> > Craig
> >
> >
>
> Even then. (see previous post). In my opinion (for as much as that of a
> user counts), only end-user products should contain all dependencies.
> Libraries should never, but instead list the dependencies with all
> needed information, including what each dependency is needed for.
>
Totally agreed on end user products (i.e binary releases) -- they
should, licenses permitting, include all the relevant dependencies.
That is a totally separate question from whether the binary artifacts
should be included in the CVS or SVN source repositories of the
software package you are interested in. That's a question of how a
product is *built*, not of how it is *packaged*.
Craig
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
Oliver,
If I sound irritated, I am. I don't really feel like being lectured
by you about how to be a team player and how the ASF works. If you
had something more to say, then just say it. There's no need to
attack me for wanting to bring the matter to conclusion when we have
99% consensus.
For once I agree with you .. further discussion of this topic is pointless.
sean
On 6/29/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
> Sean Schofield wrote:
>
> >Oliver,
> >
> >Everyone seemed to agree this was a good idea except for you. For the
> >record I simply stated that "I think we should consider the matter
> >closed." I did not say "The matter is closed." So that was an
> >opinion/suggestion, not an ultimatum.
> >
> >We could take a vote if you insist. In the past, we have tried to
> >avoid voting unless it was for a release issue or something major.
> >
> >Suggestion: Instead of complaining to me about wanting to reach a
> >conclusion, perhaps you could respond intelligently to the reasoning
> >cited by people in this thread.
> >
> >
> All right, so it gets personal again :-( I don't agree and therefore my
> reasoning is not intelligent. Ok, I take note of that and am very very
> sorry for being such a stupid.
>
> I still do not agree but also have no interest in this discussion
> anymore as it will lead to nothing. So I started a vote thread on the
> topic, you have my vote there, so go for it. I promise I will not bother
> you with my stupid opinions and unintelligent reasoning anymore.
>
> Live long and prosper,
> Oliver
>
> >sean
> >
> >On 6/29/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
> >
> >
> >>Sean,
> >>
> >>just a formal question: by which way did you get the power to end this
> >>discussion and to decide what has to happen? And in case there are
> >>divergent opinions on any topic in the future will it always be you who
> >>has the power to decide?
> >>
> >>You propose to follow the "formal and informal practices of the other
> >>projects" so please take yourself literally and do it the ASF way: start
> >>a formal vote on the topic.
> >>
> >>Oliver
> >>
> >>Sean Schofield wrote:
> >>
> >>
> >>
> >>>As for removing the jars from SVN, I think we should consider this
> >>>matter closed. Its a good idea for several reasons which Craig,
> >>>Martin and others have articulated quite clearly. Not only will this
> >>>save bandwith (and therefore money) for the ASF, but it brings us into
> >>>compliance with the standard by which other ASF projects do things.
> >>>
> >>>When possible, the various ASF projects should try to do things in a
> >>>similar fashion. Regardless of how one might decide to do things in
> >>>their corporate environment, ASF has its own way of doing things.
> >>>MyFaces should comply with the formal and informal practices of the
> >>>other projects whenever there is not a compelling reason to deviate
> >>>
> >>>
> >>>from those norms.
> >>
> >>
> >>>There is still the matter of including jars in the binary distro, etc.
> >>>where I can see advantages and disadvantages to the two approaches.
> >>>But as far as jars in SVN are concerned, it seems quite clear that
> >>>this practice should end.
> >>>
> >>>sean
> >>>
> >>>On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>And we're working on just such a list of the dependencies. That is
> >>>>one benefit of moving the jars out of SVN. I took the approach that
> >>>>the Struts build uses. The build script clearly lists the depencies
> >>>>and the version numbers required.
> >>>>
> >>>>Of course we could have that without removing the jars from SVN too.
> >>>>But its 100% essential if we don't supply the jars and so now we have
> >>>>it. Both sides should be happy on this point :-)
> >>>>
> >>>>sean
> >>>>
> >>>>On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>For the record, I am absolutely and totally -1 on including JAR files
> >>>>>>in the source code repository of any Apache project that I work on.
> >>>>>>Including them in a binary distribution, of course, is a totally
> >>>>>>different animal.
> >>>>>>
> >>>>>>Craig
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Even then. (see previous post). In my opinion (for as much as that of a
> >>>>>user counts), only end-user products should contain all dependencies.
> >>>>>Libraries should never, but instead list the dependencies with all
> >>>>>needed information, including what each dependency is needed for.
> >>>>>
> >>>>>
> >>>>>Met vriendelijke groeten,
> >>>>>
> >>>>>Jan Dockx
> >>>>>
> >>>>>PeopleWare NV - Head Office
> >>>>>Cdt.Weynsstraat 85
> >>>>>B-2660 Hoboken
> >>>>>Tel: +32 3 448.33.38
> >>>>>Fax: +32 3 448.32.66
> >>>>>
> >>>>>PeopleWare NV - Branch Office Geel
> >>>>>Kleinhoefstraat 5
> >>>>>B-2440 Geel
> >>>>>Tel: +32 14 57.00.90
> >>>>>Fax: +32 14 58.13.25
> >>>>>
> >>>>>http://www.peopleware.be/
> >>>>>http://www.mobileware.be/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>--
> >>Oliver Rossmueller
> >>Software Engineer and IT-Consultant
> >>Hamburg, Germany
> >>http://www.rossmueller.com
> >>
> >>
> >>
> >>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by Matt Blum <mb...@gmail.com>.
+1 from me, too.
-Matt
On 6/29/05, Sean Schofield <se...@gmail.com> wrote:
>
> [snip]
>
> > This thread is in itself an informal vote.
>
> Agreed.
>
> > If removing the jars from svn causes undue problems in the future we can
> always revert
> > back to including them.
>
> Exactly.
>
> > Lets get back to the business of improving Myfaces :-)
>
> +1
>
> > Grant
>
> sean
>
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Sean Schofield wrote:
>Oliver,
>
>Everyone seemed to agree this was a good idea except for you. For the
>record I simply stated that "I think we should consider the matter
>closed." I did not say "The matter is closed." So that was an
>opinion/suggestion, not an ultimatum.
>
>We could take a vote if you insist. In the past, we have tried to
>avoid voting unless it was for a release issue or something major.
>
>Suggestion: Instead of complaining to me about wanting to reach a
>conclusion, perhaps you could respond intelligently to the reasoning
>cited by people in this thread.
>
>
All right, so it gets personal again :-( I don't agree and therefore my
reasoning is not intelligent. Ok, I take note of that and am very very
sorry for being such a stupid.
I still do not agree but also have no interest in this discussion
anymore as it will lead to nothing. So I started a vote thread on the
topic, you have my vote there, so go for it. I promise I will not bother
you with my stupid opinions and unintelligent reasoning anymore.
Live long and prosper,
Oliver
>sean
>
>On 6/29/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
>
>
>>Sean,
>>
>>just a formal question: by which way did you get the power to end this
>>discussion and to decide what has to happen? And in case there are
>>divergent opinions on any topic in the future will it always be you who
>>has the power to decide?
>>
>>You propose to follow the "formal and informal practices of the other
>>projects" so please take yourself literally and do it the ASF way: start
>>a formal vote on the topic.
>>
>>Oliver
>>
>>Sean Schofield wrote:
>>
>>
>>
>>>As for removing the jars from SVN, I think we should consider this
>>>matter closed. Its a good idea for several reasons which Craig,
>>>Martin and others have articulated quite clearly. Not only will this
>>>save bandwith (and therefore money) for the ASF, but it brings us into
>>>compliance with the standard by which other ASF projects do things.
>>>
>>>When possible, the various ASF projects should try to do things in a
>>>similar fashion. Regardless of how one might decide to do things in
>>>their corporate environment, ASF has its own way of doing things.
>>>MyFaces should comply with the formal and informal practices of the
>>>other projects whenever there is not a compelling reason to deviate
>>>
>>>
>>>from those norms.
>>
>>
>>>There is still the matter of including jars in the binary distro, etc.
>>>where I can see advantages and disadvantages to the two approaches.
>>>But as far as jars in SVN are concerned, it seems quite clear that
>>>this practice should end.
>>>
>>>sean
>>>
>>>On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>>And we're working on just such a list of the dependencies. That is
>>>>one benefit of moving the jars out of SVN. I took the approach that
>>>>the Struts build uses. The build script clearly lists the depencies
>>>>and the version numbers required.
>>>>
>>>>Of course we could have that without removing the jars from SVN too.
>>>>But its 100% essential if we don't supply the jars and so now we have
>>>>it. Both sides should be happy on this point :-)
>>>>
>>>>sean
>>>>
>>>>On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>For the record, I am absolutely and totally -1 on including JAR files
>>>>>>in the source code repository of any Apache project that I work on.
>>>>>>Including them in a binary distribution, of course, is a totally
>>>>>>different animal.
>>>>>>
>>>>>>Craig
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Even then. (see previous post). In my opinion (for as much as that of a
>>>>>user counts), only end-user products should contain all dependencies.
>>>>>Libraries should never, but instead list the dependencies with all
>>>>>needed information, including what each dependency is needed for.
>>>>>
>>>>>
>>>>>Met vriendelijke groeten,
>>>>>
>>>>>Jan Dockx
>>>>>
>>>>>PeopleWare NV - Head Office
>>>>>Cdt.Weynsstraat 85
>>>>>B-2660 Hoboken
>>>>>Tel: +32 3 448.33.38
>>>>>Fax: +32 3 448.32.66
>>>>>
>>>>>PeopleWare NV - Branch Office Geel
>>>>>Kleinhoefstraat 5
>>>>>B-2440 Geel
>>>>>Tel: +32 14 57.00.90
>>>>>Fax: +32 14 58.13.25
>>>>>
>>>>>http://www.peopleware.be/
>>>>>http://www.mobileware.be/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>--
>>Oliver Rossmueller
>>Software Engineer and IT-Consultant
>>Hamburg, Germany
>>http://www.rossmueller.com
>>
>>
>>
>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
Oliver,
Everyone seemed to agree this was a good idea except for you. For the
record I simply stated that "I think we should consider the matter
closed." I did not say "The matter is closed." So that was an
opinion/suggestion, not an ultimatum.
We could take a vote if you insist. In the past, we have tried to
avoid voting unless it was for a release issue or something major.
Suggestion: Instead of complaining to me about wanting to reach a
conclusion, perhaps you could respond intelligently to the reasoning
cited by people in this thread.
sean
On 6/29/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
> Sean,
>
> just a formal question: by which way did you get the power to end this
> discussion and to decide what has to happen? And in case there are
> divergent opinions on any topic in the future will it always be you who
> has the power to decide?
>
> You propose to follow the "formal and informal practices of the other
> projects" so please take yourself literally and do it the ASF way: start
> a formal vote on the topic.
>
> Oliver
>
> Sean Schofield wrote:
>
> >As for removing the jars from SVN, I think we should consider this
> >matter closed. Its a good idea for several reasons which Craig,
> >Martin and others have articulated quite clearly. Not only will this
> >save bandwith (and therefore money) for the ASF, but it brings us into
> >compliance with the standard by which other ASF projects do things.
> >
> >When possible, the various ASF projects should try to do things in a
> >similar fashion. Regardless of how one might decide to do things in
> >their corporate environment, ASF has its own way of doing things.
> >MyFaces should comply with the formal and informal practices of the
> >other projects whenever there is not a compelling reason to deviate
> >from those norms.
> >
> >There is still the matter of including jars in the binary distro, etc.
> >where I can see advantages and disadvantages to the two approaches.
> >But as far as jars in SVN are concerned, it seems quite clear that
> >this practice should end.
> >
> >sean
> >
> >On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> >
> >
> >>And we're working on just such a list of the dependencies. That is
> >>one benefit of moving the jars out of SVN. I took the approach that
> >>the Struts build uses. The build script clearly lists the depencies
> >>and the version numbers required.
> >>
> >>Of course we could have that without removing the jars from SVN too.
> >>But its 100% essential if we don't supply the jars and so now we have
> >>it. Both sides should be happy on this point :-)
> >>
> >>sean
> >>
> >>On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> >>
> >>
> >>>On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
> >>>
> >>>
> >>>
> >>>>For the record, I am absolutely and totally -1 on including JAR files
> >>>>in the source code repository of any Apache project that I work on.
> >>>>Including them in a binary distribution, of course, is a totally
> >>>>different animal.
> >>>>
> >>>>Craig
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Even then. (see previous post). In my opinion (for as much as that of a
> >>>user counts), only end-user products should contain all dependencies.
> >>>Libraries should never, but instead list the dependencies with all
> >>>needed information, including what each dependency is needed for.
> >>>
> >>>
> >>>Met vriendelijke groeten,
> >>>
> >>>Jan Dockx
> >>>
> >>>PeopleWare NV - Head Office
> >>>Cdt.Weynsstraat 85
> >>>B-2660 Hoboken
> >>>Tel: +32 3 448.33.38
> >>>Fax: +32 3 448.32.66
> >>>
> >>>PeopleWare NV - Branch Office Geel
> >>>Kleinhoefstraat 5
> >>>B-2440 Geel
> >>>Tel: +32 14 57.00.90
> >>>Fax: +32 14 58.13.25
> >>>
> >>>http://www.peopleware.be/
> >>>http://www.mobileware.be/
> >>>
> >>>
> >>>
> >>>
> >>>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
[snip]
> This thread is in itself an informal vote.
Agreed.
> If removing the jars from svn causes undue problems in the future we can always revert
> back to including them.
Exactly.
> Lets get back to the business of improving Myfaces :-)
+1
> Grant
sean
Re: Proposal: Elimiante jar files from SVN
Posted by Ted Husted <te...@gmail.com>.
+1 for what Grant said.
Voting is what we do to approve a release, or, if we must, what we do
to resolve a dispute.
IMHO, this thread (like many MyFaces threads) has been a great example
of the ASF way. Everyone voiced their opinion, the group reached a
decision, and then someone actually did the work. (In truth, the only
decisions are the ones we commit.)
Someone still disagreed, and so called for a majority vote. That's
fine, but, for the record, outside of Jakarta, most ASF teams avoid
formal votes, unless it's to grade a release. The preferred path is to
reach decisions the way there were reached on this thread -- through
back-and-forth discussion.
-Ted.
On 6/29/05, Grant Smith <gr...@marathon-man.com> wrote:
> If I may interject before this gets too ugly...
>
> Oliver, the ASF does not require a formal vote on a matter such as this.
> The discussion in this thread clearly shows more people in favor of
> removing jars from svn. This thread is in itself an informal vote. You
> voiced your objections, and those objections I believe were taken into
> consideration.
>
> Sean has been EXTREMELY helpful and energetic in the Myfaces project and
> has demonstrated good judgment in the past. If removing the jars from
> svn causes undue problems in the future we can always revert back to
> including them.
>
> Lets get back to the business of improving Myfaces :-)
>
> Cheers,
> Grant
>
>
> Oliver Rossmueller wrote:
>
> >Sean,
> >
> >just a formal question: by which way did you get the power to end this
> >discussion and to decide what has to happen? And in case there are
> >divergent opinions on any topic in the future will it always be you who
> >has the power to decide?
> >
> >You propose to follow the "formal and informal practices of the other
> >projects" so please take yourself literally and do it the ASF way: start
> >a formal vote on the topic.
> >
> >Oliver
Re: Proposal: Elimiante jar files from SVN
Posted by Grant Smith <gr...@marathon-man.com>.
If I may interject before this gets too ugly...
Oliver, the ASF does not require a formal vote on a matter such as this.
The discussion in this thread clearly shows more people in favor of
removing jars from svn. This thread is in itself an informal vote. You
voiced your objections, and those objections I believe were taken into
consideration.
Sean has been EXTREMELY helpful and energetic in the Myfaces project and
has demonstrated good judgment in the past. If removing the jars from
svn causes undue problems in the future we can always revert back to
including them.
Lets get back to the business of improving Myfaces :-)
Cheers,
Grant
Oliver Rossmueller wrote:
>Sean,
>
>just a formal question: by which way did you get the power to end this
>discussion and to decide what has to happen? And in case there are
>divergent opinions on any topic in the future will it always be you who
>has the power to decide?
>
>You propose to follow the "formal and informal practices of the other
>projects" so please take yourself literally and do it the ASF way: start
>a formal vote on the topic.
>
>Oliver
>
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Sean,
just a formal question: by which way did you get the power to end this
discussion and to decide what has to happen? And in case there are
divergent opinions on any topic in the future will it always be you who
has the power to decide?
You propose to follow the "formal and informal practices of the other
projects" so please take yourself literally and do it the ASF way: start
a formal vote on the topic.
Oliver
Sean Schofield wrote:
>As for removing the jars from SVN, I think we should consider this
>matter closed. Its a good idea for several reasons which Craig,
>Martin and others have articulated quite clearly. Not only will this
>save bandwith (and therefore money) for the ASF, but it brings us into
>compliance with the standard by which other ASF projects do things.
>
>When possible, the various ASF projects should try to do things in a
>similar fashion. Regardless of how one might decide to do things in
>their corporate environment, ASF has its own way of doing things.
>MyFaces should comply with the formal and informal practices of the
>other projects whenever there is not a compelling reason to deviate
>from those norms.
>
>There is still the matter of including jars in the binary distro, etc.
>where I can see advantages and disadvantages to the two approaches.
>But as far as jars in SVN are concerned, it seems quite clear that
>this practice should end.
>
>sean
>
>On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
>
>
>>And we're working on just such a list of the dependencies. That is
>>one benefit of moving the jars out of SVN. I took the approach that
>>the Struts build uses. The build script clearly lists the depencies
>>and the version numbers required.
>>
>>Of course we could have that without removing the jars from SVN too.
>>But its 100% essential if we don't supply the jars and so now we have
>>it. Both sides should be happy on this point :-)
>>
>>sean
>>
>>On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>>
>>
>>>On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>>>
>>>
>>>
>>>>For the record, I am absolutely and totally -1 on including JAR files
>>>>in the source code repository of any Apache project that I work on.
>>>>Including them in a binary distribution, of course, is a totally
>>>>different animal.
>>>>
>>>>Craig
>>>>
>>>>
>>>>
>>>>
>>>Even then. (see previous post). In my opinion (for as much as that of a
>>>user counts), only end-user products should contain all dependencies.
>>>Libraries should never, but instead list the dependencies with all
>>>needed information, including what each dependency is needed for.
>>>
>>>
>>>Met vriendelijke groeten,
>>>
>>>Jan Dockx
>>>
>>>PeopleWare NV - Head Office
>>>Cdt.Weynsstraat 85
>>>B-2660 Hoboken
>>>Tel: +32 3 448.33.38
>>>Fax: +32 3 448.32.66
>>>
>>>PeopleWare NV - Branch Office Geel
>>>Kleinhoefstraat 5
>>>B-2440 Geel
>>>Tel: +32 14 57.00.90
>>>Fax: +32 14 58.13.25
>>>
>>>http://www.peopleware.be/
>>>http://www.mobileware.be/
>>>
>>>
>>>
>>>
>>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
Yes for the examples (include the dependencies). It is an end-user
product, a full web app.
From a library-user (i.e. developer) standpoint: don't include the
external jars in the binary distro.
1) It is a lot of bandwidth for stuff I have already.
2) It is a lot, in a project as wide as MyFaces.
3) It is confusing, at least if the jar's do not contain the exact
version number in the filename (maven-style).
4) You cannot include some jar's for license reasons (jsp api, e.g., I
seem to recall) anyway.
This also means that the extensive dependency documentation is needed
also outside the build script. Like in a POM.
On 27 Jun 2005, at 20:37, Bruno Aranda wrote:
> I do agree with all your points. The source distro should not include
> the jars. IMO, that distro is a snapshot of the sources as we can find
> them using SVN. No more, no less.
> I should include the dependencies in both the binary distro and in the
> examples.
> Either of the three possibilities allow to have a working myfaces
> distro. For the sources, you build them and download the dependencies
> using the script; for the binary, no build is needed and the
> dependencies are provided; and, of course, the examples should work
> out-of-the-box, and, if possible, provide versions of the examples for
> different configurations (different server version, etc...),
>
> Regards,
>
> Bruno
>
> 2005/6/27, Sean Schofield <se...@gmail.com>:
>> I've been thinking about the JAR files in the source distribution. To
>> me it makes no sense to include them in the source distro. (I don't
>> believe we have done that up to this point either so this would not be
>> a change for MyFaces.)
>>
>> If someone wants to build from the source distro they can follow the
>> standard build procedure. The depencies are only a few keystrokes
>> away using ant (or eventually Maven.)
>>
>> For the binary distro I guess I am +1 for including them there. You
>> can quickly copy the ones you need to your server/lib or whatever or
>> you can ignore them. No harm done either way. For the examples
>> distro (nightly build only) I think we definitely include them. IMO
>> those should be runable in a default Tomcat install just by dropping
>> in the WAR.
>>
>> sean
>>
>> On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
>>> As for removing the jars from SVN, I think we should consider this
>>> matter closed. Its a good idea for several reasons which Craig,
>>> Martin and others have articulated quite clearly. Not only will this
>>> save bandwith (and therefore money) for the ASF, but it brings us
>>> into
>>> compliance with the standard by which other ASF projects do things.
>>>
>>> When possible, the various ASF projects should try to do things in a
>>> similar fashion. Regardless of how one might decide to do things in
>>> their corporate environment, ASF has its own way of doing things.
>>> MyFaces should comply with the formal and informal practices of the
>>> other projects whenever there is not a compelling reason to deviate
>>> from those norms.
>>>
>>> There is still the matter of including jars in the binary distro,
>>> etc.
>>> where I can see advantages and disadvantages to the two approaches.
>>> But as far as jars in SVN are concerned, it seems quite clear that
>>> this practice should end.
>>>
>>> sean
>>>
>>> On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
>>>> And we're working on just such a list of the dependencies. That is
>>>> one benefit of moving the jars out of SVN. I took the approach that
>>>> the Struts build uses. The build script clearly lists the depencies
>>>> and the version numbers required.
>>>>
>>>> Of course we could have that without removing the jars from SVN too.
>>>> But its 100% essential if we don't supply the jars and so now we
>>>> have
>>>> it. Both sides should be happy on this point :-)
>>>>
>>>> sean
>>>>
>>>> On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>>>>>
>>>>> On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>>>>>
>>>>>>
>>>>>> For the record, I am absolutely and totally -1 on including JAR
>>>>>> files
>>>>>> in the source code repository of any Apache project that I work
>>>>>> on.
>>>>>> Including them in a binary distribution, of course, is a totally
>>>>>> different animal.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>
>>>>>
>>>>> Even then. (see previous post). In my opinion (for as much as that
>>>>> of a
>>>>> user counts), only end-user products should contain all
>>>>> dependencies.
>>>>> Libraries should never, but instead list the dependencies with all
>>>>> needed information, including what each dependency is needed for.
>>>>>
>>>>>
>>>>> Met vriendelijke groeten,
>>>>>
>>>>> Jan Dockx
>>>>>
>>>>> PeopleWare NV - Head Office
>>>>> Cdt.Weynsstraat 85
>>>>> B-2660 Hoboken
>>>>> Tel: +32 3 448.33.38
>>>>> Fax: +32 3 448.32.66
>>>>>
>>>>> PeopleWare NV - Branch Office Geel
>>>>> Kleinhoefstraat 5
>>>>> B-2440 Geel
>>>>> Tel: +32 14 57.00.90
>>>>> Fax: +32 14 58.13.25
>>>>>
>>>>> http://www.peopleware.be/
>>>>> http://www.mobileware.be/
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Proposal: Elimiante jar files from SVN
Posted by Bruno Aranda <br...@gmail.com>.
I do agree with all your points. The source distro should not include
the jars. IMO, that distro is a snapshot of the sources as we can find
them using SVN. No more, no less.
I should include the dependencies in both the binary distro and in the examples.
Either of the three possibilities allow to have a working myfaces
distro. For the sources, you build them and download the dependencies
using the script; for the binary, no build is needed and the
dependencies are provided; and, of course, the examples should work
out-of-the-box, and, if possible, provide versions of the examples for
different configurations (different server version, etc...),
Regards,
Bruno
2005/6/27, Sean Schofield <se...@gmail.com>:
> I've been thinking about the JAR files in the source distribution. To
> me it makes no sense to include them in the source distro. (I don't
> believe we have done that up to this point either so this would not be
> a change for MyFaces.)
>
> If someone wants to build from the source distro they can follow the
> standard build procedure. The depencies are only a few keystrokes
> away using ant (or eventually Maven.)
>
> For the binary distro I guess I am +1 for including them there. You
> can quickly copy the ones you need to your server/lib or whatever or
> you can ignore them. No harm done either way. For the examples
> distro (nightly build only) I think we definitely include them. IMO
> those should be runable in a default Tomcat install just by dropping
> in the WAR.
>
> sean
>
> On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> > As for removing the jars from SVN, I think we should consider this
> > matter closed. Its a good idea for several reasons which Craig,
> > Martin and others have articulated quite clearly. Not only will this
> > save bandwith (and therefore money) for the ASF, but it brings us into
> > compliance with the standard by which other ASF projects do things.
> >
> > When possible, the various ASF projects should try to do things in a
> > similar fashion. Regardless of how one might decide to do things in
> > their corporate environment, ASF has its own way of doing things.
> > MyFaces should comply with the formal and informal practices of the
> > other projects whenever there is not a compelling reason to deviate
> > from those norms.
> >
> > There is still the matter of including jars in the binary distro, etc.
> > where I can see advantages and disadvantages to the two approaches.
> > But as far as jars in SVN are concerned, it seems quite clear that
> > this practice should end.
> >
> > sean
> >
> > On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> > > And we're working on just such a list of the dependencies. That is
> > > one benefit of moving the jars out of SVN. I took the approach that
> > > the Struts build uses. The build script clearly lists the depencies
> > > and the version numbers required.
> > >
> > > Of course we could have that without removing the jars from SVN too.
> > > But its 100% essential if we don't supply the jars and so now we have
> > > it. Both sides should be happy on this point :-)
> > >
> > > sean
> > >
> > > On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> > > >
> > > > On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
> > > >
> > > > >
> > > > > For the record, I am absolutely and totally -1 on including JAR files
> > > > > in the source code repository of any Apache project that I work on.
> > > > > Including them in a binary distribution, of course, is a totally
> > > > > different animal.
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > >
> > > > Even then. (see previous post). In my opinion (for as much as that of a
> > > > user counts), only end-user products should contain all dependencies.
> > > > Libraries should never, but instead list the dependencies with all
> > > > needed information, including what each dependency is needed for.
> > > >
> > > >
> > > > Met vriendelijke groeten,
> > > >
> > > > Jan Dockx
> > > >
> > > > PeopleWare NV - Head Office
> > > > Cdt.Weynsstraat 85
> > > > B-2660 Hoboken
> > > > Tel: +32 3 448.33.38
> > > > Fax: +32 3 448.32.66
> > > >
> > > > PeopleWare NV - Branch Office Geel
> > > > Kleinhoefstraat 5
> > > > B-2440 Geel
> > > > Tel: +32 14 57.00.90
> > > > Fax: +32 14 58.13.25
> > > >
> > > > http://www.peopleware.be/
> > > > http://www.mobileware.be/
> > > >
> > > >
> > > >
> > >
> >
>
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
I've been thinking about the JAR files in the source distribution. To
me it makes no sense to include them in the source distro. (I don't
believe we have done that up to this point either so this would not be
a change for MyFaces.)
If someone wants to build from the source distro they can follow the
standard build procedure. The depencies are only a few keystrokes
away using ant (or eventually Maven.)
For the binary distro I guess I am +1 for including them there. You
can quickly copy the ones you need to your server/lib or whatever or
you can ignore them. No harm done either way. For the examples
distro (nightly build only) I think we definitely include them. IMO
those should be runable in a default Tomcat install just by dropping
in the WAR.
sean
On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> As for removing the jars from SVN, I think we should consider this
> matter closed. Its a good idea for several reasons which Craig,
> Martin and others have articulated quite clearly. Not only will this
> save bandwith (and therefore money) for the ASF, but it brings us into
> compliance with the standard by which other ASF projects do things.
>
> When possible, the various ASF projects should try to do things in a
> similar fashion. Regardless of how one might decide to do things in
> their corporate environment, ASF has its own way of doing things.
> MyFaces should comply with the formal and informal practices of the
> other projects whenever there is not a compelling reason to deviate
> from those norms.
>
> There is still the matter of including jars in the binary distro, etc.
> where I can see advantages and disadvantages to the two approaches.
> But as far as jars in SVN are concerned, it seems quite clear that
> this practice should end.
>
> sean
>
> On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> > And we're working on just such a list of the dependencies. That is
> > one benefit of moving the jars out of SVN. I took the approach that
> > the Struts build uses. The build script clearly lists the depencies
> > and the version numbers required.
> >
> > Of course we could have that without removing the jars from SVN too.
> > But its 100% essential if we don't supply the jars and so now we have
> > it. Both sides should be happy on this point :-)
> >
> > sean
> >
> > On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> > >
> > > On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
> > >
> > > >
> > > > For the record, I am absolutely and totally -1 on including JAR files
> > > > in the source code repository of any Apache project that I work on.
> > > > Including them in a binary distribution, of course, is a totally
> > > > different animal.
> > > >
> > > > Craig
> > > >
> > > >
> > >
> > > Even then. (see previous post). In my opinion (for as much as that of a
> > > user counts), only end-user products should contain all dependencies.
> > > Libraries should never, but instead list the dependencies with all
> > > needed information, including what each dependency is needed for.
> > >
> > >
> > > Met vriendelijke groeten,
> > >
> > > Jan Dockx
> > >
> > > PeopleWare NV - Head Office
> > > Cdt.Weynsstraat 85
> > > B-2660 Hoboken
> > > Tel: +32 3 448.33.38
> > > Fax: +32 3 448.32.66
> > >
> > > PeopleWare NV - Branch Office Geel
> > > Kleinhoefstraat 5
> > > B-2440 Geel
> > > Tel: +32 14 57.00.90
> > > Fax: +32 14 58.13.25
> > >
> > > http://www.peopleware.be/
> > > http://www.mobileware.be/
> > >
> > >
> > >
> >
>
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
As for removing the jars from SVN, I think we should consider this
matter closed. Its a good idea for several reasons which Craig,
Martin and others have articulated quite clearly. Not only will this
save bandwith (and therefore money) for the ASF, but it brings us into
compliance with the standard by which other ASF projects do things.
When possible, the various ASF projects should try to do things in a
similar fashion. Regardless of how one might decide to do things in
their corporate environment, ASF has its own way of doing things.
MyFaces should comply with the formal and informal practices of the
other projects whenever there is not a compelling reason to deviate
from those norms.
There is still the matter of including jars in the binary distro, etc.
where I can see advantages and disadvantages to the two approaches.
But as far as jars in SVN are concerned, it seems quite clear that
this practice should end.
sean
On 6/27/05, Sean Schofield <se...@gmail.com> wrote:
> And we're working on just such a list of the dependencies. That is
> one benefit of moving the jars out of SVN. I took the approach that
> the Struts build uses. The build script clearly lists the depencies
> and the version numbers required.
>
> Of course we could have that without removing the jars from SVN too.
> But its 100% essential if we don't supply the jars and so now we have
> it. Both sides should be happy on this point :-)
>
> sean
>
> On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> >
> > On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
> >
> > >
> > > For the record, I am absolutely and totally -1 on including JAR files
> > > in the source code repository of any Apache project that I work on.
> > > Including them in a binary distribution, of course, is a totally
> > > different animal.
> > >
> > > Craig
> > >
> > >
> >
> > Even then. (see previous post). In my opinion (for as much as that of a
> > user counts), only end-user products should contain all dependencies.
> > Libraries should never, but instead list the dependencies with all
> > needed information, including what each dependency is needed for.
> >
> >
> > Met vriendelijke groeten,
> >
> > Jan Dockx
> >
> > PeopleWare NV - Head Office
> > Cdt.Weynsstraat 85
> > B-2660 Hoboken
> > Tel: +32 3 448.33.38
> > Fax: +32 3 448.32.66
> >
> > PeopleWare NV - Branch Office Geel
> > Kleinhoefstraat 5
> > B-2440 Geel
> > Tel: +32 14 57.00.90
> > Fax: +32 14 58.13.25
> >
> > http://www.peopleware.be/
> > http://www.mobileware.be/
> >
> >
> >
>
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
And we're working on just such a list of the dependencies. That is
one benefit of moving the jars out of SVN. I took the approach that
the Struts build uses. The build script clearly lists the depencies
and the version numbers required.
Of course we could have that without removing the jars from SVN too.
But its 100% essential if we don't supply the jars and so now we have
it. Both sides should be happy on this point :-)
sean
On 6/27/05, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>
> On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>
> >
> > For the record, I am absolutely and totally -1 on including JAR files
> > in the source code repository of any Apache project that I work on.
> > Including them in a binary distribution, of course, is a totally
> > different animal.
> >
> > Craig
> >
> >
>
> Even then. (see previous post). In my opinion (for as much as that of a
> user counts), only end-user products should contain all dependencies.
> Libraries should never, but instead list the dependencies with all
> needed information, including what each dependency is needed for.
>
>
> Met vriendelijke groeten,
>
> Jan Dockx
>
> PeopleWare NV - Head Office
> Cdt.Weynsstraat 85
> B-2660 Hoboken
> Tel: +32 3 448.33.38
> Fax: +32 3 448.32.66
>
> PeopleWare NV - Branch Office Geel
> Kleinhoefstraat 5
> B-2440 Geel
> Tel: +32 14 57.00.90
> Fax: +32 14 58.13.25
>
> http://www.peopleware.be/
> http://www.mobileware.be/
>
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
On 25 Jun 2005, at 20:43, Craig McClanahan wrote:
>
> For the record, I am absolutely and totally -1 on including JAR files
> in the source code repository of any Apache project that I work on.
> Including them in a binary distribution, of course, is a totally
> different animal.
>
> Craig
>
>
Even then. (see previous post). In my opinion (for as much as that of a
user counts), only end-user products should contain all dependencies.
Libraries should never, but instead list the dependencies with all
needed information, including what each dependency is needed for.
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Proposal: Elimiante jar files from SVN
Posted by Bruno Aranda <br...@gmail.com>.
Mmh, maybe my position has not been well understood due to my limited
english as I think we are holding a similar opinion. I am AGAINST
having the jars in the SVN. You should download the jars *only* when
you need them (and almost always you already have that jar in your HD
so there isn't the necessity to download it again). I agree in the
point that is extremely important that all dependencies are well
documented (all dependencies and everything regarding the build
process). In the case you don't have the jar already and you must
download the it, you might have many ways: by hand, using the build
script, from the dependent project sites, ibiblio... wherever. This is
why I talked of a *shared* bandwith, as the bandwidth that correspond
to the download (only if needed) of that jars is *shared* among
diferent servers.
I am always talking of the code in the SVN. Of course that release
code might include the dependencies (as long as their license allows
that)...
I hope that my thoughts are clearer now,
Regards,
Bruno
2005/6/27, Craig McClanahan <cr...@gmail.com>:
> On 6/26/05, Bruno Aranda <br...@gmail.com> wrote:
> > And, returning to the developer POV, you might want the sources for two things:
> >
> > 1. Take a glance to the code to see how something is implemented.
> > 2. Develop and/or build from sources.
> >
> > IMO, for both cases is easier to download the jars using the script.
> > Probably, for #1 jars are not essential, so the checkout is faster and
> > you can get to the code sooner. If you want to do #2, you will have to
> > execute the build.xml file, so it is acceptable to download the
> > dependencies at this stage. I only see one disadvantage (and many
> > advantages) in this approach: you need to execute the build.xml being
> > online, at least the first time.
> >
> > By the way, bandwith would be divided between the source repository
> > (ASF) and the binary repository (Ibiblio or similar). It is obvious
> > than, as Craig pointed, in the jars-in-SVN approach Apache might have
> > many copies of the same commons-whathever lib (one or more for every
> > project, the same version or a different one), while the binary
> > repository would contain only one per version.
> >
>
> You so *totally* don't get it.
>
> If the JAR files are checked in to the CVS or SVN repository, then
> ***100%*** of the bandwith costs for downloading those binary JARs
> goes to the Apache Software Foundation, because doing a "cvs update"
> or "svn update" to update your source repository will *always*
> download the copy in the source repository (i.e. using ASF's
> bandwidth). There is no opportunity for the bandwidth costs to be
> shared, because nobody downloading from the source repository will
> ever be redirected to a mirror (where the bandwidth charges might be
> redirected).
>
> The technical and process reasons for not putting generated artifacts
> into source repositories are still relevant (which, independent of the
> cost issue, are sufficient to argue against such a practice) ... but
> what you are proposing is that the ASF should pay for ***you*** (who
> are checking out sources, presumably because you want to work on them)
> can be lazy. I'm not at ***all*** sympathetic -- I want the money
> that is contributed to ASF's bandwidth to go towards supporting
> ***users*** of the software being downloaded.
>
> Interestingly, this is a place where the ASF culture of meritocracy
> plays a positive role ... if you can't figure out what dependencies
> you need to download separately, in order to compile the source, then
> there is either a problem with the documentation for that project's
> build environment, or laziness on the part of the developer in
> following the provided instructions. If you won't even read the
> directions, then the problem is definitely in your court :-). If you
> read them but don't like them, then maybe the world doesn't really
> need whatever contributions you might have made to the world had you
> been able to compile that particular project.
>
> NOTE -- most open source releases include a pointer to the
> corresponding source distributions (or the source is embedded in a
> binary release), which users can load into the relevant IDEs they are
> using (to provide code completion and/or javadocs). In addition, the
> relevant ASF binary release packages we are talking about generally
> include all the corresponding binary dependencies (unless there are
> license related issues), so this thread ends up being totally about
> developers who want to download the raw source code from the
> appropriate CVS or SVN repository -- if that's you, then please get
> used to downloading your own dependencies (or cajoling the committers
> on the project in question to providing some easy mechanism to do
> this).
>
> Craig
>
Re: Proposal: Elimiante jar files from SVN
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/26/05, Bruno Aranda <br...@gmail.com> wrote:
> And, returning to the developer POV, you might want the sources for two things:
>
> 1. Take a glance to the code to see how something is implemented.
> 2. Develop and/or build from sources.
>
> IMO, for both cases is easier to download the jars using the script.
> Probably, for #1 jars are not essential, so the checkout is faster and
> you can get to the code sooner. If you want to do #2, you will have to
> execute the build.xml file, so it is acceptable to download the
> dependencies at this stage. I only see one disadvantage (and many
> advantages) in this approach: you need to execute the build.xml being
> online, at least the first time.
>
> By the way, bandwith would be divided between the source repository
> (ASF) and the binary repository (Ibiblio or similar). It is obvious
> than, as Craig pointed, in the jars-in-SVN approach Apache might have
> many copies of the same commons-whathever lib (one or more for every
> project, the same version or a different one), while the binary
> repository would contain only one per version.
>
You so *totally* don't get it.
If the JAR files are checked in to the CVS or SVN repository, then
***100%*** of the bandwith costs for downloading those binary JARs
goes to the Apache Software Foundation, because doing a "cvs update"
or "svn update" to update your source repository will *always*
download the copy in the source repository (i.e. using ASF's
bandwidth). There is no opportunity for the bandwidth costs to be
shared, because nobody downloading from the source repository will
ever be redirected to a mirror (where the bandwidth charges might be
redirected).
The technical and process reasons for not putting generated artifacts
into source repositories are still relevant (which, independent of the
cost issue, are sufficient to argue against such a practice) ... but
what you are proposing is that the ASF should pay for ***you*** (who
are checking out sources, presumably because you want to work on them)
can be lazy. I'm not at ***all*** sympathetic -- I want the money
that is contributed to ASF's bandwidth to go towards supporting
***users*** of the software being downloaded.
Interestingly, this is a place where the ASF culture of meritocracy
plays a positive role ... if you can't figure out what dependencies
you need to download separately, in order to compile the source, then
there is either a problem with the documentation for that project's
build environment, or laziness on the part of the developer in
following the provided instructions. If you won't even read the
directions, then the problem is definitely in your court :-). If you
read them but don't like them, then maybe the world doesn't really
need whatever contributions you might have made to the world had you
been able to compile that particular project.
NOTE -- most open source releases include a pointer to the
corresponding source distributions (or the source is embedded in a
binary release), which users can load into the relevant IDEs they are
using (to provide code completion and/or javadocs). In addition, the
relevant ASF binary release packages we are talking about generally
include all the corresponding binary dependencies (unless there are
license related issues), so this thread ends up being totally about
developers who want to download the raw source code from the
appropriate CVS or SVN repository -- if that's you, then please get
used to downloading your own dependencies (or cajoling the committers
on the project in question to providing some easy mechanism to do
this).
Craig
Re: Proposal: Elimiante jar files from SVN
Posted by Bruno Aranda <br...@gmail.com>.
And, returning to the developer POV, you might want the sources for two things:
1. Take a glance to the code to see how something is implemented.
2. Develop and/or build from sources.
IMO, for both cases is easier to download the jars using the script.
Probably, for #1 jars are not essential, so the checkout is faster and
you can get to the code sooner. If you want to do #2, you will have to
execute the build.xml file, so it is acceptable to download the
dependencies at this stage. I only see one disadvantage (and many
advantages) in this approach: you need to execute the build.xml being
online, at least the first time.
By the way, bandwith would be divided between the source repository
(ASF) and the binary repository (Ibiblio or similar). It is obvious
than, as Craig pointed, in the jars-in-SVN approach Apache might have
many copies of the same commons-whathever lib (one or more for every
project, the same version or a different one), while the binary
repository would contain only one per version.
Regards,
Bruno
2005/6/27, Craig McClanahan <cr...@gmail.com>:
> On 6/26/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
> > Craig McClanahan wrote:
> >
> > >On 6/24/05, James Mitchell <jm...@apache.org> wrote:
> > >
> > >
> > >>----- Original Message -----
> > >>Wrom: SZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMN
> > >>To: "MyFaces Development" <de...@myfaces.apache.org>
> > >>Sent: Friday, June 24, 2005 10:08 PM
> > >>Subject: Re: Proposal: Elimiante jar files from SVN
> > >>
> > >>
> > >>
> > >>
> > >>>James Mitchell wrote:
> > >>>
> > >>>
> > >>>
> > >>>>Unless I missed it somewhere, no one has mentioned the extra bloat in
> > >>>>your source distributions (if you include the binary dependencies).
> > >>>>
> > >>>>
> > >>>James,
> > >>>
> > >>>you need the binary dependencies anyway to build the project, so what is
> > >>>your point? You download the source distribution with libs included or
> > >>>you download the source distribution without libs and ant does the lib
> > >>>download afterwards. The sum of required network traffic is the same.
> > >>>
> > >>>
> > >>>
> > >>That's true for the developer. But I was also considering ASF hardware and
> > >>bandwidth. Again, that's a drop in the bucket if only MyFaces were doing
> > >>it. But you are not. I have had this same conversation (beating the same
> > >>dead horse) with developers on other projects, both here, sf.net, and many,
> > >>MANY closed source projects.
> > >>
> > >>
> > >
> > >To reinforce this point, even though *you* (someone downloading the
> > >CVS or SVN sources of a project) does not pay for the network
> > >bandwidth, the ASF *does* pay for it. I'd rather see that money
> > >supporting more users, rather than downloading zillions of copies of
> > >the same JAR files.
> > >
> > >
> > Craig,
> >
> > just for the record: my ISP does not give me internet access for free so
> > of course I'm paying for the network bandwidth, too. But that's not the
> > main topic. What's the topic is that I can't see the difference between
> >
> > - check out the required libraries together with the project sources
> > from SVN
> >
> > and
> >
> > - check out the project sources without required libraries from SVN and
> > afterwards call an ant target to download the required libs from some
> > apache jar repository.
> >
> > If you ask me the difference in network traffic between the two
> > scnearios is close to zero as the required jars have to be transfered to
> > my local hard disk anyway, so what's your point?
> >
>
> The point is very simple ... who is paying for it?
>
> In the "checked into the repository" case, it is *always* Apache that
> is paying for it, because access to the repository servers is not
> mirrored. In the "get it from some binary repository" case, the vast
> majority of the time you will be getting it from some site that is
> themselves donating bandwidth to support Apache (by being a mirror),
> but the costs are not borne by the Apache Software Foundation
> directly.
>
> > And if I'm informed correctly in case a new version of a required lib is
> > needed SVN is even more efficent than the solution you propose: SVN will
> > just transfer the diffs between the two binaries like rsync does, but
> > with your solution ant has to download the complete jar.
> >
> > By the way, discussing ASF's infrastructure costs will lead to nothing,
> > don't you think?
>
> If you believe that, we have nothing further to talk about, so I'll
> just delete the rest of your message and reply now.
>
> Craig
>
Re: Proposal: Elimiante jar files from SVN
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/26/05, Oliver Rossmueller <ol...@tuxerra.com> wrote:
> Craig McClanahan wrote:
>
> >On 6/24/05, James Mitchell <jm...@apache.org> wrote:
> >
> >
> >>----- Original Message -----
> >>Wrom: SZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMN
> >>To: "MyFaces Development" <de...@myfaces.apache.org>
> >>Sent: Friday, June 24, 2005 10:08 PM
> >>Subject: Re: Proposal: Elimiante jar files from SVN
> >>
> >>
> >>
> >>
> >>>James Mitchell wrote:
> >>>
> >>>
> >>>
> >>>>Unless I missed it somewhere, no one has mentioned the extra bloat in
> >>>>your source distributions (if you include the binary dependencies).
> >>>>
> >>>>
> >>>James,
> >>>
> >>>you need the binary dependencies anyway to build the project, so what is
> >>>your point? You download the source distribution with libs included or
> >>>you download the source distribution without libs and ant does the lib
> >>>download afterwards. The sum of required network traffic is the same.
> >>>
> >>>
> >>>
> >>That's true for the developer. But I was also considering ASF hardware and
> >>bandwidth. Again, that's a drop in the bucket if only MyFaces were doing
> >>it. But you are not. I have had this same conversation (beating the same
> >>dead horse) with developers on other projects, both here, sf.net, and many,
> >>MANY closed source projects.
> >>
> >>
> >
> >To reinforce this point, even though *you* (someone downloading the
> >CVS or SVN sources of a project) does not pay for the network
> >bandwidth, the ASF *does* pay for it. I'd rather see that money
> >supporting more users, rather than downloading zillions of copies of
> >the same JAR files.
> >
> >
> Craig,
>
> just for the record: my ISP does not give me internet access for free so
> of course I'm paying for the network bandwidth, too. But that's not the
> main topic. What's the topic is that I can't see the difference between
>
> - check out the required libraries together with the project sources
> from SVN
>
> and
>
> - check out the project sources without required libraries from SVN and
> afterwards call an ant target to download the required libs from some
> apache jar repository.
>
> If you ask me the difference in network traffic between the two
> scnearios is close to zero as the required jars have to be transfered to
> my local hard disk anyway, so what's your point?
>
The point is very simple ... who is paying for it?
In the "checked into the repository" case, it is *always* Apache that
is paying for it, because access to the repository servers is not
mirrored. In the "get it from some binary repository" case, the vast
majority of the time you will be getting it from some site that is
themselves donating bandwidth to support Apache (by being a mirror),
but the costs are not borne by the Apache Software Foundation
directly.
> And if I'm informed correctly in case a new version of a required lib is
> needed SVN is even more efficent than the solution you propose: SVN will
> just transfer the diffs between the two binaries like rsync does, but
> with your solution ant has to download the complete jar.
>
> By the way, discussing ASF's infrastructure costs will lead to nothing,
> don't you think?
If you believe that, we have nothing further to talk about, so I'll
just delete the rest of your message and reply now.
Craig
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Craig McClanahan wrote:
>On 6/24/05, James Mitchell <jm...@apache.org> wrote:
>
>
>>----- Original Message -----
>>Wrom: SZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMN
>>To: "MyFaces Development" <de...@myfaces.apache.org>
>>Sent: Friday, June 24, 2005 10:08 PM
>>Subject: Re: Proposal: Elimiante jar files from SVN
>>
>>
>>
>>
>>>James Mitchell wrote:
>>>
>>>
>>>
>>>>Unless I missed it somewhere, no one has mentioned the extra bloat in
>>>>your source distributions (if you include the binary dependencies).
>>>>
>>>>
>>>James,
>>>
>>>you need the binary dependencies anyway to build the project, so what is
>>>your point? You download the source distribution with libs included or
>>>you download the source distribution without libs and ant does the lib
>>>download afterwards. The sum of required network traffic is the same.
>>>
>>>
>>>
>>That's true for the developer. But I was also considering ASF hardware and
>>bandwidth. Again, that's a drop in the bucket if only MyFaces were doing
>>it. But you are not. I have had this same conversation (beating the same
>>dead horse) with developers on other projects, both here, sf.net, and many,
>>MANY closed source projects.
>>
>>
>
>To reinforce this point, even though *you* (someone downloading the
>CVS or SVN sources of a project) does not pay for the network
>bandwidth, the ASF *does* pay for it. I'd rather see that money
>supporting more users, rather than downloading zillions of copies of
>the same JAR files.
>
>
Craig,
just for the record: my ISP does not give me internet access for free so
of course I'm paying for the network bandwidth, too. But that's not the
main topic. What's the topic is that I can't see the difference between
- check out the required libraries together with the project sources
from SVN
and
- check out the project sources without required libraries from SVN and
afterwards call an ant target to download the required libs from some
apache jar repository.
If you ask me the difference in network traffic between the two
scnearios is close to zero as the required jars have to be transfered to
my local hard disk anyway, so what's your point?
And if I'm informed correctly in case a new version of a required lib is
needed SVN is even more efficent than the solution you propose: SVN will
just transfer the diffs between the two binaries like rsync does, but
with your solution ant has to download the complete jar.
By the way, discussing ASF's infrastructure costs will lead to nothing,
don't you think? Of course ASF provides the infrastructure and - thanks
to financial donations - pays for it. I'm thankful for that as I'm
thankful to VA Software and OSTG for providing the services of
sourceforge.net and as I'm thankful to anyone else providing similar
services to the open souce community. But from my POV that's the reason
d'etre of ASF: to provide infrastructure for open-source projects. To
quote from http://www.apache.org/foundation/contributing.html:
"The Apache Software Foundation is committed to providing free access to
all interested participants. All of our code is distributed under the
Apache Software License <http://www.apache.org/LICENSE.txt>, an
OSI-approved license <http://www.opensource.org/licenses/>. The project
mailing lists are all open to the public and contributors are usually
welcomed with open arms.
So, there is no cost required to contribute code to the projects.
However, there is usually a substantial time committment that is
required in order to contribute to a project. For some, time is cheaper
than money. For others, money is cheaper than time (lucky you). We
realize that, and want to promote contributions from everyone - no
matter the form."
My point is: we, the developers, contribute our time and ASF provides
the infrastructure by collecting donations in whatever form. It's giving
and taking. If you like I pay for the infrastructure by contributing
development time. So, please, don't argue I have to take care for
network costs by "optimizing" the build process and SVN usage in the way
you propose.
What's funny is that besides infrastructure costs obvioiusly nobody can
show me the problem in the MyFaces build that will be solved by
downloading the libs from some external source. This should be the core
of the discussion and from my POV your proposal just introduces
potential new problems which are not there at the moment and therefore
I'm absolutely against this.
Oliver
>For the record, I am absolutely and totally -1 on including JAR files
>in the source code repository of any Apache project that I work on.
>Including them in a binary distribution, of course, is a totally
>different animal.
>
>Craig
>
>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by "ir.ing.Jan Dockx" <ja...@mac.com>.
On 26 Jun 2005, at 19:44, Craig McClanahan wrote:
> On 6/26/05, Sean Schofield <se...@gmail.com> wrote:
>> Craig,
>>
>> What are your thoughts on including them in a binary distribution?
>> What is Struts doing these days?
>
> Including the dependent jars in a binary distribution (assuming
> license compatibility) is definitely a reasonable thing to do. That
> way, the end user who downloads your binary distribution has an "all
> in one" release that is self contained. This is how Struts releases
> are packaged.
From a user perspective, if I may, this is kinda annoying. We develop
code ourselves too, you know ;-), and have our own dependencies. This
may come as a surprise ;-), but we also tend to use bean-utils, and
the likes (and maybe the versions differ). Just a bunch of jars that
come with the binary distro is actually very complex to sort out from
our point of view.
What really helps the users, is a clean description of the
dependencies: which lib, which version (i.e., which version did the
developers test with, might work with higher versions), where can I
find it (if possible, automated), and also, what is it needed for
(runtime? compile? only for 1 component?).
Guess what? Other projects have had this problem too. And maven solves
it to a large degree.
Ugh.
>
> Craig
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
> One potential caveat here is that you'll have a set of the JARs in the
> WEB-INF directory of every such example ... that can be solved by
> providing a post-install script that can assemble runnable WARs for
> the examples from a single included copy of each jar.
Interesting idea.
> No, that one makes sense. What doesn't make sense is to have hundreds
> of copies of commons-beanutils.jar (or whatever) spread throughout the
> source repository.
Agreed.
> (Note that I would make the same sort of argument against checking in
> *any* generated artifacts, including Javadocs ... :-).
Agreed. We currently use SVN to update the website (including
javadoc.) My notion is that we should use Maven or some alternative
publishing mechnasim for that. I agree that this stuff in SVN causes
too many headaches.
> Craig
sean
Re: Proposal: Elimiante jar files from SVN
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/26/05, Sean Schofield <se...@gmail.com> wrote:
> Craig,
>
> What are your thoughts on including them in a binary distribution?
> What is Struts doing these days?
Including the dependent jars in a binary distribution (assuming
license compatibility) is definitely a reasonable thing to do. That
way, the end user who downloads your binary distribution has an "all
in one" release that is self contained. This is how Struts releases
are packaged.
>
> I think for our example web applications its nice to include them (so
> you can just drop in the WAR file and go.)
One potential caveat here is that you'll have a set of the JARs in the
WEB-INF directory of every such example ... that can be solved by
providing a post-install script that can assemble runnable WARs for
the examples from a single included copy of each jar.
> I'm not so sure for the
> binary distributions. Currently we include the jars in the binary
> distribution but maybe it makes sense not to do that either.
>
No, that one makes sense. What doesn't make sense is to have hundreds
of copies of commons-beanutils.jar (or whatever) spread throughout the
source repository.
(Note that I would make the same sort of argument against checking in
*any* generated artifacts, including Javadocs ... :-).
> sean
Craig
Re: Proposal: Elimiante jar files from SVN
Posted by Sean Schofield <se...@gmail.com>.
Craig,
What are your thoughts on including them in a binary distribution?
What is Struts doing these days?
I think for our example web applications its nice to include them (so
you can just drop in the WAR file and go.) I'm not so sure for the
binary distributions. Currently we include the jars in the binary
distribution but maybe it makes sense not to do that either.
sean
On 6/25/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 6/24/05, James Mitchell <jm...@apache.org> wrote:
> > ----- Original Message -----
> > Wrom: SZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMN
> > To: "MyFaces Development" <de...@myfaces.apache.org>
> > Sent: Friday, June 24, 2005 10:08 PM
> > Subject: Re: Proposal: Elimiante jar files from SVN
> >
> >
> > > James Mitchell wrote:
> > >
> > >> Unless I missed it somewhere, no one has mentioned the extra bloat in
> > >> your source distributions (if you include the binary dependencies).
> > >
> > > James,
> > >
> > > you need the binary dependencies anyway to build the project, so what is
> > > your point? You download the source distribution with libs included or
> > > you download the source distribution without libs and ant does the lib
> > > download afterwards. The sum of required network traffic is the same.
> > >
> >
> > That's true for the developer. But I was also considering ASF hardware and
> > bandwidth. Again, that's a drop in the bucket if only MyFaces were doing
> > it. But you are not. I have had this same conversation (beating the same
> > dead horse) with developers on other projects, both here, sf.net, and many,
> > MANY closed source projects.
>
> To reinforce this point, even though *you* (someone downloading the
> CVS or SVN sources of a project) does not pay for the network
> bandwidth, the ASF *does* pay for it. I'd rather see that money
> supporting more users, rather than downloading zillions of copies of
> the same JAR files.
>
> For the record, I am absolutely and totally -1 on including JAR files
> in the source code repository of any Apache project that I work on.
> Including them in a binary distribution, of course, is a totally
> different animal.
>
> Craig
>
Re: Proposal: Elimiante jar files from SVN
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/24/05, James Mitchell <jm...@apache.org> wrote:
> ----- Original Message -----
> Wrom: SZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMN
> To: "MyFaces Development" <de...@myfaces.apache.org>
> Sent: Friday, June 24, 2005 10:08 PM
> Subject: Re: Proposal: Elimiante jar files from SVN
>
>
> > James Mitchell wrote:
> >
> >> Unless I missed it somewhere, no one has mentioned the extra bloat in
> >> your source distributions (if you include the binary dependencies).
> >
> > James,
> >
> > you need the binary dependencies anyway to build the project, so what is
> > your point? You download the source distribution with libs included or
> > you download the source distribution without libs and ant does the lib
> > download afterwards. The sum of required network traffic is the same.
> >
>
> That's true for the developer. But I was also considering ASF hardware and
> bandwidth. Again, that's a drop in the bucket if only MyFaces were doing
> it. But you are not. I have had this same conversation (beating the same
> dead horse) with developers on other projects, both here, sf.net, and many,
> MANY closed source projects.
To reinforce this point, even though *you* (someone downloading the
CVS or SVN sources of a project) does not pay for the network
bandwidth, the ASF *does* pay for it. I'd rather see that money
supporting more users, rather than downloading zillions of copies of
the same JAR files.
For the record, I am absolutely and totally -1 on including JAR files
in the source code repository of any Apache project that I work on.
Including them in a binary distribution, of course, is a totally
different animal.
Craig
Re: Proposal: Elimiante jar files from SVN
Posted by James Mitchell <jm...@apache.org>.
----- Original Message -----
From: "Oliver Rossmueller" <ol...@tuxerra.com>
To: "MyFaces Development" <de...@myfaces.apache.org>
Sent: Friday, June 24, 2005 10:08 PM
Subject: Re: Proposal: Elimiante jar files from SVN
> James Mitchell wrote:
>
>> Unless I missed it somewhere, no one has mentioned the extra bloat in
>> your source distributions (if you include the binary dependencies).
>
> James,
>
> you need the binary dependencies anyway to build the project, so what is
> your point? You download the source distribution with libs included or
> you download the source distribution without libs and ant does the lib
> download afterwards. The sum of required network traffic is the same.
>
That's true for the developer. But I was also considering ASF hardware and
bandwidth. Again, that's a drop in the bucket if only MyFaces were doing
it. But you are not. I have had this same conversation (beating the same
dead horse) with developers on other projects, both here, sf.net, and many,
MANY closed source projects.
>>
>> Oliver, I'm having a hard time understanding your point.
>>
>> I can see how one wouldn't care about disk space and bandwidth,
>> because you (nor I) currently pay for neither. But how much more
>> "simple" can building a project be then calling "ant". That's all you
>> should have to do to build the project.
>>
>> Please explain to me what makes it "not simple" if the ant script
>> automatically goes out and gets the dependencies the first time you
>> run the script (and never has to do it again unless a dependency is
>> added or changed) ??
>
> It get's "not simple" as soon as the automatic download fails for
> whatever reason. I had problems in the past with maven-based builds
> because the attempt to download required libs ended up in corrupt jars
> in the local repository because ibiblio was not available and all the
> downloaded jars actually were http 404/500 error pages. The result is a
> long list of strange error messages talking about corrupt zip files and
> stuff like that. What you plan to do with ant is just another way to the
> same potential problem.
I'm not sure why you keep talking about corrupt binaries. This is not even
a valid case. At least not with any of the last 5 versions of Ant that I
have used.
Let me explain:
<?xml version="1.0"?>
<project name="Test build" default="test">
<target name="test">
<echo>Getting the correct JAR </echo>
<get dest="commons-beanutils.jar"
usetimestamp="true" ignoreerrors="true"
src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0.jar"/> <echo>Attempt to get an invalid JAR (with ignoreerrors=true)</echo> <get dest="commons-beanutils-8.jar" usetimestamp="true" ignoreerrors="true" src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar"/> <echo>Attempt to get an invalid JAR (with ignoreerrors=false)</echo> <get dest="commons-beanutils-9.jar" usetimestamp="true" ignoreerrors="false" src="http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar"/> </target></project>Ok, so here's what I get when I run this...---------------------------------------------------------jmitchell@compaq ~/test$ lsbuild.xmljmitchell@compaq ~/test$ antBuildfile: build.xmltest: [echo] Getting the correct JAR [get] Getting:http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0.jar [get] To: C:\cygwin\home\jmitchell\test
\commons-beanutils.jar [echo] Attempt to get an invalid JAR (with ignoreerrors=true) [get] Getting:http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar [get] To: C:\cygwin\home\jmitchell\test\commons-beanutils-8.jar [get] Error opening connection java.io.IOException [get] Error opening connection java.io.IOException [get] Error opening connection java.io.IOException [get] Can't gethttp://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar toC:\cygwin\home\jmitchell\test\commons-beanutils-8.jar [echo] Attempt to get an invalid JAR (with ignoreerrors=false) [get] Getting:http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar [get] To: C:\cygwin\home\jmitchell\test\commons-beanutils-9.jar [get] Error opening connection java.io.IOException [get] Error opening connection java.io.IOException [get]
Error opening connection java.io.IOException [get] Can't gethttp://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar toC:\cygwin\home\jmitchell\test\commons-beanutils-9.jarBUILD FAILEDC:\cygwin\home\jmitchell\test\build.xml:19: Can't gethttp://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.7.0-(does-not-exist).jar toC:\cygwin\home\jmitchell\test\commons-beanutils-9.jarTotal time: 4 secondsjmitchell@compaq ~/test$ lsbuild.xml commons-beanutils.jar--------------------------------------------------------Notice there are no corrupted JARs, just a nice clean message as to what Antwas trying to do, but couldn't.>> I'm sure you are able to deal with problems like that. If you know the> build mechanism it won't be a big deal. But there will always be users> who checkout the MyFaces sources for the first time. Consider they want> to get a fix before the next release is out. If automatic download does> not work for them
- I don't say this will happen every day, but it's a> possible scenario - they are stuck. They just called ant, they don't> know and don't want to know what's going on behind the scenes. What they> want is a working MyFaces built from sources.Why do you continue to make this assumption that someone is smart enough tobe able to download and configure both SVN and Ant, and checkout theproject, yet so dumb that they would "throw it in the trash" on the firsterror. That's not making a lot of sense to me. That's why we have a userslist, and forums, and books, and many articles and blogs about the same.--James MitchellSoftware Engineer / Open Source EvangelistConsulting / Mentoring / FreelanceEdgeTech, Inc.http://www.edgetechservices.net/678.910.8017AIM: jmitchtxYahoo: jmitchtxMSN: jmitchell@apache.orgSkype: jmitchtx
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
James Mitchell wrote:
> Unless I missed it somewhere, no one has mentioned the extra bloat in
> your source distributions (if you include the binary dependencies).
James,
you need the binary dependencies anyway to build the project, so what is
your point? You download the source distribution with libs included or
you download the source distribution without libs and ant does the lib
download afterwards. The sum of required network traffic is the same.
>
> Oliver, I'm having a hard time understanding your point.
>
> I can see how one wouldn't care about disk space and bandwidth,
> because you (nor I) currently pay for neither. But how much more
> "simple" can building a project be then calling "ant". That's all you
> should have to do to build the project.
>
> Please explain to me what makes it "not simple" if the ant script
> automatically goes out and gets the dependencies the first time you
> run the script (and never has to do it again unless a dependency is
> added or changed) ??
It get's "not simple" as soon as the automatic download fails for
whatever reason. I had problems in the past with maven-based builds
because the attempt to download required libs ended up in corrupt jars
in the local repository because ibiblio was not available and all the
downloaded jars actually were http 404/500 error pages. The result is a
long list of strange error messages talking about corrupt zip files and
stuff like that. What you plan to do with ant is just another way to the
same potential problem.
I'm sure you are able to deal with problems like that. If you know the
build mechanism it won't be a big deal. But there will always be users
who checkout the MyFaces sources for the first time. Consider they want
to get a fix before the next release is out. If automatic download does
not work for them - I don't say this will happen every day, but it's a
possible scenario - they are stuck. They just called ant, they don't
know and don't want to know what's going on behind the scenes. What they
want is a working MyFaces built from sources.
I hope you got my point this time: it's the new users I care about. I
don't see a reason to introduce a new potential source of failure just
because others do so. So can you or anybody else please show me the
problem we have at the moment with the libs in the repository which will
be fixed by moving the libs to some other external location. Storage
space does not matter (as far as I know subversion is a lot more
efficent in storing binaries than CVS for example) - if that's the
problem I'll donate a new hard disk. And "because struts and commons
also do it" is no argument on it's own. So can you please show me what
you are trying to fix as I'm sorry but I don't see it.
Oliver
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
> ----- Original Message ----- From: "Oliver Rossmueller"
> <ol...@tuxerra.com>
> To: "MyFaces Development" <de...@myfaces.apache.org>
> Sent: Friday, June 24, 2005 6:53 AM
> Subject: Re: Proposal: Elimiante jar files from SVN
>
>
>> Martin Cooper wrote:
>>
>>> I would strongly recommend that you not store your dependencies in the
>>> SVN repo. Consider the consequences if every ASF project did the same
>>> thing. There would be many dozens of copies of the exact same
>>> libraries taking up space in the repo, one (or more) per project. The
>>> repo would end up being clogged with binaries, many of them duplicates.
>>
>>
>> Martin,
>>
>> if saving hard disk space is the main argument, than it's -1 again. Of
>> course you end up with duplicates of the same jar in different projects
>> in the repository, but that's not the point. The point is simplicity of
>> the build process so it can be handled by any developer and not only the
>> MyFaces core team.
>>
>>>
>>> This is one reason that the ASF Java repo was created - so that there
>>> is one place that libraries can be placed, so that they are available
>>> to any project that needs them. This is a parallel to the Maven
>>> repository at ibiblio, but neither of these require that Maven be used
>>> for the builds.
>>>
>>> Also, as Sean points out, if you prefer not to make use of automatic
>>> downloads, you are free to configure your system that way. But for
>>> many, if not most, people, the automatic downloads give them a way to
>>> get up and running much more quickly than a manual configuration.
>>
>>
>> Of course I can configure anything manually, and I am also able to deal
>> with problems caused by failed automatic downloads. But that's because I
>> know how the build works. Consider somebody who just got the sources
>> from svn. The first step then would be to check for the existence of
>> build.xml and to run 'ant'. Now that first and straightforward attempt
>> fails because the default ant target does not download required jars or
>> the default target does download the jars but download fails for
>> whatever reason. From the POV of named user what would you do? I would
>> throw MyFaces to the trash can and don't have a look at it for at least
>> half a year as those MyFaces guys seem to be not able to handle their
>> build process so how good and stable can their software be?
>>
>> That's my point: ease of build for anybody. It should not be necessary
>> to be an ant and subversion guru to handle the build.
>>
>> Oliver
>>
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>>> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>>>
>>>> -1 on that. Please don't make the build more complex than needed. Not
>>>> any stuff that seems to be cool to implement should be implemented.
>>>>
>>>> What's your problem with having the required libs in the
>>>> repository? For
>>>> me there are advantages only:
>>>>
>>>> - one source fits it all: you check out the svn module and have
>>>> everything you need to build
>>>> - the libs are versioned with the code which depends on the libs
>>>> - you have everything maintained in one place, the svn repository; no
>>>> need for external jar repositories or stuff like that
>>>> - no build is blocked because the download of a required lib is not
>>>> working for whatever reason (firewalls, network failures, ...)
>>>>
>>>> If you ever had the html of a http 500 page as the contents of a jar
>>>> file in your maven repository instead of the required jar itself you
>>>> know what I'm talking about. So do not try to imitate maven just by
>>>> other means but follow the KISS principle and keep it simple, please.
>>>>
>>>> Oliver
>>>>
>>>>
>>>> Manfred Geiler wrote:
>>>>
>>>>> yes, looks good
>>>>> +1 for automatic download of jars
>>>>>
>>>>> -Manfred
>>>>>
>>>>>
>>>>>
>>>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>>>
>>>>>
>>>>>> First off, thanks to James Mitchell (of the Struts team) who has
>>>>>> been
>>>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>>>> make him proud. :-)
>>>>>>
>>>>>> While James and I were discussing the Struts layout he also
>>>>>> mentioned
>>>>>> something interesting. They no longer keep any jar files in their
>>>>>> repository. He has figured out a way to deal with the jar file
>>>>>> dependencies that does *not* require Maven (ie. can be done from
>>>>>> Ant.)
>>>>>>
>>>>>> I'm planning on doing something similar as part of the reorg. Check
>>>>>> out the following steps that allow you to build struts 1.2 without
>>>>>> specifying a single jar file in your properties ...
>>>>>>
>>>>>> $svn co
>>>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>>>
>>>>>>
>>>>>> struts-1.2
>>>>>> $cd struts-1.2
>>>>>> $ant download-dependencies release
>>>>>>
>>>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>>>> process ;-) Also, its possible to build using local jar files if
>>>>>> that
>>>>>> is your cup of tea (just don't run the download-dependencies target
>>>>>> and specify the jar file locations in your local props file.)
>>>>>>
>>>>>> sean
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Oliver Rossmueller
>>>> Software Engineer and IT-Consultant
>>>> Hamburg, Germany
>>>> http://www.rossmueller.com
>>>>
>>>>
>>
>>
>> --
>> Oliver Rossmueller
>> Software Engineer and IT-Consultant
>> Hamburg, Germany
>> http://www.rossmueller.com
>>
>>
>
>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by James Mitchell <jm...@apache.org>.
Unless I missed it somewhere, no one has mentioned the extra bloat in your
source distributions (if you include the binary dependencies).
Oliver, I'm having a hard time understanding your point.
I can see how one wouldn't care about disk space and bandwidth, because you
(nor I) currently pay for neither. But how much more "simple" can building
a project be then calling "ant". That's all you should have to do to build
the project.
Please explain to me what makes it "not simple" if the ant script
automatically goes out and gets the dependencies the first time you run the
script (and never has to do it again unless a dependency is added or
changed) ??
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: "Oliver Rossmueller" <ol...@tuxerra.com>
To: "MyFaces Development" <de...@myfaces.apache.org>
Sent: Friday, June 24, 2005 6:53 AM
Subject: Re: Proposal: Elimiante jar files from SVN
> Martin Cooper wrote:
>
>> I would strongly recommend that you not store your dependencies in the
>> SVN repo. Consider the consequences if every ASF project did the same
>> thing. There would be many dozens of copies of the exact same
>> libraries taking up space in the repo, one (or more) per project. The
>> repo would end up being clogged with binaries, many of them duplicates.
>
> Martin,
>
> if saving hard disk space is the main argument, than it's -1 again. Of
> course you end up with duplicates of the same jar in different projects
> in the repository, but that's not the point. The point is simplicity of
> the build process so it can be handled by any developer and not only the
> MyFaces core team.
>
>>
>> This is one reason that the ASF Java repo was created - so that there
>> is one place that libraries can be placed, so that they are available
>> to any project that needs them. This is a parallel to the Maven
>> repository at ibiblio, but neither of these require that Maven be used
>> for the builds.
>>
>> Also, as Sean points out, if you prefer not to make use of automatic
>> downloads, you are free to configure your system that way. But for
>> many, if not most, people, the automatic downloads give them a way to
>> get up and running much more quickly than a manual configuration.
>
> Of course I can configure anything manually, and I am also able to deal
> with problems caused by failed automatic downloads. But that's because I
> know how the build works. Consider somebody who just got the sources
> from svn. The first step then would be to check for the existence of
> build.xml and to run 'ant'. Now that first and straightforward attempt
> fails because the default ant target does not download required jars or
> the default target does download the jars but download fails for
> whatever reason. From the POV of named user what would you do? I would
> throw MyFaces to the trash can and don't have a look at it for at least
> half a year as those MyFaces guys seem to be not able to handle their
> build process so how good and stable can their software be?
>
> That's my point: ease of build for anybody. It should not be necessary
> to be an ant and subversion guru to handle the build.
>
> Oliver
>
>>
>> --
>> Martin Cooper
>>
>>
>> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>>
>>> -1 on that. Please don't make the build more complex than needed. Not
>>> any stuff that seems to be cool to implement should be implemented.
>>>
>>> What's your problem with having the required libs in the repository? For
>>> me there are advantages only:
>>>
>>> - one source fits it all: you check out the svn module and have
>>> everything you need to build
>>> - the libs are versioned with the code which depends on the libs
>>> - you have everything maintained in one place, the svn repository; no
>>> need for external jar repositories or stuff like that
>>> - no build is blocked because the download of a required lib is not
>>> working for whatever reason (firewalls, network failures, ...)
>>>
>>> If you ever had the html of a http 500 page as the contents of a jar
>>> file in your maven repository instead of the required jar itself you
>>> know what I'm talking about. So do not try to imitate maven just by
>>> other means but follow the KISS principle and keep it simple, please.
>>>
>>> Oliver
>>>
>>>
>>> Manfred Geiler wrote:
>>>
>>>> yes, looks good
>>>> +1 for automatic download of jars
>>>>
>>>> -Manfred
>>>>
>>>>
>>>>
>>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>>
>>>>
>>>>> First off, thanks to James Mitchell (of the Struts team) who has been
>>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>>> make him proud. :-)
>>>>>
>>>>> While James and I were discussing the Struts layout he also mentioned
>>>>> something interesting. They no longer keep any jar files in their
>>>>> repository. He has figured out a way to deal with the jar file
>>>>> dependencies that does *not* require Maven (ie. can be done from Ant.)
>>>>>
>>>>> I'm planning on doing something similar as part of the reorg. Check
>>>>> out the following steps that allow you to build struts 1.2 without
>>>>> specifying a single jar file in your properties ...
>>>>>
>>>>> $svn co
>>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>>
>>>>> struts-1.2
>>>>> $cd struts-1.2
>>>>> $ant download-dependencies release
>>>>>
>>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>>> process ;-) Also, its possible to build using local jar files if that
>>>>> is your cup of tea (just don't run the download-dependencies target
>>>>> and specify the jar file locations in your local props file.)
>>>>>
>>>>> sean
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Oliver Rossmueller
>>> Software Engineer and IT-Consultant
>>> Hamburg, Germany
>>> http://www.rossmueller.com
>>>
>>>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Martin Cooper wrote:
> I would strongly recommend that you not store your dependencies in the
> SVN repo. Consider the consequences if every ASF project did the same
> thing. There would be many dozens of copies of the exact same
> libraries taking up space in the repo, one (or more) per project. The
> repo would end up being clogged with binaries, many of them duplicates.
Martin,
if saving hard disk space is the main argument, than it's -1 again. Of
course you end up with duplicates of the same jar in different projects
in the repository, but that's not the point. The point is simplicity of
the build process so it can be handled by any developer and not only the
MyFaces core team.
>
> This is one reason that the ASF Java repo was created - so that there
> is one place that libraries can be placed, so that they are available
> to any project that needs them. This is a parallel to the Maven
> repository at ibiblio, but neither of these require that Maven be used
> for the builds.
>
> Also, as Sean points out, if you prefer not to make use of automatic
> downloads, you are free to configure your system that way. But for
> many, if not most, people, the automatic downloads give them a way to
> get up and running much more quickly than a manual configuration.
Of course I can configure anything manually, and I am also able to deal
with problems caused by failed automatic downloads. But that's because I
know how the build works. Consider somebody who just got the sources
from svn. The first step then would be to check for the existence of
build.xml and to run 'ant'. Now that first and straightforward attempt
fails because the default ant target does not download required jars or
the default target does download the jars but download fails for
whatever reason. From the POV of named user what would you do? I would
throw MyFaces to the trash can and don't have a look at it for at least
half a year as those MyFaces guys seem to be not able to handle their
build process so how good and stable can their software be?
That's my point: ease of build for anybody. It should not be necessary
to be an ant and subversion guru to handle the build.
Oliver
>
> --
> Martin Cooper
>
>
> On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
>
>> -1 on that. Please don't make the build more complex than needed. Not
>> any stuff that seems to be cool to implement should be implemented.
>>
>> What's your problem with having the required libs in the repository? For
>> me there are advantages only:
>>
>> - one source fits it all: you check out the svn module and have
>> everything you need to build
>> - the libs are versioned with the code which depends on the libs
>> - you have everything maintained in one place, the svn repository; no
>> need for external jar repositories or stuff like that
>> - no build is blocked because the download of a required lib is not
>> working for whatever reason (firewalls, network failures, ...)
>>
>> If you ever had the html of a http 500 page as the contents of a jar
>> file in your maven repository instead of the required jar itself you
>> know what I'm talking about. So do not try to imitate maven just by
>> other means but follow the KISS principle and keep it simple, please.
>>
>> Oliver
>>
>>
>> Manfred Geiler wrote:
>>
>>> yes, looks good
>>> +1 for automatic download of jars
>>>
>>> -Manfred
>>>
>>>
>>>
>>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>>
>>>
>>>> First off, thanks to James Mitchell (of the Struts team) who has been
>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>>> make him proud. :-)
>>>>
>>>> While James and I were discussing the Struts layout he also mentioned
>>>> something interesting. They no longer keep any jar files in their
>>>> repository. He has figured out a way to deal with the jar file
>>>> dependencies that does *not* require Maven (ie. can be done from Ant.)
>>>>
>>>> I'm planning on doing something similar as part of the reorg. Check
>>>> out the following steps that allow you to build struts 1.2 without
>>>> specifying a single jar file in your properties ...
>>>>
>>>> $svn co
>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>>>
>>>> struts-1.2
>>>> $cd struts-1.2
>>>> $ant download-dependencies release
>>>>
>>>> Nice! I see no reason to deprive ourselves of the same cool build
>>>> process ;-) Also, its possible to build using local jar files if that
>>>> is your cup of tea (just don't run the download-dependencies target
>>>> and specify the jar file locations in your local props file.)
>>>>
>>>> sean
>>>>
>>>>
>>>>
>>
>>
>> --
>> Oliver Rossmueller
>> Software Engineer and IT-Consultant
>> Hamburg, Germany
>> http://www.rossmueller.com
>>
>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by Martin Cooper <ma...@apache.org>.
I would strongly recommend that you not store your dependencies in the SVN
repo. Consider the consequences if every ASF project did the same thing.
There would be many dozens of copies of the exact same libraries taking up
space in the repo, one (or more) per project. The repo would end up being
clogged with binaries, many of them duplicates.
This is one reason that the ASF Java repo was created - so that there is
one place that libraries can be placed, so that they are available to any
project that needs them. This is a parallel to the Maven repository at
ibiblio, but neither of these require that Maven be used for the builds.
Also, as Sean points out, if you prefer not to make use of automatic
downloads, you are free to configure your system that way. But for many,
if not most, people, the automatic downloads give them a way to get up and
running much more quickly than a manual configuration.
--
Martin Cooper
On Thu, 23 Jun 2005, Oliver Rossmueller wrote:
> -1 on that. Please don't make the build more complex than needed. Not
> any stuff that seems to be cool to implement should be implemented.
>
> What's your problem with having the required libs in the repository? For
> me there are advantages only:
>
> - one source fits it all: you check out the svn module and have
> everything you need to build
> - the libs are versioned with the code which depends on the libs
> - you have everything maintained in one place, the svn repository; no
> need for external jar repositories or stuff like that
> - no build is blocked because the download of a required lib is not
> working for whatever reason (firewalls, network failures, ...)
>
> If you ever had the html of a http 500 page as the contents of a jar
> file in your maven repository instead of the required jar itself you
> know what I'm talking about. So do not try to imitate maven just by
> other means but follow the KISS principle and keep it simple, please.
>
> Oliver
>
>
> Manfred Geiler wrote:
>
>> yes, looks good
>> +1 for automatic download of jars
>>
>> -Manfred
>>
>>
>>
>> 2005/6/21, Sean Schofield <se...@gmail.com>:
>>
>>
>>> First off, thanks to James Mitchell (of the Struts team) who has been
>>> teaching me the wonders of svn:externals. I hope my SVN reorg will
>>> make him proud. :-)
>>>
>>> While James and I were discussing the Struts layout he also mentioned
>>> something interesting. They no longer keep any jar files in their
>>> repository. He has figured out a way to deal with the jar file
>>> dependencies that does *not* require Maven (ie. can be done from Ant.)
>>>
>>> I'm planning on doing something similar as part of the reorg. Check
>>> out the following steps that allow you to build struts 1.2 without
>>> specifying a single jar file in your properties ...
>>>
>>> $svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>> struts-1.2
>>> $cd struts-1.2
>>> $ant download-dependencies release
>>>
>>> Nice! I see no reason to deprive ourselves of the same cool build
>>> process ;-) Also, its possible to build using local jar files if that
>>> is your cup of tea (just don't run the download-dependencies target
>>> and specify the jar file locations in your local props file.)
>>>
>>> sean
>>>
>>>
>>>
>
>
> --
> Oliver Rossmueller
> Software Engineer and IT-Consultant
> Hamburg, Germany
> http://www.rossmueller.com
>
>
Re: Proposal: Elimiante jar files from SVN
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
-1 on that. Please don't make the build more complex than needed. Not
any stuff that seems to be cool to implement should be implemented.
What's your problem with having the required libs in the repository? For
me there are advantages only:
- one source fits it all: you check out the svn module and have
everything you need to build
- the libs are versioned with the code which depends on the libs
- you have everything maintained in one place, the svn repository; no
need for external jar repositories or stuff like that
- no build is blocked because the download of a required lib is not
working for whatever reason (firewalls, network failures, ...)
If you ever had the html of a http 500 page as the contents of a jar
file in your maven repository instead of the required jar itself you
know what I'm talking about. So do not try to imitate maven just by
other means but follow the KISS principle and keep it simple, please.
Oliver
Manfred Geiler wrote:
>yes, looks good
>+1 for automatic download of jars
>
>-Manfred
>
>
>
>2005/6/21, Sean Schofield <se...@gmail.com>:
>
>
>>First off, thanks to James Mitchell (of the Struts team) who has been
>>teaching me the wonders of svn:externals. I hope my SVN reorg will
>>make him proud. :-)
>>
>>While James and I were discussing the Struts layout he also mentioned
>>something interesting. They no longer keep any jar files in their
>>repository. He has figured out a way to deal with the jar file
>>dependencies that does *not* require Maven (ie. can be done from Ant.)
>>
>>I'm planning on doing something similar as part of the reorg. Check
>>out the following steps that allow you to build struts 1.2 without
>>specifying a single jar file in your properties ...
>>
>>$svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
>>struts-1.2
>>$cd struts-1.2
>>$ant download-dependencies release
>>
>>Nice! I see no reason to deprive ourselves of the same cool build
>>process ;-) Also, its possible to build using local jar files if that
>>is your cup of tea (just don't run the download-dependencies target
>>and specify the jar file locations in your local props file.)
>>
>>sean
>>
>>
>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: Proposal: Elimiante jar files from SVN
Posted by Manfred Geiler <ma...@gmail.com>.
yes, looks good
+1 for automatic download of jars
-Manfred
2005/6/21, Sean Schofield <se...@gmail.com>:
> First off, thanks to James Mitchell (of the Struts team) who has been
> teaching me the wonders of svn:externals. I hope my SVN reorg will
> make him proud. :-)
>
> While James and I were discussing the Struts layout he also mentioned
> something interesting. They no longer keep any jar files in their
> repository. He has figured out a way to deal with the jar file
> dependencies that does *not* require Maven (ie. can be done from Ant.)
>
> I'm planning on doing something similar as part of the reorg. Check
> out the following steps that allow you to build struts 1.2 without
> specifying a single jar file in your properties ...
>
> $svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
> struts-1.2
> $cd struts-1.2
> $ant download-dependencies release
>
> Nice! I see no reason to deprive ourselves of the same cool build
> process ;-) Also, its possible to build using local jar files if that
> is your cup of tea (just don't run the download-dependencies target
> and specify the jar file locations in your local props file.)
>
> sean
>
Re: Proposal: Elimiante jar files from SVN
Posted by Martin Marinschek <ma...@gmail.com>.
Looks great...
regards,
Martin
On 6/21/05, Bruno Aranda <br...@gmail.com> wrote:
> Cool! This will make the project lighter and easier to maintain. I've
> seen that there is a timestamp check so you will donwload the jar only
> if necessary. I think this is an good proposal,
>
> Regards,
>
> Bruno
>
> 2005/6/21, Sean Schofield <se...@gmail.com>:
> > First off, thanks to James Mitchell (of the Struts team) who has been
> > teaching me the wonders of svn:externals. I hope my SVN reorg will
> > make him proud. :-)
> >
> > While James and I were discussing the Struts layout he also mentioned
> > something interesting. They no longer keep any jar files in their
> > repository. He has figured out a way to deal with the jar file
> > dependencies that does *not* require Maven (ie. can be done from Ant.)
> >
> > I'm planning on doing something similar as part of the reorg. Check
> > out the following steps that allow you to build struts 1.2 without
> > specifying a single jar file in your properties ...
> >
> > $svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
> > struts-1.2
> > $cd struts-1.2
> > $ant download-dependencies release
> >
> > Nice! I see no reason to deprive ourselves of the same cool build
> > process ;-) Also, its possible to build using local jar files if that
> > is your cup of tea (just don't run the download-dependencies target
> > and specify the jar file locations in your local props file.)
> >
> > sean
> >
>
Re: Proposal: Elimiante jar files from SVN
Posted by Bruno Aranda <br...@gmail.com>.
Cool! This will make the project lighter and easier to maintain. I've
seen that there is a timestamp check so you will donwload the jar only
if necessary. I think this is an good proposal,
Regards,
Bruno
2005/6/21, Sean Schofield <se...@gmail.com>:
> First off, thanks to James Mitchell (of the Struts team) who has been
> teaching me the wonders of svn:externals. I hope my SVN reorg will
> make him proud. :-)
>
> While James and I were discussing the Struts layout he also mentioned
> something interesting. They no longer keep any jar files in their
> repository. He has figured out a way to deal with the jar file
> dependencies that does *not* require Maven (ie. can be done from Ant.)
>
> I'm planning on doing something similar as part of the reorg. Check
> out the following steps that allow you to build struts 1.2 without
> specifying a single jar file in your properties ...
>
> $svn co https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/
> struts-1.2
> $cd struts-1.2
> $ant download-dependencies release
>
> Nice! I see no reason to deprive ourselves of the same cool build
> process ;-) Also, its possible to build using local jar files if that
> is your cup of tea (just don't run the download-dependencies target
> and specify the jar file locations in your local props file.)
>
> sean
>