Build problems

[Drew McAuliffe <dr...@gmail.com>]

I've been running into a number of problems with building tapestry (RC1).
The biggest problem I have is that the build structure is completely
interdependent on HiveMind. While I can understand a need to have access to
HiveMind, I don't see why I should need the source of HiveMind, and it's
build structure, to build a dependent library. It should be sufficient (as
it is in many other OS libraries) to simply have the Hivemind jars
available. This has led to a lot of confusion in trying to adjust properties
for my particular environment, and also to debug other issues with the build
process, as listed below:

1. Why is it not possible to build Tapestry on Java 1.4? Most app servers do
not support 1.5 at this time, and yet there are compile-time dependencies on
1.5/5.0 that I have to fix by hand each time I want to do a rebuild. The
biggest one is the reference to "Collections.emptySet()" (as opposed to "
Collections.EMPTY_SET"). I don't know any way around this other than to make
the change myself.

2. If you've built older versions of tapestry, you can and will run into
problems. Tapestry builds everything into your temp directory, which under
windows is usually not easily accessible (c:/documents and settings/user
name/local settings/temp). Values cached there from building an earlier beta
were causing compile errors. Shouldn't tapestry, like most other OS
libraries, build to a temp directory local to the source path, which can
then safely be completely cleaned before each build? I don't like files
being output to a somewhat hidden directory on my computer and left there to
rot after a build.

If there's a way around these issues, it's not immediately apparent, despite
much perusing of the mail list and the wiki. I feel that build issues are
one of the first things that will turn off prospective users from the
library. If most people can't run a build (especially on a JDK version that
most people will be forced to use), then they will quickly turn away and
find another framework that does have an easy, consistent, and clean build
process.

Maybe this is just a hole in the documentation? I hope so because for each
new release, I'm forced to rebuild both hivemind and tapestry due to 2
errors that have been mentioned on the list frequently in the past but never
actually addressed (jndi lookup problems with oc4j and the fact that you
can't easily make table column headers align to the left without editing the
html in the contrib library).

Drew

Re: Build problems

[Drew McAuliffe <dr...@gmail.com>]

A lot of the test compilation targets have "1.5" build directly into the xml
files instead of reading it from a props file. Also, a great deal of the
tests are completely 1.5 dependent, using varargs, autoboxing, and
annotations, so there's no way to compile them on 1.4. Also, there's no way
to run the build without compiling the tests (even if you're not running the
tests), so it gets even messier.

If that's a bug as well, I can log it into JIRA.

Drew

On 12/7/05, Drew McAuliffe <dr...@gmail.com> wrote:
>
> Thanks for the quick response. I'll check out JIRA when I come up for air.
> The other issues that lead me to constantly rebuild have already had issues
> created, I believe. I've been able to get the patch code from the mailing
> lists in one case and dealt with it myself in the other. I'll double-check
> again, though.
>
> As for the build issues, your suggestions are helpful, and I understand
> about the temp issue. I'm more than happy to help contribute in most cases,
> it's just that the build files are something I'm terrified to touch.
>
> On 12/7/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
> >
> > Drew McAuliffe wrote:
> > > Maybe this is just a hole in the documentation? I hope so because for
> > each
> > > new release, I'm forced to rebuild both hivemind and tapestry due to 2
> > > errors that have been mentioned on the list frequently in the past but
> > never
> > > actually addressed (jndi lookup problems with oc4j and the fact that
> > you
> > > can't easily make table column headers align to the left without
> > editing the
> > > html in the contrib library).
> > >
> > > Drew
> > As with any open source library, your problems would get solved out
> > faster if you provide patches. You seem a little mad because Tapestry is
> > not living up to your expectations of how it should work ^o)?
> >
> > Go ahead, and get involved. For the problems that you mention above, are
> >
> > they active JIRA issues? If not, then please submit the issue request.
> > Maybe a small e-mail to the devel list telling Tapestry committers to
> > please look-up the issues - preferably with a fix already investigated,
> > would be nice? (I just submitted an e-mail of that kind myself, and it
> > was promptly fixed in the 4.0 branch - thanks Howard!)
> >
> > As for the temporary build problems, I think Howard moved the target to
> > a temp directory due to the large amount of code / docs / files
> > generated in the project workspace. That clutters up Eclipse (seems like
> > it can't handle large amount of files). Of course, suggestions are
> > welcome. Based on your e-mail, I'd guess they are as following:
> >
> > 1. Make the temp directory versioned. Instead of "jakarta-tapestry"
> > let's use "jakarta-tapestry-4.0". That would solve conflicts.
> > 2. Build in the temp directory but provide JARs and compiled ZIPs to the
> >
> > main project workspace. Maybe a dist directory could help. I second
> > that: I just don't like going to the temp directory to get a ZIP.
> >
> > As with the other frameworks issue, well, any OS project will ask you to
> > provide patches, fixes for documentation, etc. ;)
> >
> > Thanks for the suggestions, though.
> >
> > --
> > Ing. Leonardo Quijano Vincenzi
> > DTQ Software
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>

