small patch to build.xml

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

small patch to build.xml

Holger
Hi,

here is a patch, that fixes two very minor things:

- "swinglabs" target was missing in the "compileall" target
- JEventListPanelTest was failing because of an incomplete classpath

Is there a specific reason, why the japex jars are not handled and
downloaded like the other extensions?

Keep on glazing,
Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

build.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

Jesse Wilson
Yo Holger you rule!

This patch was great, simple, it works, it's in.

> Is there a specific reason, why the japex jars are not handled and
> downloaded like the other extensions?

Not really, Japex is kinda like Ant in that you need a
JAPEX_HOME for it to do its magic. It's not a traditional
extension since we don't export any of the performance
test code in any of our jars!

But - if you feel you can make the situation better, please
do, it's only that way for a lack of trying anything else.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

James Lemieux
I'd support the build at least downloading the Japex jars to the proper location, and a small tweak to the build.xml file to check for the instance of a JAPEX_HOME environment variable. Hell I don't even have the japex test cases running on my box, and it's mostly out of laziness over configuration. Spend 10 mintues and make it easy for all of us! (even if we don't export anything out of that area)

James

On 7/15/06, Jesse Wilson <[hidden email]> wrote:
Yo Holger you rule!

This patch was great, simple, it works, it's in.

> Is there a specific reason, why the japex jars are not handled and
> downloaded like the other extensions?

Not really, Japex is kinda like Ant in that you need a
JAPEX_HOME for it to do its magic. It's not a traditional
extension since we don't export any of the performance
test code in any of our jars!

But - if you feel you can make the situation better, please
do, it's only that way for a lack of trying anything else.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

Holger
In reply to this post by Holger
Hi,

I just experimented a bit with Japex.
To run the current Glazedlists Japex tests without the JAPEX_HOME variable I did

- copy the jars from the japex lib directory to glazedlists/extensions/japex/lib
- replace classpath references to JAPEX_HOME/lib with extensions/japex/lib in build.xml
- remove classpath references to JAPEX_HOME/jdsl in build.xml and the *config.xml files,
  because JDSL jars aren't used currently
- run ant japex and enjoy ...

So, if you would upload the japex jars to glazedlists/lib/japex on java.net, I could adapt
the build file to download the jars to extensions/japex/lib.

What do you think?

Holger

> -----Ursprüngliche Nachricht-----
> Von: [hidden email]
> Gesendet: 15.07.06 20:52:46
> An: [hidden email]
> Betreff: Re: small patch to build.xml

I'd support the build at least downloading the Japex jars to the proper location, and a small tweak to the build.xml file to check for the instance of a JAPEX_HOME environment variable. Hell I don't even have the japex test cases running on my box, and it's mostly out of laziness over configuration. Spend 10 mintues and make it easy for all of us! (even if we don't export anything out of that area)

>
>
> James
>
>
> On 7/15/06, Jesse Wilson <[hidden email]> wrote:
> Yo Holger you rule!
>
> This patch was great, simple, it works, it's in.
>
> > Is there a specific reason, why the japex jars are not handled and
> > downloaded like the other extensions?
>
> Not really, Japex is kinda like Ant in that you need a
>
> JAPEX_HOME for it to do its magic. It's not a traditional
> extension since we don't export any of the performance
> test code in any of our jars!
>
> But - if you feel you can make the situation better, please
> do, it's only that way for a lack of trying anything else.
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

James Lemieux
Holger,

   This looks great. Jesse will probably combine all of the twelve (12!!!) jars in the japex\lib directory into one uber-jar that is, hopefully, our "minimal required set of classes." Then he'll upload that to glazedlists.dev.java.net so you can make our build download and use it.

    Regarding our main build and Maven 2. Neither Jesse or myself have any experience with Maven, but from what I read, it seems to be structured in a way that might make it incompatible with one of our goals.

    Glazed List extensions are like little independent bridges that link Glazed Lists with other projects, like JFreeChart, SwingLabs, etc. We want to preserve the ability to have a user do something like:

ant clean compile swt

    and have that command line produce a \classes directory that includes ONLY WHAT THEY HAVE ASKED FOR (namely, the Glazed Lists core, plus the SWT extension). In this way, they can pick and choose exactly what they need in a "configurable build" of sorts. Any combination of extensions should produce a "minimal build" that excludes unnamed extensions.

    But, we also recognize that other Maven 2 users want the magic Maven dependency stuff to work. So, I like your idea of creating an ANT target that "produces maven-compatible output and/or uploads it to the maven repository" the most.

    If I'm wrong in assuming that Maven "isn't really made for producing configurable builds", then let me know what is involved, and we might still be able to switch over to maven with some massive reshuffling.

James

On 7/15/06, Holger Brands <[hidden email]> wrote:
Hi,

I just experimented a bit with Japex.
To run the current Glazedlists Japex tests without the JAPEX_HOME variable I did

- copy the jars from the japex lib directory to glazedlists/extensions/japex/lib
- replace classpath references to JAPEX_HOME/lib with extensions/japex/lib in build.xml
- remove classpath references to JAPEX_HOME/jdsl in build.xml and the *config.xml files,
  because JDSL jars aren't used currently
- run ant japex and enjoy ...

So, if you would upload the japex jars to glazedlists/lib/japex on java.net, I could adapt
the build file to download the jars to extensions/japex/lib.

What do you think?

Holger

> -----Ursprüngliche Nachricht-----
> Von: [hidden email]
> Gesendet: 15.07.06 20:52:46
> An: [hidden email]
> Betreff: Re: small patch to build.xml

I'd support the build at least downloading the Japex jars to the proper location, and a small tweak to the build.xml file to check for the instance of a JAPEX_HOME environment variable. Hell I don't even have the japex test cases running on my box, and it's mostly out of laziness over configuration. Spend 10 mintues and make it easy for all of us! (even if we don't export anything out of that area)

