You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2004/12/17 07:10:50 UTC
Any objections to adding Ant get's to build.xml?
I'm setting up Struts to build from Ant (again), and have to go through
the hassle of setting up build.properties. When I brought struts-bsf
in, I changed its build.xml to, if a "lib" directory didn't exist,
create one and use Ant's get task to pull the jars from ibiblio. It
wouldn't be a long term solution to our building woes, but I figure if I
have to go through the pain of setting up build.properties, I might as
well make it easier for the next guy/gal.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Escape html
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 19:24:23 -0300, Edgar Poce <ed...@gmail.com> wrote:
> > Are there any other characters that should be filtered for security
> > reasons?
>
> I think there are not. I thought it was a html escape tool and I
> expected it replaced 'à' with "à" for example. But I see it's not
> the purpose.
>
> Has it any sense to add an "escape" attribute with values "html",
> "javascript", ...?
I guess I am still missing the use case for doing this sort of thing
... what's the reasoning?
If you're talking about webapps, by the way, another option is to use
a Servlet Filter that intercepts the output and performs this sort of
transformation. That solution would work on *any* way to generate the
markup -- without requiring that the application source be modified.
>
> Thanks for your quick response
> Edgar
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Escape html
Posted by Edgar Poce <ed...@gmail.com>.
> Are there any other characters that should be filtered for security
> reasons?
I think there are not. I thought it was a html escape tool and I
expected it replaced 'à' with "à" for example. But I see it's not
the purpose.
Has it any sense to add an "escape" attribute with values "html",
"javascript", ...?
Thanks for your quick response
Edgar
Craig McClanahan wrote:
> The purpose for filtering these four characters is to avoid cross site
> scripting attacks that would otherwise be possible if an application
> accepted an input text field that had something like a <script>
> element in it, and then wrote that text to an HTML output stream with
> no modifications.
>
> Are there any other characters that should be filtered for security
> reasons? If not, what's the use case for converting anything else to
> its &xxx; equivalent? Which, among other things, can cause you some
> grief if you're trying to do XML validation of the resulting output.
>
> Craig
>
>
> On Sun, 19 Dec 2004 18:51:32 -0300, Edgar Poce <ed...@gmail.com> wrote:
>
>>Hi
>>TagUtils.filter(String value) only filters 4 html sensitive characters
>>while there are many more. Is there any special reason or it's a bug?
>>
>>Regards
>>Edgar
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Escape html
Posted by Craig McClanahan <cr...@gmail.com>.
The purpose for filtering these four characters is to avoid cross site
scripting attacks that would otherwise be possible if an application
accepted an input text field that had something like a <script>
element in it, and then wrote that text to an HTML output stream with
no modifications.
Are there any other characters that should be filtered for security
reasons? If not, what's the use case for converting anything else to
its &xxx; equivalent? Which, among other things, can cause you some
grief if you're trying to do XML validation of the resulting output.
Craig
On Sun, 19 Dec 2004 18:51:32 -0300, Edgar Poce <ed...@gmail.com> wrote:
> Hi
> TagUtils.filter(String value) only filters 4 html sensitive characters
> while there are many more. Is there any special reason or it's a bug?
>
> Regards
> Edgar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Escape html
Posted by Edgar Poce <ed...@gmail.com>.
Hi
TagUtils.filter(String value) only filters 4 html sensitive characters
while there are many more. Is there any special reason or it's a bug?
Regards
Edgar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 19 Dec 2004 19:06:56 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> Intermixed.
>
> On Sun, 19 Dec 2004 18:36:41 -0800, Martin Cooper <mf...@gmail.com> wrote:
> > On Sun, 19 Dec 2004 13:13:03 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > > On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <mf...@gmail.com> wrote:
> > > > On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > > > > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
> > > > > > At worst case, it seems we could add a task to do the downloads of
> > > > > > those binaries that are redistrutable. I think most folks would
> > > > > > rather invoke an Ant task than have to chase down dependencies. It
> > > > > > wouldn't even have to be tied to a compile.
> > > > > >
> > > > >
> > > > > Absolutely agree that there needs to be a way to point at local copies
> > > > > instead. The challenge for Mavenized projects that want to also be
> > > > > Ant-friendly is the way that the Ant plugin generates its build.xml
> > > > > files -- it does generate "get" tasks for pulling the dependencies,
> > > > > but uses hard coded paths from the project.xml file. It would be much
> > > > > better if the generated tasks used an Ant property for the "src"
> > > > > attribute, so that one could override and point at your local copy. I
> > > > > would like to see us do that in our Struts build.xml files (that are
> > > > > manually maintained) if we start using get tasks ourselves.
> > > >
> > > > Perhaps I'm misunderstanding what you're saying, but the
> > > > Maven-generated Ant build files work just fine if you're disconnected,
> > > > as long as you have previously downloaded the dependencies. All you
> > > > have to do is set the 'noget' property, and the attempts to <get> the
> > > > files will be skipped. The dependencies will then be picked up from
> > > > your local repo.
> > >
> > > The standard Maven generated build.xml for Commons Email, for example,
> > > creates hard coded get URLs for the JavaMail and JAF jars, based on
> > > the values in project.xml (which in turn point at the Sun web page
> > > where you have to click through the license to perform the downoads).
> > > It would not do any good to change where these URLs point to some
> > > "local" repository, because there is no canonical URL that would work
> > > for all users.
> >
> > OK, I see what you mean. My way around this is to not attempt to get
> > anything that isn't gettable automatically. ;-) The only thing I've
> > hit so far is the JDBC 2.0 Ext jar, which, IIUC, is only required when
> > building with JDK 1.3.
>
> I thought Commons Chain used to have some other dependencies; I'm sure
> Commons Resources does.
Chain no longer depends on anything that isn't available from ibiblio,
now that it's building against the MyFaces version of the JSF API.
Resources does depend on Hibernate, as well as some other things I've
never heard of. I'm not sure that any of those things need to be
available for building Struts or running the tests, but I could easily
be wrong on that. I guess we'll see when we switch over to using
Resources in Struts.
> > BTW, I haven't decided whether or not to try to download a Cactus
> > distro as part of this, or whether to assume that the user has one
> > somewhere. I am assuming that Tomcat would already be installed prior
> > to running Cactus tests. Comments?
>
> If we're going to be complete, we might as well be complete ... the
> only thing we should really assume the user has is a JDK. That would
> really mean downloading Tomcat as well. But isn't that the whole
> point, that running "ant download" or whatever will get *everything*
> you need?
I suppose. The question I was asking myself was "download everything
for what?". That is, downloading everything to just build, or
downloading everything to build and test. The latter would imply
downloading multiple versions of Tomcat, since we currently support 3
different versions (although the 5.5 tests don't pass yet).
If we want to be able to download everything, then we might want to
have 2 separate tasks - one to download everything to build, and one
to download the additional requirements for unit testing.
>
> >
> > > > The scheme I'm working on still defines all of the 'foo.jar'
> > > > properties we use today, but internally to the build. It uses a very
> > > > similar scheme to Maven to go get the dependencies and put them in
> > > > 'local.repo.dir' unless the 'noget' property is set, and then builds
> > > > against what is in that directory. If someone really wants to put the
> > > > dependencies elsewhere, they can still define 'foo.jar' to do that.
> > > > The versions of each dependency can also be overridden if necessary.
> > > >
> > > > Will that work for you?
> > >
> > > That sounds like it would work for me
> >
> > Great!
> >
> > > ... it would also fix another
> > > annoying quirk with the way that Maven-generated build.xml files work
> > > now. The get tasks all copy JARs into a directory that is blown away
> > > by the "clean" target, so running "ant clean dist" (which the nightly
> > > build does for each package) redownloads all the dependencies every
> > > time.
> >
> > That's the default behaviour, yes. However, if you define 'libdir' in
> > your ${user.home}/build.properties file, it will download to there and
> > not blow that away as part of 'clean'.
> >
>
> Hmm ... have to play with that one. One rough edge is that you need a
> separate libdir directory for each project, because the generated
> scripts add all the jars in the libdir directory to the classpath for
> that project. Oh well, at least that's something I can set up once
> per project and forget about it.
>
> > I actually have pretty much the same setup in what I'm doing for
> > Struts, where the default value of 'local.repo.dir' is
> > 'target/repository'. This is for the simple reason that the default
> > needs to be on a path that the build system knows exists (or can
> > exist). However, it just occurred to me that I could make the default
> > value be '${user.home}/struts-repository' (or something along those
> > lines) instead. Comments on this?
>
> I take it you don't want to assume the use of Maven? If so, I might
> recommend something like "${user.home}/.ant/repository/struts"
> (sort-of like what Maven does in "${user.home}/.maven" to start
> getting people used to this approach. I'm gonna try this sort of
> thing on my machine for the nightly builds of all the commons
> packages, which take much longer than they should due to the repeated
> downloads.
Since this is an Ant build, no, I don't want to assume that the user
uses Maven or even knows what it is. It would be confusing to use the
.maven directory for someone who didn't know what that is.
I like your recommendation of putting the repo under .ant, though.
I'll switch the default to that. :-)
--
Martin Cooper
> >
> > --
> > Martin Cooper
> >
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Craig McClanahan <cr...@gmail.com>.
Intermixed.
On Sun, 19 Dec 2004 18:36:41 -0800, Martin Cooper <mf...@gmail.com> wrote:
> On Sun, 19 Dec 2004 13:13:03 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <mf...@gmail.com> wrote:
> > > On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > > > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
> > > > > At worst case, it seems we could add a task to do the downloads of
> > > > > those binaries that are redistrutable. I think most folks would
> > > > > rather invoke an Ant task than have to chase down dependencies. It
> > > > > wouldn't even have to be tied to a compile.
> > > > >
> > > >
> > > > Absolutely agree that there needs to be a way to point at local copies
> > > > instead. The challenge for Mavenized projects that want to also be
> > > > Ant-friendly is the way that the Ant plugin generates its build.xml
> > > > files -- it does generate "get" tasks for pulling the dependencies,
> > > > but uses hard coded paths from the project.xml file. It would be much
> > > > better if the generated tasks used an Ant property for the "src"
> > > > attribute, so that one could override and point at your local copy. I
> > > > would like to see us do that in our Struts build.xml files (that are
> > > > manually maintained) if we start using get tasks ourselves.
> > >
> > > Perhaps I'm misunderstanding what you're saying, but the
> > > Maven-generated Ant build files work just fine if you're disconnected,
> > > as long as you have previously downloaded the dependencies. All you
> > > have to do is set the 'noget' property, and the attempts to <get> the
> > > files will be skipped. The dependencies will then be picked up from
> > > your local repo.
> >
> > The standard Maven generated build.xml for Commons Email, for example,
> > creates hard coded get URLs for the JavaMail and JAF jars, based on
> > the values in project.xml (which in turn point at the Sun web page
> > where you have to click through the license to perform the downoads).
> > It would not do any good to change where these URLs point to some
> > "local" repository, because there is no canonical URL that would work
> > for all users.
>
> OK, I see what you mean. My way around this is to not attempt to get
> anything that isn't gettable automatically. ;-) The only thing I've
> hit so far is the JDBC 2.0 Ext jar, which, IIUC, is only required when
> building with JDK 1.3.
I thought Commons Chain used to have some other dependencies; I'm sure
Commons Resources does.
>
> BTW, I haven't decided whether or not to try to download a Cactus
> distro as part of this, or whether to assume that the user has one
> somewhere. I am assuming that Tomcat would already be installed prior
> to running Cactus tests. Comments?
If we're going to be complete, we might as well be complete ... the
only thing we should really assume the user has is a JDK. That would
really mean downloading Tomcat as well. But isn't that the whole
point, that running "ant download" or whatever will get *everything*
you need?
>
> > > The scheme I'm working on still defines all of the 'foo.jar'
> > > properties we use today, but internally to the build. It uses a very
> > > similar scheme to Maven to go get the dependencies and put them in
> > > 'local.repo.dir' unless the 'noget' property is set, and then builds
> > > against what is in that directory. If someone really wants to put the
> > > dependencies elsewhere, they can still define 'foo.jar' to do that.
> > > The versions of each dependency can also be overridden if necessary.
> > >
> > > Will that work for you?
> >
> > That sounds like it would work for me
>
> Great!
>
> > ... it would also fix another
> > annoying quirk with the way that Maven-generated build.xml files work
> > now. The get tasks all copy JARs into a directory that is blown away
> > by the "clean" target, so running "ant clean dist" (which the nightly
> > build does for each package) redownloads all the dependencies every
> > time.
>
> That's the default behaviour, yes. However, if you define 'libdir' in
> your ${user.home}/build.properties file, it will download to there and
> not blow that away as part of 'clean'.
>
Hmm ... have to play with that one. One rough edge is that you need a
separate libdir directory for each project, because the generated
scripts add all the jars in the libdir directory to the classpath for
that project. Oh well, at least that's something I can set up once
per project and forget about it.
> I actually have pretty much the same setup in what I'm doing for
> Struts, where the default value of 'local.repo.dir' is
> 'target/repository'. This is for the simple reason that the default
> needs to be on a path that the build system knows exists (or can
> exist). However, it just occurred to me that I could make the default
> value be '${user.home}/struts-repository' (or something along those
> lines) instead. Comments on this?
I take it you don't want to assume the use of Maven? If so, I might
recommend something like "${user.home}/.ant/repository/struts"
(sort-of like what Maven does in "${user.home}/.maven" to start
getting people used to this approach. I'm gonna try this sort of
thing on my machine for the nightly builds of all the commons
packages, which take much longer than they should due to the repeated
downloads.
>
> --
> Martin Cooper
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 19 Dec 2004 13:13:03 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <mf...@gmail.com> wrote:
> > On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
> > > > At worst case, it seems we could add a task to do the downloads of
> > > > those binaries that are redistrutable. I think most folks would
> > > > rather invoke an Ant task than have to chase down dependencies. It
> > > > wouldn't even have to be tied to a compile.
> > > >
> > >
> > > Absolutely agree that there needs to be a way to point at local copies
> > > instead. The challenge for Mavenized projects that want to also be
> > > Ant-friendly is the way that the Ant plugin generates its build.xml
> > > files -- it does generate "get" tasks for pulling the dependencies,
> > > but uses hard coded paths from the project.xml file. It would be much
> > > better if the generated tasks used an Ant property for the "src"
> > > attribute, so that one could override and point at your local copy. I
> > > would like to see us do that in our Struts build.xml files (that are
> > > manually maintained) if we start using get tasks ourselves.
> >
> > Perhaps I'm misunderstanding what you're saying, but the
> > Maven-generated Ant build files work just fine if you're disconnected,
> > as long as you have previously downloaded the dependencies. All you
> > have to do is set the 'noget' property, and the attempts to <get> the
> > files will be skipped. The dependencies will then be picked up from
> > your local repo.
>
> The standard Maven generated build.xml for Commons Email, for example,
> creates hard coded get URLs for the JavaMail and JAF jars, based on
> the values in project.xml (which in turn point at the Sun web page
> where you have to click through the license to perform the downoads).
> It would not do any good to change where these URLs point to some
> "local" repository, because there is no canonical URL that would work
> for all users.
OK, I see what you mean. My way around this is to not attempt to get
anything that isn't gettable automatically. ;-) The only thing I've
hit so far is the JDBC 2.0 Ext jar, which, IIUC, is only required when
building with JDK 1.3.
BTW, I haven't decided whether or not to try to download a Cactus
distro as part of this, or whether to assume that the user has one
somewhere. I am assuming that Tomcat would already be installed prior
to running Cactus tests. Comments?
> > The scheme I'm working on still defines all of the 'foo.jar'
> > properties we use today, but internally to the build. It uses a very
> > similar scheme to Maven to go get the dependencies and put them in
> > 'local.repo.dir' unless the 'noget' property is set, and then builds
> > against what is in that directory. If someone really wants to put the
> > dependencies elsewhere, they can still define 'foo.jar' to do that.
> > The versions of each dependency can also be overridden if necessary.
> >
> > Will that work for you?
>
> That sounds like it would work for me
Great!
> ... it would also fix another
> annoying quirk with the way that Maven-generated build.xml files work
> now. The get tasks all copy JARs into a directory that is blown away
> by the "clean" target, so running "ant clean dist" (which the nightly
> build does for each package) redownloads all the dependencies every
> time.
That's the default behaviour, yes. However, if you define 'libdir' in
your ${user.home}/build.properties file, it will download to there and
not blow that away as part of 'clean'.
I actually have pretty much the same setup in what I'm doing for
Struts, where the default value of 'local.repo.dir' is
'target/repository'. This is for the simple reason that the default
needs to be on a path that the build system knows exists (or can
exist). However, it just occurred to me that I could make the default
value be '${user.home}/struts-repository' (or something along those
lines) instead. Comments on this?
--
Martin Cooper
> >
> > --
> > Martin Cooper
> >
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 12:54:38 -0800, Martin Cooper <mf...@gmail.com> wrote:
> On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> > On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
> > > At worst case, it seems we could add a task to do the downloads of
> > > those binaries that are redistrutable. I think most folks would
> > > rather invoke an Ant task than have to chase down dependencies. It
> > > wouldn't even have to be tied to a compile.
> > >
> >
> > Absolutely agree that there needs to be a way to point at local copies
> > instead. The challenge for Mavenized projects that want to also be
> > Ant-friendly is the way that the Ant plugin generates its build.xml
> > files -- it does generate "get" tasks for pulling the dependencies,
> > but uses hard coded paths from the project.xml file. It would be much
> > better if the generated tasks used an Ant property for the "src"
> > attribute, so that one could override and point at your local copy. I
> > would like to see us do that in our Struts build.xml files (that are
> > manually maintained) if we start using get tasks ourselves.
>
> Perhaps I'm misunderstanding what you're saying, but the
> Maven-generated Ant build files work just fine if you're disconnected,
> as long as you have previously downloaded the dependencies. All you
> have to do is set the 'noget' property, and the attempts to <get> the
> files will be skipped. The dependencies will then be picked up from
> your local repo.
The standard Maven generated build.xml for Commons Email, for example,
creates hard coded get URLs for the JavaMail and JAF jars, based on
the values in project.xml (which in turn point at the Sun web page
where you have to click through the license to perform the downoads).
It would not do any good to change where these URLs point to some
"local" repository, because there is no canonical URL that would work
for all users.
>
> The scheme I'm working on still defines all of the 'foo.jar'
> properties we use today, but internally to the build. It uses a very
> similar scheme to Maven to go get the dependencies and put them in
> 'local.repo.dir' unless the 'noget' property is set, and then builds
> against what is in that directory. If someone really wants to put the
> dependencies elsewhere, they can still define 'foo.jar' to do that.
> The versions of each dependency can also be overridden if necessary.
>
> Will that work for you?
That sounds like it would work for me ... it would also fix another
annoying quirk with the way that Maven-generated build.xml files work
now. The get tasks all copy JARs into a directory that is blown away
by the "clean" target, so running "ant clean dist" (which the nightly
build does for each package) redownloads all the dependencies every
time.
>
> --
> Martin Cooper
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Phil Steitz <ph...@steitz.com>.
Martin Cooper wrote:
> On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <cr...@gmail.com> wrote:
>
>>On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
>>
>>>At worst case, it seems we could add a task to do the downloads of
>>>those binaries that are redistrutable. I think most folks would
>>>rather invoke an Ant task than have to chase down dependencies. It
>>>wouldn't even have to be tied to a compile.
>>>
>>
>>Absolutely agree that there needs to be a way to point at local copies
>>instead. The challenge for Mavenized projects that want to also be
>>Ant-friendly is the way that the Ant plugin generates its build.xml
>>files -- it does generate "get" tasks for pulling the dependencies,
>>but uses hard coded paths from the project.xml file. It would be much
>>better if the generated tasks used an Ant property for the "src"
>>attribute, so that one could override and point at your local copy.
Great idea for the maven ant plugin.
>>I
>>would like to see us do that in our Struts build.xml files (that are
>>manually maintained) if we start using get tasks ourselves.
>
>
> Perhaps I'm misunderstanding what you're saying, but the
> Maven-generated Ant build files work just fine if you're disconnected,
> as long as you have previously downloaded the dependencies.
Unless you do an ant clean in the interim, since by default the
dependencies go in target/lib. It would be great to be able to specify a
"durable" location for these, similar to .maven/repository.
> All you
> have to do is set the 'noget' property, and the attempts to <get> the
> files will be skipped. The dependencies will then be picked up from
> your local repo.
>
> The scheme I'm working on still defines all of the 'foo.jar'
> properties we use today, but internally to the build. It uses a very
> similar scheme to Maven to go get the dependencies and put them in
> 'local.repo.dir' unless the 'noget' property is set, and then builds
> against what is in that directory. If someone really wants to put the
> dependencies elsewhere, they can still define 'foo.jar' to do that.
> The versions of each dependency can also be overridden if necessary.
The tomcat-5 build is a good example of this.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 19 Dec 2004 12:38:27 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
> > At worst case, it seems we could add a task to do the downloads of
> > those binaries that are redistrutable. I think most folks would
> > rather invoke an Ant task than have to chase down dependencies. It
> > wouldn't even have to be tied to a compile.
> >
>
> Absolutely agree that there needs to be a way to point at local copies
> instead. The challenge for Mavenized projects that want to also be
> Ant-friendly is the way that the Ant plugin generates its build.xml
> files -- it does generate "get" tasks for pulling the dependencies,
> but uses hard coded paths from the project.xml file. It would be much
> better if the generated tasks used an Ant property for the "src"
> attribute, so that one could override and point at your local copy. I
> would like to see us do that in our Struts build.xml files (that are
> manually maintained) if we start using get tasks ourselves.
Perhaps I'm misunderstanding what you're saying, but the
Maven-generated Ant build files work just fine if you're disconnected,
as long as you have previously downloaded the dependencies. All you
have to do is set the 'noget' property, and the attempts to <get> the
files will be skipped. The dependencies will then be picked up from
your local repo.
The scheme I'm working on still defines all of the 'foo.jar'
properties we use today, but internally to the build. It uses a very
similar scheme to Maven to go get the dependencies and put them in
'local.repo.dir' unless the 'noget' property is set, and then builds
against what is in that directory. If someone really wants to put the
dependencies elsewhere, they can still define 'foo.jar' to do that.
The versions of each dependency can also be overridden if necessary.
Will that work for you?
--
Martin Cooper
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Craig McClanahan <cr...@gmail.com>.
On Sun, 19 Dec 2004 00:55:56 -0600, Eddie Bush <ea...@gmail.com> wrote:
> At worst case, it seems we could add a task to do the downloads of
> those binaries that are redistrutable. I think most folks would
> rather invoke an Ant task than have to chase down dependencies. It
> wouldn't even have to be tied to a compile.
>
Absolutely agree that there needs to be a way to point at local copies
instead. The challenge for Mavenized projects that want to also be
Ant-friendly is the way that the Ant plugin generates its build.xml
files -- it does generate "get" tasks for pulling the dependencies,
but uses hard coded paths from the project.xml file. It would be much
better if the generated tasks used an Ant property for the "src"
attribute, so that one could override and point at your local copy. I
would like to see us do that in our Struts build.xml files (that are
manually maintained) if we start using get tasks ourselves.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Eddie Bush <ea...@gmail.com>.
At worst case, it seems we could add a task to do the downloads of
those binaries that are redistrutable. I think most folks would
rather invoke an Ant task than have to chase down dependencies. It
wouldn't even have to be tied to a compile.
I don't think easing the task of creating a build is a bad thing.
Seems to me that would make it easier for others to build, and thus to
use and test. I'd think that could help us ferret out issues quicker,
but maybe I'm wrong.
On Sat, 18 Dec 2004 22:26:45 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown <mr...@twdata.org> wrote:
> > I'm setting up Struts to build from Ant (again), and have to go through
> > the hassle of setting up build.properties. When I brought struts-bsf
> > in, I changed its build.xml to, if a "lib" directory didn't exist,
> > create one and use Ant's get task to pull the jars from ibiblio. It
> > wouldn't be a long term solution to our building woes, but I figure if I
> > have to go through the pain of setting up build.properties, I might as
> > well make it easier for the next guy/gal.
>
> If you want nightly builds to work :-), the "build.xml" file had
> better work, with minimal need for custom build.properties files,
> although I'll obviously maintain those as needed for Struts and the
> commons package it depends on.
>
> A deeper issue, though, is that the way Maven currently generates Ant
> build.xml files is to duplicate hard coded URLs for the dependencies
> to be retrieved. Besides being very tough on people who try to build
> when not connected to the net, the fatal flaw is when you run into
> dependencies that cannot (for license reasons) be posted individually
> in a repository. Examples include the Commons Email dependence on
> JavaMail.
>
> If you're willing to hand create the Ant scripts so that you can still
> use build.properties type mechanisms to override these URLs, that's
> fine. If not, then I think it's a waste of time, because there is no
> solution for the non-redistributable-binary-dependencies scenario.
>
> >
> > Don
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
--
Eddie Bush
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown <mr...@twdata.org> wrote:
> I'm setting up Struts to build from Ant (again), and have to go through
> the hassle of setting up build.properties. When I brought struts-bsf
> in, I changed its build.xml to, if a "lib" directory didn't exist,
> create one and use Ant's get task to pull the jars from ibiblio. It
> wouldn't be a long term solution to our building woes, but I figure if I
> have to go through the pain of setting up build.properties, I might as
> well make it easier for the next guy/gal.
If you want nightly builds to work :-), the "build.xml" file had
better work, with minimal need for custom build.properties files,
although I'll obviously maintain those as needed for Struts and the
commons package it depends on.
A deeper issue, though, is that the way Maven currently generates Ant
build.xml files is to duplicate hard coded URLs for the dependencies
to be retrieved. Besides being very tough on people who try to build
when not connected to the net, the fatal flaw is when you run into
dependencies that cannot (for license reasons) be posted individually
in a repository. Examples include the Commons Email dependence on
JavaMail.
If you're willing to hand create the Ant scripts so that you can still
use build.properties type mechanisms to override these URLs, that's
fine. If not, then I think it's a waste of time, because there is no
solution for the non-redistributable-binary-dependencies scenario.
>
> Don
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Don Brown <mr...@twdata.org>.
Cool, I just remembered I can build the website w/o configuring
build.properties so I'll just put that off. Good luck on that build
cleanup *shudder* :)
Don
Martin Cooper wrote:
> I'm working on this right now. I have the 'get' stuff done locally,
> but there's some other build stuff I want to clean up before I commit
> that. (Last night's Cactus property clean-up was part of that.)
>
> --
> Martin Cooper
>
>
> On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown <mr...@twdata.org> wrote:
>
>>I'm setting up Struts to build from Ant (again), and have to go through
>>the hassle of setting up build.properties. When I brought struts-bsf
>>in, I changed its build.xml to, if a "lib" directory didn't exist,
>>create one and use Ant's get task to pull the jars from ibiblio. It
>>wouldn't be a long term solution to our building woes, but I figure if I
>>have to go through the pain of setting up build.properties, I might as
>>well make it easier for the next guy/gal.
>>
>>Don
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Any objections to adding Ant get's to build.xml?
Posted by Martin Cooper <mf...@gmail.com>.
I'm working on this right now. I have the 'get' stuff done locally,
but there's some other build stuff I want to clean up before I commit
that. (Last night's Cactus property clean-up was part of that.)
--
Martin Cooper
On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown <mr...@twdata.org> wrote:
> I'm setting up Struts to build from Ant (again), and have to go through
> the hassle of setting up build.properties. When I brought struts-bsf
> in, I changed its build.xml to, if a "lib" directory didn't exist,
> create one and use Ant's get task to pull the jars from ibiblio. It
> wouldn't be a long term solution to our building woes, but I figure if I
> have to go through the pain of setting up build.properties, I might as
> well make it easier for the next guy/gal.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org