You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Sandro Martini <sa...@gmail.com> on 2011/09/07 19:02:58 UTC
Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Hi all,
what do you think if for the 2.1 release I'd move all classes that has SVG
Salamander as dependency (should be only Drawing, Image,
SVGDiagramSerializer classes all inside Wtk, simply search for
"com.kitfox.svg" for example) inside a dedicated wtk-svg subproject (or
wtk-svgsalamander or something similar) ?
The idea is to keep it inside Pivot core workspace, but moving dependency on
SVG Salamander in this new (small) project (with its jar), so anyone not
using SVG features won't have a dependency on SVG Salamander.
Of course I don't want to drop/make second citizen this interesting part of
Pivot, but only to make some cleanup in dependencies of a big part of wtk
... for example this gave me some problems with Maven, in my applications
where I'm not using SVG features.
What do you think ?
If wanted tomorrow I could create a JIRA ticket for it.
I know that I'll have to change (another time) our build file.
And this time maybe I could re-introduce even the Tools subproject
(currently empty) ... could be useful to contain some utility for Pivot.
Comments ?
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3317312.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
> So there's no need to use a service provider - the JVM already takes care of that.
Actually, the class loader handles this, not the JVM. But either way, it isn't something that we need to worry about.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
> Note that there is no build-time dependency on SVG Salamander for projects - only for the platform.
By the way, by "projects", I assumed you meant "applications". Let me know if that is not correct.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
>> Ah, OK. I have considered a similar extensibility mechanism in the past, using a static map of file extension to Serializer<Image> that the Image class would use to determine how to load a given image URL. But maybe a service provider would work better.
>
> Does that mean you would reconsider your '-1'? :)
Not as originally proposed, no. :-) But if it were implemented as an extensibility mechanism, yes.
> I think a service provider is a good fit in this case and would remove
> the build time dependency on the SVG jar from projects that don't care
> about SVGs.
Note that there is no build-time dependency on SVG Salamander for projects - only for the platform.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Chris Bartlett <cb...@gmail.com>.
On 8 September 2011 22:12, Greg Brown <gk...@verizon.net> wrote:
> Ah, OK. I have considered a similar extensibility mechanism in the past, using a static map of file extension to Serializer<Image> that the Image class would use to determine how to load a given image URL. But maybe a service provider would work better.
Does that mean you would reconsider your '-1'? :)
I think a service provider is a good fit in this case and would remove
the build time dependency on the SVG jar from projects that don't care
about SVGs.
Image could search for a provider for the supplied file extension, use
it if found, and default to Pivot's in built support for certain
types. I don't see a need to wrap existing support (via
BufferedImageSerializer?) in one or more providers. Any file
extensions that are supported internally by Pivot/JRE could be
overridden by users if they create and use their own provider.
> On Sep 8, 2011, at 10:59 AM, Chris Bartlett wrote:
>
>> On 8 September 2011 21:36, Greg Brown <gk...@verizon.net> wrote:
>>>> I have only scanned this thread quickly and haven't examined the code,
>>>> but couldn't the SVG stuff be moved into a separate JAR as Sandro
>>>> suggested, after modifying the relevant
>>>> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via
>>>> Pivot/Java service loaders?
>>>
>>> The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), which isn't included with the distribution. The only Pivot class that has a dependency on it is Drawing, but if an app doesn't use the Drawing class, then the SVG Salamander classes aren't loaded. So there's no need to use a service provider - the JVM already takes care of that.
>>
>> I just looked at the source of the Drawing class and see that it is
>> *ONLY* used for SVGs. The name suggested a much more generic class.
>> Drawing has a dependency on the SVG classes, and then Image references
>> it, and Image is referenced in a lot of places.
>>
>> I meant using a service loader to find a service (Image implementation
>> provider) that could handle SVGs and return an Image.
>> org.apache.pivot.wtk.media.Image.LoadTask.execute() currently
>> instantiates a new Drawing if the extension is 'svg'.
>> That extension could be the basis of a service lookup, which would
>> find the service that might use Drawing (or any other SVG 'provider').
>> i.e. Don't hard code a reference to the Drawing class into Image.
>>
>> Support for additional Image formats could easily be added by dropping
>> more 'image provider services' jars into the classpath.
>
>
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
thank you very much !!
If you have time, you could do both: add a folder for the project
under pivot-stuff (media, or pivot-svg, or other), and a patch (opt
inside a zip) in the ticket here (
https://issues.apache.org/jira/browse/PIVOT-793 ) ...
So now let's see what others say.
We still are closing the 2.0.1 so some weeks could be needed before
exploring it deeply, but I think it's another good thing to have in
2.1 .
Let's update.
Bye
Re: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
Posted by DreamTangerine <dr...@hotmail.com>.
I have a prototype of it.
I created a new project called media with the svg stuff.
How do I send ?
Maybe I can create a folder in
http://code.google.com/a/apache-extras.org/p/pivot-stuff/
and send the patch of org.apache.pivot.wtk.media package.
On jue, 2011-09-08 at 12:40 -0500, DreamTangerine wrote:
> I agree with you. I think a ServiceLoader is a good idea.
> If you need some help maybe I can help you.
>
> On jue, 2011-09-08 at 22:32 +0700, Chris Bartlett wrote:
> > I think I have a couple of hours 'free' today. I will try to take a
> > quick look at it, but can't promise anything.
> >
> > On 8 September 2011 22:16, Sandro Martini <sa...@gmail.com> wrote:
> > > Hi all,
> > > the related ticket is this:
> > > https://issues.apache.org/jira/browse/PIVOT-793
> > >
> > > I marked it as "Won't Fix" (see previous discussions here), but after last
> > > comments from Greg could be useful to reopen (and maybe reassign to Chris)
> > > ... what do you think ?
> > >
> > > Bye
> > >
> > >
> > > --
> > > View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3320086.html
> > > Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
> > >
> >
>
>
>
Re: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
Posted by DreamTangerine <dr...@hotmail.com>.
I agree with you. I think a ServiceLoader is a good idea.
If you need some help maybe I can help you.
On jue, 2011-09-08 at 22:32 +0700, Chris Bartlett wrote:
> I think I have a couple of hours 'free' today. I will try to take a
> quick look at it, but can't promise anything.
>
> On 8 September 2011 22:16, Sandro Martini <sa...@gmail.com> wrote:
> > Hi all,
> > the related ticket is this:
> > https://issues.apache.org/jira/browse/PIVOT-793
> >
> > I marked it as "Won't Fix" (see previous discussions here), but after last
> > comments from Greg could be useful to reopen (and maybe reassign to Chris)
> > ... what do you think ?
> >
> > Bye
> >
> >
> > --
> > View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3320086.html
> > Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
> >
>
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Chris Bartlett <cb...@gmail.com>.
I think I have a couple of hours 'free' today. I will try to take a
quick look at it, but can't promise anything.
On 8 September 2011 22:16, Sandro Martini <sa...@gmail.com> wrote:
> Hi all,
> the related ticket is this:
> https://issues.apache.org/jira/browse/PIVOT-793
>
> I marked it as "Won't Fix" (see previous discussions here), but after last
> comments from Greg could be useful to reopen (and maybe reassign to Chris)
> ... what do you think ?
>
> Bye
>
>
> --
> View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3320086.html
> Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
>
Re: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
the related ticket is this:
https://issues.apache.org/jira/browse/PIVOT-793
I marked it as "Won't Fix" (see previous discussions here), but after last
comments from Greg could be useful to reopen (and maybe reassign to Chris)
... what do you think ?
Bye
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3320086.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
Ah, OK. I have considered a similar extensibility mechanism in the past, using a static map of file extension to Serializer<Image> that the Image class would use to determine how to load a given image URL. But maybe a service provider would work better.
On Sep 8, 2011, at 10:59 AM, Chris Bartlett wrote:
> On 8 September 2011 21:36, Greg Brown <gk...@verizon.net> wrote:
>>> I have only scanned this thread quickly and haven't examined the code,
>>> but couldn't the SVG stuff be moved into a separate JAR as Sandro
>>> suggested, after modifying the relevant
>>> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via
>>> Pivot/Java service loaders?
>>
>> The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), which isn't included with the distribution. The only Pivot class that has a dependency on it is Drawing, but if an app doesn't use the Drawing class, then the SVG Salamander classes aren't loaded. So there's no need to use a service provider - the JVM already takes care of that.
>
> I just looked at the source of the Drawing class and see that it is
> *ONLY* used for SVGs. The name suggested a much more generic class.
> Drawing has a dependency on the SVG classes, and then Image references
> it, and Image is referenced in a lot of places.
>
> I meant using a service loader to find a service (Image implementation
> provider) that could handle SVGs and return an Image.
> org.apache.pivot.wtk.media.Image.LoadTask.execute() currently
> instantiates a new Drawing if the extension is 'svg'.
> That extension could be the basis of a service lookup, which would
> find the service that might use Drawing (or any other SVG 'provider').
> i.e. Don't hard code a reference to the Drawing class into Image.
>
> Support for additional Image formats could easily be added by dropping
> more 'image provider services' jars into the classpath.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Chris Bartlett <cb...@gmail.com>.
On 8 September 2011 21:36, Greg Brown <gk...@verizon.net> wrote:
>> I have only scanned this thread quickly and haven't examined the code,
>> but couldn't the SVG stuff be moved into a separate JAR as Sandro
>> suggested, after modifying the relevant
>> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via
>> Pivot/Java service loaders?
>
> The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), which isn't included with the distribution. The only Pivot class that has a dependency on it is Drawing, but if an app doesn't use the Drawing class, then the SVG Salamander classes aren't loaded. So there's no need to use a service provider - the JVM already takes care of that.
I just looked at the source of the Drawing class and see that it is
*ONLY* used for SVGs. The name suggested a much more generic class.
Drawing has a dependency on the SVG classes, and then Image references
it, and Image is referenced in a lot of places.
I meant using a service loader to find a service (Image implementation
provider) that could handle SVGs and return an Image.
org.apache.pivot.wtk.media.Image.LoadTask.execute() currently
instantiates a new Drawing if the extension is 'svg'.
That extension could be the basis of a service lookup, which would
find the service that might use Drawing (or any other SVG 'provider').
i.e. Don't hard code a reference to the Drawing class into Image.
Support for additional Image formats could easily be added by dropping
more 'image provider services' jars into the classpath.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
> I have only scanned this thread quickly and haven't examined the code,
> but couldn't the SVG stuff be moved into a separate JAR as Sandro
> suggested, after modifying the relevant
> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via
> Pivot/Java service loaders?
The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), which isn't included with the distribution. The only Pivot class that has a dependency on it is Drawing, but if an app doesn't use the Drawing class, then the SVG Salamander classes aren't loaded. So there's no need to use a service provider - the JVM already takes care of that.
G
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Chris Bartlett <cb...@gmail.com>.
On 8 September 2011 21:10, Greg Brown <gk...@verizon.net> wrote:
> Again, I don't personally see any value in doing this. There is no issue in having a dependency on the SVG JARs, either from a licensing or deployment perspective, and you'd only be saving a single class (Drawing) in the WTK JAR. You'd need to add it to another JAR, which will probably *increase* download size slightly. Finally, as I mentioned, you'll lose the ability to specify SVG files in markup:
>
> <ImageView image="@foo.svg"/>
>
> So this gets a big -1 from me.
I have only scanned this thread quickly and haven't examined the code,
but couldn't the SVG stuff be moved into a separate JAR as Sandro
suggested, after modifying the relevant
BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via
Pivot/Java service loaders?
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
Again, I don't personally see any value in doing this. There is no issue in having a dependency on the SVG JARs, either from a licensing or deployment perspective, and you'd only be saving a single class (Drawing) in the WTK JAR. You'd need to add it to another JAR, which will probably *increase* download size slightly. Finally, as I mentioned, you'll lose the ability to specify SVG files in markup:
<ImageView image="@foo.svg"/>
So this gets a big -1 from me.
On Sep 8, 2011, at 10:02 AM, Sandro Martini wrote:
> Hi Greg,
>
>> Image is the base class for Picture and some other internal image classes
> as well. Moving it outside of WTK would basically eliminate all graphic
> support in the platform. Probably not a good idea.
> Yes for sure it will not be a good idea :-) .
> So I'll try to strip out only the svg part from it, and move in another
> class (if possible that extends ImageView).
>
>> My mistake - should have been "@foo.svg".
> Don't worry ...
>
> So if there aren't other objections I could try to prototype something (for
> the 2.1), and commit only new classes (in new subproject) before making any
> change (deleting/removing some code) in old ones ...
>
> I'll create a JIRA ticket targeted to 2.1, just for reference.
>
> Bye,
> Sandro
>
>
> --
> View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3319811.html
> Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
>Image is the base class for Picture and some other internal image classes
as well. Moving it outside of WTK would basically eliminate all graphic
support in the platform. Probably not a good idea.
Yes for sure it will not be a good idea :-) .
So I'll try to strip out only the svg part from it, and move in another
class (if possible that extends ImageView).
>My mistake - should have been "@foo.svg".
Don't worry ...
So if there aren't other objections I could try to prototype something (for
the 2.1), and commit only new classes (in new subproject) before making any
change (deleting/removing some code) in old ones ...
I'll create a JIRA ticket targeted to 2.1, just for reference.
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3319811.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
>> Well, you'd basically be talking about moving just the Drawing class into
>> its own JAR, which doesn't seem worth it.
> Classes to more would be: Drawing, Image, SVGDiagramSerializer classes all
> inside Wtk.
Image is the base class for Picture and some other internal image classes as well. Moving it outside of WTK would basically eliminate all graphic support in the platform. Probably not a good idea.
>> You'd also need to remove the support in the Image class for loading
>> Drawings, so you'd no longer be able to do this: <ImageView
>> image="@foo.png"/>
> Excuse me (you know that I know little on many Pivot components), why png ?
My mistake - should have been "@foo.svg".
Re: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
@Greg:
>Well, you'd basically be talking about moving just the Drawing class into
its own JAR, which doesn't seem worth it.
Classes to more would be: Drawing, Image, SVGDiagramSerializer classes all
inside Wtk.
Of course Image could be splitted in one without SVG support, and another
extending it (if possible) in the new project with SVG support. I think that
removing such dependency from core Wtk would be useful, but I agree that it
requires some effort, but I'm ready to do it :-) .
>You'd also need to remove the support in the Image class for loading
Drawings, so you'd no longer be able to do this: <ImageView
image="@foo.png"/>
Excuse me (you know that I know little on many Pivot components), why png ?
Or I could have (moved) class names equals to original ones (but with a
little different package if it's not a problem).
@Andrei:
I just reassigned to me the ticket for the mavenization of Pivot, but
assigned to 3.0 because probably we have to wait for good time for do it :-)
.
>1) FWIW, I am building kitfox as a separate dependency:
Yes, this is another small problem that could be removed moving classes as I
proposed.
>2) if you really get to making changes to your names, I suggest you make
pivot module names consistent:
Yes, and I'd like to do this even for the 2.1 release and it will be visible
only to developers downloading Pivot sources from the trunk.
>pivot jar names should match mvn module names should match mvn artifact
names should match osgi bundle names
Yes, I agree.
So, objections to moving classes for the 2.1 ?
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3319677.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Andrei Pozolotin <an...@gmail.com>.
may be its time to replace ant with mvn? :-)
https://issues.apache.org/jira/browse/PIVOT-712
1) FWIW, I am building kitfox as a separate dependency:
https://github.com/carrot-garden/carrot-kitfox-svg
2) if you really get to making changes to your names, I suggest you make
pivot module names consistent:
https://github.com/carrot-garden/carrot-pivot
<module>pivot-core</module>
<module>pivot-core-web</module>
<module>pivot-core-web-server</module>
<module>pivot-wtk</module>
<module>pivot-wtk-skin-terra</module>
<module>pivot-wtk-charts</module>
<module>pivot-demos</module>
<module>pivot-demos-server</module>
<module>pivot-examples</module>
<module>pivot-tutorials</module>
<module>pivot-tutorials-server</module>
pivot jar names should match mvn module names should match mvn artifact
names should match osgi bundle names
-------- Original Message --------
Subject: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
From: Sandro Martini <sa...@gmail.com>
To: dev@pivot.apache.org
Date: Wed 07 Sep 2011 12:02:58 PM CDT
> Hi all,
> what do you think if for the 2.1 release I'd move all classes that has SVG
> Salamander as dependency (should be only Drawing, Image,
> SVGDiagramSerializer classes all inside Wtk, simply search for
> "com.kitfox.svg" for example) inside a dedicated wtk-svg subproject (or
> wtk-svgsalamander or something similar) ?
>
> The idea is to keep it inside Pivot core workspace, but moving dependency on
> SVG Salamander in this new (small) project (with its jar), so anyone not
> using SVG features won't have a dependency on SVG Salamander.
>
> Of course I don't want to drop/make second citizen this interesting part of
> Pivot, but only to make some cleanup in dependencies of a big part of wtk
> ... for example this gave me some problems with Maven, in my applications
> where I'm not using SVG features.
>
> What do you think ?
> If wanted tomorrow I could create a JIRA ticket for it.
>
>
> I know that I'll have to change (another time) our build file.
> And this time maybe I could re-introduce even the Tools subproject
> (currently empty) ... could be useful to contain some utility for Pivot.
> Comments ?
>
>
> Bye,
> Sandro
>
>
> --
> View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3317312.html
> Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
>
>
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
Well, you'd basically be talking about moving just the Drawing class into its own JAR, which doesn't seem worth it. You'd also need to remove the support in the Image class for loading Drawings, so you'd no longer be able to do this:
<ImageView image="@foo.png"/>
On Sep 7, 2011, at 1:13 PM, Sandro Martini wrote:
>>> The idea is to keep it inside Pivot core workspace, but moving dependency
> on SVG Salamander in this new (small) project (with its jar), so anyone not
> using SVG features won't have a dependency on SVG Salamander.
>>
>> You don't need to do this. If an app does not refer to the Drawing class,
> it won't attempt to load the SVG Salamander libraries.
> Yes, I know, but the point here is if there aren't dependencies that (for
> whatever reason) I don't want ... but note that I'm not saying here that I
> don't want this part, but I think it's better to isolate in its own jar (so
> if I don't use these features I don't have to provide it and related
> dependencies).
>
> Comments ?
>
> Bye
>
>
> --
> View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3317340.html
> Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated
wtk-svg (or similar) subproject inside Pivot
Posted by Sandro Martini <sa...@gmail.com>.
>> The idea is to keep it inside Pivot core workspace, but moving dependency
on SVG Salamander in this new (small) project (with its jar), so anyone not
using SVG features won't have a dependency on SVG Salamander.
>
>You don't need to do this. If an app does not refer to the Drawing class,
it won't attempt to load the SVG Salamander libraries.
Yes, I know, but the point here is if there aren't dependencies that (for
whatever reason) I don't want ... but note that I'm not saying here that I
don't want this part, but I think it's better to isolate in its own jar (so
if I don't use these features I don't have to provide it and related
dependencies).
Comments ?
Bye
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Move-Wtk-classes-related-to-SVGSalamander-in-a-dedicated-wtk-svg-or-similar-subproject-inside-Pivot-tp3317312p3317340.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Move Wtk classes related to SVGSalamander in a dedicated wtk-svg
(or similar) subproject inside Pivot
Posted by Greg Brown <gk...@verizon.net>.
> The idea is to keep it inside Pivot core workspace, but moving dependency on
> SVG Salamander in this new (small) project (with its jar), so anyone not
> using SVG features won't have a dependency on SVG Salamander.
You don't need to do this. If an app does not refer to the Drawing class, it won't attempt to load the SVG Salamander libraries.