>
>
> James
>
>
> On 7/15/06, Jesse Wilson <[hidden email]> wrote:
> Yo Holger you rule!
>
> This patch was great, simple, it works, it's in.
>
> > Is there a specific reason, why the japex jars are not handled and
> > downloaded like the other extensions?
>
> Not really, Japex is kinda like Ant in that you need a
>
> JAPEX_HOME for it to do its magic. It's not a traditional

> extension since we don't export any of the performance
> test code in any of our jars!
>
> But - if you feel you can make the situation better, please
> do, it's only that way for a lack of trying anything else.
>
> Cheers,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

Charlie Groves
>     Glazed List extensions are like little independent bridges that link
> Glazed Lists with other projects, like JFreeChart, SwingLabs, etc. We want
> to preserve the ability to have a user do something like:
>
>  ant clean compile swt
>
>     and have that command line produce a \classes directory that includes
> ONLY WHAT THEY HAVE ASKED FOR (namely, the Glazed Lists core, plus the SWT
> extension). In this way, they can pick and choose exactly what they need in
> a "configurable build" of sorts. Any combination of extensions should
> produce a "minimal build" that excludes unnamed extensions.

I think this would be fairly easy to do in maven 2 if you're willing
to accept the reshuffling.  You'd just create a super glazedlists
project with subprojects for glazedlists-core and one for each of the
extensions.  Then you'd add a profile to the parent for each unique
build that you want.  It'd produce a jar per extension but that seems
better to me than having various copies of glazed lists jars with
different classes in them.

On the other hand, we've been moving our stuff at work from Maven 1 to
2 so I'm waist deep in it right now(I won't go further into what "it"
is so as to protect the sensibilities of the more delicate
dev@glazedlists subscribers).  It seems like you have most of what you
want from your ant build so the headaches of learning maven and all of
its little rough edges probably aren't worth it.  You should be able
to handle "produces maven compatible output" with the mvn
deploy:deploy-file goal.  It'll take existing jars and upload them
with a pom to a maven repository.  It's what I do with glazedlists and
my internal repository right now.  See
http://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html
You'd just have to handle that and ask the maven guys for access to
the central repository.

Charlie

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

Holger
In reply to this post by Holger
Hi,

> Holger,
>
>    This looks great. Jesse will probably combine all of the twelve (12!!!) jars in the japex\lib directory into one uber-jar that is, hopefully, our "minimal required set of classes." Then he'll upload that to glazedlists.dev.java.net so you can make our build download and use it.

Ok, I'll adapt the build file then.

>
>     Regarding our main build and Maven 2. Neither Jesse or myself have any experience with Maven, but from what I read, it seems to be structured in a way that might make it incompatible with one of our goals.
>
>
>     Glazed List extensions are like little independent bridges that link Glazed Lists with other projects, like JFreeChart, SwingLabs, etc. We want to preserve the ability to have a user do something like:
>
> ant clean compile swt
>
>     and have that command line produce a \classes directory that includes ONLY WHAT THEY HAVE ASKED FOR (namely, the Glazed Lists core, plus the SWT extension). In this way, they can pick and choose exactly what they need in a "configurable build" of sorts. Any combination of extensions should produce a "minimal build" that excludes unnamed extensions.

You're right that Maven does not support such configurable builds out-of-the-box.
Charlie already mentioned some ideas to tackle this in his answer mail.
I'll think about that issue, stay tuned ...

>
>
>     But, we also recognize that other Maven 2 users want the magic Maven dependency stuff to work. So, I like your idea of creating an ANT target that "produces maven-compatible output and/or uploads it to the maven repository" the most.

Great, I'll give it a try and come back to you ...

Holger

______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: small patch to build.xml

Holger
In reply to this post by Holger
James, Charlie,

thanks for your feedback.
See my comments inline.

> [...]
>
> I think this would be fairly easy to do in maven 2 if you're willing
> to accept the reshuffling.  You'd just create a super glazedlists
> project with subprojects for glazedlists-core and one for each of the
> extensions.  Then you'd add a profile to the parent for each unique
> build that you want.  It'd produce a jar per extension but that seems
> better to me than having various copies of glazed lists jars with
> different classes in them.

Looking at other projects, Spring for example, offer something like that:

- an all encompassing jar containing all classes
or
- a jar with the core classes + separate jars for the extensions

This makes sense for a big project like spring, but it could be overkill for
Glazed Lists?
It depends on how quickly the Glazed Lists extensions grow, so
I haven't come to a final opinion yet ...

> On the other hand, we've been moving our stuff at work from Maven 1 to
> 2 so I'm waist deep in it right now(I won't go further into what "it"
> is so as to protect the sensibilities of the more delicate
> dev@glazedlists subscribers).  

He he, I can tell a story about that, too ;-)
Some required maven 2 plugins are not production ready yet.
Integration between Eclipse and Maven 2 could be better, too.
I hope, Eclipse 3.2 is able to deal with hierachical project layouts now.

> You should be able
> to handle "produces maven compatible output" with the mvn
> deploy:deploy-file goal.  It'll take existing jars and upload them
> with a pom to a maven repository.  It's what I do with glazedlists and
> my internal repository right now.  See
> http://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html
> You'd just have to handle that and ask the maven guys for access to
> the central repository.

As far as I know, you're not allowed to deploy directly to the central maven repo
at ibiblio. According to http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
you have to create one or more upload bundles and file a JIRA issue with a
request to upload it.

The first step I'll take is to enhance the current ANT build to create such upload
bundles for Java 1.4 and 1.5 versions of Glazed Lists.
When that works, we've gained some time to think about further mavenization ...

Holger

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]