On 26 Aug 2015, at 17:05, Ian Maxon wrote:
Another interesting sidenote, from my explorations with trying to see
what's up with the YARN tests: if you have an unclean working
directory, and your tests or instance attempts recovery, it will fail
miserably because of the package change. A look in the log reveals
why:
INFO: The root directory of the local resource repository is
/tmp/storage/storage
org.apache.hyracks.api.exceptions.HyracksDataException:
java.lang.ClassNotFoundException:
>edu.uci.ics.hyracks.storage.common.file.LocalResource
at
>org.apache.asterix.transaction.management.resource.PersistentLocalResourceRepository.readLocalResource(PersistentLocalResourceRepository.jav>a:304)
at
org.apache.asterix.transaction.management.resource.PersistentLocalResourceRepository.initialize(PersistentLocalResourceRepository.java:168)
at
org.apache.asterix.hyracks.bootstrap.NCApplicationEntryPoint.start(NCApplicationEntryPoint.java:114)
at
org.apache.hyracks.control.nc.NodeControllerService.startApplication(NodeControllerService.java:318)
at
org.apache.hyracks.control.nc.NodeControllerService.start(NodeControllerService.java:255)
at org.apache.hyracks.control.nc.NCDriver.main(NCDriver.java:44)
Something we might want to keep in mind if we ever plan to change the
class path again :)
Maybe we also want to re-consider the use of Java Object Serialization
here :)
Cheers,
Till
On Wed, Aug 26, 2015 at 10:32 AM, Taewoo Kim <[email protected]>
wrote:
Thanks! Chris.
Best,
Taewoo
On Wed, Aug 26, 2015 at 1:31 PM, Chris "Ceej" Hillery
<[email protected]>
wrote:
Hah. I can see how that happened, since '.' in a regexp means "any
character". We should push a quick fix for that.
Ceej
On Aug 26, 2015 1:28 PM, "Taewoo Kim" <[email protected]> wrote:
@Steven: for that issue, change the pom.xml file in the
"asterix-runtime"
project. In the following plugin, change the line 52. Then it can
generate
the package again even when you recompile the whole build. Somehow,
"org.apache" was introduced in the path.
Before:
<outputDir>${project.build.directory}/generated-sources/
*org.apache*/asterix/runtime/operators/file/adm</outputDir>
After:
<outputDir>${project.build.directory}/generated-sources/
*org/apache*/asterix/runtime/operators/file/adm</outputDir>
<plugin>
<groupId>org.apache.asterix</groupId>
<artifactId>lexer-generator-maven-plugin</artifactId>
<version>0.8.7-SNAPSHOT</version>
<configuration>
<grammarFile>src/main/resources/adm.grammar</grammarFile>
<outputDir>${project.build.directory}/generated-sources/
*org/apache*/asterix/runtime/operators/file/adm</outputDir>
</configuration>
<executions>
<execution>
<id>generate-lexer</id>
<phase>generate-sources</phase>
<goals>
<goal>generate-lexer</goal>
</goals>
</execution>
</executions>
</plugin>
Best,
Taewoo
On Wed, Aug 26, 2015 at 10:49 AM, Steven Jacobs <[email protected]>
wrote:
This solution works for me, until I do another maven build in
terminal,
at
which point it breaks again.
Steven
On Wed, Aug 26, 2015 at 7:48 AM, Taewoo Kim <[email protected]>
wrote:
In addition to Ian's posting: I would like to share my
experience. I
have
updated the master branch and my branch and I saw this happening.
After
you
do two git merges (one - the path renaming, the other - the
package
rename), Eclipse might complain about the ADMLexer and
ADMDataParser
and
shows a lot of errors. In this case, you just need to manually
create a
new
package named "org.apache.asterix.runtime.operators.file.adm" in
the
"target/generated-sources" of the "asterix-runtime" project and
put
AdmLexer.java file and AdmLexerException.java file there. The two
files
are
located in the "org.apache/asterix/runtime/operators/file/adm"
directory
in
the "target/generated-sources" of the "asterix-runtime" project.
Best,
Taewoo
On Tue, Aug 25, 2015 at 9:31 AM, Ian Maxon <[email protected]>
wrote:
Hi all,
With the last few patches that have been submitted, integrating
them
back
into all of our open topic branches may be a little more complex
than
usual.
In the simplest case, if you have a change that doesn't add
.java
files
nor
edit import or package statements, 'git gerrit update' should
just
work
without complaint or conflict. If you do have changes of that
type,
'git
gerrit update' will still work, but you'll have to resolve the
rebase
conflict.
If you use merge typically instead of 'git gerrit update' or
rebase
to
pull
in new changes, you should take extra caution. Just a plain 'git
merge'
will most likely create many ugly conflicts when it attempts to
merge
both
the path renaming change, and the package renaming change, at
once.
The
work around for this is to merge them one at a time (e.g. in
asterix,
git
merge 34d8163 for the path renaming change, and git merge
f18bba26
for
the
package rename). In the first step you'll have to move any java
files
you
created with a folder under edu/uci/ics to org/apache, and in
the
second
resolve all the conflicts related to imports and package naming.
If
in
the
last step there are a lot of conflicts, sometimes it is easier
to
merge
while taking your local changes first, and then re-doing the
package
change
from edu.uci.ics to org.apache with sed on the affected files,
instead
of
trying to resolve them all one by one.
In short, you run into a really bad merge conflict, please
don't
hesitate
to ask for advice about it here. Hopefully the above advice is
helpful,
but
every situation is unique.
Thanks,
-Ian
