suuhas / as3-commons

Automatically exported from code.google.com/p/as3-commons
0 stars 0 forks source link

Please move org.as3commons.logging.integration package to its own .swc #66

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I love as3commons-logging and the other common libraries, but a recent 
"improvement" has been hugely disruptive to me...

When I switched from as3commons-logging version 1.1 to version 2.5.1, my build 
process was suddenly broken by dependencies against several third-party 
libraries (which am I not using and am not interested in) present in 
org.as3commons.logging.integration.

Bear with me...  I understand the .swf link process and I am aware that if I 
link as3commons-library-2.5.1.swc directly into my .swf, the linker won't 
complain if my .swf doesn't actually depend on 
org.as3commons.logging.integration (and therefore won't depend on the 
third-party libraries) and there will be no problem.

HOWEVER...

In my projects, I routinely create a "ThirdParty.swc" which *includes* all my 
3rd-party libraries via the "-include-libraries" compiler switch.  This way, 
all of my modules don't need to endlessly duplicate numerous dependencies -- 
they all simply depend on ThirdParty.swc.  I use this technique in all of my 
build files and IDE configurations, implementing a "single point of change" for 
managing dependencies.

Previously, this approach worked wonderfully across the board with all of 
as3commons (since none of the libraries had any "invisible" external 
dependencies), but has been broken with the more-recent as3commons-logging and 
the "clever" dependencies in org.as3commons.logging.integration.

So, could you *please* consider moving the org.as3commons.logging.integration 
package to its own .swc so that its dependencies can be more explicitly 
controlled in build files and IDEs configurations?  Not everyone uses your 
libraries in the ways you might imagine.  I'm sure there must be others using 
the "common" .swc technique like me.

Thanks.

Original issue reported on code.google.com by m...@amphiox.com on 3 Aug 2011 at 10:45

GoogleCodeExporter commented 9 years ago
There are two reasons for why I included the dependencies in the libraries:

 1) I didn't want to make it difficult for people: 2 download links are bit much, I would prefer 1 (dropping nightly) rather than 4 links. Which we would have if add the additional integration .swcs into 2 files.

 2) Maven is a pain in the ass (at least for flash): And I just didn't/don't have the time/nerve to put another week into working this detail out.

Anyway: If you use the src (rather than the swc) to compile your swc you can 
describe what parts of the source you like and what part not.

Original comment by mastakan...@gmail.com on 4 Aug 2011 at 3:08

GoogleCodeExporter commented 9 years ago
Thanks for the reply.

Re: #1.  Hmm, I don't buy the "extra .swcs care hard" case..  you already 
provide a separate as3commons-logging-2.legacy.swc (thanks for the that, btw, 
the newer "array" calling convention is not worth the awkward usage, IMO).  
And, anyone using as3commons is already used to mixing-and-matching multiple 
.swcs to get the functionality they want.  And, sure, I know I can build the 
as3commons-logging-2.5.1.swc myself (without the .integration package), but 
custom building the source is the "difficult" option for people.  Just grabbing 
an extra .swc or two is easy.

Re: #2.  This sounds like the real reason. :)  I understand simply not having 
time.  If you eventually get time, it would still be great if you could 
consider better isolating the integration stuff.  I'm sure for many people, it 
is a corner case that should be an "extra".

Thanks for all your efforts.

Original comment by idontneedthisacct@gmail.com on 5 Aug 2011 at 7:47

GoogleCodeExporter commented 9 years ago
#1: Don't buy? Well its my intention, seems like I didn't fulfill it. I see 
as3commons-logging 100% separated from the rest of the libraries and can be 
used just by itself. That way one just needs one library. About the legacy.swc: 
We had long discussions about whether or not to go with the new syntax. Its a 
fact that the new syntax is a lot faster than the old one (for regular function 
calls) and will allow in future different uses. (like passing a object and 
referring to the properties of this object. 

#2: A lot of other things need to be done before I bother with maven again, but 
its on my list.

yours
Martin.

Original comment by mastakan...@gmail.com on 6 Aug 2011 at 3:38

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
On the other hand: I just understood that it is a pretty important problem, 
given that libraries are not possible to be compiled to a swc this way to one 
package. That gives that whole issue a new importance. I will prioritize this 
now!

http://stackoverflow.com/questions/7291163/exclude-a-file-from-compilation-in-ec
lipse-flash-builder

Original comment by mastakan...@gmail.com on 12 Sep 2011 at 5:26