[
https://issues.apache.org/jira/browse/LABS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Gianni updated LABS-201:
-------------------------------
Fix Version/s: (was: Future)
Current
When it comes to multiple jars there are two problems :
- Duplicate classes
- Duplicate resource files
- Other bytecode manipulations, like JPA or JDO
Duplicate classes could exist because many projects decide to carry in their
own jar some of their dependencies. For example, there are quite a few packages
out there containing javax.servlet.Servlet and the like. There is no real
solution to this problem, cause the class loader will load one of these classes
mostly randomly. Anyway, in a normally working system, using one or the other
of these duplicate classes should be the same.
Duplicate resource files are instead by far more important, cause they will be
different files, probably all of them will be loaded and them merged. So they
must be available to the classloader.
The best solution is obviously to unpack every single jar, weave it with all
possible aspects, and then repack the jar, eventually renaming it with
"-weaved". This solution solves both the problems : duplicate classes are there
as they were (but weaved), while resource files are there unmodified.
However, I'm afraid that this pack-weave-unpack will take a lot of time, so I'm
thinking of an alternative solution, which if fast enough could also work in
development as an alternative to LTW to achieve RAD.
In fact, LTW currently does not support class replace at runtime, while if the
classes were weaved in a simple and quick pass outside the JVM without LTW in
place, it could be possible to replace them.
Moreover, AspectJ currently supports progressive builds, which combined with
afore mentioned simple method, could lead to RAD on classes and not only on
resource files.
The simplicistic solution could be to unpack all classes in single folder, and
weave it. Since duplicate classes should be identical, this should not create a
problem from a classes POV, but it will from a resources POV. In this case,
classloading priority could come handy, cause the "classes" folder could have a
higher priority than the jars, causing the jars to be used as a fallback for
missing items, in this case resource files.
With this system, the user could change a .java file or an aspect, an agent (at
a certain timeout, on request, whatever) would recompile using the incremental
build on the giant class folder, Jetty could reload the classes or the agent
could push the new classes to the running jvm, leading to a quite nice RAD.
Moreover, such a system (classes folder + jar file) would work also once packed
in WAR, even if it would be a quite dirty solution.
> Full build system
> -----------------
>
> Key: LABS-201
> URL: https://issues.apache.org/jira/browse/LABS-201
> Project: Labs
> Issue Type: New Feature
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Current
>
>
> Currently Magma runs in a LTW environment, which is good for development. The
> final build system should create a complete WAR, performing all the necessary
> weaving optimized.
> This task is not simple as it may seem, because each jar to be included in
> the WAR have to be passed thru the weaver, and then repackaged to form the
> weaved version, avoiding to place duplicated classes (coming from different
> jars) in the same output jar.
> It needs to be investigated wether playing with current AspectJ configuration
> (inpath, aspectpath, classpath, outjar) and iterating over every jar could be
> enough, or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