Re: Build problems

[Drew McAuliffe <dr...@gmail.com>]

Thanks for the quick response. I'll check out JIRA when I come up for air.
The other issues that lead me to constantly rebuild have already had issues
created, I believe. I've been able to get the patch code from the mailing
lists in one case and dealt with it myself in the other. I'll double-check
again, though.

As for the build issues, your suggestions are helpful, and I understand
about the temp issue. I'm more than happy to help contribute in most cases,
it's just that the build files are something I'm terrified to touch.

On 12/7/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>
> Drew McAuliffe wrote:
> > Maybe this is just a hole in the documentation? I hope so because for
> each
> > new release, I'm forced to rebuild both hivemind and tapestry due to 2
> > errors that have been mentioned on the list frequently in the past but
> never
> > actually addressed (jndi lookup problems with oc4j and the fact that you
> > can't easily make table column headers align to the left without editing
> the
> > html in the contrib library).
> >
> > Drew
> As with any open source library, your problems would get solved out
> faster if you provide patches. You seem a little mad because Tapestry is
> not living up to your expectations of how it should work ^o)?
>
> Go ahead, and get involved. For the problems that you mention above, are
> they active JIRA issues? If not, then please submit the issue request.
> Maybe a small e-mail to the devel list telling Tapestry committers to
> please look-up the issues - preferably with a fix already investigated,
> would be nice? (I just submitted an e-mail of that kind myself, and it
> was promptly fixed in the 4.0 branch - thanks Howard!)
>
> As for the temporary build problems, I think Howard moved the target to
> a temp directory due to the large amount of code / docs / files
> generated in the project workspace. That clutters up Eclipse (seems like
> it can't handle large amount of files). Of course, suggestions are
> welcome. Based on your e-mail, I'd guess they are as following:
>
> 1. Make the temp directory versioned. Instead of "jakarta-tapestry"
> let's use "jakarta-tapestry-4.0". That would solve conflicts.
> 2. Build in the temp directory but provide JARs and compiled ZIPs to the
> main project workspace. Maybe a dist directory could help. I second
> that: I just don't like going to the temp directory to get a ZIP.
>
> As with the other frameworks issue, well, any OS project will ask you to
> provide patches, fixes for documentation, etc. ;)
>
> Thanks for the suggestions, though.
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: Build problems

[Leonardo Quijano Vincenzi <le...@dtqsoftware.com>]

Drew McAuliffe wrote:
> Maybe this is just a hole in the documentation? I hope so because for each
> new release, I'm forced to rebuild both hivemind and tapestry due to 2
> errors that have been mentioned on the list frequently in the past but never
> actually addressed (jndi lookup problems with oc4j and the fact that you
> can't easily make table column headers align to the left without editing the
> html in the contrib library).
>
> Drew
As with any open source library, your problems would get solved out 
faster if you provide patches. You seem a little mad because Tapestry is 
not living up to your expectations of how it should work ^o)?

Go ahead, and get involved. For the problems that you mention above, are 
they active JIRA issues? If not, then please submit the issue request. 
Maybe a small e-mail to the devel list telling Tapestry committers to 
please look-up the issues - preferably with a fix already investigated, 
would be nice? (I just submitted an e-mail of that kind myself, and it 
was promptly fixed in the 4.0 branch - thanks Howard!)

As for the temporary build problems, I think Howard moved the target to 
a temp directory due to the large amount of code / docs / files 
generated in the project workspace. That clutters up Eclipse (seems like 
it can't handle large amount of files). Of course, suggestions are 
welcome. Based on your e-mail, I'd guess they are as following:

1. Make the temp directory versioned. Instead of "jakarta-tapestry" 
let's use "jakarta-tapestry-4.0". That would solve conflicts.
2. Build in the temp directory but provide JARs and compiled ZIPs to the 
main project workspace. Maybe a dist directory could help. I second 
that: I just don't like going to the temp directory to get a ZIP.

As with the other frameworks issue, well, any OS project will ask you to 
provide patches, fixes for documentation, etc. ;)

Thanks for the suggestions, though.

-- 
Ing. Leonardo Quijano Vincenzi
DTQ Software



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Build problems

[an...@di.uoa.gr]

>From  Drew McAuliffe <dr...@gmail.com>:

> I've been running into a number of problems with building tapestry (RC1).
> The biggest problem I have is that the build structure is completely
> interdependent on HiveMind. While I can understand a need to have access to
> HiveMind, I don't see why I should need the source of HiveMind, and it's
> build structure, to build a dependent library. It should be sufficient (as
> it is in many other OS libraries) to simply have the Hivemind jars
> available. 

It's been a long time since I've set my environment (at work) for building
tapestry's betas,
and i don't remember if Hivemind's source was indeed needed (so I can't really
help on that). 
But I do remember that when tapestry went from hivemind 1.1 beta to 1.1 final I
didn't have to 
download any source code. The correct jar was automatically downloaded by the
ant task. 

> This has led to a lot of confusion in trying to adjust properties
> for my particular environment, and also to debug other issues with the build
> process, as listed below:
> 
> 1. Why is it not possible to build Tapestry on Java 1.4? Most app servers do
> not support 1.5 at this time, and yet there are compile-time dependencies on
> 1.5/5.0 that I have to fix by hand each time I want to do a rebuild. The
> biggest one is the reference to "Collections.emptySet()" (as opposed to "
> Collections.EMPTY_SET"). I don't know any way around this other than to make
> the change myself.

AFAIK, 1.5 is only needed for annotations support. I guess if you exclude that
package from
the build process, then you can build in 1.4 as well. 
I don't see this as a problem however, since I hace many jdks installed (
including 1.5 ) 
and I only have to change the JAVA_HOME env variable to switch between those.
And also,
(apart from the annotations jar) the compile task generates classes for version
1.4 (or 1.3)

> 
> 2. If you've built older versions of tapestry, you can and will run into
> problems. Tapestry builds everything into your temp directory, which under
> windows is usually not easily accessible (c:/documents and settings/user
> name/local settings/temp). Values cached there from building an earlier beta
> were causing compile errors. Shouldn't tapestry, like most other OS
> libraries, build to a temp directory local to the source path, which can
> then safely be completely cleaned before each build? I don't like files
> being output to a somewhat hidden directory on my computer and left there to
> rot after a build.

I've run into that problem too. Usually, my problem had to do with test classes
which
in later betas where deleted but still remained in the tmp folder (i'm building
in linux).
This was causing the tests to fail. The simplest way out of it is to do ant clean
before ant install.





---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Build problems

[Howard Lewis Ship <hl...@gmail.com>]

Tapestry is dependent on the *build scripts* used by HiveMind. I wrote
them out of frustration with maven 1.0, but I'm looking into Maven 2
for HiveMind (1.2) and Tapestry (4.1).

Those are problems you've identified; the framework and contrib code
is supposed to be compatible with JDK 1.3.  I'll look into those. 
Please add a bug to JIRA.

The business about building to c:/temp (set your TEMP env variable!)
makes Eclipse much, much, much happier.  Eclipse is constantly reading
and indexing everything in your folders, whether it is a derived file
or not.  Moving the majority of the derived files out of the workspace
makes Eclipse useable again.

Remember that noone can keep up with the mailing lists; if you find a
bug, adding it to JIRA is right.


On 12/7/05, Drew McAuliffe <dr...@gmail.com> wrote:
> I've been running into a number of problems with building tapestry (RC1).
> The biggest problem I have is that the build structure is completely
> interdependent on HiveMind. While I can understand a need to have access to
> HiveMind, I don't see why I should need the source of HiveMind, and it's
> build structure, to build a dependent library. It should be sufficient (as
> it is in many other OS libraries) to simply have the Hivemind jars
> available. This has led to a lot of confusion in trying to adjust properties
> for my particular environment, and also to debug other issues with the build
> process, as listed below:
>
> 1. Why is it not possible to build Tapestry on Java 1.4? Most app servers do
> not support 1.5 at this time, and yet there are compile-time dependencies on
> 1.5/5.0 that I have to fix by hand each time I want to do a rebuild. The
> biggest one is the reference to "Collections.emptySet()" (as opposed to "
> Collections.EMPTY_SET"). I don't know any way around this other than to make
> the change myself.
>
> 2. If you've built older versions of tapestry, you can and will run into
> problems. Tapestry builds everything into your temp directory, which under
> windows is usually not easily accessible (c:/documents and settings/user
> name/local settings/temp). Values cached there from building an earlier beta
> were causing compile errors. Shouldn't tapestry, like most other OS
> libraries, build to a temp directory local to the source path, which can
> then safely be completely cleaned before each build? I don't like files
> being output to a somewhat hidden directory on my computer and left there to
> rot after a build.
>
> If there's a way around these issues, it's not immediately apparent, despite
> much perusing of the mail list and the wiki. I feel that build issues are
> one of the first things that will turn off prospective users from the
> library. If most people can't run a build (especially on a JDK version that
> most people will be forced to use), then they will quickly turn away and
> find another framework that does have an easy, consistent, and clean build
> process.
>
> Maybe this is just a hole in the documentation? I hope so because for each
> new release, I'm forced to rebuild both hivemind and tapestry due to 2
> errors that have been mentioned on the list frequently in the past but never
> actually addressed (jndi lookup problems with oc4j and the fact that you
> can't easily make table column headers align to the left without editing the
> html in the contrib library).
>
> Drew
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org